Data Processing

The described authentication method addresses the challenges of vertically integrated protocols by using device-specific and application-specific authentication messages, enabling standardized, cost-effective, and adaptable authentication for secure device interactions.

JP2021527342A5Active Publication Date: 2025-06-24ARM LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2020567532
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2018-06-11
Filing Date
2019-05-24
Publication Date
2025-06-24
Estimated Expiration
2039-05-24

AI Technical Summary

Technical Problem

Existing authentication protocols are vertically integrated, costly, and difficult to adapt to changing markets, as they require hardware-specific porting and implementation, and can create commercial barriers between competing systems.

Method used

A method where a first data processing device requests authentication of a second data processing device, generating device-specific and application-specific authentication messages based on device-specific keys, hardware, and software configurations, and interaction protocols, with cryptographic conversion and verification to establish trusted interaction.

Benefits of technology

This approach enables standardized, cost-effective, and adaptable authentication, reducing commercial barriers and simplifying the process for device and software vendors, while maintaining secure and trusted interactions between devices.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

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.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This disclosure relates to data processing.

Background Art

[0002] Authentication is a data processing technique by which an entity that enables (e.g., a data processing device) can determine the reliability and / or capabilities of another entity or a data processing device with which it interacts. For example, a client device connecting to another device operating a specific software service may need to be able to confirm that the service is correctly instantiated and operating 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 reliability of the IoT devices connected to it.

[0003] In previously proposed embodiments of authentication, dedicated protocols are used to require integration across the systems of interacting entities, potentially including dedicated hardware integration. Currently, a number of such authentication protocols and systems exist, each tailored to the specific needs of the individual systems of interacting entities. These vertically integrated protocols are not likely to be standardized, harmonized, or replaced, and can represent even commercial barriers to entry between competing systems.

[0004] As secure systems become larger and more general, this configuration can be costly for device vendors to adapt to changing markets, difficult to handle, and costly and difficult for software vendors because the point of invariant trust is part of the device hardware. Therefore, authentication requires hardware-specific porting and implementation of authentication clients and / or can be costly and difficult for the enabling entity that potentially has to support multiple protocols and interacting systems.

Summary of the Invention

Means for Solving the Problem

[0005] In the configuration of the example, a method is provided. The method includes steps where a first data processing device requests authentication of a second data processing device; the second data processing device generates a device-specific authentication message depending on a device-specific key, the hardware configuration of the second data processing device, and the software configuration of the software operating on the second data processing device; the second data processing device generates 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 constrained converts the application-specific authentication message into a device-specific authentication message; the first data processing device confirms the application-specific authentication message, and the confirmation step includes detecting a trusted status of the application-specific authentication message by confirming the device-specific authentication message converted from the application-specific authentication message; and the first data processing device establishes interaction with the second data processing device according to the interaction protocol depending on the confirmed application-specific authentication message. Cryptographically constrained

[0006] In the configuration of another example, a data processing device is provided. The data processing device includes a circuit for storing a device-specific key; a circuit for generating 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 operating on the data processing device in response to a request for authentication by a second data processing device; a circuit 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; and a circuit for Cryptographically constrained converting the application-specific authentication message into a device-specific authentication message.

[0007] In the configuration of another example, a data processing device is provided, and the data processing device requests authentication of a second data processing device and depends on a device-specific key, the hardware configuration of the second data processing device, and the software configuration of the software operating on the second data processing device. From the second data processing device, depending on the interaction protocol in which the data processing device and the second data processing device interact, to an application-specific authentication message Cryptographically constrained A circuit that receives a device-specific authentication message that has been applied, and a circuit that verifies an application-specific authentication message, where verifying includes detecting a trusted status of the application-specific authentication message by verifying the device-specific authentication message that has been applied to the application-specific authentication message Cryptographically constrained A circuit that includes detecting a trusted status of an application-specific authentication message by verifying a device-specific authentication message that has been applied to the application-specific authentication message, and a circuit that establishes interaction with the second data processing device according to the interaction protocol depending on the verified application-specific authentication message.

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

