WO2022006574A1

WO2022006574A1 - Device attestation

Info

Publication number: WO2022006574A1
Application number: PCT/US2021/070753
Authority: WO
Inventors: Derek Del Miller; Mathias Sven Lucien Alain Brossard; Dominic Phillip Mulligan; Christopher Haster
Original assignee: Arm Cloud Technology Inc
Current assignee: Pelion Technology Inc
Priority date: 2020-06-29
Filing date: 2021-06-23
Publication date: 2022-01-06
Anticipated expiration: 2022-12-29

Abstract

A proxy attestation system obtains a token from a service device and determines whether the service device associated with the token has been attested by a selected one of a plurality of attestation services supported by the proxy attestation system. In response to determining successful attestation of the service device based on the success indication, an attestation certificate is generated that has a chain of trust derived from a proxy attestation service certificate associated with the proxy attestation system, and the attestation certificate is provided to the service device. This allows a client device to obtain the certificate from the service device, so that the client device can obtain an attestation about a service device according to any of a plurality of attestation services without requiring the client device to implement attestation service-specific code and while reducing communication overhead for the client device.

Description

DEVICE ATTESTATION

BACKGROUND

The present disclosure relates to data processing.

Attestation allows an entity (an attestee) to be assured about the hardware and/or software configuration of a particular platform by a third party (the attester that operates as part of an attestation system). However, this can cause difficulties since there may be a number of different attestation systems and the attestee might be required to support many or all of them, which places a large burden on the attestee to implement support for all the possible platforms.

At least one example provides a data processing method for a proxy attestation system, comprising: obtaining a token from a service device; determining whether the service device associated with the token has been attested by a selected one of a plurality of attestation services supported by the proxy attestation system; and in response to determining successful attestation of the service device: generating an attestation certificate that has a chain of trust derived from a proxy attestation service certificate associated with the proxy attestation system; and providing the attestation certificate to the service device.

At least one example provides a proxy attestation system comprising: communication circuitry to obtain a token from a service device; and proxy attestation circuitry to determine whether the service device associated with the token has been attested by a selected one of a plurality of attestation services supported by the proxy attestation system; in which: in response to determining successful attestation of the service device, the proxy attestation circuitry is configured to generate an attestation certificate that has a chain of trust derived from a proxy attestation service certificate associated with the proxy attestation system, and the communication circuitry is configured to provide the attestation certificate to the service device.

At least one example provides a data processing method for a service device, comprising: providing a token to a proxy attestation system for managing attestation of the service device according to a selected one of a plurality of attestation services supported by the proxy attestation system; receiving from the proxy attestation system an attestation response providing an attestation certificate indicating that the service device has been attested according to the selected one of the plurality of attestation services, where the attestation certificate has a chain of trust derived from a proxy attestation service certificate associated with the proxy attestation system; and providing to a requester at least one of the attestation certificate and a further certificate having a chain of trust derived from the attestation certificate.

At least one example provides a service device, comprising: communication circuitry to provide a token to a proxy attestation system for managing attestation of the service device according to a selected one of a plurality of attestation services supported by the proxy attestation system, and to receive from the proxy attestation system an attestation response providing an attestation certificate indicating that the service device has been attested according to the selected one of the plurality of attestation services, where the attestation certificate has a chain of trust derived from a proxy attestation service certificate associated with the proxy attestation system; and control circuitry to provide to a requester at least one of the attestation certificate and a further certificate having a chain of trust derived from the attestation certificate.

At least one example provides a data processing method for a service device, comprising: obtaining an attestation certificate that has a chain of trust derived from a proxy attestation service certificate associated with a proxy attestation system for managing attestation of the service device according to a selected one of a plurality of attestation services supported by the proxy attestation system; and in response to a client device initiating a handshake protocol to establish a connection with the service device, providing to the client device at least one of the attestation certificate and a further certificate having a chain of trust derived from the attestation certificate.

At least one example provides a service device comprising: control circuitry to obtain an attestation certificate that has a chain of trust derived from a proxy attestation service certificate associated with a proxy attestation system for managing attestation of the service device according to a selected one of a plurality of attestation services supported by the proxy attestation system; and communication circuitry, responsive to a client device initiating a handshake protocol to establish a connection with the service device, to provide the client device with at least one of the attestation certificate and a further certificate having a chain of trust derived from the attestation certificate.

At least one example provides a data processing method for a client device, comprising: initiating a handshake protocol to establish a connection with a service device; receiving an attestation certificate from the service device; performing verification of whether the attestation certificate has a chain of trust derived from a proxy attestation service certificate associated with a proxy attestation system for managing attestation of the service device according to a selected one of a plurality of attestation services supported by the proxy attestation system; and determining whether to proceed with communication with the service device based on the verification of the attestation certificate.

At least one example provides a client device comprising: communication circuitry to initiate a handshake protocol to establish a connection with a service device, and receive an attestation certificate from the service device; and control circuitry to perform verification of whether the attestation certificate has a chain of trust derived from a proxy attestation service certificate associated with a proxy attestation system for managing attestation of the service device according to a selected one of a plurality of attestation services supported by the proxy attestation system, and determine whether to proceed with communication with the service device based on the verification of the attestation certificate. At least some examples provide a computer program comprising instructions which, when executed on a computer, control the computer to perform the method as described in any of the examples above. A computer-readable storage medium may store the computer program. The storage medium may be a non-transitory storage medium.

In another example an apparatus comprises processing circuitry to execute instructions, and storage circuitry to store the computer program described above.

BRIEF DESCRIPTION OF THE DRAWINGS

Further aspects, features and advantages of the present technique will be apparent from the following description of examples, which is to be read in conjunction with the accompanying drawings, in which:

Figure 1 schematically illustrates a data processing system including a proxy attestation system;

Figures 2 to 7 illustrate example flows of communication;

Figure 8 illustrates an example data processing system comprising a proxy attestation system;

Figures 9 and 10 illustrate example flows of communication;

Figure 11 shows an example of a data processing system including a proxy attestation system;

Figures 12 to 14 illustrate example flows of communication;

Figure 15 illustrates a tree of certificates; and

Figure 16 illustrates another example communication flow.

DETAILED DESCRIPTION

A proxy attestation system performs a data processing method. A token is obtained from a service device, and it is determined whether the service device associated with the token can be attested by a selected one of a plurality of attestation services supported by the proxy attestation system. In response to determining successful attestation of the service device, an attestation certificate is generated that has a chain of trust derived from a proxy attestation service certificate associated with the proxy attestation system, and the attestation certificate is provided to the service device.

By using the proxy attestation system to manage attestation of the service device according to any one of the two or more different attestation services supported by the proxy attestation system, this can simplify the development of a client device which requires an attestation about a service device and may engage with service devices supporting different attestation systems. By using the proxy attestation system, this allows the client device to engage with a service device which supports any one of the attestation services, with the client device using a common protocol regardless of which particular attestation service is supported by the service device. The proxy attestation system can select the one of the plurality of attestation services to use for a particular service device, for example based on the type of service device, and handle any platform-specific details that are specific to a particular attestation service supported by the service device. However, a problem in some implementations of communication flows involving the proxy attestation system is that this can increase the number of round trip communications needed for the client device.

Hence, when the proxy attestation system determines that authentication of the service device using the selected attestation service (selected from among multiple available attestation services) is successful, then the proxy attestation system generates an attestation certificate that has a chain of trust derived from a proxy attestation service certificate associated with a proxy attestation system. This certificate can then be provided to the service device, which can retain the certificate so that in future the service device can provide the certificate to a client device, without needing the service device or the client device to check with the proxy attestation system again. This approach can help to reduce the amount of communication needed by the client device when starting communication with the service device.

In some examples, determining whether the service device has been attested by the selected attestation service may comprise forwarding the token to the selected attestation service, and receiving in response a success indication regarding whether the service device has been attested by the selected attestation service. The success indication could be a pass/fail indication indicating whether the attestation was successful or failed. Alternatively, the success indication could be an indication of one or more conditions to be satisfied in order for the service device to be attested, so that the proxy attestation system can then determine whether those conditions are satisfied and hence whether the service device can be attested.

Alternatively, for some attestation services (e.g. AWS Nitro Enclaves) there is no need to forward the token to the attestation service. The proxy attestation system may authenticate the token received from the service device using a root certificate provided by the provider of the attestation service. Hence, in this case the determination of whether the service device can be attested to by the selected attestation service may be performed locally within the proxy attestation system without requiring any communication with an external attestation service provider at the time of receiving the token from the service device (any communication with the external attestation service provider for obtaining the root certificate may have been done earlier in an off-line process not part of the process for checking the service device token).

Also, while the proxy attestation system may support two or more different attestation services, it is possible that one of those attestation services may be a native attestation service implemented specific to the proxy attestation system, so it is not essential that each attestation service relies on attestation by a different provider to the provider of the proxy attestation system. The proxy attestation system may act as a certificate authority (CA). Hence, the certificate associated with the proxy attestation system may be a root of trust which can be used as a basis for a chain of trust that the service device may use to attest to its properties in a way that can be verified by the client device using at least one key associated with the proxy attestation service certificate, to avoid the client device itself needing to interact with the proxy attestation service directly or engage in multiple round trip handshakes with the service device.

The token obtained from the service device by the proxy attestation service may include a certificate signing request, and in response to determining successful attestation of the service device based on the success indication, the attestation certificate may be generated based on the certificate signing request included in the token. The certificate signing request may be signed with a private key associated with the service device and/or software running on the service device. By embedding the certificate signing request into the token forwarded to the attestation service then the certificate signing request itself may be verified by the attestation service. The proxy attestation system may act on the certificate signing request to generate the attestation certificate in the case when attestation is successful.

The attestation certificate generated by the proxy attestation system may provide service device information indicative of at least one feature of the service device. For example the feature could indicate functionality supported by the service device, such as memory encryption or support for certain hardware architectural features for enabling isolation of different pieces of software running on the same hardware platform. The service device information could also indicate properties of the service device, such as the type of device, its manufacturer, etc. By including the service device information in the certificate this allows the client device to use the certificate (or another certificate derived in the chain of trust from the attestation certificate generated by the proxy attestation system) to authenticate features (e.g. properties, state or configuration) of the service device and, if necessary, allow clients to enforce their own client-specific policy regarding which features of the service device may be acceptable.

