Data Processing

Abstract

The method includes the steps of: a first data processing device requesting authentication of a second data processing device; the second data processing device generating a device-specific authentication message depending 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 second data processing device generating an application-specific authentication message depending on an interaction protocol by which the first data processing device and the second data processing device interact; the second data processing device cryptographically binding the application-specific authentication message to the device-specific authentication message; the first data processing device verifying the application-specific authentication message, wherein the verifying includes 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 the first data processing device establishing interaction with the second data processing device in accordance with the interaction protocol depending on the verified application-specific authentication message.

Description

[Technical Field]

[0001] This disclosure relates to data processing. [Background technology]

[0002] Authentication is a data processing technique that allows an enabling entity (e.g., a data processing device) to determine the trustworthiness and / or capabilities of other entities or data processing devices with which it is interacting. For example, a client device connecting to another device running a particular software service may need to be able to verify that the service is correctly instantiated and running in the context of a trusted hardware implementation. Similarly, an Internet of Things (IoT) service may need to be able to determine the capabilities and / or trustworthiness of the IoT devices connecting to it.

[0003] Previously proposed implementations of authentication have used proprietary protocols, requiring integration across the systems of the interacting entities, potentially including proprietary hardware integration. Currently, many such authentication protocols and systems exist, each tailored to the specific needs of the individual systems of the interacting entities. These vertically integrated protocols are considered unlikely to be standardized, harmonized, or replaced, and may even represent a commercial barrier to entry between competing systems.

[0004] As secure systems become larger and more common, this architecture can become costly and cumbersome for device vendors to adapt to a changing market, costly and cumbersome for software vendors because the immutable root of trust is part of the device hardware, and therefore authentication requires hardware-specific porting and implementation of authentication clients and / or costly and cumbersome for enabling entities that must potentially support multiple protocols and interacting systems. Summary of the Invention [Means for solving the problem]

[0005] In an example configuration, a method is provided, the method comprising: a first data processing device requesting authentication of a second data processing device; the second data processing device generating a device-specific authentication message dependent 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 second data processing device generating an application-specific authentication message dependent on an interaction protocol by which the first data processing device and the second data processing device interact; and the second data processing device converting the application-specific authentication message into a device-specific authentication message. Cryptographically Binding and a step of the first data processing device verifying the application-specific authentication message, wherein the verifying step includes: Cryptographically Binding The method includes detecting a trusted status of the application-specific authentication message by verifying the verified device-specific authentication message, and the first data processing device establishing an interaction with the second data processing device according to an interaction protocol in dependence on the verified application-specific authentication message.

[0006] In another example configuration, a data processing device is provided, the data processing device including: 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 dependent 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; circuitry for generating an application-specific authentication message dependent on an interaction protocol by which the data processing device and the second data processing device interact; and circuitry for converting the application-specific authentication message into the device-specific authentication message. Cryptographically Binding and a circuit for performing the same.

[0007] In another example configuration, a data processing device is provided, the data processing device requesting authentication of a second data processing device and receiving an application specific authentication message from the second data processing device depending 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, depending on an interaction protocol by which the data processing device and the second data processing device interact. Cryptographically Binding a circuit for receiving the device-specific authentication message and a circuit for validating the application-specific authentication message, the validating comprising: Cryptographically Binding and a circuit for establishing interaction with the second data processing device according to an interaction protocol in dependence on the verified application-specific authentication message.

[0008] In another example configuration, a data processing system is provided, the data processing system comprising the above-described data processing devices configured to interact with each other using an interaction protocol.

[0009] In another illustrative configuration, a method of operation of a data processing device is provided, the method comprising the steps of: storing a device specific key; generating, in response to a request for authentication by a second data processing device, a device specific authentication message dependent 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; generating an application specific authentication message dependent on an interaction protocol by which the data processing device and the second data processing device interact; and converting the application specific authentication message into the device specific authentication message. Cryptographically Binding and

