Hi, Henry. > Thanks, Stephen! Lots of helpful info. > I'm a little unclear on one aspect. Suppose password #2 is the MAC address > of the raspi. If someone grabbed the SD card AND the raspi, they could determine the MAC address easily enough without the encrypted SD card.
That's right. The scheme presented earlier prevents mismatched computer and card from working properly. If both are snatched, this scheme does not protect you. This kind of scheme was used in Digital Satellite Receivers in the 1990's and 2000's: the service worked as long as the unit and its data card were correctly married, no matter whose living room it was installed in. In the RasPi case, it will reboot, check its MAC address (or some other motherboard-specific serial number), decrypt the sdcard encrypted partition and merrily mount the sdcard fs, etc. > Could they then use the MAC address on another machine to mount the encrypted card? Yes. Plug the RasPi onto a LAN and its MAC can be sniffed. Most ethernet NICs can update their MAC address and can spoof the orignal host that way. A CPU serial number (if RasPi supports it) could be handy, and is not externally visible. In the early 2000's, that was used for some software enforcement of DRM. If RasPi has NVRAM, you could put a random string of your choosing there to act as password #2. Jeremy mentioned physical security. Quite right. You would need to adjust your device protection with some good judgement: decide how much is appropriate vs. the value of the data and the determination of attackers. Bolt the motherboard or case down, smother it in epoxy so that the device is too damaged if tampered with, etc. are possibilities. But one common theme is to disable the device (computer or sdcard) if it is not in its intended *environment*. How aware is the RasPi of its environment? Are there unique signatures that software can use to enable or disable the device. Hint: EDID of the connected display may be unique enough, like a TV serial number. So the device needs the correct MAC, correct display, etc. which is used to decrypt the /data fs. It's really easy to go overboard! Best regards, Stephen Benoit [email protected] _______________________________________________ mlug mailing list [email protected] https://listes.koumbit.net/cgi-bin/mailman/listinfo/mlug-listserv.mlug.ca
