Method, device and system for data processing
By generating and verifying forensic messages between data processing devices, the high cost and market entry barriers caused by vertical integration of forensic protocols in the prior art are solved, and a standardized and coordinated forensic process is realized, supporting multiple protocols and interactive systems. verify.
Patent Information
- Application Number
- CN201980037006.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2018-06-11
- Filing Date
- 2019-05-24
- Publication Date
- 2025-01-03
- Estimated Expiration
- 2039-05-24
AI Technical Summary
The vertical integration of existing forensic protocols has resulted in high cost in device vendors and software vendors when adapting to the ever-changing market and has difficulty supporting the verification of multiple protocols and interactive systems, leading to barriers to market entry.
The first data processing device requests for assertion of the second data processing device, generates device-specific and application-specific assertion messages, and binds them through cryptographic methods, establishes interactions after verifying the trusted state, and realizes standardization and coordination of the interaction protocol.
Reduces costs for equipment and software vendors, simplifies the forensic process, supports verification of multiple protocols and interactive systems, and improves market adaptability and interoperability.
Smart Images
Figure CN112236770B_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to data processing. Background Art
[0002] Attestation is a data processing technique that allows a verifying entity (e.g., a data processing device) to determine the trustworthiness and / or capabilities of another entity or data processing device that the verifying entity interacts with. For example, a client device connected to another device running a specific software service may need to be able to verify that the service has been properly instantiated and is running in the context of a trusted hardware implementation. Similarly, an IoT (Internet of Things) service may need to be able to determine the capabilities and / or trustworthiness of IoT devices connected to it.
[0003] In previously proposed authentication implementations, proprietary protocols were used that required integration within the overall inter-entity system (possibly including dedicated hardware integration). A large number of such authentication protocols and systems exist today, each of which is tailored to the specific needs of an individual inter-entity system. These vertically integrated protocols are considered unlikely to be standardized, harmonized, or replaced, and may even represent a barrier to market entry between competing systems.
[0004] As security systems become larger and more ubiquitous, this arrangement may become expensive and cumbersome for device vendors to adapt to a changing marketplace, may become expensive and cumbersome for software vendors when the immutable root of trust is part of the device hardware and thus authentication requires hardware-specific porting and implementation of the authentication client, and / or may become expensive and cumbersome for verification entities that need to potentially support multiple protocols and interacting systems. Summary of the invention
[0005] In one example arrangement, a method is provided, comprising:
[0006] A first data processing device requests authentication of a second data processing device;
[0007] The second data processing device generates a device specific authentication message based on the device specific key, a hardware configuration of the second data processing device, and a software configuration of software running on the second data processing device;
[0008] The second data processing device generates an application specific authentication message according to an interaction protocol by which the first data processing device and the second data processing device interact;
[0009] The second data processing device cryptographically binds the application specific authentication message to the device specific authentication message;
[0010] The first data processing device verifies the application-specific authentication message, the verification step comprising: detecting a trusted state of the application-specific authentication message by verifying the device-specific authentication message cryptographically bound to the application-specific authentication message; and
[0011] The first data processing device establishes interaction with the second data processing device according to the verified application specific authentication message and according to the interaction protocol.
[0012] In another example arrangement, there is provided a data processing device comprising:
[0013] circuitry for storing a device-specific key;
[0014] circuitry for generating, in response to a request for authentication by a second data processing device, a device-specific authentication message based on the device-specific key, a hardware configuration of the data processing device, and a software configuration of software running on the data processing device;
[0015] circuitry for generating an application specific authentication message in accordance with an interaction protocol by which the data processing device interacts with the second data processing device;
[0016] Circuitry for cryptographically binding the application-specific authentication message with the device-specific authentication message.
[0017] In another example arrangement, there is provided a data processing device comprising:
[0018] circuitry for requesting authentication of a second data processing device and receiving a device-specific authentication message from the second data processing device, the device-specific authentication message being based on a device-specific key, a hardware configuration of the second data processing device, and a software configuration of software running on the second data processing device, the device-specific authentication message being bound to an application-specific authentication message according to an interaction protocol by which the data processing device interacts with the second data processing device;
[0019] circuitry for verifying the application-specific authentication message, the verification comprising: detecting a trusted state of the application-specific authentication message by verifying the device-specific authentication message cryptographically bound to the application-specific authentication message; and
[0020] The circuit is used to establish interaction with the second data processing device according to the interaction protocol based on the verified application specific authentication message.
[0021] In another example arrangement, there is provided a data processing system comprising: data processing devices as defined above, the data processing devices being configured to interact with each other using the interaction protocol.
[0022] In another example arrangement, there is provided a method of operating a data processing device, the method comprising:
[0023] Storing device-specific keys;
[0024] generating, in response to a request for authentication by a second data processing device, a device-specific authentication message based on the device-specific key, a hardware configuration of the data processing device, and a software configuration of software running on the data processing device;
[0025] generating an application specific authentication message according to an interaction protocol by which the data processing device interacts with the second data processing device;
[0026] The application specific authentication message is cryptographically bound to the device specific authentication message.
[0027] In another example arrangement, there is provided a method of operating a data processing device, the method comprising:
[0028] requesting authentication of a second data processing device and receiving a device-specific authentication message from the second data processing device, the device-specific authentication message being cryptographically bound to an application-specific authentication message according to an interaction protocol by which the data processing device interacts with the second data processing device based on a device-specific key, a hardware configuration of the second data processing device, and a software configuration of software running on the second data processing device;
[0029] verifying the application-specific authentication message, the verification comprising: detecting a trusted state of the application-specific authentication message by verifying the device-specific authentication message cryptographically bound to the application-specific authentication message; and
[0030] Based on the verified application specific authentication message, interaction is established with the second data processing device according to the interaction protocol.
[0031] In another example arrangement, a computer program for controlling a host data processing device to provide an instruction execution environment is provided, comprising: computer program logic for storing a device-specific key; computer program logic for generating a device-specific authentication message in response to a request for authentication by a second data processing device based on the device-specific key, the hardware configuration of the data processing device, and the software configuration of software running on the data processing device; computer program logic for generating an application-specific authentication message based on an interaction protocol by which the data processing device interacts with the second data processing device; and computer program logic for cryptographically binding the application-specific authentication message to the device-specific authentication message.
[0032] In another example arrangement, there is provided a computer program for controlling a host data processing apparatus to provide an instruction execution environment, comprising:
[0033] computer program logic to request authentication of a second data processing device and to receive a device-specific authentication message from the second data processing device, the device-specific authentication message being based on a device-specific key, a hardware configuration of the second data processing device, and a software configuration of software running on the second data processing device, the device-specific authentication message being bound to an application-specific authentication message based on an interaction protocol by which the data processing device interacts with the second data processing device;
[0034] Computer program logic to verify the application specific authentication message, the verification comprising: detecting a trusted status of the application specific authentication message by verifying the device specific authentication message cryptographically bound to the application specific authentication message; and
[0035] Computer program logic is used to establish interaction with the second data processing device according to the interaction protocol based on the verified application specific authentication message.
[0036] Further respective aspects and features of the present technology are defined by the appended claims. BRIEF DESCRIPTION OF THE DRAWINGS
[0037] The present technology will be further described, by way of example only, with reference to embodiments of the present technology as illustrated in the accompanying drawings, in which:
[0038] Figure 1 schematically illustrates a data processing device;
[0039] Figure 2 The diagram shows the manufacturing Figure 1 A schematic flow chart of at least a portion of a method of an apparatus;
[0040] Figure 3 schematically illustrates the operation of the secure storage module;
[0041] Figure 4 A schematic overview of the operation of an embodiment of the present disclosure is provided;
[0042] Figure 5 is a schematic flow chart illustrating a method;
[0043] Figure 6 is a schematic flow chart illustrating an example cryptographic binding technique;
[0044] Figure 7 schematically illustrates another data processing device;
[0045] Figure 8 and Fig. 9 is a schematic flow chart illustrating a corresponding method; and
[0046] Fig.10 The simulator implementation is schematically illustrated. DETAILED DESCRIPTION
[0047] Now refer to the accompanying drawings, Figure 1 The schematic diagram shows a data processing device 100 suitable for use as a device capable of responding to an authentication request, the data processing device comprising an application execution circuit 110 having a processing element or central processing unit (CPU) 120, a memory 130 (e.g., a random access memory (RAM)), an interface 140, and a memory for one or more applications (e.g., a non-volatile machine-readable memory, such as a flash memory) 150. The apparatus also includes a secure storage module 160 in data communication with the application execution circuit 110.
[0048] The secure storage module 160 can be implemented as tamper-resistant memory that is accessible under all circumstances by the circuit 110. In other examples, the term "tamper-resistant" refers to the memory being stereotyped or secured against changes made after manufacture of the device 100 and / or accesses other than by the circuit 110 or permitted applications executing on the circuit 110.
[0049] In other examples, the secure storage module 160 may be a so-called trusted platform module (TPM), which again refers to a tamper-resistant piece of cryptographic hardware built into the device 100 that, in addition to storing one or more keys as discussed below, may also implement at least some cryptographic functions based on a set of cryptographic operations that may be constructed. The following link provides a description of the TPM: https: / / en.wikipedia.org / wiki / Trusted_Platform_Module , which is incorporated by reference into this specification. In some examples, as an example of secure storage module 160, the TPM can have the following capabilities: perform public key cryptographic operations, calculate hash functions, securely store keys and other secret data, and potentially generate random numbers and perform authentication functions to be discussed below. In this context, a hash function is a mathematical function used to map an input data space to a generally smaller output data space. In the context of cryptography, hash functions are generally established to make it difficult to select another input value that results in the same output hash value.
[0050] Therefore, as part of the functionality of the secure storage module 160, at least one so-called device specific key (DSK) or implementation key 162 is securely stored. This is provided and stored when the device 100 is manufactured and is stored according to the following reference. Figure 2 A method is provided for describing the same.
[0051] Thus, using the techniques further described below, device 100 may provide an example of a data processing device comprising: circuit 160 for storing a device-specific key; and circuit 110 / 160 for generating, in response to a request for authentication by a second data processing device, a device-specific authentication message based on the device-specific key, the hardware configuration of the data processing device, and the software configuration of software running on the data processing device, to generate an application-specific authentication message based on an interaction protocol by which the data processing device interacts with the second data processing device, and to cryptographically bind the application-specific authentication message to the device-specific authentication message.
[0052] refer to Figure 2 At step 200, a verification device (e.g., provided by a verification service) generates a device-specific key 162. This is unique to the device 100, or at least unique within a family of devices that includes the device 100 (so that for any particular instance of the device 100, the DSK 162 is at least unique relative to any other instance of the device 100). At step 210, a verification service (e.g., a verification service using the verification device) cryptographically signs the device-specific key. At step 220, the device-specific key 162 is stored in a secure storage module as part of the manufacture of the device 100.
[0053] Figure 3 is a schematic flow chart illustrating an example technique for controlling access to a device-specific key held by a secure storage module. This provides an example where a second data processing device (device 100) securely stores the device-specific key, and where the step of generating a device-specific authentication message includes: authentication client software of the second data processing device accessing the securely stored device-specific key.
[0054] In at least some examples, when access to the device-specific key is requested by an application at circuit 110, the CPU 120 or the hash function generator of the secure storage module 160 generates a hash value from the computer software forming the application at step 300, which is passed to the secure storage module, which then compares the generated hash value with the stored hash values of the permissible applications that should be allowed to access the device-specific key. At step 320, the secure storage module allows or denies access to the device-specific key based on whether the hash value provided by the CPU at step 300 is the same as the stored hash value detected at step 310.
[0055] Thus, this provides an example of an access step that includes comparing a hash value from an attempt by client software to access a device specific key to a set of one or more hash values indicating that access to the securely stored device specific key is allowed.
[0056] In these or other examples, arrangements as described may prohibit or limit access to device-specific keys except for indirect access to the device-specific keys through the use of device-specific authentication software (e.g., running as an example of application code 150). Such software may use a secret hash or encryption algorithm, etc. to provide access to the device-specific keys, or may test for the presence of certain device-specific hardware and / or software features to allow such access.
[0057] The overview of this embodiment is given by Figure 4 Here, the authentication process is considered separately (or split) between authentication of various device-specific aspects (e.g., the hardware configuration of the device to be authenticated and the software configuration of the software running on the device), and is independent of protocol-specific authentication considerations related to application-specific considerations of the interaction protocol by which the data processing devices (the device requesting authentication and the device to be authenticated) will communicate.
[0058] Examples of application-specific attestation parameters may include the following:
[0059] Parameters related to the authentication protocol for the interaction between device 100 and other devices
[0060] Application-specific status, such as whether the device has been commissioned to use the service
[0061] Examples of device-specific attestation parameters might include the following:
[0062] Manufacturer
[0063] Root of Trust
[0064] Hardware Implementation
[0065] Device-specific status, such as whether the device 100 is in a debugging state
[0066] Completion of the initial boot process
[0067] The software version running on the device 100 and verified by the initial boot process
[0068] refer to Figure 4 , the device-specific key 162 is referred to in the figures as an implementation key or implementation authentication key. The implementation signer 400 issues the implementation key when the device is manufactured. The implementation signer is associated with the implementation verifier 410. The signed implementation key identifies the device 430 (e.g. Figure 1 The device 430 may be configured to verify various device-specific aspects of an implementation of the device 100 of the present invention (or assertions that may be used to verify such device-specific aspects) and may be installed in secure storage of the device 430 at the time of manufacture 420. The device 430 may have a protocol-specific (application-specific) authentication client application 440 that obtains a signed authentication 442 from or uses secure storage 444 of the device 430.
[0069] The authentication process can take various forms. For example, to generate a device-specific authentication message, data can be provided to the secure storage module 160 (at the time of manufacture) that indicates hardware characteristics of the device 100, which can be provided in the form of a message signed by the device-specific key 162 (e.g., signed using the functionality of the secure storage module 160).
[0070] The application specific authentication message may be generated, for example, as follows: An application running on the application execution circuit 110 generates a public / private key pair used to sign the application specific message. The secure storage module signs the hash of the public key with the DSK 162, thereby creating a cryptographic binding.
[0071] The authentication client 440 and the verification entity 450 (eg, another data processing device, an example of which will be referred to below) Figure 7 The authentication client controls the cryptographic binding of any protocol specific authentication information 452 to the implementation authentication 454. Figure 6 The binding operation is discussed further below. This thus links the protocol specific authentication information with the root of trust represented by the implementation authentication key 444 without requiring the provisioning of protocol specific hardware at the device 430.
[0072] Verifying entity 450 verifies the protocol specific certificate with protocol specific verifier 460, which in turn interacts with implementation verifier 410 to verify implementation certificate 442 used to cryptographically sign the protocol specific certificate.
[0073] Figure 5 is a schematic flow chart illustrating a method. Figure 5 , operations performed by a verification device (referred to as a first data processing device) are shown on the left side of a dotted line 500, and operations performed by a device to be verified (referred to as a second data processing device) are shown on the right side of the dotted line 500. The method comprises the following steps.
[0074] At step 510, the first data processing device ( Figure 4 The verification entity 450 in requests authentication of the second data processing device or authentication performed by the second data processing device.
[0075] At step 520, the second data processing device ( Figure 4 The device 430 in the second data processing device generates a device-specific authentication message 454 based on the device-specific key, the hardware configuration of the second data processing device, and the software configuration of the software running on the second data processing device.
[0076] At step 530, the second data processing device generates an application specific authentication message 454 according to the interaction protocol by which the first data processing device and the second data processing device interact.
[0077] At step 540 , the second data processing device cryptographically binds the application specific authentication message 454 to the device specific authentication message 452 .
[0078] Note that in some example embodiments, step 540 may involve signing the messages generated at both steps 520 and 530, thereby creating a cryptographic binding.
[0079] At step 550 , the first data processing device verifies the application specific authentication message, the verification step comprising: detecting a trusted status of the application specific authentication message by verifying a device specific authentication message cryptographically bound to the application specific authentication message.
[0080] Step 200( Figure 2 ) and 550( Figure 5 ) may involve interactions with the same entity because they may provide an example of a verification apparatus that generates a device-specific key for storage by a second data processing device and an example of a verification step that includes a first data processing device requesting verification of a device-specific authentication message by the verification apparatus.
[0081] At step 560 , based on the verified application-specific authentication message, the first data processing device establishes interaction with the second data processing device according to the interaction protocol.
[0082] As schematically shown by steps 570 and 580, establishment of an interaction may involve the first data processing device exchanging one or more session keys with the second data processing device (e.g., via a so-called Diffie-Hellman key exchange technique for encrypted communications between the first data processing device and the second data processing device), and using the session keys to effectuate communication.
[0083] Figure 6 The schematic diagram shows the process of cryptographic binding of device-specific authentication messages with application-specific authentication messages. The steps on the left side of the dashed line 601 are implemented by the authenticating device, and the steps on the right side of the dashed line 601 are implemented by the device to be authenticated.
[0084] In general, cryptographic binding provides a technique for demonstrating data integrity and authenticity using cryptographic operations. In some examples, the technique can operate by generating a hash value for each data object and digitally signing a set of one or more hash values. When the data is subsequently accessed, the signature can be verified, and any differences in the hash values can be used to detect which data object has been modified since the binding operation occurred.
[0085] At step 600 , the device to be authenticated generates a hash of the application-specific authentication message and, at step 610 , cryptographically signs the generated hash using an implementation key or a device-specific key.
[0086] At step 620, the verification device verifies the signature, possibly with reference to verifier 410. The verification device generates a corresponding hash value using the same hash algorithm at step 630, and compares the just generated hash value with the signed hash value at step 640. If the two match, then the application-specific authentication message can be trusted.
[0087] Note that, as discussed above, in some other example embodiments, this process may be performed effectively while generating the device-specific attestation to prove that the signed binding and the device-specific attestation are together. In other words, in some examples, step 540 may involve signing both 520 and 530 to create the binding.
[0088] Figure 7 The schematic diagram shows a verification request data processing device 700, which includes a processing element (e.g., a central processing unit or CPU 710), one or more memories 720 for one or more applications including, for example, RAM and storage (e.g., non-volatile machine-readable storage, such as flash memory), and an interface 730.
[0089] Figure 7Thus, an example of a data processing device is provided, the data processing device comprising: circuitry for requesting authentication of a second data processing device and receiving from the second data processing device a device-specific authentication message based on a device-specific key, a hardware configuration of the second data processing device, and a software configuration of software running on the second data processing device, the device-specific authentication message being cryptographically bound to an application-specific authentication message based on an interaction protocol by which the data processing device interacts with the second data processing device; circuitry for verifying the application-specific authentication message, the verification comprising: detecting a trusted state of the application-specific authentication message by verifying the device-specific authentication message cryptographically bound to the application-specific authentication message; and circuitry for establishing interaction with the second data processing device according to the interaction protocol based on the verified application-specific authentication message. These functions may be performed by the CPU 710 under the control of computer software stored by the memory 720.
[0090] Figure 5 The interactions shown in can occur in the context of a data processing system including Figure 1 The data processing device 100 is configured to use the established interaction protocol to communicate with Figure 7 The data processing device 700 interacts with the data processing device 700.
[0091] Figure 8 is a diagram illustrating an operation of a data processing device (e.g., a device to be verified, such as Figure 1 A schematic flow chart of a method for a device comprising:
[0092] (at step 800) storing a device specific key;
[0093] generating, in response to a request for authentication by a second data processing device, a device-specific authentication message based on a device-specific key, a hardware configuration of the data processing device, and a software configuration of software running on the data processing device (at step 810);
[0094] generating (at step 820) an application specific authentication message according to an interaction protocol by which the data processing device interacts with a second data processing device; and
[0095] The application-specific authentication message is cryptographically bound to the device-specific authentication message (at step 830), eg, for sending to the verification requesting device.
[0096] Fig. 9 is a diagram illustrating an operation of a data processing device (eg, a verification request device, such as Figure 7 A schematic flow chart of a method for a device comprising:
[0097] requesting authentication of the second data processing device and receiving from the second data processing device a device-specific authentication message based on a device-specific key, a hardware configuration of the second data processing device, and a software configuration of software running on the second data processing device, the device-specific authentication message being cryptographically bound to an application-specific authentication message based on an interaction protocol by which the data processing device interacts with the second data processing device;
[0098] verifying (at step 910) the application-specific authentication message, the verification comprising: detecting a trusted state of the application-specific authentication message by verifying a device-specific authentication message cryptographically bound to the application-specific authentication message; and
[0099] Interaction is established with the second data processing device according to the interaction protocol based on the verified application specific authentication message (at step 920).
[0100] Fig.10 The schematic diagram shows the simulator implementation that can be used. Although the previously described embodiments implement the present disclosure from the aspect of the apparatus and method for operating the specific processing hardware supporting the related technology, it is also possible to provide an instruction execution environment according to the embodiments described herein, which is implemented by using a computer program. Such computer programs are generally referred to as simulators, as long as they provide a software-based implementation of the hardware architecture. The variants of the simulator computer program include emulators, virtual machines, models, and binary converters (including dynamic binary converters). In general, the simulator implementation can be run on a host processor 1030 (optionally running a host operating system 1020) that supports the simulator program 1010. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or there are multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been needed to provide simulator implementations that are executed at reasonable speeds, but such an approach can be reasonable in some cases, such as when there is a need to run native code relative to another processor based on compatibility or reuse reasons. For example, a simulator implementation may provide an instruction execution environment with additional functionality not supported by the host processor hardware, or provide an instruction execution environment that is generally associated with a different hardware architecture. An overview of simulation is given in "Some Efficient Architecture Simulation Techniques", by Robert Bedichek, USENIX Conference, Winter 1990, pp. 53-63, the contents of which are hereby incorporated by reference herein.
[0101] Where embodiments have previously been described for specific hardware constructs or features, equivalent functionality may be provided by suitable software constructs or features in simulated embodiments. For example, specific circuits may be implemented as computer program logic in simulated embodiments. Similarly, memory hardware (e.g., registers or caches) may be implemented as software data structures in simulated embodiments. Where one or more of the hardware elements referenced in the previously described embodiments are present in an arrangement on host hardware (e.g., host processor 1030), some simulated embodiments may utilize host hardware where appropriate.
[0102] The simulator program 1010 may be stored on a computer-readable or machine-readable storage medium (which may be a non-transitory medium) and provides a program interface (instruction execution environment) to the target code 1000 (which may include an application, an operating system, and a hypervisor) that is the same as the application program interface of the hardware architecture being modeled by the simulator program 1010. Therefore, the simulator program 1010 may be used to execute program instructions of the target code 1000 (including instructions for performing one or more of the methods described above) from within the instruction execution environment, so that there is actually no need for the above-discussed method. Figure 1 and / or Figure 7 The host computer 1030 can emulate the hardware features of the device.
[0103] In this application, the words "configured to..." are used to mean that elements of a device have a configuration that enables a defined operation. In this context, "configuration" means the arrangement or manner in which hardware or software are interconnected. For example, the device may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform a function, in which case software or program instructions by which the function is performed, and a providing medium (e.g., a non-transitory machine-readable medium) by which such software or program instructions are provided (e.g., stored) are considered to represent embodiments of the present disclosure. "Configured to" does not imply that the device elements need to be changed in any way to provide the defined operation.
[0104] Although illustrative embodiments of the present technology have been described in detail herein with reference to the accompanying drawings, it should be understood that the present technology is not limited to these precise embodiments, and various changes, additions, and modifications may be made in these embodiments by those skilled in the art without departing from the scope and spirit of the technology as defined by the appended claims. For example, various combinations of features of the dependent claims with features of the independent claims may be made without departing from the scope of the present technology.
Claims
1. A method for data processing, comprising: A first data processing device requests authentication of a second data processing device; the second data processing device generating a device specific authentication message based on a hardware configuration of the second data processing device and a software configuration of software running on the second data processing device, the device specific authentication message being signed using a device specific key; the second data processing device generating an application specific authentication message according to an interaction protocol by which the first data processing device and the second data processing device interact; The second data processing device cryptographically binds the application specific authentication message with the device specific authentication message; The first data processing device verifies the application-specific authentication message, and the verification of the application-specific authentication message includes: detecting a trusted state of the application-specific authentication message by verifying the device-specific authentication message cryptographically bound to the application-specific authentication message; and The first data processing device establishes interaction with the second data processing device according to the interaction protocol based on the verified application specific authentication message.
2. The method according to claim 1, comprising the steps of: The second data processing device securely stores the device specific key; And wherein the step of generating the device specific authentication message comprises: authentication client software of the second data processing device accessing the securely stored device specific key.
3. The method of claim 2, comprising: Access to the device specific key is prohibited except indirectly through the use of device specific attestation software.
4. The method of claim 2, wherein the accessing step comprises: The hash according to the attestation client software is compared to a set of one or more hash values indicating that access to the securely stored device-specific key is permitted.
5. The method of any one of claims 1 to 4, wherein the establishing step comprises: The first data processing device exchanges one or more session keys with the second data processing device for encrypted communication between the first data processing device and the second data processing device.
6. The method according to any one of claims 1 to 4, comprising the following steps: verification means generating said device specific key for storage by said second data processing device; And wherein the verification step comprises: the first data processing device requests the verification means to verify the device-specific authentication message.
7. A data processing device comprising: Circuitry for storing a device-specific key; circuitry for generating, in response to a request for authentication by a second data processing device, a device-specific authentication message based on a hardware configuration of the data processing device and a software configuration of software running on the data processing device, the device-specific authentication message being signed using the device-specific key; circuitry for generating an application specific authentication message in accordance with an interaction protocol by which the data processing device interacts with the second data processing device; as well as Circuitry for cryptographically binding the application specific authentication message to the device specific authentication message.
8. A data processing device comprising: circuitry for requesting authentication of a second data processing device and for receiving a device-specific authentication message from the second data processing device, the device-specific authentication message being based on a hardware configuration of the second data processing device and a software configuration of software running on the second data processing device, the device-specific authentication message being cryptographically bound to an application-specific authentication message based on an interaction protocol by which the data processing device interacts with the second data processing device, the device-specific authentication message being signed using a device-specific key; circuitry for verifying the application-specific authentication message, the verification comprising: detecting a trusted state of the application-specific authentication message by verifying the device-specific authentication message cryptographically bound to the application-specific authentication message; as well as Circuitry for establishing interaction with the second data processing device according to the interaction protocol based on the verified application specific authentication message.
9. A data processing system comprising: The data processing device of claim 7, configured to interact with the data processing device of claim 8 using the interaction protocol.
10. A method of operating a data processing device, the method comprising: Storing device-specific keys; generating, in response to a request for authentication by a second data processing device, a device-specific authentication message based on a hardware configuration of the data processing device and a software configuration of software running on the data processing device, the device-specific authentication message being signed using the device-specific key; generating an application specific authentication message according to an interaction protocol by which the data processing device interacts with the second data processing device; The application specific authentication message is cryptographically bound to the device specific authentication message.
11. A method of operating a data processing device, the method comprising: requesting authentication of a second data processing device and receiving a device-specific authentication message from the second data processing device, the device-specific authentication message being based on a hardware configuration of the second data processing device and a software configuration of software running on the second data processing device, the device-specific authentication message being cryptographically bound to an application-specific authentication message based on an interaction protocol by which the data processing device interacts with the second data processing device, the device-specific authentication message being signed using a device-specific key; Verifying the application-specific authentication message, the verification comprising: detecting a trusted state of the application-specific authentication message by verifying the device-specific authentication message cryptographically bound to the application-specific authentication message; and Based on the verified application specific authentication message, interaction is established with the second data processing device according to the interaction protocol.
12. A computer program product comprising a computer program for controlling a host data processing device to provide an instruction execution environment, comprising: Computer program logic for storing a device-specific key; computer program logic to generate, in response to a request for authentication by a second data processing device, a device-specific authentication message based on a hardware configuration of the data processing device and a software configuration of software running on the data processing device, the device-specific authentication message being signed using the device-specific key; computer program logic for generating an application specific authentication message in accordance with an interaction protocol by which the data processing device interacts with the second data processing device; as well as Computer program logic for cryptographically binding the application specific authentication message to the device specific authentication message.
13. A computer program product comprising a computer program for controlling a host data processing device to provide an instruction execution environment, comprising: computer program logic for requesting authentication of a second data processing device and receiving a device-specific authentication message from the second data processing device, the device-specific authentication message being based on a hardware configuration of the second data processing device and a software configuration of software running on the second data processing device, the device-specific authentication message being cryptographically bound to an application-specific authentication message based on an interaction protocol by which the data processing device interacts with the second data processing device, the device-specific authentication message being signed using a device-specific key; computer program logic for verifying the application specific authentication message, the verification comprising: detecting a trusted status of the application specific authentication message by verifying the device specific authentication message cryptographically bound to the application specific authentication message; as well as Computer program logic for establishing interaction with the second data processing device according to the interaction protocol based on the verified application specific authentication message.
14. A non-transitory machine-readable storage medium storing the computer program according to claim 12 or claim 13.
15. A computer program product comprising a computer program which, when executed by one or more computers, causes the one or more computers to perform the method as claimed in any one of claims 1, 10 and 11.
16. A non-transitory machine-readable storage medium storing the computer program according to claim 15.