Patent Description:
Attestation is a data processing technique allowing a validating entity (for example, a data processing device) to determine the trustworthiness and/or capabilities of another entity or data processing device it is interacting with. For example, a client device connecting to another device running a particular software service may need to be able to verify that the service has been instantiated correctly and is running in the context of a trusted hardware implementation. Similarly, an loT (internet of things) service may need to be able to determine the capabilities and/or trustworthiness of an loT device connecting to it.

In previously proposed implementations of attestation, a dedicated protocol is used requiring integration throughout a system of interacting entities, potentially including dedicated hardware integration. There is currently a large number of such attestation protocols and systems in existence, each tailored to the specific needs of individual systems of interacting entities. These vertically integrated protocols are considered unlikely to be standardised, harmonised, or replaced, and may even represent commercial barriers of entry between competing systems.

As secure systems grow larger and more common, this arrangement can become costly and cumbersome for device vendors to adapt to a changing market place, costly and cumbersome for software vendors as the immutable root of trust is part of device hardware, and hence attestation requires hardware specific porting and implementations of attestation clients, and/or costly and cumbersome for validating entities having to potentially support multiple protocols and interacting systems.

<CIT> relates to protocol-independent remote attestation and sealing. Messages, including messages in conformance with various protocols, can be hashed and the hash values added to an event log and provided to a Trusted Platform Module (TPM), which can extend one or more Platform Configuration Registers (PCRs) with the hash value, much as it would with the hash of a component that was installed or executed on the computing device with the TPM. Subsequently, the TPM can sign one or more of the PCRs and the signed PCRs can be transmitted, together with the event log and a copy of the messages. The recipient can verify the sender based on the signed PCRs, can confirm that the signed PCRs match the event log, and can verify the hash of the message in the event log by independently hashing it.

Aspects and features of the present technology are defined by the appended claims.

The present technique will be described further, by way of example only, with reference to embodiments thereof as illustrated in the accompanying drawings, in which:.

Referring now to the drawings, <FIG> schematically illustrates a data processing device <NUM> suitable for use as a device capable of responding to an attestation request, comprising application program execution circuitry <NUM> having a processing element or central processing unit (CPU) <NUM>, a memory <NUM> such as a random access memory (RAM), an interface <NUM> and storage (such as a non-volatile machine-readable memory such as a flash memory) <NUM> for one or more application programs. The apparatus also comprises a secure storage module <NUM> in data communication with the application execution circuitry <NUM>.

The secure storage module <NUM> may be implemented as temper-resistant memory accessible under all circumstances by the circuitry <NUM>. In other examples the term "tamper resistance" refers to the memory being hardened or secured against alterations made after manufacture of the device <NUM> and/or to accesses made other than by the circuitry <NUM> or permitted applications executing on the circuitry <NUM>.

In other examples, the secure storage module <NUM> may be a so-called Trusted Platform Module (TPM) which again represents a tamper-resistant piece of cryptographic hardware built into the device <NUM> that, as well as storing one or more keys as discussed below, can also implement at least some cryptographic functions on the basis of which a set of cryptographic operations can be constructed. A description of TPMs is provided at the following link: https://en. org/wiki/Trusted_Platform_Module.

In some examples, the TPM, as an example of the secure storage module <NUM>, may have capabilities of performing public key cryptographic operations, computing hash functions, securely storing keys and other secret data, along with potentially generating random numbers and performing attestation functions to be discussed below. In this context, a hash function is a mathematical function used to map an input data space to a generally smaller output data space. In the context of cryptography, hash functions are generally established to render it difficult to select another input value which leads to the same output hash value.

So, as part of the functionality of the secure storage module <NUM>, at least a so-called device-specific key (DSK) or implementation key <NUM> is securely stored. This is provided and stored at manufacture of the device <NUM> and is provided according to a method to be described below with reference to <FIG>.

Therefore, using techniques to be described further below, the device <NUM> can provide an example of a data processing device comprising: circuitry <NUM> to store a device-specific key; and circuitry <NUM>/<NUM> to generate, in response to a request for attestation by a second data processing device, a device-specific attestation message in dependence upon the device-specific key, a hardware configuration of the data processing device and a software configuration of software running on the data processing device, to generate an application-specific attestation message in dependence upon an interaction protocol by which the data processing device and the second data processing device interact and to cryptographically bind the application-specific attestation message to the device-specific attestation message.

