PROVISIONING OF SECURITY CREDENTIALS

Abstract

A security component for authenticating a device, within which it is incorporated, with another device, the security component comprising a root identity generator configured to generate a root identity comprising a public root identity and a private root identity for the security component and an output configured to output the public root identity for sharing with the other device and to not output the private root identity.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This non-provisional patent application claims priority to Great Britain applications: GB 1412715.3, filed Jul. 17, 2014; GB 1405790.5, filed Mar. 31, 2014; GB 1403314.6, filed Feb. 25, 2014; GB 1405785.5, filed Mar. 31, 2014; GB 1405786.3, filed Mar. 31, 2014; GB 1405789.7, filed Mar. 31, 2014; GB 1403312.0, filed Feb. 25, 2014; GB 1405791.3, filed Mar. 31, 2014; GB 1405797.0, filed Mar. 31, 2014.

TECHNICAL FIELD

This invention relates to provisioning a device with a means for authenticating itself to other devices.

BACKGROUND

Security is of increasing concern in the so-called Internet of Things. The identity and integrity of an individual device is of paramount importance in a network of potentially thousands of cooperating elements. A typical approach is to provide specific hardware on the device to act as the root of trust and propagate that trust up to other firmware and applications executing on the device.

The root of trust is a fundamental concept from which the security of the whole device and the services provided to/by the device propagates. The component should be reliable, tamper-proof and consistently behave in an expected manner. It should provide the minimum set of functionality needed to assess the integrity of the platform and the associated trustworthiness such as: measurement/storage/reporting of a set of metrics describing the platform characteristics (e.g. signed firmware hashes), and access to data signing/encryption for authentication, integrity and confidentiality purposes.

At the heart of the root of trust is usually a secret. The secret may be a truly random number that represents or assists in the generation of a cryptographical secret, such as a symmetric key or an asymmetric key-set, embedded in a controlled environment into the hardware of the chip/device, which can be challenged later. The secret is usually generated outside the chip and later embedded in the chip. This creates a serious challenge in managing the secret, which must be tightly controlled and monitored all the way through. Information on the secret (such as a private key burnt into the chip/device) might leak before or after manufacturing, invalidate the scheme and expose the customer to the risk of cloning and theft of sensitive data. Thus safe rooms (or “cages”) are typically required during manufacture.

There is a need for an improved mechanism for provisioning a device with security details that will enable it to authenticate itself with another device.

SUMMARY OF THE INVENTION

According to a first embodiment, there is provided a security component for authenticating a device, within which it is incorporated, with another device, the security component comprising a root identity generator configured to generate a root identity comprising a public root identity and a private root identity and an output configured to output the public root identity for sharing with the other device and to not output the private root identity.

The root identity generator may be configured to generate, as part of the private root identity, a private key of an asymmetric key set.

The root identity generator may be configured to generate, as part of the public root identity, one or more of a unique identifier for the security component, a public key of an asymmetric key set and a symmetric key.

The root identity generator may be configured to generate multiple unique root identities for the security component.

The root identity generator may be capable of repeatably generating the root identity.

The security component may be configured not to store the root identity.

The root identity generator may be configured to, when the security component requires the root identity, regenerate the root identity.

The security component may comprise a memory configured to store the root identity and the security component may be configured to, when it requires the root identity, retrieve it from memory.

The security component may comprise an enrolment indicator and may be configured to, when the public root identity is shared with the other device, set the enrolment indicator.

The security component may be configured not to share the public root identity if the enrolment indicator is set.

The root identity generator may be configured to, each time that the security component is required to generate a root identity when the enrolment indicator is not set, generate a new root identity.

The root identity generator may be configured to, each time that the security component is required to generate a root identity when the enrolment indicator is set, regenerate a previously generated root identity.

The root identity generator may be configured to, each time that the security component is required to generate a root identity when the enrolment indicator is set, regenerate the root identity that comprises the public root identity shared with the other device.

The root identity generator may be configured to generate a root identity during a self-test of the security component.

The security component may be configured not to share the private root identity with parts of the device that are outside of the security component.

The security component may comprise an encryption unit configured to encrypt and/or decrypt communications with the other device using the private root identity.