[0009] In the configuration of another example, a method for operating a data processing device is provided, and the method is a method for operating a data processing device, including the steps of storing a device-specific key, and in response to a request for authentication by a second data processing device, depending on the device-specific key, the hardware configuration of the data processing device, and the software configuration of the software operating on the data processing device, generating a device-specific authentication message, and depending on the interaction protocol in which the data processing device and the second data processing device interact, generating an application-specific authentication message, and applying the application-specific authentication message to the device-specific authentication message Cryptographically constrained And steps including doing so.

[0010] In the configuration of another example, a method for operating a data processing device is provided. The method includes a step of requesting authentication of a second data processing device, which depends on a device-specific key, the hardware configuration of the second data processing device, and the software configuration of the software operating on the second data processing device. From the second data processing device, depending on the interaction protocol in which the data processing device and the second data processing device interact, an application-specific authentication message is sent to the device-specific authentication message Cryptographically constrained receiving the device-specific authentication message; and a step of verifying the application-specific authentication message, where the verifying step includes detecting a trusted status of the application-specific authentication message by verifying the device-specific authentication message sent to the application-specific authentication message Cryptographically constrained and establishing interaction with the second data processing device according to the interaction protocol depending on the verified application-specific authentication message.

[0011] In the configuration of another example, a computer program for controlling a host data processing device that provides an instruction execution environment is provided. The computer program includes computer program logic for storing a device-specific key, computer program logic for generating 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 operating on the data processing device in response to a request for authentication by the second data processing device, computer program logic for generating an application-specific authentication message depending on the interaction protocol in which the data processing device and the second data processing device interact, and computer program logic for sending the application-specific authentication message to the device-specific authentication message Cryptographically constrained and.

[0012] In the configuration of another example, a computer program for controlling a host data processing device that provides an instruction execution environment is provided. The computer program requests authentication of a second data processing device and depends on a device-specific key, the hardware configuration of the second data processing device, and the software configuration of the software operating on the second data processing device. From the second data processing device, depending on the interaction protocol in which the data processing device and the second data processing device interact, to the application-specific authentication message Cryptographically constrained A computer program logic that receives a device-specific authentication message that has been Cryptographically constrained A computer program logic that verifies the application-specific authentication message, and verifying includes detecting a trusted status of the application-specific authentication message by verifying the device-specific authentication message that has been

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

[0014] The present technology is further described by referring to its examples merely as an example as shown in the accompanying drawings.

Brief Description of the Drawings

[0015]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

DETAILED DESCRIPTION OF THE INVENTION

[0016] Referring to the drawings below, FIG. 1 schematically shows a data processing device 100 suitable for use as a device capable of responding to an authentication request. The data processing device 100 includes an application program execution circuit 110. The application program execution circuit 110 includes a processing element or a central processing unit (CPU) 120, a memory 130 such as a random access memory (RAM), an interface 140, and a storage (for example, a non-volatile machine-readable memory, such as a flash memory) 150 for one or more application programs. The device also includes a secure storage module 160 that communicates data with the application execution circuit 110.

[0017] The secure storage module 160 may be implemented as a "tamper-resistant" memory that can be accessed by the circuit 110 under any circumstances. In other examples, the term "tamper-resistant" means a memory that is hardened against or protected from changes made after the manufacture of the device 100, and / or a memory that is hardened against or protected from access made by anyone other than the circuit 110 or an application permitted to execute on the circuit 110.

[0018] In other examples, the secure storage module 160 may be a so-called Trusted Platform Module (TPM) that again represents the tamper-resistant part of the cryptographic hardware incorporated in the device 100, which, as will be described later, can also implement at least some cryptographic functions based on which a set of cryptographic operations can be built, similar to storing one or more keys. The description of the TPM is provided at the following link (https: / / en.wikipedia.org / wiki / Trusted_Platform_Module), and that document is incorporated into this description by reference. In some examples, the TPM, as an example of the secure storage module 160, may potentially generate random numbers, perform the authentication functions described later, perform public key encryption operations, calculate hash functions, and have the ability to securely store keys and other secret data. In this context, a hash function is a mathematical function used to generally map an input data space to a smaller output data space. In the cryptographic context, a hash function is 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 implementation key 162 is securely stored. This is provided and stored during the manufacture of the device 100 and is provided according to the method described later with reference to FIG. 2.

