4

We are going to adopt Raspberry Pi in our products, this means the RP must associate with unique product. Given that RP does not have any printed serial number on its board, How one can get any unique string from the RP, this string must be readable from both hardware and software?

Jawad Sabir
  • 127
  • 2
  • 6

1 Answers1

8

Every RPi has a serial number. Here's how to learn what it is: 

cat /proc/cpuinfo | grep --ignore-case serial

Note that this result is read from a file written by the kernel; i.e. there is a layer of software and the filesystem "between" this value and the value that was "burned into" the OTP memory during hardware fabrication.

This value (serial number) is also available directly from the hardware. The available OTP documentation states that the serial number is in OTP register #28. Therefore, we can read it "directly" as follows: 

vcgencmd otp_dump | grep '28:'

Of course the verity of this result also depends on a layer of software. But it may not be the same software used by the kernel to generate /proc/cpuinfo, and so perhaps you get a second opinion here. If neither of these approaches meets your needs, you could always study the source code, and develop your own approach to reading the OTP memory.

You may compare the values generated by these two methods of reading the Raspberry Pi's serial number. They should, of course, be the same.

Alternatively (or Additionally):

You can use the Ethernet MAC address for those devices that have built-in Ethernet. All Ethernet-equipped Raspberry Pis through ver 3B+ have a MAC address that begins with b8:27:eb (i.e. the OUI); since ver 4B the OUI has changed to dc:a6:32. When combined with the last 3 octets, this MAC address should be globally unique according to IEEE Guidelines. You should peruse these guidelines as there are important caveats, and other potentially useful information.

The Ethernet MAC address is also written to a file, but of course subject to the caveats discussed above for the serial number. To get the MAC address from the hardware: 

ethtool --show-permaddr eth0    # for the Ethernet adapter
ethtool --show-permaddr wlan0   # for the WiFi adapter

Note that there is also a MAC address for the Bluetooth transceiver - again, for those boards that are equipped with Bluetooth. The governing specification for Bluetooth v5 states:

Each Bluetooth device shall be allocated a unique 48-bit Bluetooth device address (BD_ADDR). The address shall be a 48-bit extended unique identifier (EUI-48) created in accordance with section 8.2 ("Universal addresses") of the IEEE 802-2014 standard.

The Bluetooth MAC must be different from the Ethernet MAC, and again, this is covered by the IEEE guidelines. I think this will get the Bluetooth MAC address from the firmware: 

hciconfig -a | grep BD

Know that while MAC addresses can (and often are) "spoofed", this "spoofing" does not change the MAC address that was built/programmed into the product when it was manufactured. It would be foolish to claim that any address or serial number is "unalterable" or "perfectly secure", but reading the values directly from the ROM/OTP would seem to offer some greater assurance that the value is "authentic" than reading these values from the filesystem.

Seamus
  • 21,900
  • 3
  • 33
  • 70
  • How to physically read serial number or MAC address? – Jawad Sabir Apr 17 '19 at 14:15
  • @JawadSabir: Re-read my answer please, and let me know if you still have a question. – Seamus Apr 17 '19 at 14:33
  • When you say the serial number is stored in a file and hence can be changed, do you mean someone could edit /proc/cpuinfo, or something else? – Mark Smith Apr 17 '19 at 15:15
  • @MarkSmith: Yes, someone could edit it. Here's one way it could be done – Seamus Apr 17 '19 at 17:51
  • That's not editing the file, it's making changes to the kernel. If you distrust the kernel, you probably can't trust the vcgencmd command either, in my opinion :-) – Mark Smith Apr 17 '19 at 18:44
  • @MarkSmith: Maybe I'm missing your point... are you suggesting the file(s) written by the kernel can't be modified? Or are you suggesting that the data in the files is as relaible as what's in OTP mem, or...? – Seamus Apr 17 '19 at 19:04
  • Yes, files in /proc/ are mostly not files in the sense of lumps of data on disk, but interfaces to the kernel. They are generated on the fly when you read them. Some can be written to, for example to change kernel config, but not that particular one (try it). The only way to "change it" is to alter the kernel to report different information. If you can't trust the kernel, you're stuffed really. – Mark Smith Apr 17 '19 at 20:06
  • @MarkSmith: Perhaps... but in the context of this question, the OP wanted a "unique string". He didn't say what he wanted to do with it. I assumed he wanted a "unique string" whose value could be verified in hardware. That's how I tried to answer. You seem to feel I've missed the mark, and you may be right. I'm not sure anything is bullet proof, what most do is try to "raise the bar" so it's not trivial. Do you have a proposal/answer? And that's not a rebuttal, but an honest question. I'm here to learn, too. – Seamus Apr 17 '19 at 20:44
  • I think your proposal is very good and very thorough, I don't have anything better! My only issue is with the slightly misleading part about changing that file: I think really relying on /proc/cpuinfo is as reliable as anything you'll get and you don't need to worry about it not being correct. Having several other ways of doing it (MAC addresses) is good too, might as well have options. – Mark Smith Apr 17 '19 at 21:04
  • @MarkSmith: I do respect your opinion, but I have to disagree. And my reason has nothing to do with subterfuge - it has only to do with human error. In other words, if I accept the data in the file, I have also accepted that the developer did his job correctly (the code is correct). OTOH, if I read it myself from the hardware, I only have to trust me. And I have seen some weird things. – Seamus Apr 17 '19 at 22:42
  • @MarkSmith: All of that said, I should try to make this as clear as possible. I'm going to make another edit. Please do me the favor of reviewing it, or even adding your own edits, and we'll move this answer closer to "correct". :) – Seamus Apr 17 '19 at 22:46
  • @Seamus reading OTP is a production environment is uneasy exercise, how can we speed up this for many Pis? – Jawad Sabir Apr 18 '19 at 05:52
  • @JawadSabir: I can't answer that; many of the necessary details to formulate an approach are likely to be proprietary. If it were my project, I would first consider using a different platform, quite frankly. If that's not an option, I would approach someone at "The Foundation", and make inquiries. An idea that you could act on today: Ask another question in this site: "Access OTP Memory with no OS" - or words to that effect. – Seamus Apr 18 '19 at 13:19