The encryption unit may be configured to encrypt any data that it shares with the other device with a public key of the other device.

The output may be configured to output the public root identity for sharing with a certificate authority.

The root identity generator may comprise an entropy source.

The security component may be for incorporation in a wireless communication device.

According to a second embodiment, there is provided a method for provisioning a device with security credentials to enable it to authorise itself with another device, comprising incorporating a security component in the device, generating, by means of the security component, a root identity comprising a public root identity and a private root identity and the security component outputting the public root identity for sharing with the other device and not outputting the private root identity.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described by way of example with reference to the accompanying drawings. In the drawings:

FIG. 1 shows a method for generating an identity certificate;

FIG. 2 shows the enrolment and deployment of a chip;

FIG. 3 shows a method for blowing an enrolment fuse; and

FIGS. 4a and 4b show examples of security components.

DETAILED DESCRIPTION

The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art.

The general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

An example of a method for generating an identity certificate for a device is shown in FIG. 1. The device incorporates a security component. This component may be capable of acting as a silicon root of trust for the device. It is likely to be implemented as an integrated circuit or chip. The method starts in step S101 with the security component generating a root identity. The root identity is a fundamental, source of identification for a “thing”, e.g. a device in the Internet of Things. Its main purpose is to provide the basis for authentication, authorisation, accountability and accounting of services for the “thing”. The root identity can be mapped onto authenticating data such as unique identifiers (UUID), symmetric keys or private/public key sets. It can be used to seed and/or validate additional identities in order to enable access to specific services. The root identity should be exposed as little as possible to prevent theft, abuse and privacy loss.

The root identity may comprise some components that are “public” in the sense that, while they should be exposed as little as possible, some public exposure is necessary to authenticate the device. The public parts of a root identity may include, for example, one or more of a unique identifier for the security component, a symmetric key, and a public key. The public root identity typically includes information that has to be exposed to a certificate authority to record a Root Identity Certificate that can later be used to authorise the security component. Other parts of the root identity can be considered “private” because they do not need to be exposed during any authentication procedure and should be kept secret by the device. An example of a private part of a root identity is a private key from an asymmetric key pair. The security component may generate both public and private parts of its root identity internally.

The security component can be requested to provide its root identity (step S102). The security component determines whether it is currently operating in an enrolment phase (step S103). If yes, the security component returns its public root identity to the requester (step S104). If no, the security component does not provide its public root identity to the requester (step S105). The private root identity is not provided to the requester.

A more detailed example of a chip generating an identity certificate is shown in FIG. 2, with additional information about how the chip might respond to authentication requests after deployment.

FIG. 2 shows a chip during an enrolment phase (shown generally at 201) and later deployment phase (shown generally at 202). The chip (204) comprises means for autonomously generating one or more root identities for the chip (RI_chip). The chip may generate the root identities during the enrolment phase or earlier, such as during manufacture. In one example the root identities may be generated during the first self-test of the chip. The chip may be configured to store the one or more root identities once generated so that they can be retrieved when needed. Alternatively the chip may also be capable of re-generating the root identities when required. Having the one or more root identities generated on the chip avoids the manufacturer having to securely manage cryptographic secrets before, during and after manufacture.

The certificate authority (203) will still need to know the public root identity of the chip before it is deployed, however, so that it can authenticate the chip later. One possible opportunity for obtaining this information is at the end of manufacture, during chip testing. The root identity encrypted with the public key of a certification authority may be exposed to firmware and retrieved by a manufacturing testing JIG, for example. The root identity may then be safely stored on a local or remote server as a Root Identity Certificate before the chip is shipped to a customer.

The public root identity may only be able to be exposed to the manufacturer until the manufacturing process is finished. One way of achieving this is to include one or more “enrolled fuses” on the chip. Once the enrolled fuse is blown, the root identity can no longer be read from the chip. If the manufacturer's certificate authority will be storing the Root Identity Certificate, only one enrolled fuse is required. Alternatively, the manufacturer could sell chips to customers with their own certificate authority. To enable this, some chips may have an extra enrolment fuse. This is termed “UseOtherCAPubKeyFuse” (see FIGS. 4a and 4b), since if this fuse is blown by the manufacturer, it indicates that the harvesting process will be conducted using the public key of the customer's certificate authority rather than the manufacturer's. This additional public key may be written in NVM (non-volatile memory) or OTP (one-time programmable memory) (e.g., OTP 406) before enrolment takes place. An example method for blowing an enrolment fuses that implements the mechanism described above is shown in FIG. 3.