[0020] Therefore, using the techniques described below, device 100 can provide an example of a data processing device, the data processing device including a circuit 160 that stores a device-specific key, and in response to a request for authentication by a second data processing device, generating 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 operating on the data processing device, and generating an application-specific authentication message depending on an interaction protocol in which the data processing device and the second data processing device interact, and converting the application-specific authentication message into a device-specific authentication message Cryptographically constrained and a circuit 110 / 160 for doing so.

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

[0022] FIG. 3 is a schematic flowchart showing an example technique for controlling access to a device-specific key held by a secure storage module. This provides an example in which the steps of a second data processing device (device 100) securely storing a device-specific key and generating a device-specific authentication message include steps in which an authentication client software of the second data processing device accesses the securely stored device-specific key.

[0023] In at least some examples, when access to a device-specific key is requested by an application program in circuit 110, the hash function generator of CPU 120 or the secure storage module 160 generates, in step 300, a hash value from the computer software that forms the application program, which is passed to the secure storage module. Next, the secure storage module compares the generated hash value with the stored hash value of an acceptable application program that is permitted access to the device-specific key. In step 320, the secure storage module permits 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 detected in step 310.

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

[0025] In these or other examples, the described configuration can prohibit or limit access to a device-specific key other than by indirect access using device-specific authentication software (e.g., operating as an example of application program code 150). This type of software can provide access to a device-specific key using a secret hash or encryption algorithm, etc., or can inspect for the presence of certain device-specific hardware and / or software features to enable this type of access.

[0026] The overview of this embodiment is provided by FIG. 4. Here, the authentication process is considered (or split) separately from the authentication of device-specific aspects such as the hardware configuration of the device to be authenticated and the software configuration of the software operating on that device, apart from the protocol-specific authentication regarding application-specific considerations for the interaction protocol through which the data processing devices (the device requesting authentication and the device to be authenticated) communicate.

[0027] Examples of application-specific authentication parameters can include the following. · Parameters regarding the authentication protocol for the interaction between device 100 and other devices · Application-specific states such as whether the device has been requested by a service

[0028] Examples of device-specific authentication parameters can include the following. · Manufacturer · Trust base · Hardware implementation · Device-specific states such as whether device 100 is in a debug state · Completion of the initial startup process · Software version operating on device 100 and verified by the initial startup process

[0029] Referring to FIG. 4, the device-specific key 162 is referred to in the drawing as the implementation key or the implementation authentication key. The implementation signer 400 issues the implementation key in device manufacturing. The implementation signer is associated with the implementation verifier 410. The signed implementation key identifies (or can be used to confirm the determination of) the device-specific aspects of the implementation of device 430 (e.g., device 100 in FIG. 1) and is installed in the secure storage of device 430 during manufacturing 420. Device 430 has a protocol-specific (application-specific) authentication client application 440 that obtains the signed authentication 442 from, or using, the secure storage 444 of device 430.

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

[0031] An application-specific authentication message can be generated, for example, as follows. An application program operating on the application program execution circuit 110 generates a public / private key pair and uses it to sign an application-specific message. The secure storage module signs the hash of the public key with the DSK162 by and Cryptographically constrained does so.

[0032] The authentication client 440 implements the authentication protocol by an enabling entity 450 such as another data processing device (an example of which will be described later with reference to FIG. 7). The authentication client controls any protocol-specific authentication information 452 for the implemented authentication 454. Cryptographic constraint to do so. Constraint The operation will be further described below with reference to FIG. 6. Therefore, this links protocol-specific authentication information to a trust basis represented by the implemented authentication key 444 without requiring protocol-specific hardware provisioning in the device 430.

[0033] The enabling entity 450 verifies the protocol-specific authentication by a protocol-specific verifier 460. Next, the protocol-specific verifier 460 interacts with the implemented verifier 410 to verify the implemented authentication 442 used to cryptographically sign the protocol-specific authentication.