There can be different ways of representing the service device information in the attestation certificate. In one example the service device information is specified in an extension of the attestation certificate. For example the service device information may be explicitly indicated in the extension.

However, in other examples it is not necessary to include explicit details of the service device information, and instead this could be implicit from other information associated with the attestation certificate. For example, the proxy attestation system could maintain two or more different proxy attestation service certificates and depending on at least one feature of the service device, the proxy attestation system can select one of those proxy attestation service certificates to be used for generating the attestation certificate to be sent to the service device. Hence, the attestation certificate generated on a successful attestation of the service device has a chain of trust derived from the specific one of the two or more proxy attestation service certificates selected by the proxy attestation system. This means that the service device information may be represented implicitly in the attestation certificate according to which of the two or more proxy attestation service certificates was used as the selected certificate for deriving the attestation certificate. There is no need for an explicit encoding of the features of the service device being attested to. For example the different attestation certificates may correspond to different profiles of service device and so the proxy attestation system may select the certificate which corresponds to the particular profile used on the service device being interrogated.

In one specific example, the two or more different proxy attestation service certificates may be part of a tree of certificates which branch out from a root certificate so that each certificate other than the root certificate is a child certificate of a parent certificate at an earlier level of the tree, and a given child certificate in the tree has a chain of trust derived from its parent certificate in the tree. In this case, a given child certificate may attest that the service device has at least one feature also attested to by its parent certificate, but the given child certificate may additionally specify that the service device also has at least one additional feature that is not attested to by its parent certificate. This approach for managing the certificates in the tree can make verification of certificates at the client device acting as attestee more efficient, because the client device can verify a whole class of related profiles that share a common feature based on certificates at a higher level of the tree, but the client device also has the flexibility to use certificates from lower levels of the tree if a more specific profile is required for the client device to trust the service device.

The token may be obtained from the service device by a proxy attestation system after issuing a challenge to the service device. A response to the challenge may provide the token and may also provide information derived from the challenge (which could be the token itself or be additional information). By using a challenge-response mechanism this can guard against replay attacks since it avoids a service device providing an old token from a previous authentication in an attempt to circumvent a later authentication.

The attestation certificates described in this application could be according to any known certificate format. However, in some examples the attestation certificate is an X.509 certificate, which can simplify integration with known communication protocols.

In a corresponding way, a data processing method may be provided for a service device which comprises providing a token to a proxy attestation system for managing attestation of the service device according to a selected one of two or more different attestation services supported by the proxy attestation system, receiving from the proxy attestation system an attestation response providing an attestation certificate indicating that the service device has been attested according to the selected one of the attestation services, where the attestation certificate has a chain of trust derived from a proxy attestation service certificate associated with a proxy attestation system, and providing to a requester at least one of the attestation certificate obtained from the proxy attestation system and a further certificate having a chain of trust derived from the attestation certificate. Hence, the requester may be provided either with the original attestation certificate from the proxy attestation system, or with a further certificate derived from that attestation certificate (with the attestation certificate itself not being provided), or the requester can be provided with both the original attestation certificate obtained from the proxy attestation system and the further certificate derived from it in the chain of trust. With this approach, the service device can obtain a certificate that can be provided as an attestation as to its own properties (enabling more efficient flow of communication between the service device and the client device than if the service device merely could provide its token to the client device and the client device had to separately contact the proxy attestation system). The attestation is according to any one of the two or more attestation services supported by the proxy attestation system, so that the client device does not need to interact separately with each attestation service provider.

The token provided to the proxy attestation system may comprise a certificate signing request requesting that the proxy attestation system generates the attestation system generates the attestation certificate.

The token may be provided to the proxy attestation system as a response to a challenge received from the proxy attestation system, and the token may specify information derived from the challenge.

In some examples, the attestation certificate received from the proxy attestation system could be forwarded directly to the requester by the service device.

However, it is also possible for the service device to generate the further certificate (having a chain of trust derived from the attestation certificate received from the proxy attestation system) and provide the further certificate to the requester. This can be useful to allow the service device to pass on information about properties not directly attested to by the proxy attestation system. For example, a measurement of a piece of software running on the service device may be taken (a hash of data or program code in a certain region of memory, for example), and included in the further certificate.

In some examples, the further certificate may be generated according to a certificate signing request received from the requester.

In some examples the requester to whom the attestation certificate and/or the further certificate is provided may be a client device which is an attestee which is seeking an attestation regarding a feature of the service device.

However, in some examples the requester may be an internal requester within the service device itself.

For example, in some examples the steps of providing the token to the proxy attestation system, receiving the attestation certificate from the proxy attestation system, and providing the attestation certificate and/or further certificate to the requester may be performed by a root enclave of the service device which is isolated from an execution enclave of the service device using hardware architectural features of the service device. For example the execution enclave may be application software which the client device wishes to interact with, but the root enclave may be enclave software which may manage certain security functions. By centralising functions for interacting with a proxy attestation in the root enclave, isolated from the execution enclave which may perform actual application- level processing, this avoids each software developer of an execution enclave needing to interface with the proxy attestation system, and can therefore make application software development simpler and the service device more secure.

The hardware architectural features used to isolate the root enclave from the execution enclave may vary according to the particular architecture supported by the service device. In some examples, the processing circuitry which executes software corresponding to the root and execution enclaves may allow instructions to be executed in two or more different security domains, and access to data and program code in memory may be controlled based on which domain is currently executing, with data or instructions associated with a more secure domain being inaccessible when processing instructions in a less secure domain. Different domains may have associated physical address spaces which are partitioned for the respective security domains, so that memory accesses made from one domain may be seen by certain system components as if they access a totally different location in memory compared to accesses issued from another domain which specify the same physical address. For example, memory system components (such as a cache or an interconnect) which operate at a point before a “point of physical aliasing” may treat aliasing physical addresses in different physical address spaces which actually correspond to the same memory system resource as if they correspond to different memory system resources. For example, data for the same address in a more secure address space may be cached separately from data for the same address in a less secure address space so as to maintain the illusion that these are different addresses. At the point of physical aliasing, the aliasing addresses may be collapsed into a single non-aliased address corresponding to the memory system location to be accessed for that data or instruction. This approach can avoid cache timing attacks or other mechanisms being used to probe the operation in another security domain and helps to maintain the physical isolation of the different enclaves operating in different domains. These are just some examples of hardware architecture features which could be used to isolate respective enclaves. In one example, TrustZone® architecture provided by Arm® Limited of Cambridge, UK, could be used. Alternatively, other architectures may be used which provide more than the two security domains associated with TrustZone®. Also, similar hardware architectural features may be available in secure enclave architectures provided by other parties, such as SGX or AWS Nitro Enclaves. Hence, in one example the interaction with the proxy attestation system may be performed by the root enclave of the service device, while the requester to which the root enclave provides the attestation certificate and/or a further certificate may be the execution enclave on the same device.

In some examples, the root enclave may already trust the execution enclave (e.g. it may be implicit/inherent in some secure platform architectures that the execution enclave would already have been locally authenticated before it can run), and so in that case there may be no need to perform any local authentication of the execution enclave at the point of interacting with the proxy attestation system. Hence, if the attestation certificate has been obtained from the proxy attestation system then it may simply be provided to the execution enclave to use for attesting to the service device’s own properties when communicating with a client device.

In other examples, local attestation of the execution enclave may be performed by the root enclave. A further certificate may be generated in response to the successful local attestation of the execution enclave, so that the root enclave can attest to certain properties of the execution enclave as verified during the successful local attestation. For example the furthest certificate may comprise a measurement of the execution enclave. For example the measurement may include a hash of program code or data associated with the execution enclave, so that a client device can compare the measurement of the execution enclave with expected values to determine whether the execution enclave can be trusted. Hence, in the case when a local measurement is desired, it can be useful for the root enclave to generate the further certificates with a chain of trust derived from the proxy attestation service certificate via the attestation certificate obtained from the proxy attestation system.

In examples where local attestation is performed between the root enclave and the execution enclave, the local attestation may comprise the root enclave obtaining a local token from the execution enclave. The local token may comprise a certificate signing request and then the further certificate may be generated according to the certificate signing request included in the local token (in the case when local attestation is successful). Alternatively, if no attestation is needed, the execution enclave could simply send a certificate signing request separate from any token used locally for local attestation (so that it is not necessary to send a local token at all) and in that case the root enclave may simply generate the further certificate with the measurement of the execution enclave in response to the certificate signing request. When local attestation is performed then in one example this may comprise the root enclave providing a local challenge to the execution enclave, and receiving in response the local token, with the local token specifying information derived from the local challenge.

As in the discussion above, the attestation certificate obtained by the root enclave from the proxy attestation system may specify service device information indicating at least one feature of the service device, which can be represented in any of the ways discussed above. Again the attestation certificate may comprise an X.509 certificate.

In another corresponding method, a service device may perform a method comprising obtaining an attestation certificate that has a chain of trust derived from a proxy attestation service certificate associated with a proxy attestation system for managing attestation of the service device according to a selected one of a plurality of attestation services supported by the proxy attestation system; and in response to a client device initiating a handshake protocol to establish a connection with the service device, providing to the client device at least one of the attestation certificate and a further certificate having a chain of trust derived from the attestation certificate.

Hence, since the service device has obtained an attestation certificate that can be verified based on the chain of trust back to the proxy attestation service certificate, this means that when establishing a connection with a client device which is seeking attestation of the service device, the service device can provide either the attestation certificate itself or a further certificate having a chain of trust derived from the attestation certificate, or both, so that it is not necessary to have more than one round trip handshake between the client device and the service device in order for the client device to obtain the required attestation and initiate communication with the service device. This also avoids the client device needing to perform a further communication with the proxy attestation service at the time of interacting with the service device.

The attestation certificate and/or further certificate may be provided in a first response provided to the client device after initiating the handshake protocol. Hence it is not necessary to have multiple messages exchanged between the client device and the service device in order to obtain the required attestation.