[0010] In another example configuration, a method of operating a data processing device is provided, the method including the step of requesting authentication of a second data processing device, the step of receiving from the second data processing device an application specific authentication message depending 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 application specific authentication message depending on an interaction protocol by which the data processing device and the second data processing device interact. Cryptographically Binding receiving an application-specific authentication message; and verifying the application-specific authentication message, wherein the verifying step includes: Cryptographically Binding The method includes detecting a trusted status of the application-specific authentication message by verifying the verified device-specific authentication message, and establishing interaction with the second data processing device according to an interaction protocol in dependence on the verified application-specific authentication message.

[0011] In another illustrative configuration, a computer program for controlling a host data processing apparatus providing an instruction execution environment is provided, the computer program including: computer program logic for storing a device-specific key; computer program logic for generating, in response to a request for authentication by a second data processing device, a device-specific authentication message dependent 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; computer program logic for generating an application-specific authentication message dependent on an interaction protocol by which the data processing device and the second data processing device interact; and computer program logic for converting the application-specific authentication message into the device-specific authentication message. Cryptographically Binding and computer program logic for:

[0012] In another illustrative configuration, a computer program for controlling a host data processing apparatus providing an instruction execution environment is provided, the computer program requesting authentication of a second data processing device and transmitting an application-specific authentication message from the second data processing device depending 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, depending on an interaction protocol by which the data processing device and the second data processing device interact. Cryptographically Binding and computer program logic for receiving the device-specific authentication message and validating the application-specific authentication message, wherein the validating includes: Cryptographically Binding and computer program logic for establishing an interaction with a second data processing device according to an interaction protocol in dependence on the verified application-specific authentication message.

[0013] Further and various aspects and features of the present technology are defined by the appended claims.

[0014] The present technology will now be described further, by way of example only, with reference to embodiments thereof as illustrated in the accompanying drawings, in which: [Brief explanation of the drawings]

[0015] [Figure 1] 1 illustrates a schematic diagram of a data processing device; [Figure 2] 2 is a schematic flow chart illustrating at least part of a method for manufacturing the device of FIG. 1. [Figure 3] 1 illustrates schematically the operation of the secure storage module. [Figure 4] 1 provides a general overview of the operation of the disclosed embodiments. [Figure 5] 1 is a schematic flow chart illustrating a method. [Figure 6] 1 is a schematic flow chart illustrating an example cryptographic binding technique. [Figure 7] 1 illustrates schematically another data processing device. [Figure 8] 1 is a schematic flow chart illustrating a method. [Figure 9] 1 is a schematic flow chart illustrating a method. [Figure 10] 1 shows a schematic representation of a simulator implementation. DETAILED DESCRIPTION OF THE INVENTION

[0016] 1 illustrates a data processing device 100 suitable for use as a device capable of responding to authentication requests, the data processing device 100 comprising application program execution circuitry 110, which comprises a processing element or central processing unit (CPU) 120, memory 130 such as random access memory (RAM), an interface 140, and storage (e.g., non-volatile machine-readable memory, e.g., flash memory) 150 for one or more application programs. The device also comprises a secure storage module 160 in data communication with the application execution circuitry 110.

[0017] Secure storage module 160 may be implemented as "tamper-resistant" memory that can be accessed under any circumstances by circuitry 110. In other instances, the term "tamper-resistant" refers to memory that is hardened or protected against changes made after device 100 is manufactured and / or memory that is hardened or protected against access other than by circuitry 110 or applications authorized to run on circuitry 110.

[0018] In other instances, secure storage module 160 may be a so-called Trusted Platform Module (TPM), again representing a tamper-resistant portion of cryptographic hardware integrated into device 100, which may perform at least some cryptographic functions based on which a set of cryptographic operations can be constructed, as well as storing one or more keys, as described below. A description of TPM is provided at the following link (https: / / en.wikipedia.org / wiki / Trusted_Platform_Module), which document is incorporated by reference into this description. In some instances, a TPM, as an example of secure storage module 160, may potentially have the ability to generate random numbers, perform authentication functions, as described below, as well as perform public key cryptographic operations, calculate hash functions, and securely store keys and other secret data. 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 other input values ​​that lead to the same output hash value.

