In a scenario where you control the provisioning of the hardware and can determine that all devices with the same hardware model do indeed have unique MAC addresses for their networking interfaces, are there any downsides to writing code that uses that assumption? (Note based on some replies: I am not going to write networking code using this assumption. It is just meant to be a low-touch way of having a uuid per device without having to manually generate and update the device HDD with an id before deploying to the field)

The backstory to this is I am researching implementing a private hardware IOT type implementation for a client. We will provision a set of hardware devices with networking capabilities to install in remote locations. These devices will then communicate back to an API by sending messages. In order to reduce the setup complexity, I was hoping to send the MAC address of the network interface on the device in the message, to tie these messages back to a "device_id" on the API side. My thought is that by making it something that doesn't have to be setup on the device before usage, it can just be queried during normal operation. I can safely assume that we can determine that the MAC addresses of each device are in fact unique, and we can control when/if the device is replaced to know that the messages for that device_id will now have a different MAC address.

  • 4
    Virtual devices have generated MAC addresses, which are unique only the local broadcast domain. There are other instances where a mac might collide with another - some devices let you update the mac in firmware. HA devices have a virtual mac in some cases. These are examples, they might not be relevant to your scenario. – Paul Oct 13 '17 at 3:03
  • 9
    People are greatly confused about the uniqueness of MAC addresses. What is unique about a MAC address is the OUI assigned to an organization. The individual addresses within the OUI are not guaranteed to be unique, and the IEEE says that the assignment of the addresses within the OUI is completely at the discretion of the owner of the OUI. – Ron Maupin Oct 13 '17 at 3:44
  • 2
    Also, it is very easy for an individual to modify the MAC address of a device. That means that MAC addresses can be cloned or assigned in a way that creates duplicates. An individual assigning a MAC address is supposed to set the U/L bit, but that rarely happens. – Ron Maupin Oct 13 '17 at 3:47
  • 5
    There are, there must be identical MAC addresses out in the wild. For example, Intel has registered 7 OUIs, each having 16.7 million addresses under their respective prefix That's a total of 116 million addresses. Heck, there's an Intel network card on almost every motherboard. Are you going to tell me there's fewer than 116 million computers in the world? No, of course not. But the logical consequence is: Of course MACs are not in any way unique. It's just that the likelihood of having two identical MACs on the same LAN is rather low, so that's not a problem. – Damon Oct 13 '17 at 12:24
  • 7
    I ended up with two identical MAC addresses in the same network by pure chance - It was hell to debug. – Christian Oct 13 '17 at 13:29

Based on your statements that you can confirm during provisioning that the manufacturer MAC is in fact unique within the network of devices you are creating (which is not in and of itself a certainty, even though it should be), you are probably fine proceeding, but consider the following questions:

  • Are you using the MAC for security checks (authentication, authorization)? If so, a MAC is not sufficient. Don't even consider it. Use a cryptographic structure, and transmit any auth requests securely.

  • Is 48 bits wide enough? It probably is, but worth asking.

  • Will you ever need to repair a device by replacing its nic?

  • If you do replace a device in its entirety, or replace its nic, will you need to be able to associate the new address to the existing key in your database in order to assure continuity of data collection for the deployment location?

  • Will there be any maintenance interface by which a user (authorized or not) might change the nic at the ROM, driver, or OS level? An attacker could introduce flaws in your data if they were to modify the MAC.

  • Will your data ever be joined with other datasources using MAC as a key?

  • Will you ever use the MAC for any networking purpose other than simply navigating the layer2 LAN the device is connected to (wired or wireless)?

  • Will the LAN your devices are connected to, be a private network, or one that large numbers of transient clients (like employees cellphones) will connect to?

If your answers are

NO, yes, no, no, no, no, no, private

then I can't think of any real flaw in your plan.

Keep in mind, you don't need globally unique MACs to pull this off; you just need to make sure that the subset of Internet devices that call your API are unique. Just like a duplicate nic assigned in two different cities can't collide because they are on different LANs, you can't have a database key collission on a MAC if it doesn't ever call your API.