In one example, the handshake protocol may be a TLS (transport layer security) handshake protocol. This enables the service device and the client device to use known library software which may use the TLS handshake protocol to establish communication. In particular, the attestation certificate and/or the further certificate may be provided in a ServerHello message returned to the client device in response to a ClientHello message for initiating the TLS handshake protocol. Hence, this enables the interaction between the client and the service device to avoid increasing the number of messages exchanged beyond those that would already be used in the existing TLS handshake protocol that would be used in other systems not making use of the proxy attestation system, regardless of which particular attestation service is supported by the service device and without requiring the client device to support multiple attestation services to engage with different service devices requiring different attestation services.

The steps of obtaining the attestation certificate and providing the attestation certificate and/or the further certificate to the client device may be performed by an execution enclave of the service device which may be isolated from a root enclave of the service device using the hardware architectural features of the service device as discussed above. The attestation certificate may be obtained by the execution enclave from the root enclave.

The execution enclave may provide a certificate signing request to the root enclave requesting that the root enclave generates the attestation certificate and returns it to the execution enclave. The certificate signing request could be included within a local token provided to the root enclave in a local attestation process which is performed by the root enclave to determine whether the root enclave can attest to at least one feature of the execution enclave. Alternatively, in cases where no local attestation is performed by the root enclave, a certificate signing request may be provided by the execution enclave without sending any local token. If local attestation is performed, this may comprise the execution enclave receiving from the root enclave a local attestation challenge, and providing the local token to the root enclave as a response to the local attestation challenge, with the local token specifying information derived from the local attestation challenge.

Again the attestation certificate obtained by the execution enclave or other element of the service device which interacts with the client device may provide service device information indicative at least one feature of the service device, which can be represented either using an extension of the attestation certificate or based on the attestation certificate having a chain of trust derived from a selected one of two or more proxy attestation service certificates as discussed above (where the two or more certificates could be implemented as a tree as explained earlier). Again the attestation certificate may comprise an X.509 certificate.

In a further method corresponding to those above, the client device may perform a data processing method comprising initiating a handshake protocol to establish a connection with a service device; receiving an attestation certificate from the service device; performing verification of whether the attestation certificate has a chain of trust derived from a proxy attestation service certificate associated with a proxy attestation system for managing attestation of the service device according to a selected one of a plurality of attestation services supported by the proxy attestation system; and determining whether to proceed with communication with the service device based on the verification of the attestation certificate.

Hence, as the client device verifies the attestation certificate based on a chain thrust derived from a proxy attestation service certificate associated with the proxy attestation system for managing attestation of the service device, it is not necessary for the client device to communicate with a proxy attestation system itself at the time of engaging with the service device, and also this helps to eliminate an earlier communication round trip with the service device (if the certificate was not available, instead the client device would need to obtain a token from the service device to provide to the proxy attestation system and then wait for the proxy attestation system’s response before initiating the communication handshake to establish connection with the service device). Hence, several round trip communications for the client device can be eliminated up to the point when the client device can determine whether to proceed with communication with the service device.

Hence, the client device can determine whether to proceed with communication with the service device based on a single round trip communication in the handshake protocol, with that single round trip communication comprising a single message from the client device to the service device and a single response from the service device to the client device. The attestation certificate may be provided in a first response provided by the service device to the client device after the client device initiates a handshake protocol. Again the handshake protocol may be TLS and the attestation certificate may be provided in a ServerHello message with the ClientHello message of the TLS handshake triggering that ServerHello message to be returned.

Note that as the verification of the attestation certificate may be based on a key associated with the proxy attestation service as certificate authority, rather than a specific key associated with the service device or an enclave running on the service device, this means that the client device operation can be independent of the particular platform used by the service device. This simplifies software development of the client device and increases interoperability between client devices and service devices.

When verifying the service device, the client device can determine whether the service device has at least one feature based on service device information specified in the attestation certificate received from the service device. Again this service device information can be represented in various ways as described earlier (in an extension, or based on selecting one of a multiple available certificates, which could be implemented as a tree). Again, the attestation certificate obtained by the client device may be an X.509 certificate.

All the features above can be implemented using bespoke hardware, with the various apparatuses including the proxy attestation system, the service device and/or the client device having specific hardware circuitry for performing the functions discussed above.

However, these functions can also be implemented in software. Hence, a computer program may be provided comprising instructions which when executed on a computer may control the computer to perform any of the methods described above also, in some cases an apparatus may be provided which has a processing circuitry (e.g. a general purpose processor) for executing instructions, and storage circuitry which stores the computer program mentioned earlier.

In accordance with one example configuration there is provided a data processing system comprising: challenge circuitry to issue a challenge to a service device and to receive a response to the challenge; forwarding circuitry to forward at least part of the response to a selected one of a plurality of attestation systems and to receive a success indication from the selected one of the plurality of attestation systems regarding whether the service device has been attested by the selected one of the plurality of attestation systems; and request circuitry to receive a request to provide an attestation of the service device, and to provide the attestation in dependence on the success indication.

The data processing system could, for instance, take the form of a ‘proxy’ attestation system, which is able to provide attestation of particular platforms. The challenge circuitry issues a challenge to a service device (e.g. a platform to be attested). A response to the challenge (a challenge response) is then provided by the service device. This response could be such that, for instance, it can only be provided by the platform. The challenge response could itself be or contain a first attestation token used by the platform with one of the ‘native’ attestation servers. This is received by the data processing system, and at least part of the response (e.g. the first attestation token) is forwarded to at least one of several ‘native’ attestation servers. Those of the ‘native’ attestation systems that have been selected to have the at least partial response forwarded can reply with a success indication regarding the attestation of the platform. This success indication need not be a Boolean (yes/no; true/false, pass/fail, etc.). The success indication could, for instance, be implicit in the response made by the ‘native’ attestation system. The success indication could be further information regarding the platform that is provided by the ‘native’ attestation system, or could be a set of conditions under which the attestation is valid. At this point, the data processing system knows the extent to which the platform has been attested by the ‘native’ attestation system. Consequently, when request circuitry of the data processing system receives a request to provide attestation of the service device (e.g. platform) from an attestee, the attestation can be provided based on the success indicator that was received. For instance, if the success indicator indicated success then the attestation can be provided. If the success indicator indicated failure then the attestation can be refused. If the success indicator indicated conditional success, then the attestation can be provided if the conditions are met. In this way, the attestee and the platform (e.g. service device) need not be directly configured to work with any of the ‘native’ attestation systems. Instead of the attestee having to communicate with and support different attestation systems for all the platforms it works with, it only needs to support the data processing system, which handles the ‘native’ attestation systems itself.

In some examples, the data processing system comprises policy storage circuitry, adapted to store at least one policy; and the request circuitry is adapted to provide the attestation in dependence on the at least one policy. Policies can be made in respect of attestation servers (e.g. which attestation systems can be used, under what circumstances, etc.), in respect of service devices (e.g. the requirements of the service device) or in respect of the proxy attestation server itself (e.g. whether attestation should be automatically refused or accepted).

In some examples, the at least one policy indicates the selected one of the plurality of attestation systems. These examples can therefore be used to specify which of the ‘native’ attestation systems the at least partial challenge response is forwarded. This policy could use more local attestation systems in preference to more global attestation systems, for instance, thereby allowing a local provider to override a global policy. In other situations, the policy could be used to ban or prohibit a particular attestation system from being used, or to prefer the use of specialised attestation systems for particular attestations.

In some examples, the response to the challenge indicates the selected one of the plurality of attestation systems. In these examples, the platform itself indicates the attestation system that is to be used. This could be useful in a situation where the platform is specifically designed with a particular attestation system in mind, or where one particular attestation system is known to work better (e.g. more reliably) than another.

In some examples, the selected policy denies the use of a banned attestation system in the plurality of attestation systems. There are a number of ways in which the policies can control the use of the attestation systems. However, in these examples, the policy denies the use of a particular attestation system. This denial could be conditional or unconditional. In this way, it is possible to deny the use of an attestation system that is compromised or that is deemed to offer unsatisfactory attestation.

In some examples, the policy storage circuitry is adapted to store a plurality of policies; and the request comprises an indication of a selected policy in the plurality of policies that is to be applied; and the request circuitry is adapted to provide the attestation in dependence on the selected policy. In these examples, the attestee itself indicates which of the policies is to be applied. This makes it possible for the attestee to dictate how attestation is to be performed. For instance, the attestee may require that particular ‘native’ attestation systems are used, or could place requirements on the level or degree to which attestation is provided. The attestee could also specify policies that import requirements regarding the service device. This can be achieved in a number of ways. In particular, the data processing system could, on receiving the challenge response containing a first attestation token, attempt to obtain attestation for the platform immediately using the first attestation token. Once the policy is selected by the attestee, the obtained attestations are then each considered based on the selected policy. In other examples, the attestation is not performed until the attestee specifies a policy to be used and then based on the policy, attestation with a certain ‘native’ attestation system is carried out. The former approach may have a lower latency since at the time an attestation request is sent, it is possible to respond with attestation if it can be provided. However, the latter approach offers a reduction in bandwidth since attestation requests that are unsuitable can avoid being sent. Furthermore, less information need be stored at the data processing system since only relevant (useful) attestation results need to be stored.

There are a number of ways in which the policies can be used, and also in which the success indicator can be used. However, in some examples, the success indicator comprises one or more service device characteristics; and the at least one policy specifies requirements of the service device characteristics. Such characteristics could relate to, for instance, the firmware version or provider, or could relate to hardware characteristics of the platform. For instance, the policy could require that the platform provides encrypted memory. Such a requirement can either be considered by the data processing system, or can be passed to the ‘native’ attestation systems when attestation for the platform is sought. This makes it possible to only attest to particular platforms having the requested characteristics. Other examples of characteristics could relate to the manufacturing date, manufacturing quality, the location of manufacturing, the total runtime (or lifetime) of the platform, the firmware version, and so on.

In some examples, the requirements of the service device characteristics are hardware requirements. For instance, the characteristics could relate to the type of chip set, the processor type, brand, or features, types or amounts of particular resources available (e.g. 2MB of secure memory must be available), and so on.