The chip may generate its root identity during a self-test procedure, as mentioned above. The chip may go through multiple self-tests during manufacture. The chip may generate one or more root identities during each of these self-tests. These root identities may be different from one another, because the chip only needs to be able to re-generate an existing root identity after that root identity has been passed to a certificate authority. The chip may therefore be configured to generate new root identities until the enrolment phase is complete (e.g. the fuse has blown) and thereafter either re-generate the root identities that have been passed to the certificate authority or retrieve them from memory (if the chip is configured to store its root identities). The re-generated identities may be the same as those that the chip previously generated, and the same as the identities shared with the certificate authority.

An advantage of the method described above is that the private root identity, such as the private keys of the asymmetric key sets, are internally generated in the chip. The initial generation of the private root identity is thus independent of any external input, so the manufacturer is freed from having to protect cryptographic secrets. The root identity is additionally not exposed to the rest of the chip, and particularly not to firmware, after enrolment has been completed. Indeed most the information released by the chip during enrolment will be publicly exposed during use of the device anyway. The exception is any symmetric keys (SymKey), although the risk that these might fall into the wrong hands can be reduced by encrypting RI_chip with CA_PubKey. If the reduced level of security is unacceptable, then symmetric keys need not be exchanged as part of the enrolment process. Thus, the exact contents of the “private” and “public” parts of the root identity may depend on the context. In some implementations a symmetric key may not be exchanged at enrolment, so that it forms part of the private root identity, and at other times it may be exchanged at enrolment, and form part of the public root identity.

The Root Identity Certificates stored by the certificate authority can later be used to authenticate the chip's identity and integrity following a challenge in the field. An example of this is shown as part of the “deployment process” in FIG. 1. In this example, after the enrolment phase has been terminated and the device (onto which the chip is embedded) deployed in the field, a network gateway challenges the identity and application/firmware integrity of the chip. The actors in this process are a new device (204), a network gateway (205) that can admit the device to a network and the certificate authority (203), whose address is known to the gateway. The certificate authority vouches for the identity and integrity of the device (via the chip) as follows:

• • The network gateway issues an identity challenge.
  • The chip returns its UUID and a nonce, encrypted with the certificate authority's public key (CAPubKey).
  • The network gateway transparently forwards the reply from the device to the certificate authority.
  • The certificate authority decrypts the chip's initial response to the challenge, identifies the UUID and fetches from the database the associated public key of the chip (ChipPubKey)
  • The certificate authority uses the public key (ChipPubKey) to encrypt a salted challenge, which the network gateway transparently forwards to the device.
  • Only the real chip is able to decrypt the challenge using its private key and successfully reply using the certificate authority's public key (CAPubKey).
  • The certificate authority decrypts the reply and confirms the identity of the device to the network gateway.
  • The network gateway finally allows the device to join the network.

In a further development the chip may autonomously re-generate its root identity. This is represented in FIG. 2 by PUF (physically unclonable function) 206. Thus, rather than storing its root identity the chip may just regenerate it when required, hence improving security.

Specific examples of a security component are shown in FIGS. 4a and b. The security component might be incorporated into a wide range of devices but it is likely that it will most commonly be incorporated into devices that are configured for wireless communication. In general terms, the security component comprises a root identity generator, which may provide the ability to generate a configurable number (NUUID) of unique identifiers (UUIDs). The identifiers are thus unique in the sense that they are unique to the component, but each component may have multiple identifiers: {UUID_i}, i=1. NUUID

The root identity generator may also be configured to generate an asymmetric private/public key set associated with each unique identifier: {PrivateKey_i, PublicKey_i} The root identity generator may also be configured to generate a symmetric key associated with each unique identifier: {SymKey_i}.

