MAC Address as product ID - Page 1
Forum section: electronics / projects

author: Caio Negri
author_rank: Contributor
timestamp: April 04, 2017, 07:49:36 pm
content: Hello,I'm developing wireless fill level sensors for trash collectors in my city. Each sensor needs to have a unique ID that is sent along with the fill level measurements. Is it safe to use the device's MAC address as the ID? If not, what would be a simple and safe way to automatically assign a unique ID to each sensor?Thank you for your time

author: RGB255_0_0
author_rank: Frequent Contributor
timestamp: April 04, 2017, 07:58:42 pm
content: Ideally not. How hard is it to generate serial numbers though?

author: Dumont
author_rank: Newbie
timestamp: April 04, 2017, 08:04:00 pm
content: I can't think of too many problems with this. These are numbers already intended to be unique, so they certainly should uniquely identify the device. I suppose in some situations there may be some information disclosure concerns in that if someone gains access to the entries in the reading database, they've gained information that would allow them to identify that device on the network without needing to interrogate it for an internal identifier, as the MAC address will be readily visible in the network traffic.

author: ataradov
author_rank: Super Contributor
timestamp: April 04, 2017, 08:05:05 pm
content: That depends on how you assign MAC addresses. I don't really see a problem using them as UID, if you actually make sure they are unique.

author: FrankBuss
author_rank: Unknown
timestamp: April 04, 2017, 08:07:38 pm
content: The MAC address is unique, should be safe. Costs$550, if you buy a block of 4096 addresses, but you can buya chip which has a MAC insidefor less than a buck. If your device has a WLAN interface, you might already have a MAC. But if the manufacturer are not carefully, or didn't buy an official block, it might be not unique.

author: dmills
author_rank: Super Contributor
timestamp: April 04, 2017, 09:46:36 pm
content: Also worth noting that if you are using a PIC32 which has a built in MAC they all have unique mac addresses pre programmed and you can find it even if you are not actually using the built in MAC hardware.I have one X86 based product where one of the I210 based ports has a microchip MAC because there was a PICs elsewhere on the board doing other things that had a MAC but was not using it.But yea an I2C based eeprom where half of it is read only and contains a MAC is a few tens of cents (The biggest problem with the tings is that they are I2C, hateful bus, give me SPI any day of the week).Regards, Dan.

author: rs20
author_rank: Super Contributor
timestamp: April 04, 2017, 10:36:58 pm
content: How are you programming these devices in the first place? Why not assign any unique info to the MCU's EEPROM at this time?Or, how about when the device first wakes up, it notices that it has no unique info assigned, and as a one-off connects to the server and retrieves the info?Just asking if it's "safe" is incredibly vague. What threats are you trying to defend against? Rule #1: pretend that you are the attacker trying to damage your system. What would you do?If these sensors are connected by a secured, physically uninfiltratable network, then indeed uniqueness is the only requirement, and MAC addresses should be unique and therefore suitable.However, if the devices communicate via something more-or-less safe like HTTPS, but one of these devices could be physically compromised, the attacker could then easily build, on a large scale, devices which impersonate your devices and provide bogus values. Wouldthisbe "safe"?If you provide each device with a unique number, called a salt, then every report sent by your device can be signed by appending a hash of the message contents, and that device's salt. The receiving server can then perform the same hash using the received message's contents, and the salt stored in its database, to verify that it really was sent by the real device (or at least, a device that knows the salt). That's whatI'dconsider "safe", but obviously security is a spectrum and different people may choose different thresholds.It's preferable that you use an MCU with built-in EEPROM or flash, if you want to take security seriously.

author: Caio Negri
author_rank: Contributor
timestamp: April 05, 2017, 12:38:31 am
content: I should clarify: the sensors use Espressif modules. By unique I mean unique within my own network of sensors at least. The idea was to use a unique property of the own SoC as the ID to simplify programming a large amount of chips. My concern was that some cheap wifi modules like the ESP ones could have duplicate MAC addresses and cause issues in the long run.Quote from: rs20 on April 04, 2017, 10:36:58 pmYep that is the case. Could be a serious problem.Quote from: rs20 on April 04, 2017, 10:36:58 pmWill look into that, thanks.