[0034] Figure 5 is a schematic flowchart showing the method. In Figure 5, the operations by the enabling device (referred to as the first data processing device) are shown to the left of the dashed line 500, and the operations by the enabled device (referred to as the second data processing device) are shown to the right of the dashed line 500. The method includes the following steps.

[0035] In step 510, the first data processing device (the enabling entity 450 in FIG. 4) requests authentication of the second data processing device or authentication by the 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 a device-specific key, the hardware configuration of the second data processing device, and the software configuration of the software operating on the second data processing device.

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

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

[0039] In some example embodiments, step 540 includes signing the message generated together in both steps 520 and 530, Cryptographically constrained and it should be noted that this can be done.

[0040] In step 550, the first data processing device verifies the application-specific authentication message, and the verification step Cryptographically constrainedDetecting a trusted status of an application-specific authentication message by verifying a device-specific authentication message specific to the device involved.

[0041] Steps 200 (FIG. 2) and 550 (FIG. 5) can relate to an interaction with the same entity in that they can 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 the step of verification can include the first data processing device requesting verification of a device-specific authentication message by the verification apparatus.

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

[0043] As schematically shown by steps 570, 580, the establishment of the interaction can include the first and second data processing devices exchanging one or more session keys (e.g., by means of so-called Diffie-Hellman key sharing techniques) and performing communication using the session keys for encrypted communication between the first and second data processing devices.

[0044] FIG. 6 schematically shows the process of the device-specific authentication message and the application-specific authentication message. The steps to the left of the dashed line 600 are performed by the verifying device, and the steps to the right of the dashed line 600 are performed by the device to be verified. Cryptographic constraint The steps to the left of the dashed line 600 are performed by the verifying device, and the steps to the right of the dashed line 600 are performed by the device to be verified.

[0045] Generally speaking, Cryptographic constraint provides techniques 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 the collection of one or more hash values. When the data is then accessed, the signature is verifiable and any inconsistencies in the hash values are used toConstraint After an action occurs, it is possible to detect which data objects have been modified.

[0046] In step 600, the device to be verified generates a hash of the application-specific authentication message, and in step 610, it cryptographically signs the generated hash using an implementation key or a device-specific key.

[0047] In step 620, the device to be verified potentially refers to the verifier 410 and verifies the signature. The device to be verified 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 described above, in some other example embodiments, this process is effectively executed simultaneously with generating device-specific authentication, and it should be noted that it can be demonstrated that the signed Constraint and device-specific authentication go together. In other words, in some embodiments, step 540 includes signing together both in steps 520 and 530, Constraint and can be done.

[0049] FIG. 7 schematically shows a data processing device 700 that requests verification. The data processing device 700 includes a processing element, such as a central processing unit or CPU 710, and one or more memories 720 including, for example, RAM and storage (such as non-volatile machine-readable memory, such as flash memory) for one or more application programs, and an interface 730.

[0050] Therefore, FIG. 7 provides an example of a data processing device that requests authentication of a second data processing device and depends on a device-specific key, the hardware configuration of the second data processing device, and the software configuration of the software operating on the second data processing device. Depending on the interaction protocol in which the data processing device and the second data processing device interact, to the application-specific authentication message Cryptographically constrained A circuit that receives a device-specific authentication message that has been Cryptographically constrained An application-specific authentication message is confirmed, and the confirmation includes detecting a trusted status of the application-specific authentication message by confirming the device-specific authentication message that has been

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

[0052] FIG. 8 is a schematic flowchart showing a method of operation of a data processing device (e.g., an enabling device, e.g., the device of FIG. 1), the method comprising the steps of storing a device-specific key (at step 800), 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, the hardware configuration of the data processing device, and the software configuration of the software operating on the data processing device (at step 810), generating an application-specific authentication message depending on an interaction protocol in which the data processing device and the second data processing device interact (at step 820), and, for example, sending the application-specific authentication message to the enabling request device, incorporating the application-specific authentication message into the device-specific authentication message (at step 830). Cryptographically constrained Incorporating