[0019] Therefore, as part of the functionality of the secure storage module 160, at least a so-called device specific key (DSK) or enforcement key 162 is securely stored, which is provided and stored at the time of manufacture of the device 100 and is provided according to the method described below with reference to FIG.

[0020] Thus, using the techniques described below, the device 100 can provide an example of a data processing device, which includes a circuit 160 for storing a device-specific key, and which, in response to a request for authentication by a second data processing device, generates a device-specific authentication message depending on the device-specific key, the hardware configuration of the data processing device and the software configuration of the software running on the data processing device, generates an application-specific authentication message depending on an interaction protocol by which the data processing device and the second data processing device interact, and converts the application-specific authentication message into a device-specific authentication message. Cryptographically Binding and a circuit 110 / 160 for performing the same.

[0021] 2, in step 200, a verification device, such as provided by a verification service, generates a device-specific key 162 that is specific to device 100 or at least specific within a family of devices that includes device 100 (so that for any particular instance of device 100, DSK 162 is at least specific with respect to any other instance of device 100). In step 210, the verification service, using, for example, the verification device, cryptographically signs the device-specific key. In step 220, the device-specific key 162 is stored in a secure storage module as part of the manufacture of device 100.

[0022] 3 is a schematic flow chart illustrating an example technique for controlling access to a device-specific key maintained by a secure storage module, which provides an example in which a second data processing device (device 100) securely stores a device-specific key and in which generating a device-specific authentication message includes authentication client software on the second data processing device accessing the securely stored device-specific key.

[0023] In at least some instances, when access to the device-specific key is requested by an application program in circuit 110, a hash function generator in CPU 120 or secure storage module 160 generates a hash value from the computer software forming the application program, which is passed to the secure storage module in step 300. The secure storage module then compares the generated hash value with stored hash values ​​of permissible application programs that should be allowed to access the device-specific key. In step 320, the secure storage module allows or denies access to the device-specific key depending on whether the hash value provided by the CPU in step 300 is the same as the stored hash value found in step 310.

[0024] Therefore, this provides an example of an accessing step that compares a hash value dependent on the client software attempting to access the device-specific key with a set of one or more hash values ​​that indicate that access to the securely stored device-specific key is permitted.

[0025] In these or other instances, the described configurations may prohibit or limit access to device-specific keys other than indirect access using device-specific authentication software (e.g., operating as an instance of application program code 150). Such software may provide access to the device-specific keys using a secret hash or encryption algorithm, or may check for the presence of certain device-specific hardware and / or software features to enable such access.

[0026] An overview of this embodiment is provided by Figure 4. Here, the authentication process is considered (or split) separately between authentication of device-specific aspects, such as the hardware configuration of the device being authenticated and the software configuration of the software running on that device, and protocol-specific authentication, which relates to application-specific considerations of the interaction protocol over which the data processing devices (the device requesting authentication and the device being authenticated) communicate.

[0027] Examples of application-specific authentication parameters may include: Parameters related to authentication protocols for interactions between device 100 and other devices Application-specific state, such as whether the device is enlisted by a service or not

[0028] Examples of device-specific authentication parameters may include: ·Manufacturer Root of Trust Hardware implementation Device-specific state, such as whether the device 100 is in debug state or not Completing the initial boot process (Software version running on device 100 and confirmed by the initial boot process)

[0029] Referring to Figure 4, the device-specific key 162 is referred to in the figure as an enforcement key or enforcement authentication key. An enforcement signer 400 issues the enforcement key at device manufacture. The enforcement signer is associated with an enforcement verifier 410. The signed enforcement key identifies (or can be used to verify) device-specific aspects of the implementation of a device 430 (e.g., device 100 of Figure 1) and is placed in secure storage on the device 430 at manufacture 420. The device 430 has a protocol-specific (application-specific) authentication client application 440 that obtains signed authentication 442 from or with secure storage 444 on the device 430.