author: rs20
author_rank: Super Contributor
timestamp: April 05, 2017, 01:57:43 am
content: Quote from: Caio Negri on April 05, 2017, 12:38:31 amExercise for the reader: how could this go wrong?

author: bitwelder
author_rank: Super Contributor
timestamp: April 05, 2017, 05:28:32 am
content: How many devices are we talking about? I wondering, because if it's not too large number *and* they are all programmed in the same station it wouldn't be too difficult to keep a local counter and burn to each one an incrementing serial number.Anyway MAC addresses should be unique. Perhaps instead of using them 'as is', you could take them as basis to generate your own S/N. E.g. you could compose a S/N made of 'city area of sensor deployment' + MAC, so that at a glance you could tell where a specific sensor signaling something noticeable is.

author: Jeroen3
author_rank: Super Contributor
timestamp: April 05, 2017, 05:35:37 am
content: Most modern chips do have a Unique ID, you can use that.

author: ataradov
author_rank: Super Contributor
timestamp: April 05, 2017, 05:49:57 am
content: Quote from: Jeroen3 on April 05, 2017, 05:35:37 amI would be careful with that. They are unique to manufacturer at best, and to device series at worst. So you are locking yourself to a manufacturer or a series of devices. It is better to make your own.

author: Jeroen3
author_rank: Super Contributor
timestamp: April 05, 2017, 05:57:23 am
content: They will be right next to the chip family and configuration bytes. The combination of those bytes is supposed to be unique.If you can't trust your chip manufacture with this, do you trust them with anything?

author: RoGeorge
author_rank: Super Contributor
timestamp: April 05, 2017, 06:05:56 am
content: Quote from: Caio Negri on April 04, 2017, 07:49:36 pmYes, MAC addresses are supposed to be unique.https://regauth.standards.ieee.org/standards-ra-web/pub/view.html#registriesUnless you buy fake network card/chips, there should be no MAC duplicates worldwide, no matter the manufacturer. However, if it happen that you have MAC duplicates in the same network, then your network will not work properly anyway.

author: ataradov
author_rank: Super Contributor
timestamp: April 05, 2017, 06:10:58 am
content: Quote from: Jeroen3 on April 05, 2017, 05:57:23 amWhat if you decide to change a chip manufacturer down the road? That's the problem.You need to have a numbering scheme that you know and can continue to make unique numbers by hand, if needed. This is not possible with most embedded UIDs.

author: amspire
author_rank: Super Contributor
timestamp: April 05, 2017, 06:18:53 am
content: MAC addresses are easily discoverable, and there are many devices that allow you to use any MAC address you like. I would never use it for an ID.Here is my suggestion. When you poll a fill level sensor, you also send the sensor a date/time string. When the sensor replies, it has to send the data, an ID (can just be a simple number or code), plus the date/time string you sent. All this information is sent in a single encrypted block of data. Because the date always increases, no-one can reuse an old cloned encrypted block to try and fool you. You will never use the same date/time string twice.When you receive this block and decrypt it, the date/time string has to exactly match the one you sent. With this method, the ID does not have to be a secret - it can be written on the fill sensor if you like. Makes it easy.The Expressif chip has some internal ROM, and also uses AES encryption on the external attached eeprom, so I suspect it is possible to keep the encryption key secure. Don't make up your own encryption method - use a standard encryption.

author: Nusa
author_rank: Super Contributor
timestamp: April 05, 2017, 06:19:27 am
content: Quote from: RoGeorge on April 05, 2017, 06:05:56 amI dunno about that. A standard feature on routers is the ability to spoof the mac address of one of the attached PC's to the ISP rather than its own mac address. You have to ask what will happen if someone else spoofs your hardware. Will anything bad happen?

author: ataradov
author_rank: Super Contributor
timestamp: April 05, 2017, 06:21:37 am
content: Quote from: Nusa on April 05, 2017, 06:19:27 amThis has to be taken care of on other levels. What if someone spoofs your custom serial number? It is just a number, MAC is as good as any other.

author: Jeroen3
author_rank: Super Contributor
timestamp: April 05, 2017, 06:31:54 am
content: If you're intending to keep the option to change chip open, then you're right.You could get a silicon serial number maxim, if you trust maxim.In any other case you'd have to use eeprom or nvram emulation to write your serialnumber data.