The root identity generator may be capable of the following:

• • Stochastic distribution across different chips so that, taking a chip at random, it is statistically impossible to tell if the i^th bit of any of the identifiers and/or keys is a 0 or a 1, even if one or more of the other bits are known and even if the output of all other chips is known.
  • Generating different sizes of identifiers and/or keys and identifiers and/or keys that can be used for different purposes (e.g. signing vs. encryption).
  • Autonomous regeneration of identifiers and/or keys each time that the chip is powered up or each time that the chip needs to use the identifiers and/or keys. Identifiers and/or keys may be strictly repeatable over a wide range of operative conditions, in temperature and voltage and across different power-cycling events. The key generator need only be configured to regenerate identifiers and/or keys after it has been through the enrolment phase. Before that point, the key generator may be configured to generate new identifiers and/or keys each time that the chip is powered up or goes through a self-test procedure.

The security component may comprise an output for sharing some security information with another device, so that the other device may authenticate it. This shared information is likely to include a unique identifier, public key of an asymmetric key pair and possibly a symmetric key pair. This information is suitably only shared during the enrolment phase, however. The security bit may therefore comprise an indicator such as an enrolment fuse or bit in OTP, which can be blown/set when the enrolment phase is completed.

If the indicator is not set, the security component may be configured to share the following with the other device:

RI_chip={(UUID₁: PublicKey₁,SymKey₁),(UUID₂: PublicKey₂,SymKey₂), . . . }

The security component may comprise an encryption unit for encrypting the information to be shared with the public key of the other device (which is likely to be associated with a certification authority). The information may be shared with the other device by being exposed to the firmware of the device within which the security component is incorporated, from which it can be transferred to the other device via a wired or wireless connection.

If the indicator is set, the security component may be configured to regenerate the set of identifiers and keys (or of a part of it), in the same way as at initial switch on, at power up and/or on-demand, but the set is not exposed to any other part of the device (e.g. firmware).

Examples of two different security components are shown in FIGS. 4a and 4b (like components across the two figures are indicated by like numerals). In the examples of FIGS. 4a and 4b, the root identity generator is implemented by crypto-block 401. The root identity generator may comprise a repeatable source of entropy capable of seeding the identifier and/or keys. In the example of FIG. 4a, the source of entropy is Physical Unclonable Function Block (PUF) 403, which is configured to provide a seed to cryptographic engine 402. Another embodiment is presented in FIG. 4b. In this example the source of entropy is a true random number generator 409 (possibly one that is National Institute of Science and Technology (NIST) compliant). The random number generator may be configured to generate the seed once at enrolment. The seed is then written in OTP and extracted from OTP every time that identifier and/or key regeneration is needed.

Crypto-block 401 comprises a cryptographic engine 402. The entropy source 403 is configured to seed the generation of a root identity by providing a seed to the cryptographic engine. The entropy source may generate the same or different seed for each functional unit in the cryptographic engine that generates a respective element of the root identity. Examples of suitable functional units include:

1. an Elliptical Curve Cryptography (ECC) multiplier to generate the public/private key pair as a set of asymmetric elliptic cryptographic keys {PrKey, PubKey};
2. a key derivation function to generate a symmetric key {SymKey}; and
3. a hashing function to generate a unique identifier {UUID}.

The cryptoblock 401 is managed by trusted processor block 404 that has exclusive access to the configuration registers 405 of the crypto-block. The processor block may be configured to coordinate entropy source operation and RI_chip extraction. It may also coordinate Root of Trust activities.

The security component also comprises an output represented by bus 408 for sharing its public root identity with other parts of the device or a certificate authority. Bus 408 is merely an example, and any suitable wired or wireless output means might be employed. The security component also comprises an enrolment fuse 407 for preventing transfer of the public root key after the enrolment process is complete.

The structures shown in FIGS. 4a and 4b (and indeed all block apparatus diagrams included herein) are intended to correspond to a number of functional blocks in an apparatus. This is for illustrative purposes only. FIGS. 4a and 4b are not intended to define a strict division between different parts of hardware on a chip or between different programs, procedures or functions in software. In some embodiments, some or all of the algorithms described herein may be performed wholly or partly in hardware. In other implementations, the algorithms may be implemented by a processor acting under software control. Any such software may be stored on a non-transient computer readable medium, such as a memory (RAM, cache, hard disk etc) or other storage means (USB stick, CD, disk etc).

