2

How can i generate a unique ID in VxWorks 6.8 that are unique within a closed net?

Each device in the net requires a associated ID, set once on startup and are kept until shutdown. They don't have to be random nor cryptographically secure - just unique within the closed net.

The available length is 6 Byte.

Restrictions:

  1. Devices may boot at once (or very close together) as well as separated in time
  2. Devices may vary in types / architectures (however, each supports whether dTSEC or eTSEC)
  3. Devices run with same (at least or similar) VxWorks 6.8 Kernel
  4. ID's cant be set manually or hard coded
  5. No 3rd Party libraries
  6. No network communication / negotiation

I've made some attempts for testing and development purposes using some kind of "random voodoo" (e.g. see code below); until now they worked without a collision but i'm not sure if they are unique enough to stay secure.

What i need is a real solution.

At the moment i use the nanosecond time of CLOCK_MONOTONIC and an id for each microcontroller architecture:

#ifdef ARCH_1
# define MC_ARCH_ID    0x01
#elif defined(ARCH_2)
# define MC_ARCH_ID    0x02
/* ... */
#else
# define MC_ARCH_ID    0x00
#endif /* MC_ARCH_ID */

/* ... */

char id[6];

struct timespec tspec;
clock_gettime(CLOCK_MONOTONIC, &tspec);

UINT32 t = htonl(tspec.tv_nsec); /* consistent endian */

id[0] = MC_ARCH_ID; /* 1 Byte ID set for each arch. */
id[1] = (UINT8) ((UINT8*) &t)[0];
id[2] = (UINT8) ((UINT8*) &t)[1];
id[3] = (UINT8) ((UINT8*) &t)[2];
id[4] = (UINT8) ((UINT8*) &t)[3];
id[5] = 0x00; /* Not used yet */

(Hopefully) the monotonic nanoseconds are different everywhere in the net (remember: those ID's are set once at startup) - hence the ID is "unique". But as the "hopefully" indicates: there's a chance they are not. Time is not the best choice here.

As a better and more secure solution i considered the usage of the MAC-address. Unfortunately 

char mac[6];
muxIoctl(muxCookie, EIOCGADDR, mac);

returns just garbage.

Community
  • 1
  • 1
ollo
  • 24,797
  • 14
  • 106
  • 155
  • 2
    If the MAC address is better and more secure, you should look into why `muxIoctl` is returning garbage. Does `ifconfig` show a MAC address? If so, then perhaps you have the wrong `muxCookie`. Or try going through the network stack's API or directly to your ethernet driver. – indiv Aug 11 '14 at 20:06
  • Yes, `ifconfig` - if available - shows correct MAC. It's also used in transmitted packets. The cookie is correct; i used the one returned from `muxBind()`. Furthermore `muxDevAcquire()` and `endFindByName()` give same results and `muxShow()` / `muxDevExists()` are also ok. Getting the MAC seems a bit complicated on VxWorks 6.8. – ollo Aug 12 '14 at 16:42
  • Btw. if there's a better solution than using the MAC it's also ok. MAC is not mandatory. As long as the ID's are more unique than implementation above. I was hoping there's a ready-to-use solution yet. However, i guess i'll open a new question for the MAC problem since it's a separate topic. – ollo Aug 12 '14 at 16:44
  • 1
    Your question comes down to [finding entropy in an embedded system](http://security.stackexchange.com/questions/39512/), which is not necessarily an easy thing to do. The MAC address is equivalent to injecting entropy in the factory, which is why it is the ideal solution. If your hardware has a TRNG, that's another good solution because your device can generate its own entropy. What you're doing now is relying on the non-determinism of the system to provide entropy, which is OK but you might find the amount of entropy is really small and might not suffice for a UUID. – indiv Aug 12 '14 at 17:03
  • Thanks for the comment (and the link). MAC address would be unique enough, but at the moment i have [problems getting it from VxWorks 6.8](https://stackoverflow.com/questions/25270816/getting-mac-address-on-vxworks-6-8). I've just checked some manuals of devices mostly used in the network, my first impression is they have some kind of TRNG (but i'll have to look more closely before). – ollo Aug 12 '14 at 17:57
  • @indiv Your comment was / is very helpful and a valid answer to my question. If you have some time, please post this as an answer so i can accept and upvote it. – ollo Aug 25 '14 at 14:12

0 Answers0