In some examples, the forwarding circuitry is adapted to forward the at least part of the response to each of the plurality of attestation systems and to receive a plurality of success indicators from each of the attestation systems regarding whether the service device has been attested by that attestation system. In these examples, the at least partial challenge response is sent to each of the attestation systems, each of which can make its own independent determination as to whether attestation can be provided or not, before responding with a success indicator. This can therefore result in the data processing system receiving a set of responses, each of which could indicate success or failure. The attestation that is forwarded in response to the later request from the attestee can be selected based on the active policy. For instance, if only a single success indicator is received, then the policy could cause that single success to be returned.

In some examples, at least some of the plurality of attestation systems are mirrors; and the forwarding circuitry is adapted to use a backup one of the mirrors in response to a communication error with a primary one of the mirrors. In response to a communication error occurring when a given (e.g. selected) one of the attestation systems occurs, the forwarding circuitry is able to use a backup of the given (e.g. selected) attestation systems instead. Accordingly, the backup attestation system acts as a mirror for when a communication error occurs thereby increasing availability and resilience of the attestation system. The use of such a backup provision can be hard-coded into the forwarding circuitry or can be mandated within a policy, for instance.

Although there are a number of different communication errors that might be considered, in some embodiments the communication error is the primary one of the mirrors being unreachable.

In some examples, the at least part of the response is consistent across all of the attestation systems. That is to say that the challenge response can be independent of the ‘native’ attestation systems and therefore contain sufficient information for any of the ‘native’ attestation systems to be used. In some other embodiments, the data processing system can provide an indicator of which ‘native’ attestation systems can be used and the platform/service device provides necessary information for the attestation to occur, based on the set of requirements for each of the specified attestation systems to provide attestation.

In accordance with another example configuration, there is provided a data processing apparatus comprising: challenge circuitry to issue a challenge to a service device and to receive a response to the challenge, wherein the response includes a set of policies that the service device complies with according to an attestation server, the set of policies being signed using a signature of a data processing system that is adapted to communicate with the attestation server; and comparison circuitry to validate the signature and when the signature is validated, to determine whether the set of policies comprises a desired policy of the data processing apparatus, wherein the policies indicate requirements regarding at least one of the attestation system and the service device.

In this example configuration, the data processing system is able to act as a proxy attestation server as explained above. However, the data processing apparatus, that seeks attestation of a target system or service device need not communicate directly with the proxy attestation server. Instead, the data processing system is able to produce a set of policies that are met by the target system. These are signed by the data processing system so that they cannot be modified and then sent to the target system. When attestation of the target system is sought, the target system is able to provide the signed set of policies that the target system meets to the attestee. The attestee can then determine whether a particular (desired) policy falls within that list. If so, then attestation is achieved.

Figure 1 schematically illustrates a proxy attestation system 100 and attestee 120 in accordance with some examples. The proxy attestation system 100 is an example of the data processing system mentioned earlier. The proxy attestation system 100 includes challenge circuitry 150, which is responsible for issuing a challenge to root software 110 of a device/target system or platform 105. The root software 110 could take the form of an operating system or other privileged software. The device/target system or platform 105 is an example of the service device.

In response to the challenge, the root software 110 provides a corresponding challenge response (cresponse), which is received by the challenge circuitry 150. The cresponse could be or could contain a first attestation token, for instance. All or part of the cresponse is forwarded to one or more native attestation systems 125, 130, 135, which perform the attestation using the cresponse. The cresponse contains sufficient information (e.g. the first attestation token) for each native attestation system 125, 130, 135 to decide whether the device/target system 105 should be attested. For instance, this process could include consulting databases of known systems for which attestation can be provided. Each native attestation system 125, 130, 135 provides a success indication back to the forwarding circuitry. The success indication could take a number of forms and need not be a Boolean, but either implicitly or explicitly indicates whether the attestation has been successful or not. For instance, the success indication could include hardware information regarding the platform 105, which is either available in a database of the native attestation system 125, 130, 135, or which is provided by the platform 105 itself as part of its cresponse.

When the attestee 120 seeks to attest the app software 115 on the platform 105, it sends an attestation request to the app software 115. The app software 115 communicates with the root software 110 on the platform 105 in order to request a second attestation token using the attestation credentials of the device 105 (provided by the proxy attestation system 100). The app software 115 passes this on to the attestee 120, which requests token verification from the proxy attestation system 100. The proxy attestation system 100 contains request circuitry 145 to receive a token verification request from the attestee 120. The token verification request contains the second attestation token provided by the app software 115. The proxy attestation system therefore responds to the verification request with a success/fail indication depending on whether the second token was valid or not.

Policy storage circuitry 155 is also provided in the proxy attestation system 100 in order to store one or more policies. The policies can indicate how the success indications are acquired, mediated, and used by the proxy attestation system 100 and can provide conflict resolution when different success indications disagree. The policies can also be used to specify particular requirements of a platform 105 in order to achieve attestation. There are a number of ways in which one or more of policies can be invoked, as will be discussed later.

Note that Figure 1 illustrates the flow of attestation in a general sense. In some embodiments, the information provided at particular steps could be more extensive and in some cases, the ordering in which communications are issued could be varied.

Figure 2 illustrates an example flow of communication between a native attestation system 135, a further native attestation system 125, a proxy attestation system 100, an attestee 120, and a target system 105 for which attestation is sought, including root software 110, app software 115, and firmware 160.

The root software 110 on the device 105 freshly generates the key pair (RApub, RApriv). The firmware 160 also makes use of a key pair (TSFpub, TSFSpriv). The native attestation system 135 has the public key (TSFpub) for the device 105. When attestation is to begin, the root software 110 on the device 105 sends a message to the proxy attestation system 100 that attestation is to begin. The proxy attestation system 100 responds by generating a challenge, which is issued back to the root software 110 of the device 105. The challenge could take the form of a large (e.g. 128 bit) random or pseudo random number, thereby inhibiting a replay attack from occurring. The root software 110 responds by requesting a token from the firmware 160, by providing the challenge and the root software’s public key RApub. The firmware generates a first attestation token (attestation_token1), which includes a measurement of the root software (e.g. a hash of the root software), RApub, and the challenge. The attestation_token1 is signed using TSFpriv, thereby confirming that it originated from the firmware 160. This attestation_token1 forms part of a challenge response, which is sent to the proxy attestation system 100 via the root software 110. A selected one of several policies held at the proxy attestation system 100 is also provided in the challenge response. At the proxy attestation system 100, the challenge in attestation_token_1 is checked to determine whether it matches the sent challenge. If not, this could be indicative that a replay attack is being performed, and the attestation process could be cancelled (with the target system 105 being ignored/blacklisted). Otherwise, one or more native attestation systems 125, 135 are selected for use (e.g. via the policy specified by the root software 110). In this case, the active policy indicates that the native attestation system 135 is to be used and so this system 135 is selected. The attestation_token1 is passed to that native attestation system 135 from the proxy attestation system 100. The native attestation system 135 determines whether or not attestation should be provided based on attestation_token1. In particular, since the native attestation system 135 has a copy of TSFpub, it is possible to confirm that the token that was received originated from the firmware 160 of the device 105, since only the firmware 160 has access to TSFpriv. Furthermore, the measurement of the root software 110 has also been provided. All of this information can be looked up in, for instance, a database of attestable devices/root softwares held by the native attestation system 135. In response to these checks, the native attestation system 135 responds with a success indicator, which in this example is a pass/fail and, in the case of a path, attestation information. On receiving the success indicator, the attestation information is checked to see whether any requirements of the selected policy are met. For example, such requirements could relate to the nature of the native attestation system 135 that performed the attestation, or could relate to the reported requirements of the platform 105.

When an attestee 120 seeks to make use of app software 115 on the target system/platform 105, the attestee 120 issues a challenge to the app software 115. Again, the challenge can be produced by generating a large (e.g. 128 bit) random or pseudo random number, in order to prevent replay attacks. At this point, local attestation occurs between the app software 115 and the root software 110. Provided the root software 110 is agreeable, a second attestation token (attestation_token2) is provided to the app software 115 from the root software 110. The attestation_token2 is generated by measuring the app software 115 and by signing this measurement using RApriv. This is provided to the application 115, which provides it back to the attestee 120, which forwards the second token to the proxy attestation system 100 for verification. Since the proxy attestation system 100 has access to RApub, it is possible for the proxy attestation system 100 to confirm that attestation_token2 was produced by the root software 110 on the device/platform 105. The proxy attestation system 100 can access the body of attestation_token2 to obtain the measurement (e.g. hash) of the application software 115. This can be checked against the active (e.g. selected) policy for instance to ensure that it matches what is recorded at the proxy attestation server 100. A pass/fail indication can then be sent from the proxy attestation system 100 back to the attestee 120.

Figure 3 illustrates a further example flow of communication between a native attestation system 135, a further native attestation system 125, a proxy attestation system 100, an attestee 120, and a target system 105 for which attestation is sought, including root software 110, app software 115, and firmware 160.

Much of the flow of communication in Figure 3 corresponds with the flow shown in Figure 2. Of particular interest in this example is that the root software 110 indicates a policy that is to be applied when providing the challenge response comprising the token to the proxy attestation system 100. In this example, the selected policy causes the further native attestation system 125 to be banned so that it cannot be used for attesting to the target system 105. As a consequence, the proxy attestation system uses the native attestation system 135 to perform the attestation of the target system 105 and the flow proceeds as per the flow shown with respect to Figure 2. This mechanism makes it possible to prevent the use of particular attestation servers. This could be carried out for security reasons (if the further native attestation system 125 becomes untrusted for instance), licensing reasons (if the further native attestation system 125 refuses to attest the target system 105 any longer for instance), or for reasons of efficiency (if, for instance, the further native attestation system 125 has stopped working and it is desirable to prevent time consuming attempts to use it).

Figure 4 illustrates a further example flow of communication between a native attestation system 135, a further native attestation system 125, a proxy attestation system 100, an attestee 120, and a target system 105 for which attestation is sought, including root software 110, app software 115, and firmware 160.