Referring to <FIG>, at a step <NUM>, a verification apparatus, for example provided by a verification service, generates the device-specific key <NUM>. This is unique to the device <NUM>, or at least unique within a family of devices including the device <NUM> (so that for any particular instance of the device <NUM>, the DSK <NUM> is unique at least as regards any other instance of the device <NUM>). At a step <NUM>, the verification service, for example using the verification apparatus, cryptographically signs the device-specific key. At a step <NUM>, the device-specific key <NUM> is stored in the secure storage module as part of manufacture of the device <NUM>.

<FIG> is a schematic flow chart illustrating an example technique for controlling access to the device-specific key held by the secure storage module. This provides an example in which the second data processing device (the device <NUM>) securely stores a device-specific key and in which the step of generating the device-specific attestation message comprises attestation client software of the second data processing apparatus accessing the securely stored device-specific key.

In at least some examples, when access to the device-specific key is requested by an application program at the circuitry <NUM>, the CPU <NUM> or a hash function generator of the secure storage module <NUM> generates a hash value from the computer software forming the application program at a step <NUM> this is passed to the secure storage module which then compares the generated hash value with a stored hash value of an allowable application program which should be permitted to access the device-specific key. At a step <NUM>, the secure storage module allows or declines access to the device-specific key in dependence upon whether the hash value provided by the CPU at the step <NUM> is the same as a stored hash value is detected at the step <NUM>.

Therefore, this provides an example of an accessing step comparing a hash value dependent upon the client software attempting to access the device-specific key with a set of one or more hash values indicating that access to the securely stored device-specific key is allowed.

In these or other examples, the arrangement as described can inhibit or restrict access to the device-specific key other than by indirect access using device-specific attestation software (for example, running as an example of the application program code <NUM>). Such software could use a secret hashing or encryption algorithm or the like to provide access to the device-specific key, or could test for the presence of certain device-specific hardware and/or software features in order to allow such access.

An overview of the present embodiment is provided by <FIG>. Here, the attestation process is considered separately (or partitioned) as between the attestation of device-specific aspects such as a hardware configuration of the device to be attested and the software configuration of software running on that device, separately from protocol-specific attestation relating to application-specific considerations upon which an interaction protocol by which the data processing devices (the device requesting attestation and the device to be attested) will communicate.

Examples of application-specific attestation parameters can include the following;.

Examples of device-specific attestation parameters can include the following:.

Referring to <FIG>, the device-specific key <NUM> is referred to as the implementation key or implementation attestation key in the drawing. An implementation signer <NUM> issues an implementation key at device manufacture. The implementation signer is associated with an implementation verifier <NUM>. The signed implementation key identifies (or can be used to verify an assertion of) the device specific aspects of the implementation of the device <NUM> (such as a device <NUM> of <FIG>) and is installed in the secure storage of the device <NUM> at manufacture <NUM>. The device <NUM> has a protocol-specific (application-specific) attestation client application <NUM> which obtains a signed attestation <NUM> from or using the secure storage <NUM> of the device <NUM>.

The attestation process can take various forms. For example, to generate the device-specific attestation message, the secure storage module <NUM> can be provided with (at manufacture) data indicating hardware features of the device <NUM>, which can be provided in the form of a message signed(for example, using functionality of the secure storage module <NUM>) by the device-specific key <NUM>.

The application-specific attestation message can for example be generated as follows. The application program running on the application program execution circuitry <NUM> generates a public/private key pair, used to sign application specific messages. The secure storage module signs a hash of the public key with the DSK <NUM>, creating a cryptographic binding.

The attestation client <NUM> implements an attestation protocol with a validating entity <NUM> such as another data processing device (an example of which will be described below with reference to <FIG>). The attestation client controls the cryptographic binding of any protocol specific attestation information <NUM> to the implementation attestation <NUM>. The binding operation will be discussed further below with reference to <FIG>. This therefore links the protocol specific attestation information with the root of trust represented by the implementation attestation key <NUM> without requiring protocol-specific hardware provisioning at the device <NUM>.