[0030] The authentication process can take a variety of forms. For example, the secure storage module 160 can be provided with data (at manufacture) that describes the hardware characteristics of the device 100, which can be provided in the form of a message that is signed (e.g., using functionality of the secure storage module 160) by a device-specific key 162 to generate a device-specific authentication message.

[0031] For example, an application-specific authentication message can be generated as follows: An application program running on the application program execution circuit 110 generates a public / private key pair and uses it to sign the application-specific message. The secure storage module uses the DSK162 in Sign the hash of the public key, Cryptographically Binding do.

[0032] The authentication client 440 performs an authentication protocol with an enabling entity 450, such as another data processing device (an example of which is described below with reference to FIG. 7). The authentication client may use any protocol-specific authentication information 452 to perform authentication 454. Cryptographic Constraints Control. restraint The operation is further described below with reference to Figure 6. This therefore ties protocol-specific authentication information to a root of trust represented by enforcement authentication key 444 without requiring protocol-specific hardware provisioning in device 430.

[0033] The validating entity 450 verifies the protocol-specific certificate with a protocol-specific verifier 460, which then interacts with an enforcement verifier 410 to verify the enforcement certificate 442 used to cryptographically sign the protocol-specific certificate.

[0034] Figure 5 is a schematic flow chart illustrating the method, in which actions by the enabling device (called the first data processing device) are shown to the left of dashed line 500 and actions by the enabled device (called the second data processing device) are shown to the right of dashed line 500. The method includes the following steps:

[0035] In step 510, a first data processing device (enabling entity 450 in FIG. 4) requests authentication of or by a second data processing device.

[0036] In step 520, the second data processing device (device 430 in FIG. 4) generates a device-specific authentication message 454 depending 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.

[0037] In step 530, the second data processing device generates an application-specific authentication message 454 depending on the interaction protocol by which the first and second data processing devices interact.

[0038] In step 540, the second data processing device converts the application-specific authentication message 454 into the device-specific authentication message 452. Cryptographically Binding do.

[0039] In some example embodiments, step 540 includes signing the message generated in both steps 520 and 530 together; Cryptographically Binding Note that it is possible to

[0040] In step 550, the first data processing device validates the application-specific authentication message, the validating step comprising: Cryptographically BindingThe method includes detecting the trusted status of the application-specific authentication message by verifying the received device-specific authentication message.

[0041] Steps 200 (FIG. 2) and 550 (FIG. 5) may involve interactions with the same entity in that they may provide an example of a verification device generating a device-specific key for storage by a second data processing device, and an example of the verifying step includes the first data processing device requesting verification of a device-specific authentication message by the verification device.

[0042] In step 560, the first data processing device establishes interaction with the second data processing device according to an interaction protocol, dependent on the verified application-specific authentication message.

[0043] As illustrated schematically by steps 570, 580, establishing an interaction may include the first and second data processing devices exchanging one or more session keys (e.g., by the so-called Diffie-Hellman key agreement technique) for encrypted communication between the first and second data processing devices, and performing communication using the session keys.

[0044] Figure 6 shows the difference between device-specific and application-specific authentication messages. Cryptographic Constraints 6 shows a schematic representation of the process of Step 600. Steps to the left of dashed line 600 are performed by the verifying device, and steps to the right of dashed line 600 are performed by the verified device.

[0045] Generally speaking, Cryptographic Constraints provides techniques for demonstrating data integrity and authenticity using cryptographic operations. In some instances, the techniques may operate by generating a hash value for each data object and digitally signing the collection of one or more hash values. When the data is subsequently accessed, the signature can be verified, and any discrepancies in the hash values ​​can be used to verify the authenticity of the data. restraint It is possible to detect which data objects have been modified since an action occurred.

