Picking a MAC address for a FreedomBox

The FreedomBox project is working toward the creation of an inexpensive, in-home device that can be used for secure and private communications. The initial plan is to create a version of the Debian distribution that can be installed on a device like the DreamPlug; the resulting configuration should "just work" for nontechnical users in potentially hostile situations. The project has many challenges to overcome, one of which — the choice of MAC address for the network interface — shows how tricky this problem space can be.

An interface's MAC address is a unique number identifying the interface to any other devices it may communicate directly with. Ethernet-style MAC addresses are six-byte quantities; half of those bytes identify the manufacturer while the other half are meant to be a unique serial number. The MAC address for the Ethernet interface on the system where this article being typed is:

    18:03:73:be:76:4a

This MAC address identifies the relevant system as having been manufactured by Dell. If Dell has done its job properly (and there is no evidence to the contrary), no other Ethernet interface on the planet should have that same MAC address.

FreedomBox developer Nick Daly recently started pondering the question of how a FreedomBox should set its MAC address. The hardware will come with an address provided by the manufacturer, of course, but that address can be changed by the kernel and there may well be good reasons for doing so. Many of those were outlined in this lengthy message from John Gilmore, which is well worth reading in its entirety; it forms the basis of this summary.

One obvious problem is that a static MAC address is a unique number identifying a particular system. Most interfaces never operate with anything but the vendor-supplied address; if a hostile party learns that address, they can quickly identify the system it belongs to. So, while a FreedomBox device might move around, a suitably informed observer will always know which device it is. That allows the correlation of activities over time and the monitoring of specific devices.

Current technologies make things worse. Quoting John:

In other words, a hostile entity might not have to drive around a city in an attempt to detect a device with a specific MAC address; instead, it is just a matter of asking Apple, which has a widespread surveillance network in place and can simply say where that device is to be found. Similar information is maintained by other parties — Google, for example.

John also pointed out that it is often trivial to determine which IP address is assigned to a device; it is often just a matter of sending a DNS query to the MAC address of interest. That can enable the identification of the location from which specific network activity has been generated.

Finally, there is the matter of that manufacturer identification number found in every MAC address. If FreedomBox becomes a widely used and effective system, certain authorities might develop a strong interest in knowing where DreamPlug systems are to be found. The identifying information found in the MAC address makes that identification a relatively simple task. Turning on a DreamPlug could be a way of painting a target on a specific location — not the sort of dream the owner may have been looking for.

The obvious conclusion is that FreedomBox systems should not normally run with the default MAC address provided by the vendor. They should, instead, generate a new address, and that address should be changed frequently. Fortunately, much of this is easy to do; any even remotely contemporary hardware will allow the host system to provide a new MAC address, and the data link layer (and above) protocols are pretty good about responding to MAC address changes. So there is no obvious technical barrier preventing frequent changing of a system's MAC address.

But there is still the question of what that address should be. Nick had suggested defaulting to 00:00:00:00:00:00 by default, a choice that would clearly prevent the identification of specific FreedomBoxes. But there are problems with that choice, starting with the fact that confusion would result as soon as two FreedomBoxes appeared on the same network. So something a little smarter is needed.

One obvious possibility is to simply generate a six-byte random number and use that. Care would have to be taken to avoid MAC address collisions on any given net, but that is not a particularly hard problem to solve. There are also the usual issues with having enough entropy available to generate a proper random number at boot time; without an adequate level of care, that random address might be far less random than people expect. Once again, that is a problem that should be amenable to a proper solution.

But, as John pointed out, there is another problem: real-world MAC addresses follow a specific pattern; a random address, being unlikely to fit that pattern, would probably stand out like a neon sign to anybody who is looking for it. To be convincing, a system-chosen MAC address cannot be completely random. It should have a recognized manufacturer number, preferably a manufacturer that actually makes contemporary wireless network interfaces. The serial number also needs to fit into a range that was actually shipped by that manufacturer. In other words, a random MAC address will only blend in if it makes the device look like some other random piece of real-world hardware.

These problems are all tractable, but the solution requires a great deal of due care if it is not to expose its users to unwanted consequences. Indeed, the whole system must be designed and implemented with that level of care; that is part of why the FreedomBox has not come to fruition as quickly as many would have liked. Privacy is a surprisingly difficult problem, with many pitfalls for those who try for a quick solution.

---

(Log in to post comments)

020406	BBN				internal usage (not registered)
020701	Interlan [now Racal-InterLAN]	DEC (UNIBUS or QBUS), Apollo, Cisco
020701	Racal-Datacom
026060	3Com
026086	Satelcom MegaPac (UK)
02608C	3Com				IBM PC; Imagen; Valid; Cisco; Macintosh
02A0C9	Intel
02AA3C	Olivetti
02CF1F	CMC				Masscomp; Silicon Graphics; Prime EXL
02E03B	Prominet Corporation		Gigabit Ethernet Switch
02E6D3	BTI (Bus-Tech, Inc.)		IBM Mainframes
2E2E2E	LAA (Locally Administered Address) for Meditech Systems
475443	GTC (Not registered!)		(This number is a multicast!)
525400	Realtek (UpTech? also reported)
52544C	Novell 2000
5254AB	REALTEK (a Realtek 8029 based PCI Card)
565857	Aculab plc			audio bridges
AA0000	DEC				obsolete
AA0001	DEC				obsolete
AA0002	DEC				obsolete
AA0003	DEC				Global physical address for some DEC machines
AA0004	DEC				Local logical address for DECNET systems
E20C0F	Kingston Technologies

$ to_stderr() { echo "$@" >&2; }
$ to_stderr test 2>&1 >/dev/null
test
$ to_stderr test >/dev/null 2>&1

You'd be able to tell that the device _was_ a FreedomBox but you wouldn't be able to track _which_ one it was.