The validating entity <NUM> verifies the protocol specific attestation with a protocol specific verifier <NUM> which in turn interacts with the implementation verifier <NUM> to verify the implementation attestation <NUM> which was used to cryptographically sign the protocol specific attestation.

<FIG> is a schematic flowchart illustrating a method. In <FIG>, operations by a validating device (referred to as a first data processing device) are shown to the left of a dashed line <NUM>, and operations by a device to be validated (referred to as a second data processing device) are shown to the right of the broken line <NUM>. The method comprises the following steps.

At a step <NUM>, the first data processing device (the validating entity <NUM> in <FIG>) requests attestation of or by the second data processing device.

At a step <NUM>, the second data processing device (the device <NUM> in <FIG>) generates a device-specific attestation message <NUM> in dependence upon a device-specific key, a hardware configuration of the second data processing device and a software configuration of software running on the second data processing device.

At a step <NUM>, the second data processing device generates an application-specific attestation message <NUM> in dependence upon an interaction protocol by which the first data processing device and the second data processing device interact.

At a step <NUM>, the second data processing device cryptographically binds the application-specific attestation message <NUM> to the device-specific attestation message <NUM>.

Note that in some example embodiments, the step <NUM> can involve signing the messages generated at both steps <NUM> and <NUM> together, creating the cryptographic binding.

At a step <NUM>, the first data processing device verifies the application-specific attestation message, the verifying step comprising detecting a trusted status of the application-specific attestation message by verifying the device-specific attestation message cryptographically bound to the application-specific attestation message.

The steps <NUM> (<FIG>) and <NUM> (<FIG>) can concern interaction with the same entity, in that they can provide an example of a verification apparatus generating the device-specific key for storage by the second data processing device; and an example of a verifying step comprises the first data processing device requesting verification of the device-specific attestation message by the verification apparatus.

At a step <NUM>, the first data processing device establishes an interaction with the second data processing device according to the interaction protocol, in dependence upon the verified application-specific attestation message.