[0046] In step 600, the device being authenticated generates a hash of the application-specific authentication message and, in step 610, cryptographically signs the generated hash using an enforcement key or a device-specific key.

[0047] The verifying device verifies the signature, potentially with the verifier 410, in step 620. The verifying device generates a corresponding hash value using the same hash algorithm in step 630 and compares the just-generated hash value with the signed hash value in step 640. If the two match, the application-specific authentication message can be trusted.

[0048] As mentioned above, in some other example embodiments, this process is effectively performed simultaneously with generating a device-specific certificate and signing it. restraint Note that it can be proven that the authentication and device-specific authentication go together. In other words, in some instances, step 540 involves signing both steps 520 and 530 together, restraint It is possible.

[0049] FIG. 7 shows a schematic diagram of a data processing device 700 for requesting confirmation, the data processing device 700 comprising a processing element, e.g., a central processing unit or CPU 710, one or more memories 720 including, e.g., RAM and storage (e.g., non-volatile machine-readable memory, e.g., flash memory) for one or more application programs, and an interface 730.

[0050] Thus, FIG. 7 provides an example of a data processing device requesting authentication of a second data processing device and receiving an application-specific authentication message from the second data processing device depending on a 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, depending on an interaction protocol by which the data processing device and the second data processing device interact. Cryptographically Binding a circuit for receiving the device-specific authentication message and a circuit for validating the application-specific authentication message, the validating comprising: Cryptographically Binding and a circuit for establishing interaction with a second data processing device according to an interaction protocol in dependence on the verified application-specific authentication message. These functions are executable by the CPU 710 under the control of computer software stored by the memory 720.

[0051] The interaction shown in Figure 5 can occur in the context of a data processing system comprising data processing device 100 of Figure 1 configured to interact with data processing device 700 of Figure 7 using an established interaction protocol.

[0052] FIG. 8 is a schematic flow chart illustrating a method of operation of a data processing device (e.g., a device to be activated, e.g., the device of FIG. 1), the method comprising the steps of (step 800) storing a device-specific key; (step 810) generating a device-specific authentication message in response to a request for authentication by a second data processing device, depending 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; (step 820) generating an application-specific authentication message depending on an interaction protocol by which the data processing device and the second data processing device interact; and (step 830) converting the application-specific authentication message into a device-specific authentication message, e.g., for transmission to the activation-requesting device. Cryptographically Binding and

[0053] FIG. 9 is a schematic flow chart illustrating a method of operation of a data processing device (e.g., an activation requesting device, e.g., the device of FIG. 7), the method including (at step 900) requesting authentication of a second data processing device, depending on a device-specific key, the hardware configuration of the second data processing device, and the software configuration of software running on the second data processing device, receiving an application-specific authentication message from the second data processing device, depending on an interaction protocol by which the data processing device and the second data processing device interact. Cryptographically Binding receiving an application-specific authentication message; and (at step 910) validating the application-specific authentication message, wherein the validating step includes: Cryptographically Binding detecting a trusted status of the application-specific authentication message by verifying the verified device-specific authentication message; and (at step 920) establishing interaction with the second data processing device according to an interaction protocol in dependence on the verified application-specific authentication message.

[0054] FIG. 10 illustrates a schematic diagram of a possible simulator implementation. While the above-described embodiments embody the present disclosure with respect to apparatus and methods for operating specific processing hardware supporting the related technology, it is also possible to provide an instruction execution environment according to the embodiments described herein implemented using a computer program. Such computer programs are often referred to as simulators, insofar as they provide a software-based implementation of a hardware architecture. Types of simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may run on a host processor 1030, optionally running a host operating system 1020 and supporting the simulator program 1010. In some configurations, multiple layers of simulation may exist between the hardware and the provided instruction execution environment and / or multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations that run at significant speeds, but this type of approach may be justified in certain situations, such as when there is a desire to execute code native to other processors for compatibility or reuse. For example, a simulator implementation may provide an instruction execution environment with additional features not supported by the host processor hardware, or may provide an instruction execution environment that is typically associated with a different hardware architecture. An overview of simulation is given in "Some Efficient Architecture Simulation Techniques," Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63, the contents of which are incorporated herein by reference.

