What state are you from?

In what ways is an initial key pair or shared state better than a serial number on an initially unbranded hardware device?

• Suppose that many hardware widgets are to be distributed, and that these widgets are meant to be kept in sync with a server - whether for purposes of logging or accountability.  Independent of the cryptography, these widgets report their transactions back up to the server.  If these widgets also contain software that runs on a modern processor, then an adversary could examine the code in the widget, deploy the software on a set of virtual machines, and then pretend as if they are in possession of many such widgets.  Also, as the initial widget is cloned, the copy could presumably receive communications from the server because the server may assume that the widget is the original.  Fuzzy checks that determine probabilistically if the current widget is running on a VM or is the original (whether run on the device and, better, confirmed on the server) can be kept aside for now, unless there are provable ways of determining this.  And they're still lower priority because the clone could be an identical processor or hardware component, and without the presence of a tamperproof hardware component, a widget can easily be cloned as long as the state can be examined.  And the cloning of the widget could either involve disconnecting the original from the network or keeping both the original and the copy online (optionally changing the copy's serial number). It seems important for a widget to be able to prove its identity during communications with the server.  Otherwise a new serial number could be used which can stomp upon a yet-to-be-connected device, or a previous serial number can be used which would replace the communications of another device that has already been deployed and registered.  In either case the server's ability to track down the set of legitimate deployed instances is lost.  Just using a serial number per se has various shortcomings, since it can be spoofed (and maybe there are other attack vectors).  But suppose as a next step that the widget has a state that it shares with the server.  The server then keeps a tally of each serial number and the current state that it shares with the corresponding widget.  The state may evolve in a number of ways, but suppose that the server and the widget participate in the selection of random data and that as a result of a protocol interchange, the state is irreversibly incremented in such a way that a passive eavesdropper could not predict the next state, where both parties atomically advance to the next shared state in such a way that they both can agree (and have proof) that this has been done.  And suppose also that an active eavesdropper would be detectable or could at best achieve denial of service (or alternatively would at best have the option to do what a passive eavesdropper could, even if the key material was attained from the widget originally). Assuming symmetric cryptography is used on its own (no protocols allowed that are based upon public key cryptography), given that an adversary has silently cloned the state of the device (and thus knows the keys of the widget and any relevant internal state), I believe that the adversary can continue to monitor the communications channel indefinitely, and is effectively always able to keep its own internal state in sync with the original device's state (state used in the protocol with the server), based upon the observed communications.  I believe that the original widget's state in general could diverge (for example it could craft its own set of random numbers that it just stores to disk) but I assert that a portion of its random or uniquely derived state could not be used to successfully advance the shared state exclusively between the original widget and the server in such a way that the adversary could not observe, intervene, or continue to masquerade the connection.  Further, because the state is kept in sync, at any point the clone could begin masquerading as the original, and this could not be detected by the server (except for fuzzy metrics like timing, location, or network path) if the original goes offline.  At that point the clone could then receive data just as if it is the original widget.  The arbitrary slowness and silent nature of this attack gives the adversary an advantage, since they are perhaps undetected until a critical point (maybe a financial transaction is involved, or it becomes possible to ask the server API to report a history of logged locations of the device, or there is a temporary security issue that can then be taken advantage of). Now suppose that asymmetric, or public-key cryptography may be used.  Then, if the widget and its clone exist and the eavesdropper in possession of the clone also has the ability to listen in on and even alter network traffic between the widget and the server, the original widget and server have a way to agree upon a session key through a public-key based key exchange protocol in such a way that the eavesdropper can no longer indefinitely monitor the channel and where a meet-in-the middle attack cannot work.  But even in this case, the adversary has two options.  Firstly, the eavesdropper, presumably in possession of the original software along with the cloned copy, can actually be the one who initiates the key exchange, and so it is the adversary who wins the "race" and then is able to continue communications with the server.  In that case, the original widget will gradually become out of sync with the server, and the server - being well-written - would detect this and can either reject the out-of-sync data or trigger a silent alarm and pretend that the communications should proceed, noticing such a fork has taken place, and observing enough information to be able to differentiate which is the original and which is the clone (and hopefully learning further details about the clone, such as its location, in the process).  But the step the eavesdropper took of being the initiator at least lets that adversary have exclusive access to communicate with the server up until the point that the original widget tries to communicate - and even then if the eavesdropper has the ability to alter communications they can at least deny network communications to the widget. The other attack that the eavesdropper can perform has to do with the frequency of the key exchange protocol.  Although my assertion that a public-key derived, or asymmetric protocol is needed to allow only one widget (or clone) to legitimately (or illegitimately, respectively) advance the shared state, that step would then have high overhead compared to symmetric key communications.  So it wouldn't be after every packet that the key exchange would happen.  There would still be the concept of a session.  And depending on the protocol, the session could be extended for a long time especially if the adversary got ahold of the internal state during the cloning process.  So the adversary could take advantage of an existing session, or existing sessions.  Also, if the protocol allows for the key exchange to be optional or to be delayed, then the adversary, who may be able to masquerade as the server (because it knows the shared state that the widget believes that the server should have), can give the widget false information and say that the server does not have the resources at this time to proceed with the key update or session negotiation.  So the original widget, for a longer period of time, would not know that it has been cloned.  If the server includes a public key signature of one of its messages, assuming that the attacker does not have the resources to hack into the server, then those signed messages (with some overhead) could not be spoofed by the attacker and so they could at best be suppressed.  So here again I assert that the use of a public-key or asymmetric cryptography based step is what's critical to help narrow the impact that a adversary can have when the widget and its state can be silently cloned. So it seems to achieve a certain kind of security or control over deployed widgets, it is important to have not only a shared state, but frequent session checkpoints where a public key derived protocol is used, to prevent a device from being cloned or monitored.  Feel free to suggest attack vectors or security vulnerabilities I've not mentioned.  Or other measures that I've not mentioned that can increase the security of the ecosystem.  Or maybe the assumption that this must involve an asymmetric cryptography step can be made more formal. The remaining part of my question has to do with the process of what I"ll call "branding" (or registration).  Suppose it's known that there is a certain steady state best practice that should be observed to maintain security of the system - where for example the widgets and server are in frequent communication, maintain shared state, and occasionally do a key exchange to set up a new session.  Initially when a hardware component is deployed, it can either be unbranded or undifferentiated, or it can be deployed with (at monotonically increasing levels of security, I believe): a serial number, an initial unpredictable lengthy shared state that is meant to evolve over time, a public/private key pair (along with a copy of the server's public key), a similar pair where the widget's private key is protected by a password, and maybe a more advanced pair where a different key is used for encryption and signatures, and maybe other scenarios which presumably offer greater security.  This may also involve general issues like the key distribution problem (tailored to this scenario); and other existing protocols, like Bluetooth, may already have key steps in the protocol exchange that arrive at the needed security.  Also, the design of Bluetooth for instance points out how the user experience is important in security, since to pair earphones with a phone, one doesn't enter a 32-digit code on the earphones; and also the length of a pairing number is given to be a compromise between security and convenience. But if the hardware arrives without a key at all, and there's a certain registration step needed to provide that device with its key (thus bringing it to the steady state), I'd like to understand better the vulnerabilities that are opened up given that the hardware is deployed in an initially undifferentiated way.  For example, then just anyone can communicate with the server, and masquerade as a new device.  Presumably the server can keep track of the total number of manufactured devices and then determine a discrepancy.  And then as a step beyond that, when the server receives communication from an alleged new widget, it can check entitlement based upon a fuzzy process such as checking its customer database.  However, if the widget can guess at customer IDs or credentials then they can choose a vulnerable or available customer ID and pretend that their device is owned by the customer (this can even become a race condition).  If the widget, when purchased by the customer, is given a serial number that is unique and is registered to that customer, and if the initial delivery is assumed to be secure, then that serial number on its own might be sufficient to reach the ideal secure steady state, since the eavesdropper by assumption would not be able to intercept *that* (initial) delivery.  But in some sense I would guess (especially if the initial delivery can be intercepted) that populating the widget not (just) with a serial number but with a public/private key pair can be considered more secure, defending against other attacks.  It is this pre-steady-state that is of concern, although I'd be interested to hear feedback on the other issues as well.

• Answer:

  The simplest disadvantage of a predefined hardware serial number is that anybody in the products distribution chain could have access to that information. The matter is even made worst because these serial numbers are printed on the packaging. On the matter of cloning, that is always a problem with any type of device. But if you generate this shared state after deployment then you could make a reasonable assumption that the person who deployed the widget took reasonable security measures. This assumption could be made about distribution before sales.