| improve this answer | |
  • 2
    Just an aside, In the Mid-nineties, a sysadmin friend told me he had just received a box of Nics from a manufacturer that all had the same NIC. I have no idea how true that story is, but its about the only one of its kind I have heard, beyond general allegations that some manufacturers have "overused" their allocation at one time or another. – Frank Thomas Oct 13 '17 at 3:33
  • Thank you for the detailed answer. I think the only answer that doesnt match is #3. But if we have to fix a device with a broken nic we would probably replace the entire device. The client controls both the api and the hardware, and there will be physical controls in place to prevent unauthorized physical access to the devices. Also, I think it's important to note that a lot of the comments/points here are related to trying to using the MAC for networking purposes, which I understand can be problematic to assume is unique. This is purely for a uuid/device that doesnt require generating – Matt Phillips Oct 13 '17 at 4:07
  • cont: which i understand will be device/nic manufacturer specific. – Matt Phillips Oct 13 '17 at 4:08
  • 7
    @FrankThomas : It does happen. I've been to some computer conventions where a group of a few dozen mostly professionals had a few people say they've encountered this. Apparently big manufacturers' refurbishing departments have been particularly prone to do such. – TOOGAM Oct 13 '17 at 4:24
  • @FrankThomas just received a box of Nics ... all had the same NIC – Dmitry Kudriavtsev Oct 13 '17 at 16:08

MAC addresses are not unique

There can be, and will be duplicates with MACs. There are several reasons for that, one being that they need not be (globally) unique.

The MAC must be unique on the local network, so ARP/NDP can do its job, and the switch knows where to send incoming datagrams to. Usually (not necessarily) that precondition is fulfilled and things work just fine, simply because the likelihood of having two identical MACs on the same LAN, even if they are not unique, is quite low.

Another reason is that there simply exist more devices than there are addresses. While 48 bit addresses sounds like there's enough addresses for everybody until the end of days, that's not the case.

The address space is divided into two 24-bit halves (it's slightly more complicated, but let's ignore the petty details). One half is the OUI that you can register with the IEEE and assign to your company for around 2000 dollars. The remaining 24 bits, you do whatever you want. Of course you can register several OUIs, which is what the bigger players do.

Take Intel as an example. They have registered a total of 7 OUIs, giving them a total of 116 million addresses.
My computer's mainboard (which uses a X99 chipset) as well my laptop's mainboard as well as the mainboard of every x86 based computer that I have owned during the last 10-15 years had an Intel network card as part of the chipset. Certainly there's a lot more than 116 million Intel-based computers in the world. Thus, their MACs cannot possibly be unique (in a sense of globally unique).

Also, cases have been reported of uh... cheaper... manufacturers simply "stealing" addresses from someone else's OUI. In other words, they just used some random address. I've heard of manufacturers that just use the same address for a complete product range, too. Neither of that is really conforming or makes a lot of sense, but what can you do about it. These network cards exist. Again: The likelihood that it becomes a practical problem is still very low if addresses are used for what they're intended, you need to have two of them on the same LAN to even notice.

Now, what to do about your problem?

The solution is maybe simpler than you think. Your IoT devices will most probably need some notion of time, usually time is automatically obtained via NTP. The typical precision of NTP is in the microsecond range (yes, that's micro, not milli). I just ran ntpq -c rl to be sure and was told 2-20.

The likelihood of two of your devices being turned on for the first time at the precise same microsecond is very low. It's generally possible to happen (especially if you sell millions of them in a very short time, congratulations on your success!), sure. But it's not very likely -- in practice it will not happen. Thus, save the time after first booting up on permanent store.

The boot time of your IoT device will be the same on every device. Except that's not true at all.
Given a high resolution timer, boot times are measurably different even on the same device, every time. It's maybe only a few clock ticks different (or a few hundred thousand, if you read something like the CPU's time stamp counter), so not very unique altogether, but it sure adds some entropy.
Similarly, the time it takes connect to return the first time you access your API site will be slightly, but measurably, different every time. Similarly, getaddrinfo will take a slightly different, measurable amount of time for every device when looking up your web API's hostname for the first time.

Concatenate those three or four sources of entropy (MAC address, time of first power-on, time to boot for the first time, connect time) and calculate a hash from that. MD5 will do just fine for that purpose. There, you're unique.

While that does not truly guarantee uniqueness, it "pretty much" guarantees it, with a neglegible chance of failure. You would have to have two devices with identical MACs that are turned on for the first time on the same microsecond, and took the exact same time to boot, and to connect to your site. That isn't going to happen. If it does happen, you should immediately start playing the lottery because to all appearances, you're guaranteed to win.

If, however, "will not happen" is not good enough as a guarantee, simply pass each device a sequentially increasing number (generated on the server) the first time they access your web API. Let the device store that number, done.