author: amspire
author_rank: Super Contributor
timestamp: April 05, 2017, 06:40:22 am
content: Quote from: RoGeorge on April 05, 2017, 06:05:56 amThat is the way it is meant to work, but if you are using any virtualization software, the MAC addresses are not hardware - they just make up a MAC address when the VM instance is created and you can change it to anything you like.

author: RoGeorge
author_rank: Super Contributor
timestamp: April 05, 2017, 07:42:02 am
content: 1. Virtual machines also generates unique MAC addresses, but this is offtopic. The OP is asking about physical devices.2. Of course there are cases where one can force a MAC collision (by manually assigning a duplicated MAC), but again, it is supposed the OP will not sabotage his own network.3. For people who don't believe MAC addresses MUST be unique in the same network in order to have a fully functional network (according to all RFC specs), just try to duplicate some MAC addresses and see your network going crazy in unpredictable ways depending on what switch/protocol/devices you are using.MAC addresses are supposed to be unique worldwide (virtual or not), across any device and any hardware manufacturer, unless you have fake chips or you manually change the MAC.https://en.wikipedia.org/wiki/MAC_addressOf course it is safer to assign your own unique ID if possible, especially if you expect other people to mess with your network, but it comes with extra costs.

author: AndyC_772
author_rank: Super Contributor
timestamp: April 05, 2017, 07:43:02 am
content: The question here is about whether or not a MAC address is unique, to which the answer should be 'yes'. System security is a whole different topic.You could also use a CPU's own internal manufacturer specific unique ID, provided you concatenate it with a few bytes to indicate the hardware type you've used, and which you can change if you decide to use a different type of CPU on a new board revision. It doesn't matter if two CPU types both have a unique ID of 12345 if you're actually using A12345 and B12345.It might be worth considering using a hash of whatever ID you choose to use, rather than the ID itself. That will give you a sequence of bytes which is still (overwhelmingly likely to be) unique, but which appears to change randomly from one unit to another. This makes it much harder to guess valid IDs given a limited set of examples.

author: nctnico
author_rank: Super Contributor
timestamp: April 05, 2017, 08:00:00 am
content: Quote from: RoGeorge on April 05, 2017, 06:05:56 amWRONG! A MAC address is supposed to be unique on an ethernet segment. However manufacturers do re-use MAC addresses because the number of MAC addresses is limited and so are the number of nodes on an ethernet segment so in reality the chance of having two devices with the same MAC on the same ethernet segment is similar to winning millions in a lottery (it does happen though).Back to the original question: you can use the MAC as the device ID. The devices will be distributed randomly over the garbage bins anyway. Just make sure that any data going over the air is encrypted. If your wireless module has SSL use that (with preset keys for authentification so there is no need to negotiate keys and an extra authentification phase at the application layer) and allow for remote encryption key updates.

author: rs20
author_rank: Super Contributor
timestamp: April 05, 2017, 08:10:54 am
content: This whole debate about whether MAC addresses are globally unique isCOMPLETELY IRRELEVANTto the OP's question, as is the observation that MAC addresses are spoofable.As pointed out by ataradov already, an attacker can choose to spoof ANY aspect of the packet they want. To single out MAC addresses as a uniquely spoofable thing is totally ignorant; as assuming that the attacker is limited to the spoofing abilities afforded by Windows Network Control panel settings is ignorant.Open to being proven wrong on this, but the only way to defeat spoofing is through cryptographic means -- either full blown encryption, or simple signing of packets using salts+hashes. It doesn't matter how carefully guarded and unique your secret is if you send it in cleartext over an untrusted network.Also, there's no need to overengineer things -- a 64-bit random number generated through a decently seeded PRNG has a vanishingly small chance of ever experiencing a collision; if generating the random number locally closes an avenue of allowing an attacker to perform a MITM attack, then the chance of an MITM massively trumps the chance of an RNG collision and the random number becomes the simplest and preferred approach. Once again, it's incredibly naive to consider the probability of a MAC or random number collisions to be a relevant threat compared to the probability of screwing up a more complex solution.