[0055] To the extent that embodiments have been described above with reference to particular hardware configurations or features, in the simulated embodiments, equivalent functionality may be provided by appropriate software configurations or features. For example, particular circuits may be implemented as computer program logic in the simulated embodiments. Similarly, memory hardware, such as registers or caches, may be implemented as software data structures in the simulated embodiments. In configurations in which one or more of the hardware elements referenced in the above embodiments reside on host hardware (e.g., host processor 1030), some simulated embodiments may use the host hardware, where appropriate.

[0056] 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 (an instruction execution environment) to the target code 1000 (which may include an application, an operating system, and a hypervisor) that is similar to the application program interface of the hardware architecture being modeled by the simulator program 1010. In this manner, program instructions of the target code 1000, including instructions for performing one or more of the methods described above, may be executed from within the instruction execution environment using the simulator program 1010, allowing a host computer 1030 that does not actually have the hardware features of the apparatus of Figures 1 and / or 7 described above to emulate those features.

[0057] In this application, the term "configured to" is used to mean that elements of an apparatus have a configuration capable of performing a predetermined operation. In this context, "configuration" refers to an arrangement or method of interconnection of hardware or software. For example, an apparatus may have dedicated hardware that provides a predetermined operation, or a processor or other processing device may be programmed to perform a function, in which case software or program instructions that perform the function and media on which such software or program instructions are provided (e.g., stored), such as non-transitory machine-readable media, are considered to represent embodiments of the disclosure. "Configured" does not imply that the apparatus elements need to be altered in any way to provide the predetermined operation.

[0058] 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 technology is not limited to those precise embodiments, and that various changes, additions, and modifications may be made by those skilled in the art without departing from the scope and spirit of the technology as set forth in the appended claims. For example, various combinations of the features of the following dependent claims may be made with the features of the independent claims without departing from the scope of the technology.

Claims

1. 1. A method comprising: a first data processing device requesting authentication of a second data processing device; generating, by the second data processing device, a device-specific authentication message depending on a hardware configuration of the second data processing device and a software configuration of software running on the second data processing device, and signing the device-specific authentication message with a device-specific key; generating, by the second data processing device, an application-specific authentication message depending on an interaction protocol by which the first data processing device and the second data processing device interact; said second data processing device signing said application-specific authentication message with said device-specific key to cryptographically bind said device-specific authentication message; the first data processing device validating the application-specific authentication message, the validating step including detecting a trusted status of the application-specific authentication message by validating the device-specific authentication message cryptographically bound to the application-specific authentication message; said first data processing device establishing an interaction with said second data processing device according to said interaction protocol in dependence on said verified application-specific authentication message; A method comprising:

2. said second data processing device securely storing said device-specific key; generating the device-specific authentication message includes authentication client software of the second data processing device accessing the securely stored device-specific key; The method of claim 1.

3. prohibiting access to the device-specific key except through indirect access using device-specific authentication software; The method of claim 2.

4. the step of accessing includes comparing the authentication client software dependent hash with a set of one or more hash values ​​indicating that access to the securely stored device-specific key is permitted. The method of claim 2.

5. the establishing step includes the first and second data processing devices exchanging one or more session keys for encrypted communications between the first and second data processing devices; 5. The method according to any one of claims 1 to 4.

6. a verification device generating said device-specific key for storage by said second data processing device; the step of verifying includes the step of the first data processing device requesting verification of the device-specific authentication message by the verification device; 6. The method according to any one of claims 1 to 5.