As shown schematically by the steps <NUM>, <NUM>, the establishing of the interaction can involve the first and second data processing devices exchanging one or more session keys (for example, by a so-called Diffie-Hellman key exchange technique for encrypted communication between the first and second data processing devices, and carrying out communication using the session keys.

<FIG> schematically illustrates the process of cryptographic binding of the device-specific attestation message and the application specific attestation message. Steps to the left of a broken line <NUM> are carried out by the verifying device and steps to the right of the broken line <NUM> are carried out by the device to be verified.

Generally speaking, cryptographic binding provides a technique for demonstrating data integrity and authenticity using cryptographic operations. In some examples, the technique can operate by generating a hash value of each data object and digitally signing the collection of one or more hash values. When the data is subsequently accessed, the signature can be verified and any discrepancy in hash values can be used to detect which data object has been modified since the binding operation took place.

At a step <NUM>, the device to be verified generates a hash of the application specific attestation message and at a step <NUM> cryptographically signs the generated hash using the implementation key or device-specific key.

At a step <NUM>, the verifying device verifies the signature, potentially with reference to the verifier <NUM>. The verifying device generates a corresponding hash value using the same hash algorithm at a step <NUM> and compares the just-generated hash value with the signed hash value at a step <NUM>. If the two match then the application-specific attestation message can be trusted.

Note that as discussed above, in some other example embodiments, this process may effectively be performed at the same time as generating the device specific attestation, to prove that the signed binding and device specific attestation go together. In other words, in some examples the step <NUM> can involve signing both <NUM> and <NUM> together, creating the binding.

<FIG> schematically illustrates a verification requesting data processing device <NUM> comprising a processing element such as a central processing unit or CPU <NUM>, one or more memories <NUM> including for example a RAM and storage (such as a non-volatile machine-readable memory such as a flash memory) for one or more application programs, and an interface <NUM>.

<FIG> therefore provides an example of a data processing device comprising: circuitry to request attestation of a second data processing device and to receive from the second data processing device a device-specific attestation message in dependence upon a device-specific key, a hardware configuration of the second data processing device and a software configuration of software running on the second data processing device, cryptographically bound to an application-specific attestation message in dependence upon an interaction protocol by which the data processing device and the second data processing device interact; circuitry to verify the application-specific attestation message, the verifying comprising detecting a trusted status of the application-specific attestation message by verifying the device-specific attestation message cryptographically bound to the application-specific attestation message; and circuitry to establish an interaction with the second data processing device according to the interaction protocol, in dependence upon the verified application-specific attestation message. These functions can be performed by the CPU <NUM> under the control of computer software stored by the memory <NUM>.

The interactions shown in <FIG> can take place in the context of a data processing system comprising a data processing device <NUM> of <FIG> configured to interact with a data processing device <NUM> of <FIG>, using the established interaction protocol.

<FIG> is a schematic flowchart illustrating a method of operation of a data processing device (such as a device to be validated, for example the device of <FIG>), the method comprising:.

<FIG> is a schematic flowchart illustrating a method of operation of a data processing device (such as a validation requesting device, for example the device of <FIG>), the method comprising:.

<FIG> schematically illustrates a simulator implementation that may be used. Whilst the earlier described embodiments implement the present disclosure in terms of apparatus and methods for operating specific processing hardware supporting the techniques concerned, it is also possible to provide an instruction execution environment in accordance with the embodiments described herein which is implemented through the use of a computer program. Such computer programs are often referred to as simulators, insofar as they provide a software based implementation of a hardware architecture. Varieties of simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may run on a host processor <NUM>, optionally running a host operating system <NUM>, supporting the simulator program <NUM>. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and/or multiple distinct instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations which execute at a reasonable speed, but such an approach may be justified in certain circumstances, such as when there is a desire to run code native to another processor for compatibility or re-use reasons. For example, the simulator implementation may provide an instruction execution environment with additional functionality which is not supported by the host processor hardware, or provide an instruction execution environment typically associated with a different hardware architecture. An overview of simulation is given in "<NPL>.

To the extent that embodiments have previously been described with reference to particular hardware constructs or features, in a simulated embodiment, equivalent functionality may be provided by suitable software constructs or features. For example, particular circuitry may be implemented in a simulated embodiment as computer program logic. Similarly, memory hardware, such as a register or cache, may be implemented in a simulated embodiment as a software data structure. In arrangements where one or more of the hardware elements referenced in the previously described embodiments are present on the host hardware (for example, host processor <NUM>), some simulated embodiments may make use of the host hardware, where suitable.

The simulator program <NUM> may be stored on a computer-readable or machine-readable storage medium (which may be a non-transitory medium), and provides a program interface (instruction execution environment) to the target code <NUM> (which may include applications, operating systems and a hypervisor) which is the same as the application program interface of the hardware architecture being modelled by the simulator program <NUM>. Thus, the program instructions of the target code <NUM>, including instructions to perform one or more of the methods described above, may be executed from within the instruction execution environment using the simulator program <NUM>, so that a host computer <NUM> which does not actually have the hardware features of the apparatus of <FIG> and/or <NUM> discussed above can emulate these features.

For example, the apparatus may have dedicated hardware which provides the defined operation, or a processor or other processing device may be programmed to perform the function, in which case software or program instructions by which the function is performed, and a providing medium such as a non-transitory machine-readable medium by which such software or program instructions are provided (for example, stored) are considered to represent embodiments of the disclosure.

Claim 1:
A method of operation of a data processing device, the method comprising:
storing a device-specific key;
generating, in response to a request for attestation by a validating data processing device, a device-specific attestation message in dependence upon a hardware configuration of the data processing device and a software configuration of software running on the data processing device, the device-specific attestation message signed using the device-specific key;
generating an application-specific attestation message in dependence upon an interaction protocol by which the data processing device and the validating data processing device interact;
cryptographically binding the application-specific attestation message to the signed device-specific attestation message;
wherein cryptographically binding the application-specific attestation message to the signed device-specific attestation message comprises at least one of:
signing the application-specific attestation message and the signed device-specific attestation message together; and
generating a hash of the application-specific attestation message and cryptographically signing the hash using the device-specific key.