How to inject a key (physically) on a huge number of devices?

Question

The system I am designing has a huge number (assume millions) of individual devices, and each device needs to be injected with a unique symmetric key dedicated to that device. Each device also has a serial number with which it can be physically tracked and accounted for.

Question: what industry-standard approaches exist for injecting keys into such a huge quantity of devices?

I am interested in the physical mechanisms that are available on such an industrial scale. The solution can be a combination of hardware and software.

Associated Requirements:

1. No two devices can get the same key. The system needs to ensure that each key is only used once.
2. For reasons of traceability during the lifecycle of the device, the system needs to know which serial number received which key.

Answer 1

Since you seem unable (likely understandably so) to give any more information, I am going to rephrase your situation so you can determine if we are on the same level. And make an assumption that looks like reasonable.

For all intent and purposes the symmetric keys are not keys but just data, since we get them "prefabricated" out of some system. Thus, in other words, you are asking how can I send some "private data" (= keys) to a group of "users" (= devices) over an "insecure channel" (= the factory and it's employees), with the users having an uniquely identifying feature (= serial number) which is easily known and/or imitated by a malicious user. I will also amuse losing some devices (or having a cost of reprogramming) due to an attack is not a problem.

What you need is for each user to be able to request its data only ONCE.

1. The user connects to your server using a secure authenticated channel (I would suggest some kind of SSL connection).
2. The user sends its ID (serial number) to the server.
3. The server checks if the data (symmetric key) corresponding to this ID has not been handed out (is not flagged).
4. Is not flagged: The server sends the user its data (symmetric key) and flags this key as handed out in it's DB-system.
5. Is flagged: The server does not deliver the data to the user.

The device should only be able to work if it has received a symmetric key from this server. This could be a final part of the production process, let the device initialize (get the key) and check that it has received a key (without the device letting know that the key is of course).

Should someone breach your factory and start sending malicious requests to the server, it cannot breach the security (though it will involve some costs due to some devices being manufactured with already used serial numbers, either the cost of a device must be very small or you can reprogram the serial number, which should also reset the symmetric key of course).

The whole point of this system is to reduce the size of the secure environment, only the server and its DB need to be secure and those can be located off-site if needed. Assuming the server and DB are safe and the device cannot be read or abused between initialization and being in the customers possession, once a device leaves the factory, the fact it turns on will let the customer know it has its key and only the server (and DB) know this key.

I believe the device cannot be read or abused between initialization and being in the customers possession falls outside the context of this SE as it is about physical security. One note I do like to make is that if the device could be initialized in front of the customer, say by a vendor under customer supervision this could greatly decrease the potential for this condition to impact security.

Edit: response to remarks made by Gilles

the server has no way to know whether the serial number sent in the request is genuine

I read the comment from the OP saying that "You can assume for this question that keys have already been generated and have an associated identifier" as "there is a DB containing {serial-number, key} pairs". Thus the server can check (does) if the serial number is genuine.

it means that some devices will be bricked as communication breaks down for one reason or another

I'm not sure how to interpret this but I read this as "if communication breaks down during initialization then the device becomes bricked". I presumed this would be a network internal to the factory or at least the same company making communication problems rather unlikely (though possible, true). Only when the communication fails during sending of the key to the device is there a problem by the way. When I said "This could be a final part of the production process" I did not mean this should happen outside the companies network, just that it's the most secure to have it as close to the end as possible, sorry for any miscommunication.

it enables a trivial DoS attack where an attacker claims all serial numbers

It does allow a DoS attack against the serial numbers. This is because I made the assumption that security was a very important concern for this device and that resetting a device would be an acceptable trade-off to security. However as you will need to be breaching the companies internal network first I do not see this to be that big of a risk. However the attacker will still need to guess correct serial numbers and given a decent lengthy serial the hit-rate should be rather low as we know the production capacity and thus can limit the query limits of the server as an extra security measure.

It also allows quite a wide range of impersonation scenarios that the “only once” rule does not prevent, for example: a company orders 100 devices, provisions 90 and keeps the last 10 as backups; an attacker impersonates one of those 10 and gets a key that the company has recorded as belonging to one of its legitimate devices. You need to provision a key (not necessarily the one that will be used by the final customer, it can be a temporary provisioning key) before the device leaves the manufacturer's secure supply chain.

I should have made it clear that the "initializing" should take place in the companies secure network. Either as part of the production process or as part of the sales (I assumed part of the company but did not make this clear in my "note") but I did say in my "note" that the vendor did have to initialize the device (under supervision of the customer). So any scenario where a customer has a not initialized device should not occur.

I don't think this question is answerable, given that it is extremely general and does not say anything about the device manufacturing process, the distribution process, or the device capabilities.

I do agree that given the general nature of this question an optimal (or very good) solution can not be given. The solution I provide has an inherent cost in the possibility of needing to reprogram serial numbers (or bricked devices depending on implementation). But this is intended to allow a general answer without impacting security. I believe a better solution would involve PKI for client authentication but this is prohibited by the OP.

Answer 2

There exist SoCs (Systems on a Chips) that implement deep security, having the following features:

1. On-board crypto engine
2. One-Time Programmable (OTP) memory
3. Secure boot loader (usually accessible via a UART)
4. Unique, embedded chip serial number

Security is usually implemented in the following way:

1. A manufacturer, in this case your company, creates a master key-pair in an appropriately deep-secure environment. (You may choose to have many master key-pairs, one pair for each sales region, config or whatever, in order to contain a breach.)
2. Still in the deep-secure environment, firmware is signed using the master private-key.
3. The signed firmware and the master public-key are exported from the deep-secure environment to the production-line.
4. On the production line, the master public-key is written to the OTP on the SoCs, and...
5. ...the firmware is transferred to the SoC using a secure protocol, implemented in the boot loader, which checks the signature.
6. The embedded software can now use the SoC's crypto engine and the SoC's unique serial number to generate a symmetric key (or better: assymmetric key-pair).
7. The chip's serial-number and public-key are then sent from the chip and stored in the server's database.
8. The server authenticates the chip by sending it a cryptogram of some message (a random string), which is encoded using the chip-specific public-key. The chip returns the decoded message, and the server compares this with the original.

Answer 3

I think best Industrially available technique is to use Derived unique key per transaction (https://en.wikipedia.org/wiki/Derived_unique_key_per_transaction) which is come under ANS X9.24 standard.

A single BDK ( base derived key ) able to facilitate 500,000 devices. Therefore By having several BDKs you may able to support millions of devices which able to use a unique key for every instance they are going to encrypt data.

You can store your BDKs in a industrial used HSM (Hardware Secure Module). The same HSM can be program to inject IPEK (Initial Key) to all the devices as well.

This is a technique which used in Financial Industry to inject keys to their payment devices.

The two requirements you mentioned ( using a unique and Having a Serial Number to identify devices) will satisfy by using above standard.

You may need a Secure Memory (store secure keys) and tamper resistance for your device in order make sure that the device never compromise with the keys.

Nowadays we are working on similar product (payment device) which needed the above requirements that you are highlighted, we use the above describe technique to achieve it.

Answer 4

Have the firmware generate a random private key on first startup, and store it in write-once memory. The device then needs to talk to a provisioning server, usually over a network, but you could pull it off with a UART pin for example, depending on your workflow. Send the public key in, along with the processor serial number, and have the server sign an the serial number and public key. The firmware can verify the signature, and then store the serial number and signature in the write-once memory as well to complete the provisioning process. (The public key used for provisioning can be part of the firmware image, no need to burn that in.)

Elliptic curve crypto works well for this, because keys are small and generation is simple. If you use Ed25519 for the above procedure and a 32-bit serial number, you only need 100 bytes of write-once memory for a complete provisioning package.

If you want a full X.509 certificate infrastructure, you can pull that off too: just have the provisioning server construct the certificate deterministically. Set validity dates statically, use the device serial number as the certificate serial number, and use a set of predetermined extensions (probably just basic constraints). The firmware can calculate everything about the certificate except the signature, and insert that from the write-once memory, and voilá, you have a certificate infrastructure and can use TLS for your higher-level operations. The only disadvantage is you can't use Ed25519 with most TLS libraries, so you'd have to go with ECDSA over P-256.

From this point, you can bootstrap any provisioning of secrets by transmitting them over a TLS connection, and the device can store secrets securely. This can be accomplished by generating a new ephemeral keypair for each file, deriving a symmetric file encryption key using ECDH, and storing the public key of the ephemeral pair with the encrypted file. (This provides forward secrecy. You never want to encrypt with the stored private key directly.)

The beauty of this system is that the device is requesting the key, rather than you injecting it each time, simplifying firmware flashing. If you want maximum security, have it make the request over a physical connection (UART, or just bit-bang a GPIO) to the programming computer, but it's even more secure than injecting keys because the programmer can't impersonate the device after it's provisioned.

Another benefit is that the device stores all the required state. There's no massive database of keys and serial numbers that can be lost or compromised, just a list of device serials for each processor serial, and even that can be deleted after provisioning.