7. 1. A data processing device, comprising: a circuit for storing a device-specific key; circuitry for generating a device-specific authentication message in response to a request for authentication by a second data processing device, the device-specific authentication message being signed with the device-specific key, the device-specific authentication message being signed in response to a request for authentication by the second data processing device, the device-specific authentication message being signed in response to a hardware configuration of the second data processing device and a software configuration of software running on the second data processing device; circuitry for generating an application-specific authentication message depending on an interaction protocol by which the data processing device and the second data processing device interact; circuitry for signing the application-specific authentication message with the device-specific key to cryptographically bind the application-specific authentication message to the device-specific authentication message; A data processing device comprising:

8. 1. A data processing device, comprising: a circuit for requesting authentication of a second data processing device and receiving from the second data processing device a device-specific authentication message that is dependent 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 by a signature with a device-specific key to an application-specific authentication message that is dependent on an interaction protocol by which the data processing device and the second data processing device interact; a circuit for validating the application-specific authentication message, the validating including detecting a trusted status of the application-specific authentication message by validating the device-specific authentication message cryptographically bound to the application-specific authentication message; circuitry for establishing interaction with the second data processing device according to the interaction protocol in dependence on the verified application-specific authentication message; A data processing device comprising:

9. 1. A data processing system comprising: A data processing device according to claim 7 and a data processing device according to claim 8, configured to interact with each other using said interaction protocol. Data processing system.

10. 1. A method of operation of a data processing device, comprising: storing a device-specific key; in response to a request for authentication by a second data processing device, generating a device-specific authentication message dependent on a hardware configuration of said data processing device and a software configuration of software running on said data processing device, and signing said device-specific authentication message with said device-specific key; generating an application-specific authentication message depending on an interaction protocol by which said data processing device and said second data processing device interact; cryptographically binding the application-specific authentication message to the device-specific authentication message by signing it with the device-specific key; A method comprising:

11. 1. A method of operation of a data processing device, comprising: requesting authentication of a second data processing device, receiving from the second data processing device a device-specific authentication message that depends 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 by a signature with a device-specific key to an application-specific authentication message that depends on an interaction protocol by which the data processing device and the second data processing device interact; validating the application-specific authentication message, the validating step including detecting a trusted status of the application-specific authentication message by validating the device-specific authentication message cryptographically bound to the application-specific authentication message; establishing an interaction with said second data processing device according to said interaction protocol in dependence on said verified application-specific authentication message; A method comprising:

12. A computer program for controlling a host data processing device that provides an instruction execution environment, comprising: computer program logic that stores a device-specific key; computer program logic for generating a device-specific authentication message and signing the device-specific authentication message with the device-specific key in response to a request for authentication by a second data processing device, the device-specific authentication message being dependent on a hardware configuration of the data processing device and a software configuration of software running on the data processing device; computer program logic for generating an application-specific authentication message depending on an interaction protocol by which the data processing device and the second data processing device interact; computer program logic for signing the application-specific authentication message with the device-specific key to cryptographically bind the application-specific authentication message to the device-specific authentication message; A computer program comprising:

13. A computer program for controlling a host data processing device that provides an instruction execution environment, comprising: computer program logic for requesting authentication of a second data processing device and receiving from the second data processing device a device-specific authentication message that is dependent 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 by a signature with a device-specific key to an application-specific authentication message that is dependent on an interaction protocol by which the data processing device and the second data processing device interact; computer program logic for validating the application-specific authentication message, the validating including detecting a trusted status of the application-specific authentication message by validating the device-specific authentication message cryptographically bound to the application-specific authentication message; computer program logic for establishing an interaction with the second data processing device according to the interaction protocol in dependence on the verified application-specific authentication message; A computer program comprising:

14. A non-transitory machine-readable storage medium storing the computer software of claim 12 or claim 13.

15. Computer software which, when executed by one or more computers, causes said one or more computers to carry out the method of any one of claims 1, 10 and 11.

16. 16. A non-transitory machine-readable storage medium storing the computer software of claim 15.

Images