In this flow, a plurality of policies exists on the proxy attestation system 100. The attestee 120 has a particular policy (Apolicy) that is required. This policy could, for instance, specify hardware requirements of the target system 105 for which attestation is sought, such as requiring that the target system 105 has secure memory for instance. The flow proceeds as previously discussed with the target system 105 seeking attestation, the proxy attestation system 100 issuing a challenge, and the root software 110 on the target system 105 issuing a first token (attestation_token1). When the first token is forwarded to a selected native attestation system 135, the native attestation system 135 provides attestation information in the form of target system properties (e.g. target system hardware) of the target system 105 together with the pass/fail indicator. Indeed, in some embodiments, the presence of the target system properties could be indicative of a pass while the lack thereof within a given time period could be interpreted as a fail. The properties (e.g. hardware characteristics) of the target system 105 are then compared to each of the policies to see which policies would accept the properties of the target system 105. This is used to form a set ts_policies. The flow then continues as discussed. When the attestee 120 seeks to verify the attestation_token2 that was received from the app software 115, it also provides the identity of Apolicy to the proxy attestation system 100. As part of the proxy attestation system’s checks, the proxy attestation system 100 determines whether Apolicy is one of the policies is in ts_policies. That is, the proxy attestation system 100 determines whether Apolicy is one of the policies that will accept the hardware characteristics that were provided for the target system 105. If not, then the attestation fails. If so, then the attestation passes or fails in dependence on the other tests performed by the proxy attestation system 100.

Figure 5 illustrates an additional element in the example flow of Figure 4.

In particular, Figure 5 illustrates that a policy (or policies) can be updated. This could, for instance, be used to change security requirements on-the-fly. In particular, when one or more updated policies are added to the proxy attestation system 100 there are a number of ways in which this can be handled. In one example, the attestation process can be restarted for each target system 105 for which attestation has been carried out. For instance, current attestations can be invalidated and the target system 105 can either pre-emptively request attestation or can be prompted to request attestation by the proxy attestation system 100 or the attestee 120 if the attestee 120 becomes aware of the changed policies. Alternatively, if the target system policies that were obtained from the native attestation system 135 are stored then these can be compared to the revised set of policies in order to regenerate ts_policies. In either event, the flow proceeds as illustrated in Figure 4.

Figure 6 illustrates a further example flow of communication between a native attestation system 135, a further native attestation system 125, a proxy attestation system 100, an attestee 120, and a target system 105 for which attestation is sought, including root software 110, app software 115, and firmware 160.

Figure 6 considers a situation in which, after having received the first token from the root software 110, each of the further native attestation system 125 and the native attestation system 135 is sent the first token by the proxy attestation system 100 in order to produce and return a plurality of success indicators. There are a number of ways in which these success indicators can be used by the proxy attestation system 100. In some systems, a majority ‘vote’ could be used to determine whether attestation can be provided by the proxy 100. This makes it possible to spread risk by requiring a number of systems to be able to attest to a target system 105 before attestation can be provided by the proxy 100. In other systems, even a single success is sufficient for the target system 105 to acquire attestation. In still other systems, the exact conditions are set according to a policy. In the example shown in Figure 6, the active policy (which could be selected by the owner of the proxy attestation system 100 or could be selected by the attestee 120 for instance) selects the native attestation system 125, 135 to provide the attestation system based on which of the native attestation systems 125, 135 provides a pass. For instance, the policy might select the nearest or most convenient native attestation system 125, 135 or could select one that provides the most information about the target system 105 as a result of the attestation succeeding, or the first native attestation system 125, 135 to provide success could be selected.

Figure 7 illustrates a further example flow of communication between a native attestation system 135, a further native attestation system 125, a proxy attestation system 100, an attestee 120, and a target system 105 for which attestation is sought, including root software 110, app software 115, and firmware 160.

Figure 7 particularly illustrates the use of mirrors. In this situation, a mirror native attestation system 125 is provided in order to replicate the functionality of native attestation system 135. The mirror native attestation system 125 could be provided in a location that is geographically closer (e.g. more responsive) to the attestee 120 or could simply be provided as a redundant system to the native attestation system 135. In either event, in this example, after receiving the first token and selecting the native attestation system 135 for use, a communication error occurs in the form of the native attestation system 135 becoming unreachable. As a consequence, the proxy attestation system 100 instead communicates the token to the mirror native attestation server 125, which response with the success indicator. The flow then proceeds as previously described.

Figure 8 schematically illustrates a proxy attestation system 900 and attestee 920 in accordance with some embodiments. The proxy attestation system 900 is an example of the data processing system mentioned earlier and the attestee 920 is an example of the data processing apparatus mentioned earlier. As before, the proxy attestation system 900 issues a challenge to root software 910 of the device/target system 905. This responds with a challenge response (cresponse), which again contains a first attestation token. All or part of the cresponse is forwarded by the proxy attestation system 900 to one or more of a plurality of native attestation systems 925, 930, 935, each of which provides a success indication. The list of successes is compared to a list of policies in policy storage circuitry 955 and the successful policies are signed and sent by the proxy attestation system 900 to the root software 910 on the device 905. In due course, when the attestee 920 seeks attestation of app software 915 on the device 905, the app software 915 communicates with the root software 910 in order to gain the use of the attestation token. The attestation token and the signed list of successful policies are then forwarded by the app software 915 to the attestee 920. Here, the attestee confirms the signature of the signed list of successes and determines whether a desired policy stored in policy storage circuitry 990 is in the list of successful policies sent by the app software 915. If so, the attestation succeeds.

In this version of the system, the attestee 920 need not communicate with the proxy attestation system 900 (except perhaps to obtain a list of possible policies). Instead, the device/target system 905 provides a list of policies that are met via its attestation. These are signed by the proxy attestation system 900 so that the list cannot be modified. The list of successes is sent to the attestee at the time of attestation to the attestee so that the attestee can determine whether its requirements are met by comparing the list of successes to its own desired policy or policies to see if they are found in the list. If they are found in the list, then the attestation succeeds. Otherwise, the attestation fails.