[0053] FIG. 9 is a schematic flowchart showing a method of operation of a data processing device (e.g., an enabling request device, e.g., the device of FIG. 7), the method comprising the step of requesting authentication of a second data processing device (at step 900), receiving, from the second data processing device, a device-specific authentication message incorporated into an application-specific authentication message, depending on the device-specific key, the hardware configuration of the second data processing device, and the software configuration of the software operating on the second data processing device, and depending on an interaction protocol in which the data processing device and the second data processing device interact, and the step of verifying the application-specific authentication message (at step 910), the verifying step including detecting a trusted status of the application-specific authentication message by verifying the device-specific authentication message incorporated into the application-specific authentication message, and the step of establishing an interaction with the second data processing device according to the interaction protocol depending on the verified application-specific authentication message (at step 920). Cryptographically constrained Incorporated Cryptographically constrained Incorporated

[0054] Figure 10 schematically shows a possible simulator implementation. The above-described embodiments implement the present disclosure with respect to apparatuses and methods for operating specific processing hardware that supports the relevant technology, but it is also possible to provide an instruction execution environment according to the embodiments described herein, which is implemented by using a computer program. This type of computer program is often called a simulator insofar as it provides 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 operate on a host processor 1030 and, optionally, execute a host operating system 1020 and support a simulator program 1010. In some configurations, there may be multiple layers of simulation 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 execute at a reasonable speed, but this type of approach may be justified in certain situations, for example, when there is a desire to execute code native to another processor for compatibility or reuse. For example, a simulator implementation may provide additional functionality to the instruction execution environment that is not supported by the host processor hardware, or may provide an instruction execution environment 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, pages 53 - 63, the content of which is incorporated herein by reference.

[0055] To the extent that embodiments have been described above with reference to specific hardware configurations or features, in simulated embodiments, equivalent functions may be provided by appropriate software configurations or features. For example, a particular circuit may be implemented as computer program logic in a simulated embodiment. Similarly, memory hardware, such as registers or caches, may be implemented as software data structures in a simulated embodiment. In configurations where one or more of the hardware elements referred to in the embodiments described above are present 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 in a computer-readable or machine-readable storage medium (which may be a non-transitory medium), and provides a program interface (instruction execution environment) to target code 1000 (which may include applications, operating systems, and hypervisors) that is similar to the application program interface of the hardware architecture modeled by the simulator program 1010. Thus, program instructions of the target code 1000 that include 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, such that a host computer 1030 that does not actually have the hardware features of the apparatus of FIG. 1 and / or FIG. 7 described above can emulate these features.

[0057] In this application, the term "configured as" is used to mean that an element of a device has a configuration capable of performing a predetermined operation. In this context, "configuration" means a configuration of hardware or software interconnections or a method. For example, a device 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 the software or program instructions by which the function is performed, and the medium that provides such software or program, such as a non-transitory machine-readable medium in which the instructions are provided (e.g., stored), are considered to represent the disclosed embodiments. "Configured" does not mean that a device element needs to be changed in any way to provide a predetermined operation.

[0058] Although the illustrated embodiments of the present technology have been described in detail in this specification with reference to the accompanying drawings, it should be understood that the present technology is not limited to those exact embodiments, and various changes, additions, and modifications can be made by those skilled in the art without departing from the scope and spirit of the technology described in the appended claims. For example, various combinations of the features of the dependent claims can be made with the features of the independent claims without departing from the scope of the present technology.

Claims