The provisioning methods and security component described above invert the role between originator and receiver of the cryptographical secret: the secret is generated on the chip and only public data is exposed during the enrolment process to the manufacturer. Private data is retained on the chip. If public data is leaked for a batch of chips, the manufacturer might lose income associated with providing a recurring identification and integrity verification service to a customer of those chips, but data confidentiality has not been compromised nor impersonation allowed. The prospect of external secret-leaking before, during and after manufacture is avoided since the focus has shifted from the securely storing keys externally provided by the manufacturer to chip internal, autonomous (re)generation of cryptographical secrets. Thus, provided that side-attacks are prevented, impersonation and sensitive data stealing are not possible unless the chip's private keys are extracted from the crypto-block using lab-attacks. This is theoretically impossible with a PUF since accessing the PUF structure by definition alters its behaviour. It is also highly unlikely with OTP.

The applicant hereby discloses in isolation each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the present specification as a whole in the light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein, and without limitation to the scope of the claims. The applicant indicates that aspects of the present invention may consist of any such individual feature or combination of features. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.

Claims

1. A security component for authenticating a device, within which it is incorporated, with another device, the security component comprising:

a root identity generator configured to generate a root identity comprising a public root identity and a private root identity; and

an output configured to output the public root identity for sharing with the other device and to not output the private root identity.

2. The security component as claimed in claim 1, the root identity generator being configured to generate, as part of the private root identity, a private key of an asymmetric key set.

3. The security component as claimed in claim 1, the root identity generator being configured to generate, as part of the public root identity, one or more of a unique identifier for the security component, a public key of an asymmetric key set, and a symmetric key.

4. The security component as claimed in claim 1, the root identity generator being configured to generate multiple unique root identities for the security component.

5. The security component as claimed in claim 1, the root identity generator being capable of repeatably generating the root identity.

6. The security component as claimed in claim 1, the security component being configured not to store the root identity.

7. The security component as claimed in claim 1, the root identity generator being configured to, when the security component requires the root identity, regenerate the root identity.

8. The security component as claimed in claim 1, the security component comprising a memory configured to store the root identity and being configured to, when it requires the root identity, retrieve it from memory.

9. The security component as claimed in claim 1, comprising an enrolment indicator, the security component being configured to, when the public root identity is shared with the other device, set the enrolment indicator.

10. The security component as claimed in claim 9, the security component being configured not to share the public root identity if the enrolment indicator is set.

11. The security component as claimed in claim 9, the root identity generator being configured to, each time that the security component is required to generate a root identity when the enrolment indicator is not set, generate a new root identity.

12. The security component as claimed in claim 9, the root identity generator being configured to, each time that the security component is required to generate a root identity when the enrolment indicator is set, regenerate a previously generated root identity.

13. The security component as claimed in claim 9, the root identity generator being configured to, each time that the security component is required to generate a root identity when the enrolment indicator is set, regenerate the root identity that comprises the public root identity shared with the other device.

14. The security component as claimed in claim 1, the root identity generator being configured to generate a root identity during a self-test of the security component.

15. The security component as claimed in claim 1, the security component being configured not to share the private root identity with parts of the device that are outside of the security component.

16. The security component as claimed in claim 1, comprising an encryption unit configured to encrypt and/or decrypt communications with the other device using the private root identity.

17. The security component as claimed in claim 16, the encryption unit being configured to encrypt any data that it shares with the other device with a public key of the other device.

18. The security component as claimed in claim 1, the output being configured to output the public root identity for sharing with a certificate authority.

19. The security component as claimed in claim 1, in which the root identity generator comprises an entropy source.

20. A method for provisioning a device with security credentials to enable it to authorise itself with another device, comprising:

incorporating a security component in the device;

generating, by the security component, a root identity comprising a public root identity and a private root identity; and

the security component outputting the public root identity for sharing with the other device and not outputting the private root identity.