Figure 9 shows the flow in more detail. The proxy attestation system 900 has a public/private key pair (AASpub, AASpriv) for producing the signed set of successful policies. In addition, the proxy attestation system 900 has a set of policies, each of which specifies particular system characteristics. The attestee has access to the public key AASpub and also knows the ID of the various policies that it wishes to apply. The attestation process begins in the manner previously discussed. In particular, the root software 910 sends a begin_attestation notification to the proxy attestation system 900, which generates a challenge. The challenge is then sent to the root software 910, which generates a first token using (as before. This token is then sent to the proxy attestation system 900, which forwards the token as part of a challenge response to one or more native attestation systems 935 (again, as previously discussed). The native attestation system 935 responds with a success indicator, together with a set of platform properties of the target system 905. Validation is performed, as previously described. The proxy attestation system then generates a set ts_cert, which contains a list of policies (or policy IDs) whose system requirements are met by the target system 905 and RApub. This is determined using the platform properties that are received from the native attestation system 935. Each of these policies/policy IDs is signed using AASpriv. ts_cert is then sent to the root software 910.

When attestation of the app software 915 is sought by the attestee 920, the attestee 920 issues a challenge to the app software 915 as previously described. Local attestation is then performed by the app software 905 sending an attestation request (together with the challenge) to the root software 910. The root software 910 responds with a ctoken (a second attestation token). The ctoken contains ts_cert, the challenge, and information regarding the app software 915. All of this is signed using RApriv (the private key of the root software 910). The ctoken is forwarded by the app software 915 to the attestee 920. The attestee 920 verifies the signature of ctoken (e.g. using RApub). The ID of the policy that the attestee 920 requires is then checked to see if it lies within ts_cert (the successful policies). If so, attestation is successful. Otherwise, attestation has failed. In this way, the attestee 920 need not communicate directly with the proxy attestation system 900 while still making use of its capabilities to act as an intermediary between the native attestation systems 925, 935.

Figure 10 shows another example communication flow similar to those above. Again, in this flow the proxy attestation service enables the client (attestee) to obtain an attestation relating to the target device according to any one of two or more native attestation services, without the client device needing to include bespoke code for interacting with each of those native attestation services as service-specific details are handled by the proxy attestation service. However, the flow shown in Figure 10 requires the client device to go through two full round trip communications with the service device (the first obtaining the proxy token from the execution enclave of the service device, and the second undertaking the client hello/server hello handshake according to the TLS protocol), as well as a third round trip communication with the proxy attestation service to obtain the pass/fail indication regarding authentication. This can slow down the start of communicating with the target device.

Figure 11 shows another example of the data processing system 1000, again comprising a proxy attestation system 1002, the service device 1005 acting as the device/target system to be attested, a client device 1020 acting as the attestee which is seeking attestation of this service device 1005, and two or more different native attestation systems 1025, 1030, 1035 which provide different mechanism for attesting to properties of devices. The proxy attestation system manages attestation of the service device 1005 according to any of the native attestation systems 1025 without requiring software on the client device 1020 to use specific code for a given native attestation system. This is useful because different service devices may use different native attestation systems and so by going through the proxy attestation system 1002 this avoids the client device 1020 needing to have code specific to the native attestation system while increasing the range of service devices with which it can communicate. While the native attestation systems are all shown as external to the proxy attestation system 1002 in Figure 11, in some examples one or more of the native attestation systems could be supported by the proxy attestation system based on a local check using a key or certificate provided by the native attestation system provider, without needing communication with an external device associated with the native attestation system.

The service device 1005 includes communication circuitry 1008 for communicating with the proxy attestation system 1002 and the client device 1020, and control circuitry 1009 for performing control operations. For example the control circuitry and communication circuitry 1008 may both form part of a processor. The control circuitry 1009 may include a root enclave 1010 and an execution enclave 1015 which may correspond to different software running on the control circuitry 1009. The root enclave 1010 and execution enclave 1015 may be physically isolated according to hardware architectural features such as those described earlier.

Similarly, the client device 1020 may include communication circuitry 1022 and control circuitry 1024. The communication circuitry 1022 may communicate with the service device 1005, but in this example does not need to communicate with a proxy attestation system 1002 at the time of interacting with the service device 1005 (although the client device 1020 could communication with the proxy attestation system 1002 in advance, for example to provide client-specific policy information to use when selecting which attestation system is to be used as described earlier). The control circuitry 1024 may, for example, be a general purpose processor executing software and may perform functions for verifying any certificates obtained by the communication circuitry 1022 to determine whether the client device 1020 will trust the service device 1005 and hence engage in communication. The proxy attestation system 1002 includes a certificate store 1050 for storing one or more certificate authority (CA) certificates and keys used by the proxy attestation system as a certifying authority to attest to validity of certain properties of the service device 1005. The certificate authority certificates act as a root of trust which the client device can use to verify whether an attestation provided by a service device can be trusted.

The proxy attestation system includes proxy attestation circuitry 1052 (an example of which may be the forwarding circuitry 140 described earlier) which determines, based on a token received from the service device 1005, whether the service device can be attested by a selected attestation system selected from among the respective native attestation systems 1025, 1030, 1035. In some cases, the proxy attestation system may authenticate the token directly based on a certificate associated with the selected attestation system. However, for other attestation systems the proxy attestation system may forward the token provided by the service device to the selected attestation system, and receive in return a success indication which provides an indication of whether the device has passed the attestation or an indication of one or more conditions required to be satisfied for a successful attestation.

The proxy attestation system 1002 includes communication circuitry 1054 which communicates with the service device 1005, for example engaging in a challenge/response handshake for obtaining the token from the service device, and upon successful attestation, providing a certificate generated based on the CA certificates in the certificate store 1050 to the service device 1005. Although communication between the proxy attestation circuitry 1052 and the native attestation system 1035 is shown directly in Figure 11, in other examples the communication circuitry 1054 may be used to communicate with the native attestation system 1035 as well.

The proxy attestation system may also have policy storage circuitry 1055 which corresponds to the policy storage circuitry 155, 955 described earlier and can be used to define the policy used to determine how to authenticate the service device 1005 and/or select which native attestation system is to be used for particular service devices. The use of the policy storage circuitry may as described earlier and is not described further in this example.

Figure 12 shows an example communication flow using the example system of Figure 11. The Proxy Attestation Service 1002 is in possession of a Proxy CA Certificate and a Proxy CA private key, which has been used to sign the Proxy CA Certificate. When the Root Enclave 1010 on the target system 1005 starts, it generates a Root Enclave Public/Private Keypair, and an X.509 Certificate Signing Request (CSR), signed with the Root Enclave Private Key.

The Proxy Attestation Service 1002 initiates Native Attestation by issuing a challenge value to the Root Enclave 1010. To deter replay attacks, the challenge value may be an unpredictable, non-repeating value, such as a random or pseudorandom number, of a sufficient number of bits to reduce the likelihood of an attacker “guessing” the correct challenge by brute force (e.g. an 128-bit random value could be used). The root enclave 1010 generates an attestation token using the platform's native mechanism, embedding the challenge and the CSR into the token. The Root Enclave 1010 returns the token to the Proxy Attestation Service 1002.

When the Proxy Attestation Service 1002 receives the token, it forwards it to the selected Native Attestation Service 1035 (selected according to the nature of the target device). The Native Attestation Service authenticates that the token came from a valid enclave on a valid target platform, and returns a success indication (e.g. pass or fail), with (optionally) additional information about the target platform 1005.

An alternative would be for the proxy attestation service 1002 to authenticate the token according to the selected native attestation service directly without forwarding the token to the native attestation service.

If the proxy attestation system 1002 receives a fail indication from the native attestation service 1035 or otherwise determines that the service device 1005 cannot be authenticated, then the process ends and the service device 1005 is not provided with any attestation certificate by the proxy attestation system 1002.

If the proxy attestation system 1002 receives a pass indication from the Native Attestation Service or the target platform 1005 can otherwise be authenticated according to the selected native attestation service, the Proxy Attestation Service 1002 generates a Root Enclave Certificate from the CSR, signing it with a key that has a certificate chain back to the Proxy CA Certificate stored in the CA certificate store 1050 (naively, the proxy attestation service 1002 could just sign the root enclave certificate with the Proxy CA private key). It then sends the Root Enclave Certificate to the Root Enclave 1010.

The Root Enclave 1010 stores the Root Enclave Certificate in its enclave memory. When the Execution Enclave 1015 boots, it generates an Execution Enclave Public/Private Key pair.

In a platform where local attestation of the execution enclave 1015 is required, the Root Enclave 1010 issues a challenge to the Execution Enclave 1015. The Execution Enclave responds by generating an X.509 Certificate Signing Request, and generating a local attestation token that contains the CSR. The Execution Enclave 1015 then returns the token to the Root Enclave 1010. The Root Enclave then authenticates the token (either locally or using a Native Attestation Service). If the authentication passes, it generates an Execution Enclave certificate from the CSR, embedding the measurements of the Execution Enclave from the token in an extension in the Execution Enclave certificate. It then returns the Execution Enclave certificate to the execution enclave.

In other examples, local attestation may not be required, for example if the Root Enclave can regard on mutually trusted system firmware to “vouch” for the Execution Enclave. For example, a secure operating system operating in the secure domain or secure monitor software responsible for switching between code operating in different domains may be implicitly trusted to have authenticated the execution enclave, so that the root enclave does not need to do this during the proxy attestation process.

When the client device 1020 starts, it has the Proxy CA Certificate in its certificate store. When it initiates a TLS handshake with a ClientHello message to the Execution Enclave 1015, the Execution Enclave 1015 responds with a ServerHello message with the certificate(s) it received from the Root Enclave. For example, any one or more of the execution enclave certificate, root enclave certificate and Proxy CA certificate may be included in the ServerHello message.

The client can then authenticate the certificate(s) using the standard TLS methods, making sure it roots back to the Proxy CA Certificate. The client also verifies that the Execution Enclave measurement contained in the Execution Enclave certificate matches its expectations.

Note that in the approach shown in Figure 10, the Proxy Attestation required that the client have 2 round-trip messages with the Execution Enclave, as well as 1 round-trip with the Proxy Attestation Service. In the approach shown in Figure 12, the client only needs the standard TLS handshake messages (a single round trip using the ClientHello and ServerHello messages) to establish a secure connection.

Figure 13 shows another example communication flow. Figure 13 shows an example where the local attestation process is omitted. In other examples local attestation could still be performed between the root enclave 1010 and the execution enclave 1015.

In the example of Figure 12 the client 1020 has no way to authenticate the properties or state of the target device 1005, which may make it harder for clients to enforce their own policy regarding the properties or state of the target device which can be trusted. The approach shown in Figure 13 addresses this problem because when the proxy attestation system 1002 issues the root enclave certificate to the root enclave 1010, the proxy attestation service embeds details about the target device as an extension inside the root enclave certificate. The execution enclave certificate is derived from this root enclave certificate adding the measurement of execution enclave, and both certificates are provided to the client device which can then check the extension within the root enclave certificate to identify the properties of the target device and verify that they are acceptable before deciding to continue with communication with the target device 1005.

Figure 14 shows another example communication flow which is similar to Figure 13, but this time instead of embedding the details of the target platform inside the root enclave certificate which the client can check, instead the proxy attestation service has N different proxy root CA certificates available for different target profiles of the service device 1005 (N is 2 or more). When generating the root enclave certificate, the proxy attestation system 1002 checks which profile matches the actual profile of the service device 1005 (target platform) and then selects, from among the available proxy CA certificates, the certificate which corresponds to the actual target profile of the device. For example the different certificates could correspond to different features or functionality that may be supported by different profiles of target device, for example distinguishing whether memory encryption is supported by the target device 1005, or whether the service device uses a stronger or weaker form of authentication (e.g. distinguished by the number of bits in values used for the authentication). Hence, the root enclave certificate is signed by a key associated with the selected proxy CA certificate (which could be a key specific to that proxy CA certificate or could be a shared key associated with the proxy CA that is used for each of the different proxy CA certificates for the different target device profiles). The subsequent processing is as in Figure 12 or 13 (again in the example of Figure 14 the local attestation steps are omitted but could still be provided if desired). In Figure 14, when the client device receives the attestation certificate(s) in the ServerHello response received from the target device 1005, the client device 1020 can choose which target platform profile it wants to support by selecting the appropriate proxy CA certificate as the root CA certificate to be used for verifying the attestations received from the target device 1005 when performing the TLS handshake.

As shown in Figure 15, in some examples the different proxy CA certificates used by the proxy attestation system 1002 may be managed as a tree structure in a hierarchy of certificates. Each of the certificates off the root certificate may represent a feature or a set of features that is supported by the target device 1005 according to a certain target profile. For example at the first level of the tree, profile A could represent support for encrypted DRAM (dynamic random access memory), while profile B could represent that the device does not support encrypted DRAM. The various profiles at the next level may combine the DRAM encryption or non-DRAM encryption features with further second-level features A, B, C such as whether the target device 1002 uses a specific hardware security architecture such as TrustZone®, whether a particular form of authentication is supported, etc. The features indicated by a certificate at one node of the tree flow down to its children and descendants, so that all of the certificates for target profiles AA, AB, AC attest to the service device 1005 having the feature represented by target profile A, but also attest to additional features A, B, C at the next level which are not attested to by the parent certificate for target profile A.

This approach can allow the client to more efficiently verify the features which it requires for successful attestation, since the service device only needs to send a single certificate at a leaf node of the tree representing the specific combination of features supported by that device, but if the client device 1020 only needs the service device 1005 to have one of the features represented at a higher level of the tree, then it can perform a single verification of the certificate provided by the service device using, as the root of trust, the CA certificate from a higher node of the tree, without individually needing to check the attestation certificate received from the service device according to multiple acceptable profiles.

This provides flexibility for different client devices to require more or less specific constraints on which service devices it will trust. For example if feature A at the second level of the tree of Figure 15 represents DRAM encryption and feature B at the bottom level of the tree represents support for TrustZone®, then if a client device 1020 requires the service device 1005 to support TrustZone® but does not require memory encryption, it may allow the service device to be authenticated if its attestation meets either target profile AB or target profile BB and these are the two certificates that it will accept as root certificates in the certificate chain, not supporting other variants such as AA, AC, BA. On the other hand, if a client device 1020 desires memory encryption but does not need support for TrustZone® then it could perform its verification of the attestations based on the CA certificate for target profile A, so that a single verification action can verify whether the service device can be trusted regardless of whether the service device actually provides the certificate for profile AA, AB, or AC.

Figure 16 shows an example of a communication flow in which the proxy attestation service uses the tree of certificates in the way described above. Figure 16 is the same as Figure 14 except that when generating the root enclave certificate the proxy attestation system 1002 selects one of the CA certificates from the leaf node of the tree corresponding to the profile of the service device 1005, and when verifying the certificate(s) received from the service device 1005, the client device authenticates the execution enclave certificate based on the certificate chain down to the level of the tree which is requires to be supported (or if desired, compares against the certificates in multiple branches of the tree).

Examples are set out in the following clauses:

1. A data processing method for a proxy attestation system, comprising: obtaining a token from a service device; determining whether the service device associated with the token has been attested by a selected one of a plurality of attestation services supported by the proxy attestation system; and in response to determining successful attestation of the service device: generating an attestation certificate that has a chain of trust derived from a proxy attestation service certificate associated with the proxy attestation system; and providing the attestation certificate to the service device.

2. The method of clause 1, in which the proxy attestation system acts as a certificate authority.

3. The method of any of clauses 1 and 2, in which the token obtained from the service device includes a certificate signing request, and in response to determining successful attestation of the service device based on the success indication, the attestation certificate is generated based on the certificate signing request included in the token.

4. The method of any preceding clause, in which the attestation certificate provides service device information indicative of at least one feature of the service device.

5. The method of clause 4, in which the service device information is specified in an extension of the attestation certificate.

6. The method of clause 4, comprising: selecting, depending on at least one feature of the service device, one of a plurality of proxy attestation service certificates, wherein the attestation certificate has a chain of trust derived from the selected one of the plurality of proxy attestation service certificates; and the service device information is represented in the attestation certificate according to which of the plurality of proxy attestation service certificates is the selected one of the plurality of proxy attestation service certificates.

7. The method of clause 6, in which the plurality of proxy attestation service certificates are part of a tree of certificates in which a given child certificate in the tree has a chain of trust derived from its parent certificate in the tree.

8. The method of clause 7, in which the given child certificate attests that the service device has at least one feature also attested to by its parent certificate, and the service device also has at least one additional feature not attested to by its parent certificate.

9. The method of any preceding clause, comprising issuing a challenge to the service device, and receiving a response to the challenge from the service device, the response providing the token and specifying information derived from the challenge.

10. The method of any preceding clause, in which the attestation certificate comprises an X.509 certificate.

11. A proxy attestation system comprising: communication circuitry to obtain a token from a service device; and proxy attestation circuitry to determine whether the service device associated with the token has been attested by a selected one of a plurality of attestation services supported by the proxy attestation system; in which: in response to determining successful attestation of the service device, the proxy attestation circuitry is configured to generate an attestation certificate that has a chain of trust derived from a proxy attestation service certificate associated with the proxy attestation system, and the communication circuitry is configured to provide the attestation certificate to the service device.

12. A data processing method for a service device, comprising: providing a token to a proxy attestation system for managing attestation of the service device according to a selected one of a plurality of attestation services supported by the proxy attestation system; receiving from the proxy attestation system an attestation response providing an attestation certificate indicating that the service device has been attested according to the selected one of the plurality of attestation services, where the attestation certificate has a chain of trust derived from a proxy attestation service certificate associated with the proxy attestation system; and providing to a requester at least one of the attestation certificate and a further certificate having a chain of trust derived from the attestation certificate.

13. The method of clause 12, in which the token provided to the proxy attestation system comprises a certificate signing request requesting that the proxy attestation system generates the attestation certificate.

14. The method of any of clauses 12 and 13, comprising receiving a challenge from the proxy attestation system, where the token is provided to the proxy attestation system as a response to the challenge, and the token specifies information derived from the challenge. 15. The method of any of clauses 12 to 14, in which the further certificate is generated and provided to the requester.

16. The method of any of clause 15, in which the further certificate is generated according to a certificate signing request received from the requester.

17. The method of any of clauses 12 to 16, in which steps of providing the token, receiving the attestation certificate, and providing the attestation certificate to the requester are performed by a root enclave of the service device which is isolated from an execution enclave of the service device using hardware architectural features of the service device.

18. The method of clause 18, in which the requester comprises the execution enclave.

19. The method of any of clauses 17 and 18, in which the further certificate is generated and provided to the requester, and the further certificate comprises a measurement of the execution enclave.

20. The method of any of clauses 17 to 19, comprising performing local attestation of the execution enclave, in which the local attestation comprises providing a local challenge to the execution enclave, and receiving a local token as a response to the local challenge, the local token specifying information derived from the local challenge.

21. The method of any of clauses 12 to 20, in which the attestation certificate provides service device information indicative of at least one feature of the service device.

22. The method of clause 21, in which the service device information is specified in an extension of the attestation certificate.

23. The method of clause 21, in which the attestation certificate has a chain of trust derived from a selected one of a plurality of proxy attestation service certificates; and the service device information is represented for the attestation certificate according to which of the plurality of proxy attestation service certificates is the selected one of the plurality of proxy attestation service certificates.

24. The method of clause 23, in which the plurality of proxy attestation service certificates are part of a tree of certificates in which a given child certificate in the tree has a chain of trust derived from its parent certificate in the tree.

25. The method of clause 24, in which the given child certificate attests that the service device has at least one feature also attested to by its parent certificate, and that the service device has at least one additional feature not attested to by its parent certificate.

26. The method of any of clauses 12 to 25, in which the attestation certificate comprises an X.509 certificate.

27. A service device, comprising: communication circuitry to provide a token to a proxy attestation system for managing attestation of the service device according to a selected one of a plurality of attestation services supported by the proxy attestation system, and to receive from the proxy attestation system an attestation response providing an attestation certificate indicating that the service device has been attested according to the selected one of the plurality of attestation services, where the attestation certificate has a chain of trust derived from a proxy attestation service certificate associated with the proxy attestation system; and control circuitry to provide to a requester at least one of the attestation certificate and a further certificate having a chain of trust derived from the attestation certificate.

28. A data processing method for a service device, comprising: obtaining an attestation certificate that has a chain of trust derived from a proxy attestation service certificate associated with a proxy attestation system for managing attestation of the service device according to a selected one of a plurality of attestation services supported by the proxy attestation system; and in response to a client device initiating a handshake protocol to establish a connection with the service device, providing to the client device at least one of the attestation certificate and a further certificate having a chain of trust derived from the attestation certificate.

29. The method of clause 28, in which the at least one of the attestation certificate and the further certificate is provided in a first response provided to the client device after initiating the handshake protocol.

30. The method of any of clauses 28 and 29, in which the handshake protocol is a TLS (Transport Layer Security) handshake protocol.

31. The method of clause 30, in which said at least one of the attestation certificate and the further certificate is provided in a ServerHello message returned to the client device in response to a ClientHello message for initiating the TLS handshake protocol.

32. The method of any of clauses 28 to 31, in which steps of obtaining the attestation certificate and providing the at least one of the attestation certificate and the further certificate to the client device are performed by an execution enclave of the service device which is isolated from a root enclave of the service device using hardware architectural features of the service device.

33. The method of clause 32, in which the attestation certificate is obtained from the root enclave.

34. The method of any of clauses 32 and 33, comprising providing a certificate signing request to the root enclave requesting that the root enclave generates the attestation certificate.

35. The method of clause 34, in which the certificate signing request is included within a local token provided to the root enclave in a local attestation process performed by the root enclave to determine whether the root enclave can attest to at least one feature of the execution enclave.

36. The method of clause 35, in which the local attestation process comprises receiving from the root enclave a local attestation challenge, and providing the local token to the root enclave as a response to the local attestation challenge, the local token specifying information derived from the local attestation challenge.

37. The method of any of clauses 28 to 36, in which the attestation certificate provides service device information indicative of at least one feature of the service device. 38. The method of clause 37, in which the service device information is specified in an extension of the attestation certificate.

39. The method of clause 37, in which the attestation certificate has a chain of trust derived from a selected one of a plurality of proxy attestation service certificates; and the service device information is represented in the attestation certificate according to which of the plurality of proxy attestation service certificates is the selected one of the plurality of proxy attestation service certificates.

40. The method of clause 39, in which the plurality of proxy attestation service certificates are part of a tree of certificates in which a given child certificate in the tree has a chain of trust derived from its parent certificate in the tree.

41. The method of clause 40, in which the given child certificate attests that the service device has at least one feature also attested to by its parent certificate, and that the service device has at least one additional feature not attested to by its parent certificate.

42. The method of any of clauses 28 to 41, in which the attestation certificate comprises an X.509 certificate.

43. A service device comprising: control circuitry to obtain an attestation certificate that has a chain of trust derived from a proxy attestation service certificate associated with a proxy attestation system for managing attestation of the service device according to a selected one of a plurality of attestation services supported by the proxy attestation system; and communication circuitry, responsive to a client device initiating a handshake protocol to establish a connection with the service device, to provide the client device with at least one of the attestation certificate and a further certificate having a chain of trust derived from the attestation certificate.

44. A data processing method for a client device, comprising: initiating a handshake protocol to establish a connection with a service device; receiving an attestation certificate from the service device; performing verification of whether the attestation certificate has a chain of trust derived from a proxy attestation service certificate associated with a proxy attestation system for managing attestation of the service device according to a selected one of a plurality of attestation services supported by the proxy attestation system; and determining whether to proceed with communication with the service device based on the verification of the attestation certificate.

45. The method of clause 44, in which the client device determines whether to proceed with communication with the service device based on a single round trip communication in the handshake protocol, the single round trip communication comprising a single message from the client device to the service device and a single response from the service device to the client device.

46. The method of any of clauses 44 and 45, in which the attestation certificate is provided in a first response provided by the service device to the client device after the client device initiates the handshake protocol. 47. The method of any of clauses 44 to 46, in which the handshake protocol is a TLS (Transport Layer Security) handshake protocol.

48. The method of clause 47, in which the attestation certificate is provided in a ServerHello message returned to the client device in response to a ClientHello message for initiating the TLS handshake protocol.

49. The method of any of clauses 44 to 48, in which the verification comprises verifying whether the service device has at least one feature, based on service device information specified in the attestation certificate.

50. The method of clause 49, in which the service device information is specified in an extension of the attestation certificate.

51. The method of clause 49, in which the attestation certificate has a chain of trust derived from a selected one of a plurality of proxy attestation service certificates; and the service device information is represented in the attestation certificate according to which of the plurality of proxy attestation service certificates is the selected one of the plurality of proxy attestation service certificates.

52. The method of clause 51, in which the verification comprises determining whether the attestation certificate can be authenticated based a selected subset of the proxy attestation service certificates defined as allowed proxy attestation service certificates by the client device.

53. The method of any of clauses 51 and 52, in which the plurality of proxy attestation service certificates are part of a tree of certificates in which a given child certificate in the tree has a chain of trust derived from its parent certificate in the tree.

54. The method of clause 53, in which the given child certificate attests that the service device has at least one feature also attested to by its parent certificate, and that the service device has at least one additional feature not attested to by its parent certificate.

55. The method of any of clauses 44 to 54, in which the attestation certificate comprises an X.509 certificate.

56. A client device comprising: communication circuitry to initiate a handshake protocol to establish a connection with a service device, and receive an attestation certificate from the service device; and control circuitry to perform verification of whether the attestation certificate has a chain of trust derived from a proxy attestation service certificate associated with a proxy attestation system for managing attestation of the service device according to a selected one of a plurality of attestation services supported by the proxy attestation system, and determine whether to proceed with communication with the service device based on the verification of the attestation certificate.

57. A computer program comprising instructions which, when executed on a computer, control the computer to perform the method of any of clauses 1 to 10, 12 to 26, 28 to 42 and 44 to 55.

58. A computer-readable storage medium storing the computer program of clause 57. 59. An apparatus comprising: processing circuitry to execute instructions; and storage circuitry to store the computer program of clause 57.

60. A data processing system comprising: challenge circuitry to issue a challenge to a service device and to receive a response to the challenge; forwarding circuitry to forward at least part of the response to a selected one of a plurality of attestation systems and to receive a success indication from the selected one of the plurality of attestation systems regarding whether the service device has been attested by the selected one of the plurality of attestation systems; and request circuitry to receive a request to provide an attestation of the service device, and to provide the attestation in dependence on the success indication.

61. The data processing system according to clause 60, comprising: policy storage circuitry, adapted to store at least one policy; and the request circuitry is adapted to provide the attestation in dependence on the at least one policy.

62. The data processing system according to clause 61 , wherein the at least one policy indicates the selected one of the plurality of attestation systems.

63. The data processing system according to any of clauses 61 and 62, wherein the policy storage circuitry is adapted to store a plurality of policies; and the request comprises an indication of a selected policy in the plurality of policies that is to be applied; and the request circuitry is adapted to provide the attestation in dependence on the selected policy.

64. The data processing system according to any of clauses 61 to 63, wherein the policy storage circuitry is adapted to store a plurality of policies; and the request circuitry is adapted, in response to the request to provide the attestation, to provide an indication of which of the plurality of policies have requirements that are met by the service device.

65. The data processing system according to any of clauses 61 to 64, wherein the success indicator comprises one or more service device characteristics; and the at least one policy specifies requirements of the service device characteristics.

66. The data processing system according to clause 65, wherein the requirements of the service device characteristics are hardware requirements.

67. The data processing system according to any of clauses 60 to 66, wherein the response to the challenge indicates the selected one of the plurality of attestation systems.

68. The data processing system according to any of clauses 60 to 67, wherein the selected policy denies the use of a banned attestation system in the plurality of attestation systems.

69. The data processing system according to any of clauses 60 to 68, wherein the forwarding circuitry is adapted to forward the at least part of the response to each of the plurality of attestation systems and to receive a plurality of success indicators from each of the attestation systems regarding whether the service device has been attested by that attestation system.

70. The data processing system according to any of clauses 60 to 69, wherein at least some of the plurality of attestation systems are mirrors; and the forwarding circuitry is adapted to use a backup one of the mirrors in response to a communication error with a primary one of the mirrors.

71. The data processing system according to clause 70, wherein the communication error is the primary one of the mirrors being unreachable.

72. The data processing system according to any of clauses 60 to 71, wherein the at least part of the response is consistent across all of the attestation systems.

73. A data processing method comprising: issuing a challenge to a service device; receiving a response to the challenge; forwarding at least part of the response to a selected one of a plurality of attestation systems; receiving a success indication from the selected one of the plurality of attestation systems regarding whether the service device has been attested by the selected one of the plurality of attestation systems; and receiving a request to provide an attestation of the service device, and to provide the attestation in dependence on the success indication.

74. A data processing apparatus comprising: challenge circuitry to issue a challenge to a service device and to receive a response to the challenge, wherein the response includes a set of policies that the service device complies with according to an attestation server, the set of policies being signed using a signature of a data processing system that is adapted to communicate with the attestation server; and comparison circuitry to validate the signature and when the signature is validated, to determine whether the set of policies comprises a desired policy of the data processing apparatus, wherein the policies indicate requirements regarding at least one of the attestation system and the service device.

In the present application, the words “configured to...” are used to mean that an element of an apparatus has a configuration able to carry out the defined operation. In this context, a “configuration” means an arrangement or manner of interconnection of hardware or software. 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. “Configured to” does not imply that the apparatus element needs to be changed in any way in order to provide the defined operation.

Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes, additions and modifications can be effected therein by one skilled in the art without departing from the scope and spirit of the invention as defined by the appended claims. For example, various combinations of the features of the dependent claims could be made with the features of the independent claims without departing from the scope of the present invention.

Claims

2. The method of claim 1, in which the proxy attestation system acts as a certificate authority.

3. The method of any of claims 1 and 2, in which the token obtained from the service device includes a certificate signing request, and in response to determining successful attestation of the service device based on the success indication, the attestation certificate is generated based on the certificate signing request included in the token.

4. The method of any preceding claim, in which the attestation certificate provides service device information indicative of at least one feature of the service device.

5. The method of claim 4, in which the service device information is specified in an extension of the attestation certificate.

6. The method of claim 4, comprising: selecting, depending on at least one feature of the service device, one of a plurality of proxy attestation service certificates, wherein the attestation certificate has a chain of trust derived from the selected one of the plurality of proxy attestation service certificates; and the service device information is represented in the attestation certificate according to which of the plurality of proxy attestation service certificates is the selected one of the plurality of proxy attestation service certificates.

7. The method of claim 6, in which the plurality of proxy attestation service certificates are part of a tree of certificates in which a given child certificate in the tree has a chain of trust derived from its parent certificate in the tree.

8. A proxy attestation system comprising: communication circuitry to obtain a token from a service device; and proxy attestation circuitry to determine whether the service device associated with the token has been attested by a selected one of a plurality of attestation services supported by the proxy attestation system; in which: in response to determining successful attestation of the service device, the proxy attestation circuitry is configured to generate an attestation certificate that has a chain of trust derived from a proxy attestation service certificate associated with the proxy attestation system, and the communication circuitry is configured to provide the attestation certificate to the service device.

9. A data processing method for a service device, comprising: providing a token to a proxy attestation system for managing attestation of the service device according to a selected one of a plurality of attestation services supported by the proxy attestation system; receiving from the proxy attestation system an attestation response providing an attestation certificate indicating that the service device has been attested according to the selected one of the plurality of attestation services, where the attestation certificate has a chain of trust derived from a proxy attestation service certificate associated with the proxy attestation system; and providing to a requester at least one of the attestation certificate and a further certificate having a chain of trust derived from the attestation certificate.

10. A service device, comprising: communication circuitry to provide a token to a proxy attestation system for managing attestation of the service device according to a selected one of a plurality of attestation services supported by the proxy attestation system, and to receive from the proxy attestation system an attestation response providing an attestation certificate indicating that the service device has been attested according to the selected one of the plurality of attestation services, where the attestation certificate has a chain of trust derived from a proxy attestation service certificate associated with the proxy attestation system; and control circuitry to provide to a requester at least one of the attestation certificate and a further certificate having a chain of trust derived from the attestation certificate.

11. A data processing method for a service device, comprising: obtaining an attestation certificate that has a chain of trust derived from a proxy attestation service certificate associated with a proxy attestation system for managing attestation of the service device according to a selected one of a plurality of attestation services supported by the proxy attestation system; and in response to a client device initiating a handshake protocol to establish a connection with the service device, providing to the client device at least one of the attestation certificate and a further certificate having a chain of trust derived from the attestation certificate.

12. A service device comprising: control circuitry to obtain an attestation certificate that has a chain of trust derived from a proxy attestation service certificate associated with a proxy attestation system for managing attestation of the service device according to a selected one of a plurality of attestation services supported by the proxy attestation system; and communication circuitry, responsive to a client device initiating a handshake protocol to establish a connection with the service device, to provide the client device with at least one of the attestation certificate and a further certificate having a chain of trust derived from the attestation certificate.

13. A data processing method for a client device, comprising: initiating a handshake protocol to establish a connection with a service device; receiving an attestation certificate from the service device; performing verification of whether the attestation certificate has a chain of trust derived from a proxy attestation service certificate associated with a proxy attestation system for managing attestation of the service device according to a selected one of a plurality of attestation services supported by the proxy attestation system; and determining whether to proceed with communication with the service device based on the verification of the attestation certificate.

14. A client device comprising: communication circuitry to initiate a handshake protocol to establish a connection with a service device, and receive an attestation certificate from the service device; and control circuitry to perform verification of whether the attestation certificate has a chain of trust derived from a proxy attestation service certificate associated with a proxy attestation system for managing attestation of the service device according to a selected one of a plurality of attestation services supported by the proxy attestation system, and determine whether to proceed with communication with the service device based on the verification of the attestation certificate.

15. A computer program comprising instructions which, when executed on a computer, control the computer to perform the method of any of claims 1 to 7, 9, 11 and 13.