| improve this answer | |
  • was the command supposed to be ntpq -c rl? – Tom Oct 13 '17 at 16:44
  • 1
    @Tom: Yes, I'm not sure why it reads "r1" in my answer, certainly has to be "rl"!? Will correct that :) – Damon Oct 13 '17 at 20:30
  • I was managing a LAN about 30 years ago and we had duplicate MACs. The vendor used the I/O board's serial number to generate the MAC, but they forgot to include the model number, and we had two different models with the same serial number. Luckily they provided a way to set the MAC manually, so we overrode it on one of the devices. – Barmar Oct 13 '17 at 22:05
  • MAC addresses are usually allocated by the board vendor not the chip vendor. So Intel would only need to acquire addresses for intel boards not intel chips. – plugwash Oct 13 '17 at 22:33
  • We are probably going to go a route similar to your last paragraph. Thanks for the ideas! – Matt Phillips Oct 14 '17 at 4:04

Since the problem here is really an XY Problem, I'm going to address solving that: how to get a unique identifier for a piece of hardware the first time it boots without having to preload identifiers onto them. All the good methods really boil down to one thing: having a source of entropy.

If your hardware has something designed to be a hardware entropy source (note: this is basically a requirement for any proper IoT device implementation since it's needed for TLS, so your hardware should be designed with that in mind), just use that. If not, you have to get creative.

Fortunately, almost every computer ever made has an excellent source of entropy: crystal oscillators (clocks). The rate of a given crystal is not just dependent on subtle temperature changes, but is subject even to temperature hysteresis in nonlinear ways. However, to measure the entropy, you need a second clock to time the first. What this means is that, whenever your computer has at least two clocks you can sample, you can use the rate of one as measured by the other as a very high quality entropy source.

| improve this answer | |
  • 1
    This is a good idea, provided the op can work with an entirely non-deterministic value. The question is, if the device is reinitialized, and the value rederived, will it suit their needs for management and continuity. – Frank Thomas Oct 14 '17 at 2:14

I don't want to directly answer the question as there are other very good responses but instead i would like to suggest another more suitable value that might be available to use as the device id.

If supported by your hardware you could consider using the SMBIOS UUID. This is a unique id for the mainboard and thus the device. Keep in mind even IoT devices can have multiple NICs (LAN & WiFi) so if you choose the MAC route you still need to find a method of picking one consistently.

Also whilst the UUID is unique its should not be used for security purposes as it is only guaranteed to be unique in a friendly environment.

| improve this answer | |

I hate assuming an XY problem because often the OP has a good albeit complex reason for doing things the way that they're doing them but you might want to look into other methods for generating a unique identifier for each device that, like the MAC address, is "built in" to the device and doesn't require generating your own identifier.

If the devices are all from the same manufacturer (or, even better, the same model) you could use the serial number to generate the identifier. This doesn't work so well across devices from different manufacturers though, even if you combine it with the manufacturer name and model number, because of different serial number formats and possibly different APIs for obtaining the serial number in the case of embedded/proprietary devices. An alternative to the device serial number might be the serial number of the motherboard, CPU, or hard disk (I believe Windows licensing uses a combination of these).

It's also worth remembering that filesystem formatters typically generate a unique ID for each filesystem. Unless you're preparing all the devices from the same image (which I would recommend doing, for unrelated reasons), each hard disk will already have a unique ID stored in the filesystem that you can use.

Having said that though, there's really no reason not to use MAC addresses, especially if as part of your provisioning process you can determine that they are in fact unique (although this shouldn't even be necessary, assuming we're talking not more than a few thousand devices here). Of course, bear in mind that whatever you use may be spoofed by the device so don't rely on this for authentication in an untrusted environment (you said it's a private setup so presumably this is a "trusted" environment where you don't care about your client spoofing their own devices against their own servers, but they should obviously bear this in mind if management of the devices is handed over to third parties or end users).

| improve this answer | |
  • I'm not actually certain that this is in fact an XY problem, at least not for our audience. That the OP needs a mechanism for his software to persistently identify a device, and to then logically tie values to it is clear and unambiguous. The OP is not asking the wrong question; if they had asked what mechanism they could use to ID the devices, this question would have been closed as offtopic for having some relation to programming, and not expressing a specific problem with computer hardware or software. Asking for peer review on a technical decision is not XY. – Frank Thomas Oct 19 '17 at 13:02
  • @FrankThomas As I said, I hate assuming an XY problem. I am not assuming an XY problem here. I agree that it is perfectly acceptable to ask for review of a particular solution to a problem even if there are other solutions. But people often accuse those kinds of questions of being XY problems. – Micheal Johnson Oct 19 '17 at 17:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.