5

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.
  • 1
    @Purefan: If I understand correctly, to ssh into the device would entail (a) that it is a member of a network, and (b) that there is a private key installed there (part of a symmetric pair). I think use of ssh is good, but it would create a new problem. – D.H. Sep 7 '15 at 12:47
  • 3
    I think the term for this is "device provisioning" if it helps your googling. – domen Sep 7 '15 at 13:19
  • 1
    Do you need a symmetric key (only)? I would think that you might simplify the requirements and potentially improve security if you say each device needs a key, serial pair at the end of the process. For example, if each device generates an asymmetric keypair and exports the public key and its serial number, then there's no risk that your factory has a list of all the symmetric keys. – Adam Shostack Sep 7 '15 at 15:31
  • 1
    "No two devices can get the same key. The system needs to ensure that each key is only used once." Is there any reason to require absolute uniqueness? Is generating a random key not enough? Chances are extremely small to get a duplicate key and even if one existed finding which two devices got the same key is difficult (without a DB with all the keys of course). Exploiting the possibility of a duplicate key seems practically impossible to me (given decent key size of course). I believe requiring absolute uniqueness may actually lower the security of such system. – Selenog Sep 14 '15 at 11:51
  • 1
    D.H. : I won't post this as an answer, since it really isn't quite, but I think the practical aspects of the personalization/key injection process are going to depend on the factor of what kind of secure environment will be in this device. Meaning: it sounds like you definitely want inside your device either (a) a tamper-resistant, hardened chip/module to hold the key or (b) an actual (if small) complete secure cryptographic processing module to handle encryption & decryption all-together. There are certainly many suppliers with many solutions out there for both of those, and ... (cont.) – mostlyinformed Sep 16 '15 at 18:19
3
+25

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.

| improve this answer | |
  • Your proposed system doesn't work: the server has no way to know whether the serial number sent in the request is genuine. The “only once” mechanism means that there won't be two devices with the same key, but it means that some devices will be bricked as communication breaks down for one reason or another, and it enables a trivial DoS attack where an attacker claims all serial numbers. (cont.) – Gilles 'SO- stop being evil' Sep 15 '15 at 11:13
  • (cont.) 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. – Gilles 'SO- stop being evil' Sep 15 '15 at 11:14
  • +1 for "reduce the size of the secure environment". This is a highly desirable objective. – D.H. Sep 16 '15 at 16:57
  • 1
    A small note: You want to avoid an RSA scenario--a hack that gets to and steals cryptographic secrets-- here at all possible costs. Getting into the key generation/injection/storage area means protecting the security of these keys is going to be one of the most critical aspects of your business. Be ready to do air-gapping, intense physical security, EM isolation of the most important areas... you get the point. If that sounds like too much pain, farm out the key generation & injection (at least) if you can. (Though RSA proved that even that's not bulletproof today.) – mostlyinformed Sep 16 '15 at 19:00
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.
| improve this answer | |
  • My answer assumes that the devices are proprietary, with production managed by you. It does not assume general purpose, existing devices - like smartphones, tablets and laptops. – Potion Sep 18 '15 at 19:26
  • Thanks @Potion, very interesting. Your assumption is correct. How well does this scale up for a huge number of devices? – D.H. Sep 19 '15 at 6:13
  • In this case, the key is derived from the chip serial number alone. This is dangerous, because that is not typically private information! – Reid Rankin Sep 19 '15 at 14:37
  • As I understand the question it specifically asks for device key injection (there is already a key) instead of device key generation. Quote from OP: "You can assume for this question that keys have already been generated and have an associated identifier. The set of keys is an input to the process this question is trying to elucidate." Of course key generation has a lot of advantages, hence why the industry uses it (almost exclusively to my knowledge). (Same thing for assym vs sym keys.) But as this question asks for sym key injection, I feel like this does not answer the question. – Selenog Sep 22 '15 at 7:15
  • @DH - In this particular case the internal Unique ID is never published. It cannot be derived from the 'outside' serial number. – Potion Sep 23 '15 at 20:26
0

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.

| improve this answer | |
  • 1
    The same HSM can be program to inject IPEK (Initial Key) to all the devices as well. How is it physically done and how does the physical process scale up? – D.H. Sep 19 '15 at 7:11
  • In Payment Industry, Prior to giving the Payment device to their Merchants, Bank will inject relevant IPEK to the devices by using their HSM. The relevant program inside the HSM ( which is in the Bank key injection Facility ) make sure that each device get unique initial key and initial KSN. After Payment device located in the Merchant store, whenever a PIN enter by a customer, the relevant encrypted PIN block will send to the bank to verify it. So the same PIN block will divert to the HSM to decrypt the PIN block, Since it has the capability identify key ( using KSN) to decrypt it. – Muditha sumanathunga Sep 19 '15 at 11:56
  • The beauty of DUKPT KSN is, it has a TRSM id ( in your case the Serial number of the device) which help to identify the device correctly when a encrypted PIN block received by the BANK – Muditha sumanathunga Sep 19 '15 at 12:00
0

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.