author: RoGeorge
author_rank: Super Contributor
timestamp: April 05, 2017, 09:51:44 am
content: Quote from: nctnico on April 05, 2017, 08:00:00 amThanks for this info.I always thought the manufacturers never re-use their MACs, and buy more OUI space (the first 3 MAC bytes) instead, because as a manufacturer you can never know in what network segment your hardware will land - so you need to be worldwide unique, but it seems I was wrong.

author: Jeroen3
author_rank: Super Contributor
timestamp: April 05, 2017, 10:48:35 am
content: Quote from: rs20 on April 05, 2017, 08:10:54 amYes. Look for points of failure below.QuoteYes, with low quantity.For high quantity I can think of this: keep a section of FF's in the flash outside bootloader reach, when the device passes final testing, you write those bytes with a number, and set the JTAG lockbits. The number is written to a database (so you can retrieve the latest), together with who tested it and the test results/parameters.If you don't want the end user to know how many units you've made, put the incremental #SN number trough a simple hash.

author: rs20
author_rank: Super Contributor
timestamp: April 05, 2017, 12:01:33 pm
content: Quote from: Jeroen3 on April 05, 2017, 10:48:35 amWow, you seriously don't appreciate how unlikely collisions are. Realising that human errors are far more likely than certain mathematical probabilities is an important thing to internalise and appreciate.Point of failure: Subsequent production run fails to restart incremental counting from where it left off last time, because the previous production run produced a few extra and failed to record this fact. Solution: have a separate field for production date? Point of failure: human error fails to update date.Probability of thing above happening? Let's be generous and say one in a billion.Probability of 64-bit random number colliding? One in a trillion.

author: rs20
author_rank: Super Contributor
timestamp: April 05, 2017, 12:25:36 pm
content: Quote from: Jeroen3 on April 05, 2017, 10:48:35 amWhile I'm on a roll, let's suppose the OP took this suggestion to heart and naively used a standard, unsalted hash. Let's suppose I intercept one ID: 0xf9afa97535cf7c8789a1c50a2cd83787. Gosh darn it, how on earth am I going to retrieve the original ID? How aboutjust googling it. Second and third results reveal that this is the md5 hash of "9452", so the attacker now knows that there are 9452 devicesand knows exactly how to generate all 9451 previous IDs as well. Awful, critical security hole.Oh, and you know what the probability of a collision is with N-bit hashes vs N-bit random numbers?Exactly the same, the ideal behaviour of a hash function is that it looks like a new random number for each different input. So there's a deep irony here that your counter-suggestion not only introduces a bunch of new security concerns, but completely fails to address the problem you had with mine. If you're going to suggest that the central database assigning these IDs could check for collisions, that solution applies equally well to random numbers; except without the ability to predict one ID from others.Just to say it again, my suggestion had a one in atrillionchance of collision; an easily detectable and non-problematic situation in any case. Place your bets, kids.

author: nctnico
author_rank: Super Contributor
timestamp: April 05, 2017, 12:36:21 pm
content: Quote from: rs20 on April 05, 2017, 08:10:54 amAny ID number is spoofable if there isn't some kind of encryption or at least authentification scheme in place. The security of the system shouldn't rely on an ID number being obscure. All in all using the MAC address as an ID is convenient to use as a unique number as long as you can check whether it is really unique within the system.

author: Scrts
author_rank: Frequent Contributor
timestamp: April 05, 2017, 12:44:05 pm
content: I would not risk and go with something like this:https://www.maximintegrated.com/en/products/digital/memory-products/DS2401.html

author: Jeroen3
author_rank: Super Contributor
timestamp: April 05, 2017, 01:46:22 pm
content: A serial number is for traceability, not for security.When I read the startpost, it's to create an unique key in the database for each sensor. It could even be printed on the label!It's not for security, and it should never be. There used to be a brand of wifi routers that came with an ISP, they used MD5 from the serial to create SSID and WEP key. You could find the WEP key form the SSID in seconds.

author: Caio Negri
author_rank: Contributor
timestamp: April 06, 2017, 12:07:27 am
content: Alright, seems like using MAC as device ID for traceability is as valid option. Security is a whole other matter and I thank you all for the suggestions. I'll be looking at encryption methods and posting more questions on new threads.Thank you all for your help