Claim 1 A 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 depending on a hardware configuration of the second data processing device and a software configuration of software operating on the second data processing device, and signing the device-specific authentication message with a device-specific key; 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 signing the application-specific authentication message with the device-specific key and cryptographically binding it to the device-specific authentication message; the first data processing device verifying the application-specific authentication message, the verifying step including 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; the first data processing device establishing interaction with the second data processing device according to the interaction protocol depending on the verified application-specific authentication message; A method comprising the above steps. Claim 2 The method of claim 1, wherein the second data processing device includes a step of securely storing the device-specific key, and the step of generating the device-specific authentication message includes a step of an authentication client software of the second data processing device accessing the securely stored device-specific key. The method according to claim 1. Claim 3 The method of claim 2, including a step of prohibiting access to the device-specific key other than by means of indirect access using device-specific authentication software. The method according to claim 2. Claim 4 The method of claim 2, wherein the accessing step includes comparing a hash depending on the authentication client software with a set of one or more hash values indicating that access to the securely stored device-specific key is permitted. The method according to claim 2. Claim 5 The step of establishing includes the step in which the first and second data processing devices exchange one or more session keys for encrypted communication between the first and second data processing devices. The method according to any one of claims 1 to 4.

6. The confirmation device includes the step of generating the device-specific key to be stored by the second data processing device. The step of confirming includes the step in which the first data processing device requests confirmation of the device-specific authentication message by the confirmation device. The method according to any one of claims 1 to 5.

7. A data processing device, a circuit for storing a device-specific key, a circuit that, in response to a request for authentication by a second data processing device, generates a device-specific authentication message depending on the hardware configuration of the data processing device and the software configuration of the software operating on the data processing device, and signs the device-specific authentication message with the device-specific key. a circuit for generating an application-specific authentication message depending on an interaction protocol in which the data processing device and the second data processing device interact; a circuit for signing the application-specific authentication message with the device-specific key and cryptographically binding it to the device-specific authentication message; A data processing device comprising the same.

8. A data processing device, a circuit that requests authentication of a second data processing device and receives from the second data processing device a device-specific authentication message depending on the hardware configuration of the second data processing device and the software configuration of the software operating on the second data processing device, wherein the device-specific authentication message is cryptographically bound to an application-specific authentication message depending on an interaction protocol in which the data processing device and the second data processing device interact by a signature with a device-specific key. A circuit for verifying the application-specific authentication message, wherein the verification 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; A circuit for establishing interaction with the second data processing device according to the interaction protocol depending on the verified application-specific authentication message; A data processing device comprising the same. **Claim 9** A data processing system, Comprising the data processing device according to claim 7 and the data processing device according to claim 8, configured to interact with each other using the interaction protocol; A data processing system. **Claim 10** A method for operating 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 depending on the hardware configuration of the data processing device and the software configuration of the software operating on the data processing device, and signing the device-specific authentication message with the device-specific key; Generating an application-specific authentication message depending on an interaction protocol by which the data processing device and the second data processing device interact; Signing the application-specific authentication message with the device-specific key and cryptographically binding it to the device-specific authentication message; A method including the above. **Claim 11** A method for operating a data processing device, comprising: Requesting authentication of a second data processing device, the step of receiving, from the second data processing device, a device-specific authentication message depending on the hardware configuration of the second data processing device and the software configuration of the software operating 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 depending on an interaction protocol by which the data processing device and the second data processing device interact; A step of verifying the application-specific authentication message, wherein the verifying step 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. A step of establishing interaction with the second data processing device according to the interaction protocol depending on the verified application-specific authentication message. A method comprising the above. [

12. ] A computer program for controlling a host data processing device that provides an instruction execution environment, Computer program logic for storing a device-specific key, In response to a request for authentication by a second data processing device, computer program logic for generating a device-specific authentication message depending on the hardware configuration of the data processing device and the software configuration of the software operating on the data processing device, and signing the device-specific authentication message with the device-specific key. 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 and cryptographically binding it to the device-specific authentication message. A computer program comprising the above. [

13. ] A computer program for controlling a host data processing device that provides an instruction execution environment, 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 depending on the hardware configuration of the second data processing device and the software configuration of the software operating on the second data processing device, wherein the device-specific authentication message is cryptographically bound by a signature with a device-specific key to 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 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. Computer program logic for establishing interaction with the second data processing device according to the interaction protocol, depending on the verified application-specific authentication message. A computer program comprising the above.

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

15. Computer software that, when executed by one or more computers, causes the one or more computers to execute the method according to any one of claims 1, 10, and 11.

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