In order to securely access high-value services (such as high-definition video content or e-commerce), devices need a so-called “root of trust”—most commonly a key pair for a public-key cryptography scheme. Furthermore, the devices also need an internal root of trust for securing their internal databases; most commonly, this will be a secret key (RKEK, or root key-encryption key) unique to the device and unknown outside it.
The challenge with all of these secrets is that they have to get to the device, usually at some point during its manufacturing (or when it is activated). But to get a secret from one place to another, we need a secure channel; and the only two ways known to establish such a channel are either physical security or cryptographic security. In this case, physical security implies a secure assembly plant, which raises costs. Cryptographic security, on the other hand, requires a secret key to be shared between the sender and recipient—which then becomes a chicken-and-egg problem.
The Discretix solution to provisioning the device RKEK involves use of the digital random-bit generator (DRBG) built into CryptoCell. The DRBG is built according to NIST cryptographic standards (NIST SP800-90), and produces truly random, cryptographic-strength random bit vectors. Discretix’ provisioning tools use this DRBG on the manufacturing line in order to produce the per-device key and program it securely into the device’s non-volatile memory.
Discretix’ solution to provisioning OEM-supplied assets (such as key pairs for enabling high-value services) is more complicated. The foundation for Discretix’ solution is a 128-bit secret embedded in every CryptoCell; this secret is combined with an OEM public key in order to produce a per-OEM provisioning key. Since the secret is not itself known to OEMs, these provisioning keys can only be computed by the manufacturer of the CryptoCell-enabled chip (or by the CryptoCell device itself); since the same key is used for code signing, one OEM cannot reproduce another OEM’s key. Even more importantly, no-one else—including any eavesdroppers on communication lines, or untrustworthy assembly-plant employees—can compute these keys. These keys are then used by the OEM to encrypt and sign their secure assets; the encrypted assets are recorded in the device’s memory, and the embedded CryptoCell can verify their authenticity and decrypt them when access to the services is required.
The end result from all these mechanisms is a secure solution for provisioning a device with all the secrets it needs for high-value services.
device does a lot more than you actually need. In so far as the system manages to do what is needed, nobody should complain about the extra functionality. However the extra functionality usually has severe consequences for the device’s level of security. An interesting example of this was presented at Hack in the Box this year.
