Ethernet MAC address as activation code for an appliance?

Question

Let's suppose you deploy a network-attached appliances (small form factor PCs) in the field. You want to allow these to call home after being powered on, then be identified and activated by end users.

Our current plan involves the user entering the MAC address into an activation page on our web site. Later our software (running on the box) will read the address from the interface and transmit this in a "call home" packet. If it matches, the server response with customer information and the box is activated.

We like this approach because it's easy to access, and usually printed on external labels (FCC requirement?).

Any problems to watch out for? (The hardware in use is small form factor so all NICs, etc are embedded and would be very hard to change. Customers don't normally have direct acccess to the OS in any way).

I know Microsoft does some crazy fuzzy-hashing function for Windows activation using PCI device IDs, memory size, etc. But that seems overkill for our needs.

--

@Neall Basically, calling into our server, for purposes of this discussion you could call us the manufacturer.

Neall is correct, we're just using the address as a constant. We will read it and transmit it within another packet (let's say HTTP POST), not depending on getting it somehow from Ethernet frames.

Answer 1

From a security perspective, I know that it is possible to spoof a MAC, though I am not entirely sure how difficult it is or what it entails.

Otherwise, if the customers don't have easy access to the hardware or the OS, you should be fairly safe doing this... probably best to put a warning sticker on saying that messing with anything will disrupt communication to the server.

Answer 2

I don't think that the well-known spoofability of MAC addresses is an issue in this case. I think tweakt is just wanting to use them for initial identification. The device can read its own MAC address, and the installer can (as long as it's printed on a label) read the same number and know, "OK - this is the box that I put at location A."

tweakt - would these boxes be calling into the manufacturer's server, or the server of the company/person using them (or are those the same thing in this case)?

Answer 3

I don't think there's anything magic about what you're doing here - couldn't what you're doing be described as:

"At production we burn a unique number into each of our devices which is both readable by the end user (it's on the label) and accessible to the internal processor. Our users have to enter this number into our website along with their credit-card details, and the box subsequently contacts to the website for permission to operate"

"Coincidentally we also use this number as the MAC address for network packets as we have to uniquely assign that during production anyway, so it saved us duplicating this bit of work"

I would say the two obvious hazards are:

1. People hack around with your device and change this address to one which someone else has already activated. Whether this is likely to happen depends on some relationship between how hard it is and how expensive whatever they get to steal is. You might want to think about how easily they can take a firmware upgrade file and get the code out of it.

2. Someone uses a combination of firewall/router rules and a bit of custom software to generate a server which replicates the operation of your 'auth server' and grants permission to the device to proceed. You could make this harder with some combination of hashing/PKE as part of the protocol.

As ever, some tedious, expensive one-off hack is largely irrelevant, what you don't want is a class-break which can be distributed over the internet to every thieving dweep.

Answer 4

The MAC address is as unique as a serial number printed on a manual/sticker.

Microsoft does hashing to prevent MAC address spoofing, and to allow a bit more privacy.

With the only MAC approach, you can easily match a device to a customer by only being in the same subnet. The hash prevents that, by being opaque to what criteria are used and no way to reverse engineer individual parts.

(see password hashing)