U.S. patent application number 14/505418 was filed with the patent office on 2015-08-27 for provisioning of security credentials.
This patent application is currently assigned to Cambridge Silicon Radio Limited. The applicant listed for this patent is Cambridge Silicon Radio Limited. Invention is credited to Dragan Boscovic, Nicolas Guy Alberl Graube, Mauro Scagnol.
Application Number | 20150242614 14/505418 |
Document ID | / |
Family ID | 50737759 |
Filed Date | 2015-08-27 |
United States Patent
Application |
20150242614 |
Kind Code |
A1 |
Scagnol; Mauro ; et
al. |
August 27, 2015 |
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.
Inventors: |
Scagnol; Mauro; (Cambridge,
GB) ; Graube; Nicolas Guy Alberl; (Barrington,
GB) ; Boscovic; Dragan; (South Barrington,
IL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Cambridge Silicon Radio Limited |
Cambridge |
|
GB |
|
|
Assignee: |
Cambridge Silicon Radio
Limited
Cambridge
GB
|
Family ID: |
50737759 |
Appl. No.: |
14/505418 |
Filed: |
October 2, 2014 |
Current U.S.
Class: |
726/2 |
Current CPC
Class: |
H04L 43/065 20130101;
H04W 12/003 20190101; Y02A 10/46 20180101; H04W 84/18 20130101;
H04W 12/04 20130101; Y02D 70/166 20180101; H04L 41/14 20130101;
Y02D 30/70 20200801; Y02D 70/162 20180101; H04L 43/0882 20130101;
H04L 63/061 20130101; G06F 21/44 20130101; Y02D 70/1262 20180101;
H04L 69/22 20130101; Y02D 70/22 20180101; H04L 9/0861 20130101;
Y02D 70/164 20180101; H04W 12/06 20130101; H04W 52/0251 20130101;
H04L 47/115 20130101; Y02A 10/40 20180101; G06Q 10/0833 20130101;
H04W 76/14 20180201; H04L 47/16 20130101; H04W 76/11 20180201; H04L
63/08 20130101; H04W 4/06 20130101; H04W 4/80 20180201; Y02D 70/144
20180101; Y02D 70/142 20180101; H04W 4/029 20180201; H04W 88/06
20130101; H04W 52/38 20130101; H04L 63/0853 20130101; H04B 7/14
20130101; H04H 20/71 20130101; H04L 43/0852 20130101; H04L 5/0055
20130101; H04L 45/02 20130101; H04W 16/18 20130101; H04W 40/24
20130101; H04L 41/082 20130101; H04L 49/1584 20130101; H04L 67/30
20130101; H04W 12/00522 20190101; H04W 72/12 20130101; H04L 43/10
20130101; H04W 24/06 20130101; H04L 43/0817 20130101 |
International
Class: |
G06F 21/44 20060101
G06F021/44; H04L 9/08 20060101 H04L009/08 |
Foreign Application Data
Date |
Code |
Application Number |
Feb 25, 2014 |
GB |
1403312.0 |
Feb 25, 2014 |
GB |
1403314.6 |
Mar 31, 2014 |
GB |
1405785.5 |
Mar 31, 2014 |
GB |
1405786.3 |
Mar 31, 2014 |
GB |
1405789.7 |
Mar 31, 2014 |
GB |
1405790.5 |
Mar 31, 2014 |
GB |
1405791.3 |
Mar 31, 2014 |
GB |
1405797.0 |
Jul 17, 2014 |
GB |
1412715.3 |
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.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] 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
[0002] This invention relates to provisioning a device with a means
for authenticating itself to other devices.
BACKGROUND
[0003] 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.
[0004] 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.
[0005] 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.
[0006] 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
[0007] 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.
[0008] The root identity generator may be configured to generate,
as part of the private root identity, a private key of an
asymmetric key set.
[0009] 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.
[0010] The root identity generator may be configured to generate
multiple unique root identities for the security component.
[0011] The root identity generator may be capable of repeatably
generating the root identity.
[0012] The security component may be configured not to store the
root identity.
[0013] The root identity generator may be configured to, when the
security component requires the root identity, regenerate the root
identity.
[0014] 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.
[0015] 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.
[0016] The security component may be configured not to share the
public root identity if the enrolment indicator is set.
[0017] 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.
[0018] 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.
[0019] 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.
[0020] The root identity generator may be configured to generate a
root identity during a self-test of the security component.
[0021] 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.
[0022] The security component may comprise an encryption unit
configured to encrypt and/or decrypt communications with the other
device using the private root identity.
[0023] 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.
[0024] The output may be configured to output the public root
identity for sharing with a certificate authority.
[0025] The root identity generator may comprise an entropy
source.
[0026] The security component may be for incorporation in a
wireless communication device.
[0027] 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
[0028] The present invention will now be described by way of
example with reference to the accompanying drawings. In the
drawings:
[0029] FIG. 1 shows a method for generating an identity
certificate;
[0030] FIG. 2 shows the enrolment and deployment of a chip;
[0031] FIG. 3 shows a method for blowing an enrolment fuse; and
[0032] FIGS. 4a and 4b show examples of security components.
DETAILED DESCRIPTION
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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.sub.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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.sub.chip with
CA.sub.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.
[0044] 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: [0045] The
network gateway issues an identity challenge. [0046] The chip
returns its UUID and a nonce, encrypted with the certificate
authority's public key (CAPubKey). [0047] The network gateway
transparently forwards the reply from the device to the certificate
authority. [0048] 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) [0049] The certificate authority uses the public key
(ChipPubKey) to encrypt a salted challenge, which the network
gateway transparently forwards to the device. [0050] 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). [0051] The certificate authority decrypts the reply and
confirms the identity of the device to the network gateway. [0052]
The network gateway finally allows the device to join the
network.
[0053] 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.
[0054] 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.sub.i}, i=1. NUUID
[0055] The root identity generator may also be configured to
generate an asymmetric private/public key set associated with each
unique identifier: {PrivateKey.sub.i, PublicKey.sub.i} The root
identity generator may also be configured to generate a symmetric
key associated with each unique identifier: {SymKey.sub.i}.
[0056] The root identity generator may be capable of the following:
[0057] Stochastic distribution across different chips so that,
taking a chip at random, it is statistically impossible to tell if
the i.sup.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. [0058] 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).
[0059] 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.
[0060] 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.
[0061] If the indicator is not set, the security component may be
configured to share the following with the other device:
RI.sub.chip={(UUID.sub.1:
PublicKey.sub.1,SymKey.sub.1),(UUID.sub.2:
PublicKey.sub.2,SymKey.sub.2), . . . }
[0062] 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.
[0063] 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).
[0064] 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.
[0065] 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}.
[0066] 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.sub.chip extraction. It
may also coordinate Root of Trust activities.
[0067] 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.
[0068] 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).
[0069] 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.
[0070] 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.
* * * * *