WO2021037344A1 - Trusted device and computing system - Google Patents

Trusted device and computing system Download PDF

Info

Publication number
WO2021037344A1
WO2021037344A1 PCT/EP2019/072849 EP2019072849W WO2021037344A1 WO 2021037344 A1 WO2021037344 A1 WO 2021037344A1 EP 2019072849 W EP2019072849 W EP 2019072849W WO 2021037344 A1 WO2021037344 A1 WO 2021037344A1
Authority
WO
WIPO (PCT)
Prior art keywords
trusted
trusted device
program code
hash value
numerical value
Prior art date
Application number
PCT/EP2019/072849
Other languages
French (fr)
Inventor
Saggi Mizrahi
Dima KUZNETSOV
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to PCT/EP2019/072849 priority Critical patent/WO2021037344A1/en
Priority to EP19759378.3A priority patent/EP3980911A1/en
Priority to CN201980097445.7A priority patent/CN113966510A/en
Publication of WO2021037344A1 publication Critical patent/WO2021037344A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575—Secure boot
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities

Definitions

  • the present invention relates to the field of trusted computing. More specifically, the present invention relates to a trusted device and to a trusted computing system comprising the trusted device. The present invention can, in particular, be used in the field of cloud computing.
  • Cloud computing involves using shared resources by multiple tenants. This allows for reductions of costs and maintenance. Because of this shared model, the cloud provider usually has full control over a user’s data and resources (e.g. virtual machines, storage or network). This includes access to privileged data (e.g. private keys, passwords), secure information stored in the cloud, ability to act on behalf of a user, mislead a user about the resources provided in the cloud. This can also be done by attackers if they compromise the cloud infrastructure.
  • data and resources e.g. virtual machines, storage or network.
  • privileged data e.g. private keys, passwords
  • secure information stored in the cloud e.g. private keys, passwords
  • This can also be done by attackers if they compromise the cloud infrastructure.
  • the tenant can still enjoy utilization of cloud infrastructure under the following conditions: all privileged data is inaccessible at rest, or all privileged data is inaccessible while being processed.
  • the former requires encryption of the data while the latter requires the ability to perform trusted execution of the tenant code.
  • Intel provides instruction set extension (Software Guard Extensions - SGX) to create enclaves of trusted and secure execution.
  • the user may create such enclave, run an attestation protocol and run computations without exposing the state of the computation to any other code running on the CPU.
  • SGX is a set of instructions that help to increase the security of any application code and data, thereby giving them more protection from disclosure or tempering.
  • TPM Trusted Platform Module
  • ISO/IEC 11889 is an international standard for a secure crypto-processor, a dedicated microcontroller designed to secure hardware through integrated cryptographic keys.
  • a tenant user in particular lacks the following properties for trusted execution: ability to attest the deployed software that will be accessing the privileged data, and ability to attest the provided hardware, and verify it is under exclusive access.
  • embodiments of the present invention aim to improve the conventional trusted devices and systems.
  • a first aspect of the present invention provides a trusted device for a trusted computing system, wherein the trusted device is configured to obtain a numerical value and program code from a user device; calculate a hash value based on the numerical value and based on the program code; sign the hash value; and provide the signed hash value to a verification device.
  • TPM which provides key store functionality and fixed set of cryptographic and vendor specific functions. This facilitates that a program on the trusted module is the sole arbiter of messages going out of the module, and can be written to disallow unauthorized access to stored information. This is contrary to TPM, where hardware owner can invoke TPM functions to sign messages with currently stored keys.
  • the hash value is in particular calculated using a hash function.
  • a hash function can be any function that maps data of arbitrary size to data of a fixed size.
  • the values returned by a hash function can be called hash values.
  • the hash value is in particular signed using public/private key cryptography.
  • calculating a hash value based on the numerical value and based on the program code includes that the numerical value the program code are used as input values of the hash function.
  • signing the hash value includes signing algorithm that, given the hash value and a private key, produces a signature (i.e. the signed hash value).
  • the trusted device (which also may be called trusted module) may be regarded as a unit of trusted computation including memory and 10.
  • the trusted device can be a co-processor, a system-on- chip, or any processor with memory and bus isolated from other computation units and inspection through physical means.
  • the trusted device can expose a low-level messaging interface (send/receive), and an ability to reset-and-load new programs in a trusted manner.
  • the trusted device can be temper-proof and may include all facilities needed to perform trusted reset-and-load. A user of the trusted device can thus be able to gain proof of the device authenticity and the correct completion of a reset to a clean state and loading of a new program (through secrets provided by a vendor of the trusted device).
  • the reset and load command of the trusted device may allow to load a program into the trusted device.
  • the command may ensure reset of state in the trusted device hardware (including memories, registers, and other states of the trusted device).
  • the command may expect a user provided challenge and may complete with a cryptographically sound response.
  • the trusted device may provide a cryptographic proof of completion.
  • the proof of the reset-and-load command can be verified by the device vendor and attests the following aspects:
  • the proof was generated on a trusted device manufactured on behalf of the vendor.
  • the trusted device performed a reset to initial state.
  • the trusted device loaded a program with a specific hash only.
  • the numerical value is a nonce.
  • the nonce is also called “number used once”.
  • the nonce can also be called cryptographic challenge.
  • a nonce is an arbitrary number that can be used just once in a cryptographic communication.
  • the trusted device comprises a trusted processor, wherein the trusted device is further configured to reset the trusted processor and load the program code to the trusted processor.
  • the trusted processor is further configured to calculate the hash value based on the numerical value and based on the loaded program code.
  • the trusted processor is further configured to calculate the hash value based on a content of a memory of the trusted device.
  • the hash value is calculated based on the whole content of the memory, in particular including the program code.
  • the trusted processor is further configured to sign the hash value based on a private key of the trusted device.
  • the private key is pre-stored in the trusted device, e.g. during manufacturing of the trusted device by a vendor.
  • the trusted device is implemented as a pluggable card.
  • the trusted device can be realized as a pluggable and a non-integrated device.
  • a second aspect of the present invention provides a trusted computing system comprising the trusted device according to the first aspects or any of its implementation forms and a verification device, wherein the verification device is configured to obtain the numerical value from a user device; obtain the signed hash value from the trusted device; and verify authenticity of the trusted device, based on the numerical value and based on the signed hash value.
  • the signed hash value can be provided to the verification device directly or indirectly.
  • the signed hash value is forwarded from the trusted device to the verification device e.g. by means of a user device (e.g. a user terminal, personal computer, notebook, smartphone, and the like).
  • the numerical value which is obtained by the trusted device is the same, which is obtained by the verification device.
  • the numerical value can be determined and provided by a user device.
  • system further comprises the user device, wherein the user device is configured to calculate the numerical value, to obtain the program code, to provide the numerical value and the program code to the trusted device, and to provide the numerical value to the verification device.
  • the user device is further configured to obtain the signed hash value from the trusted device, and forward the signed hash value to the verification device.
  • the trusted device indirectly provides the signed hash value to the verification device.
  • the user device receives the signed hash value from the trusted device and then provides it to the verification device.
  • the user device is further configured to calculate and store a hash value of the program code before providing the program code to the trusted device.
  • the user device is further configured to compare the stored hash value of the program code and a hash value calculated based on the program code loaded to the trusted processor, to verify that the program code provided by the user device is the program code loaded to the trusted processor.
  • the user device can directly or indirectly access the trusted processor in the trusted device. That is, the calculation of the hash value is performed by the user device.
  • the verification device is further configured to verify that the program code that is executed by the trusted device is the program coded that was provided by the user device, to verify the authenticity of the trusted device.
  • the verification device is further configured to verify one or more of the following to verify the authenticity of the trusted device: an identity of the trusted device, a vendor of the trusted device.
  • the verification device is further configured to verify the authenticity of the trusted device based on a public key corresponding to the private key of the trusted device.
  • the public key is pre-stored in the verification device.
  • the verification device is further configured to provide a result of verification of authenticity of the trusted device to the user device.
  • a third aspect of the present invention provides a method for operating a trusted device, wherein the method comprises the steps of: obtaining, by the trusted device, a numerical value and program code from a user device; calculating, by the trusted device, a hash value based on the numerical value and based on the program code; signing, by the trusted device, the hash value; and providing, by the trusted device, the signed hash value to a verification device.
  • the numerical value is a nonce.
  • the method further includes resetting, by the trusted device, a trusted processor of the trusted device and loading, by the trusted device, the program code to the trusted processor.
  • the method further includes calculating, by the trusted processor, the hash value based on the numerical value and based on the loaded program code. In a further implementation form of the third aspect, the method further includes calculating, by the trusted processor, the hash value based on a content of a memory of the trusted device.
  • the method further includes signing, by the trusted processor, the hash value based on a private key of the trusted device.
  • the trusted device is implemented as a pluggable card.
  • the third aspect and its implementation forms include the same advantages as the first aspect and its respective implementation forms.
  • a fourth aspect of the present invention provides a method for operating a trusted computing system comprising a trusted device and a verification device, wherein the method comprises the steps of: obtaining, by the trusted device, a numerical value and program code from a user device; calculating, by the trusted device, a hash value based on the numerical value and based on the program code; signing, by the trusted device, the hash value; and providing, by the trusted device, the signed hash value to the verification device; obtaining, by the verification device, the numerical value from the user device; obtaining, by the verification device, the signed hash value from the trusted device; and verifying, by the verification device, authenticity of the trusted device, based on the numerical value and based on the signed hash value.
  • the method further comprises, by a user device of the system, calculating the numerical value, obtaining the program code, providing the numerical value and the program code to the trusted device, and providing the numerical value to the verification device.
  • the method further includes obtaining, by the user device, the signed hash value from the trusted device, and forwarding, by the user device, the signed hash value to the verification device.
  • the method further includes calculating and storing, by the user device a hash value of the program code before providing the program code to the trusted device. In a further implementation form of the fourth aspect, the method further includes compare, by the user device, the stored hash value of the program code and a hash value calculated based on the program code loaded to the trusted processor, to verify that the program code provided by the user device is the program code loaded to the trusted processor.
  • the method further includes verifying, by the verification device, that the program code that is executed by the trusted device is the program coded that was provided by the user device, to verify the authenticity of the trusted device.
  • the method further includes verifying, by the verification device, one or more of the following to verify the authenticity of the trusted device: an identity of the trusted device, a vendor of the trusted device.
  • the method further includes verifying, by the verification device, the authenticity of the trusted device based on a public key corresponding to the private key of the trusted device.
  • the method further includes providing, by the verification device, a result of verification of authenticity of the trusted device to the user device.
  • the fourth aspect and its implementation forms include the same advantages as the second aspect and its respective implementation forms.
  • a fifth aspect of the present invention provides a computer program product comprising program code configured to perform the method according to the third aspect or any of its implementation forms when the computer program is executed on a computer.
  • the fifth aspect and its implementation forms include the same advantages as the third aspect and its respective implementation forms.
  • a sixth aspect of the present invention provides a computer program product comprising program code configured to perform the method according to the fourth aspect or any of its implementation forms when the computer program is executed on a computer.
  • the sixth aspect and its implementation forms include the same advantages as the fourth aspect and its respective implementation forms. It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.
  • FIG. 1 shows a schematic view of a trusted device according to an embodiment of the present invention.
  • FIG. 2 shows a schematic view of a trusted device according to an embodiment of the present invention in more detail.
  • FIG. 3 shows another schematic view of a trusted device according to an embodiment of the present invention.
  • FIG. 4 shows a schematic view of a system according to an embodiment of the present invention.
  • FIG. 5 shows a schematic view of a system according to an embodiment of the present invention in more detail.
  • FIG. 6 shows an operating manner of a system according to the present invention.
  • FIG. 7 shows another operating manner of a system according to the present invention.
  • FIG. 8 shows a schematic view of a method according to an embodiment of the present invention.
  • FIG. 9 shows a schematic view of a method according to an embodiment of the present invention.
  • FIG. 1 shows a schematic view of a trusted device 100 according to an embodiment of the invention.
  • the trusted device 100 can be used in a trusted computing system 400 as it is going to be described below in view of FIG. 4.
  • the trusted device 100 and the trusted computing system 400 are in particular suitable for cloud computing.
  • the trusted device 100 is configured to obtain a numerical value 101 and program code 102 from a user device 501 (the user device 501 is also going to be described in view of FIG. 5 below).
  • the user device 501 is not part of the trusted device 100.
  • the trusted device 100 can calculate a hash value 103, and sign the hash value 103. Then, the signed hash value 103 is provided to a verification device 401 (which is also going to be described below).
  • FIG. 2 shows the trusted device 100 according to an embodiment of the present invention in more detail.
  • the trusted device 100 as shown in FIG. 2 comprises the same features and functionality as the device 100 described in view of FIG. 1.
  • the trusted device 100 optionally can comprise a trusted processor 201, which can load and executed the program code 102. Before, the trusted processor 201 can in particular be reset, so that there is no other code than the program code 102 loaded to the trusted processor 201.
  • the trusted device 100 optionally can also comprise a memory 202.
  • the memory 202 generally can stored all kinds of information that is provided to, or processed by the trusted device 100.
  • the hash value 103 can be obtained based on the content of the memory 202 that is the numerical value 101 and the program code 102.
  • the trusted device 100 can also store a private key 203 that relates to the trusted device 100.
  • the private key 203 can be used for signing the hash value 103.
  • the private key 203 can e.g. be stored in the memory 202 of the trusted device 100.
  • FIG. 3 shows a possible embodiment of the trusted device 100.
  • FIG. 3 schematically shows a server with a special PCI-E card that will act as the trusted device 100.
  • the PCI-E card contains the following: a multicore processor, hereinafter named Trusted Environment Processor Unit (TEPU), memory devices, an attestation unit.
  • TEPU encrypts all data stored in the memory, so it cannot be read by tapping the connection between the TEPU and its memory. Only the TEPU can access the attestation unit to generate attestation proofs.
  • the TEPU implements in its hardware a reset-and-load command as described above (that is, a trusted processor is instructed to be reset and to load program code).
  • a vendor of the trusted device can embed a private key inside the attestation unit (based on this key, the attestation unit signs the hash value 103).
  • the public key is recorded in the vendor systems (e.g. in the verification device 401) and is used to verify that proofs come from the correct trusted device 100.
  • FIG. 4 shows a trusted computing system 400 according to an embodiment of the present invention in a schematic manner.
  • the trusted computing system 400 in particular includes the trusted device 100.
  • the trusted computing system 400 further comprises a verification device 401. Together with the verification device 401 , the trusted device 100 allows for verifying that the program code 102 that is loaded to the trusted device 100 is not tampered or changed.
  • the verification device 401 is configured to obtain the numerical value 101 from a user device 501. This is in particular the same numerical value which is also obtained by the trusted device according to figures 1 to 3 above.
  • the verification device 401 is further configured to obtain the signed hash value 103 from the trusted device 100, and to verify authenticity of the trusted device 100, based on the numerical value 101 and based on the signed hash value 103.
  • FIG. 5 shows the trusted computing system 400 according to an embodiment of the present invention in more detail.
  • the trusted computing system 400 as shown in FIG. 5 comprises the same features and functionality of the system 400 described in view of FIG. 4.
  • the trusted computing system 400 further comprises the user device 501.
  • the user device 501 supports the trusted computing system 400 and the verification 401 in obtaining the numerical value 101 and in obtaining the program code 102. Therefore, the user device 501 e.g. calculates the numerical value 101 and obtains the program code 102 (e.g. by user input), and provides the numerical value 101 and the program code 102 to the trusted device 100. Also, it provides the numerical value 101 to the verification device 401.
  • the user device 501 also can obtain the signed hash value 103 from the trusted device 100 and forward it to the verification device 401.
  • the user device can calculate and store a hash value 502 of the program code 102 before providing the program code 102 to the trusted device 100 (where it is loaded to the trusted processor 201, after the trusted processor 201 is reset). The user device 501 then compares the stored hash value 502 of the program code 102 and a hash value 103 calculated based on the program code 102 loaded to the trusted processor 201.
  • FIG. 6 shows an operating example of the trusted computing system 400.
  • FIG. 6 in particular depicts a bootstrapping flow where a user loads a program code 102 into the trusted device 100 and establishes trust.
  • a user computes a cryptographic hash of a program (i.e. the program code 102) that the user intends to run on a trusted device 100 (as if it was loaded into clean memory).
  • the user stores the result of the cryptographic hash computation.
  • the hash is computed so later on the user can verify that the loaded program matches the program the user intended to run.
  • the user then transfers the program to a main core connected to the trusted device (without running it).
  • the user instructs the main core to reset the trusted core (i.e. the trusted processor 201) and load the program at once (“reset-and-load” command).
  • the user provides a cryptographic nonce (i.e. the numerical value 101) as a challenge (i.e. the challenge according to a challenge and response mechanism) as one of the inputs to the command (along with the program code 102).
  • the trusted device 100 resets and loads the program code 102, then provides the hash 103 of the whole memory (including the loaded program code 102), and the challenge, signed by the private key 203 of the trusted device 100.
  • the user retrieves the signature of the hash (i.e. the signed hash 103) and the challenge (i.e. the numerical value 101).
  • the trusted device 100 becomes trusted only once a predefined program is loaded into the trusted device 100 and it is made sure that it is only the predefined program running inside.
  • the nonce (challenge) is passed to the trusted device 100 and the trusted device 100 returns the signed nonce (response). This means that as long as a user uses secure nonces, no adversary can impersonate the trusted module.
  • the user sends the signed hash 103 and the challenge 101 to a vendor of the trusted device 100 (i.e. to the verification device 401).
  • the vendor then verifies that the signature 103 belongs to one of the trusted devices 100 manufactured by the vendor and reports the result to the user. If the user receives a positive answer, the user can trust that the correct program code 102 was loaded to the correct device (trusted device 100), and can begin trusted interaction with the trusted device 100.
  • FIG. 7 shows an operating example of the trusted computing system 400 in which the trusted device 100 is implemented by means of a trusted PCI-E module.
  • the reset- and-load command that is sent by the Main Core to the Trusted PCI-E module includes providing memory locations of the program code 102.
  • the Trusted PCI-E module Upon receiving, the Trusted PCI-E module resets to a clean state, uses direct memory access (DMA) to load the program code 102 from the provided address and then computes the hash of the internal memory.
  • DMA direct memory access
  • FIG. 8 shows a schematic view of a method 800 according to an embodiment of the present invention.
  • the method 800 is for operating a trusted device 100, and comprises a steps of obtaining 801, by the trusted device 100, a numerical value 101 and program code 102 from a user device 501.
  • the method 800 further comprises a step of calculating 802, by the trusted device 100, a hash value 103 based on the numerical value 101 and based on the program code 102.
  • the method 800 further comprises a step of signing 803, by the trusted device 100, the hash value 103.
  • the method 800 further comprises a step of providing 804, by the trusted device 100, the signed hash value 103 to a verification device 401.
  • FIG. 9 shows a schematic view of a method 900 according to an embodiment of the present invention.
  • the method 900 is for operating a trusted computing system 400 comprising the trusted device 100 and the verification device 401, and comprises a step of obtaining 901, by the trusted device 100, a numerical value 101 and program code 102 from a user device 501.
  • the method 900 further comprises a step of calculating 902, by the trusted device 100, a hash value 103 based on the numerical value 101 and based on the program code 102.
  • the method 900 further comprises a step of signing 903, by the trusted device 100, the hash value 103.
  • the method 900 further comprises a step of providing 904, by the trusted device 100, the signed hash value 103 to the verification device 401.
  • the method 900 further comprises a step of obtaining 905, by the verification device 401 , the numerical value 101 from the user device 501.
  • the method 900 further comprises a step of obtaining 906, by the verification device 401, the signed hash value 103 from the trusted device 100.
  • the method 900 further comprises a step of verifying 907, by the verification device 401, authenticity of the trusted device 100, based on the numerical value 101 and based on the signed hash value 103.

Abstract

The present invention relates to the fields of trusted computing and cloud computing. The present invention provides a trusted device for a trusted computing system. The trusted device is configured to obtain a numerical value and program code from a user device; calculate a hash value based on the numerical value and based on the program code; sign the hash value; and provide the signed hash value to a verification device.

Description

TRUSTED DEVICE AND COMPUTING SYSTEM
TECHNICAL FIELD
The present invention relates to the field of trusted computing. More specifically, the present invention relates to a trusted device and to a trusted computing system comprising the trusted device. The present invention can, in particular, be used in the field of cloud computing.
BACKGROUND
Cloud computing involves using shared resources by multiple tenants. This allows for reductions of costs and maintenance. Because of this shared model, the cloud provider usually has full control over a user’s data and resources (e.g. virtual machines, storage or network). This includes access to privileged data (e.g. private keys, passwords), secure information stored in the cloud, ability to act on behalf of a user, mislead a user about the resources provided in the cloud. This can also be done by attackers if they compromise the cloud infrastructure.
Due to these reasons, trust is required between the cloud provider and the tenant. This is acceptable for most cases but in some circumstances (e.g. regulation or business reasons) this kind of trust cannot be established.
For a use case where such trust is impossible, the tenant can still enjoy utilization of cloud infrastructure under the following conditions: all privileged data is inaccessible at rest, or all privileged data is inaccessible while being processed. The former requires encryption of the data while the latter requires the ability to perform trusted execution of the tenant code.
Intel provides instruction set extension (Software Guard Extensions - SGX) to create enclaves of trusted and secure execution. The user may create such enclave, run an attestation protocol and run computations without exposing the state of the computation to any other code running on the CPU. In particular, SGX is a set of instructions that help to increase the security of any application code and data, thereby giving them more protection from disclosure or tempering.
ARM provides TrustZone technology that partitions hardware into the trusted and less-trusted environments, which are isolated one from another. The hardware is responsible for switching the modes. Trusted Platform Module (TPM, also known as ISO/IEC 11889) is an international standard for a secure crypto-processor, a dedicated microcontroller designed to secure hardware through integrated cryptographic keys.
However, these technologies are not suitable for cloud computing or any other use case where a device is shared among tenants or is not owned by the user, as the above solutions assume that the owner, user and administrator are the same entity.
That is, a tenant user in particular lacks the following properties for trusted execution: ability to attest the deployed software that will be accessing the privileged data, and ability to attest the provided hardware, and verify it is under exclusive access.
SUMMARY
In view of the above-mentioned problems and disadvantages, embodiments of the present invention aim to improve the conventional trusted devices and systems.
It is in particular an objective to provide a trusted device that allows to verify that program code, which was provided by a user device to the trusted device, is actually executed by the trusted device.
The objective is achieved by the embodiments provided in the enclosed independent claims. Advantageous implementations of these embodiments are further defined in the dependent claims.
A first aspect of the present invention provides a trusted device for a trusted computing system, wherein the trusted device is configured to obtain a numerical value and program code from a user device; calculate a hash value based on the numerical value and based on the program code; sign the hash value; and provide the signed hash value to a verification device.
This is beneficial, as code is executed on a dedicated and physically separate computation core, which makes it much less susceptible to side-channel attacks. This also ensures that any arbitrary program can be executed on the trusted device, unlike a TPM which provides key store functionality and fixed set of cryptographic and vendor specific functions. This facilitates that a program on the trusted module is the sole arbiter of messages going out of the module, and can be written to disallow unauthorized access to stored information. This is contrary to TPM, where hardware owner can invoke TPM functions to sign messages with currently stored keys.
The hash value is in particular calculated using a hash function. A hash function can be any function that maps data of arbitrary size to data of a fixed size. The values returned by a hash function can be called hash values. The hash value is in particular signed using public/private key cryptography. In particular, calculating a hash value based on the numerical value and based on the program code includes that the numerical value the program code are used as input values of the hash function. In particular, signing the hash value includes signing algorithm that, given the hash value and a private key, produces a signature (i.e. the signed hash value).
The trusted device (which also may be called trusted module) may be regarded as a unit of trusted computation including memory and 10. The trusted device can be a co-processor, a system-on- chip, or any processor with memory and bus isolated from other computation units and inspection through physical means. The trusted device can expose a low-level messaging interface (send/receive), and an ability to reset-and-load new programs in a trusted manner.
The trusted device can be temper-proof and may include all facilities needed to perform trusted reset-and-load. A user of the trusted device can thus be able to gain proof of the device authenticity and the correct completion of a reset to a clean state and loading of a new program (through secrets provided by a vendor of the trusted device).
The reset and load command of the trusted device may allow to load a program into the trusted device. The command may ensure reset of state in the trusted device hardware (including memories, registers, and other states of the trusted device). The command may expect a user provided challenge and may complete with a cryptographically sound response. Once the program is loaded into the trusted device, the trusted device may provide a cryptographic proof of completion.
The proof of the reset-and-load command can be verified by the device vendor and attests the following aspects: The proof was generated on a trusted device manufactured on behalf of the vendor. The trusted device performed a reset to initial state. The trusted device loaded a program with a specific hash only.
Thereby it is ensured that code running on the trusted device is trusted, contrary to an enclave that can run on the same CPU with untrusted code. The user of the trusted device can attest authenticity of the used trusted device and its loaded code. Physical access to the trusted device does not compromise its contents.
In an implementation form of the first aspect, the numerical value is a nonce.
In particular, the nonce is also called “number used once”. In particular, the nonce can also be called cryptographic challenge. In particular, a nonce is an arbitrary number that can be used just once in a cryptographic communication.
In a further implementation form of the first aspect, the trusted device comprises a trusted processor, wherein the trusted device is further configured to reset the trusted processor and load the program code to the trusted processor.
This ensures that the trusted processor only runs the program code obtained from the user device. No other program code can be provided to the user device unnoticed.
In a further implementation form of the first aspect, the trusted processor is further configured to calculate the hash value based on the numerical value and based on the loaded program code.
In a further implementation form of the first aspect, the trusted processor is further configured to calculate the hash value based on a content of a memory of the trusted device.
In particular, the hash value is calculated based on the whole content of the memory, in particular including the program code.
In a further implementation form of the first aspect, the trusted processor is further configured to sign the hash value based on a private key of the trusted device.
In particular, the private key is pre-stored in the trusted device, e.g. during manufacturing of the trusted device by a vendor.
In a further implementation form of the first aspect, the trusted device is implemented as a pluggable card.
This is beneficial, as the trusted device can be realized as a pluggable and a non-integrated device.
A second aspect of the present invention provides a trusted computing system comprising the trusted device according to the first aspects or any of its implementation forms and a verification device, wherein the verification device is configured to obtain the numerical value from a user device; obtain the signed hash value from the trusted device; and verify authenticity of the trusted device, based on the numerical value and based on the signed hash value.
In particular, the signed hash value can be provided to the verification device directly or indirectly. In particular, in case that the signed hash value is provided to the verification device indirectly, the signed hash value is forwarded from the trusted device to the verification device e.g. by means of a user device (e.g. a user terminal, personal computer, notebook, smartphone, and the like).
In particular, the numerical value which is obtained by the trusted device is the same, which is obtained by the verification device. In particular, the numerical value can be determined and provided by a user device.
In an implementation form of the second aspect, the system further comprises the user device, wherein the user device is configured to calculate the numerical value, to obtain the program code, to provide the numerical value and the program code to the trusted device, and to provide the numerical value to the verification device.
In a further implementation form of the second aspect, the user device is further configured to obtain the signed hash value from the trusted device, and forward the signed hash value to the verification device.
In particular, thereby the trusted device indirectly provides the signed hash value to the verification device. In particular, the user device receives the signed hash value from the trusted device and then provides it to the verification device.
In a further implementation form of the second aspect, the user device is further configured to calculate and store a hash value of the program code before providing the program code to the trusted device.
In a further implementation form of the second aspect, the user device is further configured to compare the stored hash value of the program code and a hash value calculated based on the program code loaded to the trusted processor, to verify that the program code provided by the user device is the program code loaded to the trusted processor. In particular, to calculate the hash value based on the program code loaded to the trusted processor, the user device can directly or indirectly access the trusted processor in the trusted device. That is, the calculation of the hash value is performed by the user device.
In a further implementation form of the second aspect, the verification device is further configured to verify that the program code that is executed by the trusted device is the program coded that was provided by the user device, to verify the authenticity of the trusted device.
In a further implementation form of the second aspect, the verification device is further configured to verify one or more of the following to verify the authenticity of the trusted device: an identity of the trusted device, a vendor of the trusted device.
In a further implementation form of the second aspect, the verification device is further configured to verify the authenticity of the trusted device based on a public key corresponding to the private key of the trusted device.
In particular, the public key is pre-stored in the verification device.
In a further implementation form of the second aspect, the verification device is further configured to provide a result of verification of authenticity of the trusted device to the user device.
A third aspect of the present invention provides a method for operating a trusted device, wherein the method comprises the steps of: obtaining, by the trusted device, a numerical value and program code from a user device; calculating, by the trusted device, a hash value based on the numerical value and based on the program code; signing, by the trusted device, the hash value; and providing, by the trusted device, the signed hash value to a verification device.
In an implementation form of the third aspect, the numerical value is a nonce.
In a further implementation form of the third aspect, the method further includes resetting, by the trusted device, a trusted processor of the trusted device and loading, by the trusted device, the program code to the trusted processor.
In a further implementation form of the third aspect, the method further includes calculating, by the trusted processor, the hash value based on the numerical value and based on the loaded program code. In a further implementation form of the third aspect, the method further includes calculating, by the trusted processor, the hash value based on a content of a memory of the trusted device.
In a further implementation form of the third aspect, the method further includes signing, by the trusted processor, the hash value based on a private key of the trusted device.
In a further implementation form of the third aspect, the trusted device is implemented as a pluggable card.
The third aspect and its implementation forms include the same advantages as the first aspect and its respective implementation forms.
A fourth aspect of the present invention provides a method for operating a trusted computing system comprising a trusted device and a verification device, wherein the method comprises the steps of: obtaining, by the trusted device, a numerical value and program code from a user device; calculating, by the trusted device, a hash value based on the numerical value and based on the program code; signing, by the trusted device, the hash value; and providing, by the trusted device, the signed hash value to the verification device; obtaining, by the verification device, the numerical value from the user device; obtaining, by the verification device, the signed hash value from the trusted device; and verifying, by the verification device, authenticity of the trusted device, based on the numerical value and based on the signed hash value.
In an implementation form of the fourth aspect, the method further comprises, by a user device of the system, calculating the numerical value, obtaining the program code, providing the numerical value and the program code to the trusted device, and providing the numerical value to the verification device.
In a further implementation form of the fourth aspect, the method further includes obtaining, by the user device, the signed hash value from the trusted device, and forwarding, by the user device, the signed hash value to the verification device.
In a further implementation form of the fourth aspect, the method further includes calculating and storing, by the user device a hash value of the program code before providing the program code to the trusted device. In a further implementation form of the fourth aspect, the method further includes compare, by the user device, the stored hash value of the program code and a hash value calculated based on the program code loaded to the trusted processor, to verify that the program code provided by the user device is the program code loaded to the trusted processor.
In a further implementation form of the fourth aspect, the method further includes verifying, by the verification device, that the program code that is executed by the trusted device is the program coded that was provided by the user device, to verify the authenticity of the trusted device.
In a further implementation form of the fourth aspect, the method further includes verifying, by the verification device, one or more of the following to verify the authenticity of the trusted device: an identity of the trusted device, a vendor of the trusted device.
In a further implementation form of the fourth aspect, the method further includes verifying, by the verification device, the authenticity of the trusted device based on a public key corresponding to the private key of the trusted device.
In a further implementation form of the fourth aspect, the method further includes providing, by the verification device, a result of verification of authenticity of the trusted device to the user device.
The fourth aspect and its implementation forms include the same advantages as the second aspect and its respective implementation forms.
A fifth aspect of the present invention provides a computer program product comprising program code configured to perform the method according to the third aspect or any of its implementation forms when the computer program is executed on a computer.
The fifth aspect and its implementation forms include the same advantages as the third aspect and its respective implementation forms.
A sixth aspect of the present invention provides a computer program product comprising program code configured to perform the method according to the fourth aspect or any of its implementation forms when the computer program is executed on a computer.
The sixth aspect and its implementation forms include the same advantages as the fourth aspect and its respective implementation forms. It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.
BRIEF DESCRIPTION OF THE DRAWINGS
The above-described aspects and implementation forms of the present invention will be explained in the following description of more specific embodiments in relation to the enclosed drawings, in which
FIG. 1 shows a schematic view of a trusted device according to an embodiment of the present invention.
FIG. 2 shows a schematic view of a trusted device according to an embodiment of the present invention in more detail. FIG. 3 shows another schematic view of a trusted device according to an embodiment of the present invention.
FIG. 4 shows a schematic view of a system according to an embodiment of the present invention.
FIG. 5 shows a schematic view of a system according to an embodiment of the present invention in more detail.
FIG. 6 shows an operating manner of a system according to the present invention.
FIG. 7 shows another operating manner of a system according to the present invention. FIG. 8 shows a schematic view of a method according to an embodiment of the present invention.
FIG. 9 shows a schematic view of a method according to an embodiment of the present invention.
DETAILED DESCRIPTION OF THE EMBODIMENTS
FIG. 1 shows a schematic view of a trusted device 100 according to an embodiment of the invention. The trusted device 100 can be used in a trusted computing system 400 as it is going to be described below in view of FIG. 4. The trusted device 100 and the trusted computing system 400 are in particular suitable for cloud computing.
The trusted device 100 is configured to obtain a numerical value 101 and program code 102 from a user device 501 (the user device 501 is also going to be described in view of FIG. 5 below). The user device 501 is not part of the trusted device 100. Based on the numerical value 101 and based on the program code 102, the trusted device 100 can calculate a hash value 103, and sign the hash value 103. Then, the signed hash value 103 is provided to a verification device 401 (which is also going to be described below).
Thereby, it is possible to verify that program code 102 which is provided to the trusted device 100 is also the program code 102 executed by the trusted device.
FIG. 2 shows the trusted device 100 according to an embodiment of the present invention in more detail. The trusted device 100 as shown in FIG. 2 comprises the same features and functionality as the device 100 described in view of FIG. 1.
As shown in FIG. 2, the trusted device 100 optionally can comprise a trusted processor 201, which can load and executed the program code 102. Before, the trusted processor 201 can in particular be reset, so that there is no other code than the program code 102 loaded to the trusted processor 201.
The trusted device 100 optionally can also comprise a memory 202. The memory 202 generally can stored all kinds of information that is provided to, or processed by the trusted device 100. In particular, the hash value 103 can be obtained based on the content of the memory 202 that is the numerical value 101 and the program code 102.
The trusted device 100 can also store a private key 203 that relates to the trusted device 100. The private key 203 can be used for signing the hash value 103. The private key 203 can e.g. be stored in the memory 202 of the trusted device 100.
FIG. 3 shows a possible embodiment of the trusted device 100. FIG. 3 schematically shows a server with a special PCI-E card that will act as the trusted device 100. The PCI-E card contains the following: a multicore processor, hereinafter named Trusted Environment Processor Unit (TEPU), memory devices, an attestation unit. The TEPU encrypts all data stored in the memory, so it cannot be read by tapping the connection between the TEPU and its memory. Only the TEPU can access the attestation unit to generate attestation proofs. The TEPU implements in its hardware a reset-and-load command as described above (that is, a trusted processor is instructed to be reset and to load program code). A vendor of the trusted device can embed a private key inside the attestation unit (based on this key, the attestation unit signs the hash value 103). The public key is recorded in the vendor systems (e.g. in the verification device 401) and is used to verify that proofs come from the correct trusted device 100.
FIG. 4 shows a trusted computing system 400 according to an embodiment of the present invention in a schematic manner. The trusted computing system 400 in particular includes the trusted device 100.
As it is shown in FIG. 4, the trusted computing system 400 further comprises a verification device 401. Together with the verification device 401 , the trusted device 100 allows for verifying that the program code 102 that is loaded to the trusted device 100 is not tampered or changed.
To this end, the verification device 401 is configured to obtain the numerical value 101 from a user device 501. This is in particular the same numerical value which is also obtained by the trusted device according to figures 1 to 3 above. The verification device 401 is further configured to obtain the signed hash value 103 from the trusted device 100, and to verify authenticity of the trusted device 100, based on the numerical value 101 and based on the signed hash value 103. FIG. 5 shows the trusted computing system 400 according to an embodiment of the present invention in more detail. The trusted computing system 400 as shown in FIG. 5 comprises the same features and functionality of the system 400 described in view of FIG. 4.
As shown in FIG. 5, the trusted computing system 400 further comprises the user device 501.
The user device 501 supports the trusted computing system 400 and the verification 401 in obtaining the numerical value 101 and in obtaining the program code 102. Therefore, the user device 501 e.g. calculates the numerical value 101 and obtains the program code 102 (e.g. by user input), and provides the numerical value 101 and the program code 102 to the trusted device 100. Also, it provides the numerical value 101 to the verification device 401.
Although this is not illustrated in FIG. 5, the user device 501 also can obtain the signed hash value 103 from the trusted device 100 and forward it to the verification device 401.
To verify that the program code 102 provided by the user device 501 is the program code 102 loaded to the trusted processor 201, the user device can calculate and store a hash value 502 of the program code 102 before providing the program code 102 to the trusted device 100 (where it is loaded to the trusted processor 201, after the trusted processor 201 is reset). The user device 501 then compares the stored hash value 502 of the program code 102 and a hash value 103 calculated based on the program code 102 loaded to the trusted processor 201.
FIG. 6 shows an operating example of the trusted computing system 400. FIG. 6 in particular depicts a bootstrapping flow where a user loads a program code 102 into the trusted device 100 and establishes trust.
During a load phase, a user computes a cryptographic hash of a program (i.e. the program code 102) that the user intends to run on a trusted device 100 (as if it was loaded into clean memory). The user stores the result of the cryptographic hash computation. The hash is computed so later on the user can verify that the loaded program matches the program the user intended to run. The user then transfers the program to a main core connected to the trusted device (without running it). The user instructs the main core to reset the trusted core (i.e. the trusted processor 201) and load the program at once (“reset-and-load” command). For this process, the user provides a cryptographic nonce (i.e. the numerical value 101) as a challenge (i.e. the challenge according to a challenge and response mechanism) as one of the inputs to the command (along with the program code 102).
Then, the trusted device 100 resets and loads the program code 102, then provides the hash 103 of the whole memory (including the loaded program code 102), and the challenge, signed by the private key 203 of the trusted device 100. In turn, the user retrieves the signature of the hash (i.e. the signed hash 103) and the challenge (i.e. the numerical value 101). In other words, the trusted device 100 becomes trusted only once a predefined program is loaded into the trusted device 100 and it is made sure that it is only the predefined program running inside. During the reset-and-load command, the nonce (challenge) is passed to the trusted device 100 and the trusted device 100 returns the signed nonce (response). This means that as long as a user uses secure nonces, no adversary can impersonate the trusted module.
During an attestation phase, the user sends the signed hash 103 and the challenge 101 to a vendor of the trusted device 100 (i.e. to the verification device 401). The vendor then verifies that the signature 103 belongs to one of the trusted devices 100 manufactured by the vendor and reports the result to the user. If the user receives a positive answer, the user can trust that the correct program code 102 was loaded to the correct device (trusted device 100), and can begin trusted interaction with the trusted device 100.
FIG. 7 shows an operating example of the trusted computing system 400 in which the trusted device 100 is implemented by means of a trusted PCI-E module. As shown in FIG. 7, the reset- and-load command that is sent by the Main Core to the Trusted PCI-E module includes providing memory locations of the program code 102. Upon receiving, the Trusted PCI-E module resets to a clean state, uses direct memory access (DMA) to load the program code 102 from the provided address and then computes the hash of the internal memory.
FIG. 8 shows a schematic view of a method 800 according to an embodiment of the present invention. The method 800 is for operating a trusted device 100, and comprises a steps of obtaining 801, by the trusted device 100, a numerical value 101 and program code 102 from a user device 501. The method 800 further comprises a step of calculating 802, by the trusted device 100, a hash value 103 based on the numerical value 101 and based on the program code 102. The method 800 further comprises a step of signing 803, by the trusted device 100, the hash value 103. The method 800 further comprises a step of providing 804, by the trusted device 100, the signed hash value 103 to a verification device 401.
FIG. 9 shows a schematic view of a method 900 according to an embodiment of the present invention. The method 900 is for operating a trusted computing system 400 comprising the trusted device 100 and the verification device 401, and comprises a step of obtaining 901, by the trusted device 100, a numerical value 101 and program code 102 from a user device 501. The method 900 further comprises a step of calculating 902, by the trusted device 100, a hash value 103 based on the numerical value 101 and based on the program code 102. The method 900 further comprises a step of signing 903, by the trusted device 100, the hash value 103. The method 900 further comprises a step of providing 904, by the trusted device 100, the signed hash value 103 to the verification device 401. The method 900 further comprises a step of obtaining 905, by the verification device 401 , the numerical value 101 from the user device 501. The method 900 further comprises a step of obtaining 906, by the verification device 401, the signed hash value 103 from the trusted device 100. The method 900 further comprises a step of verifying 907, by the verification device 401, authenticity of the trusted device 100, based on the numerical value 101 and based on the signed hash value 103.
The present invention has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed invention, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

1. A trusted device (100) for a trusted computing system (400), wherein the trusted device (100) is configured to:
- obtain a numerical value (101) and program code (102) from a user device (501);
- calculate a hash value (103) based on the numerical value (101) and based on the program code (102);
- sign the hash value (103); and
- provide the signed hash value (103) to a verification device (401).
2. The trusted device (100) according to claim 1, wherein the numerical value (101) is a nonce.
3. The trusted device (100) according to claim 1 or 2, wherein the trusted device (100) comprises a trusted processor (201), and wherein the trusted device (100) is further configured to reset the trusted processor (201) and load the program code (102) to the trusted processor (201).
4. The trusted device (100) according to claim 3, wherein the trusted processor (201) is further configured to calculate the hash value (103) based on the numerical value (101) and based on the loaded program code (102).
5. The trusted device (100) according to claim 3 or 4, wherein the trusted processor (201) is further configured to calculate the hash value (103) based on a content of a memory (202) of the trusted device (100).
6. The trusted device (100) according to any one of claims 3 to 5, wherein the trusted processor (201) is further configured to sign the hash value (103) based on a private key (203) of the trusted device (100).
7. The trusted device (100) according to any of the preceding claims, wherein the trusted device (100) is implemented as a pluggable card.
8. A trusted computing system (400) comprising the trusted device (100) according to any one of claims 1 to 7 and a verification device (401), wherein the verification device (401) is configured to: - obtain the numerical value (101) from a user device (501);
- obtain the signed hash value (103) from the trusted device (100); and
- verify authenticity of the trusted device (100), based on the numerical value (101) and based on the signed hash value (103).
9. The system (400) according to claim 8, wherein the system (400) further comprises the user device (501), wherein the user device (501) is configured to calculate the numerical value (101), to obtain the program code (102), to provide the numerical value (101) and the program code (102) to the trusted device (100), and to provide the numerical value (101) to the verification device (401).
10. The system (400) according to claim 8 or 9, wherein the user device (501) is further configured to obtain the signed hash value (103) from the trusted device (100), and forward the signed hash value (103) to the verification device (401).
11. The system (400) according to any one of claims 8 to 10, wherein the user device (501) is further configured to calculate and store a hash value (502) of the program code (102) before providing the program code (102) to the trusted device (100).
12. The system (400) according to claim 11, wherein the user device (501) is further configured to compare the stored hash value (502) of the program code (102) and a hash value calculated based on the program code (102) loaded to the trusted processor (201), to verify that the program code (102) provided by the user device (501) is the program code (102) loaded to the trusted processor (201).
13. The system (400) according to any one of claims 8 to 12, wherein the verification device (401) is further configured to verify that the program code (102) that is executed by the trusted device (100) is the program coded (102) that was provided by the user device (501), to verify the authenticity of the trusted device (100).
14. The system (400) according to any one of claims 8 to 13, wherein the verification device (401) is further configured to verify one or more of the following to verify the authenticity of the trusted device (100): an identity of the trusted device (100), a vendor of the trusted device (100).
15. The system (400) according to any one of claims 8 to 14, wherein the verification device (401) is further configured to verify the authenticity of the trusted device (100) based on a public key corresponding to the private key (203) of the trusted device (100).
16. The system (400) according to any one of claims 8 to 15, wherein the verification device (401) is further configured to provide a result of verification of authenticity of the trusted device (100) to the user device (501).
17. A method (800) for operating a trusted device (100), wherein the method (800) comprises the steps of:
- obtaining (801), by the trusted device (100), a numerical value (101) and program code (102) from a user device (501);
- calculating (802), by the trusted device (100), a hash value (103) based on the numerical value (101) and based on the program code (102);
- signing (803), by the trusted device (100), the hash value (103); and
- providing (804), by the trusted device (100), the signed hash value (103) to a verification device (401).
18. A method (900) for operating a trusted computing system (400) comprising a trusted device (100) and a verification device (401), wherein the method (900) comprises the steps of:
- obtaining (901), by the trusted device (100), a numerical value (101) and program code (102) from a user device (501);
- calculating (902), by the trusted device (100), a hash value (103) based on the numerical value (101) and based on the program code (102);
- signing (903), by the trusted device (100), the hash value (103); and
- providing (904), by the trusted device (100), the signed hash value (103) to the verification device (401);
- obtaining (905), by the verification device (401), the numerical value (101) from the user device (501);
- obtaining (906), by the verification device (401), the signed hash value (103) from the trusted device (100); and
- verifying (907), by the verification device (401), authenticity of the trusted device (100), based on the numerical value (101) and based on the signed hash value (103).
19. A computer program product comprising program code configured to perform the method (800) according to claim 17 when the computer program is executed on a computer.
20. A computer program product comprising program code configured to perform the method (900) according to claim 18 when the computer program is executed on a computer.
PCT/EP2019/072849 2019-08-27 2019-08-27 Trusted device and computing system WO2021037344A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/EP2019/072849 WO2021037344A1 (en) 2019-08-27 2019-08-27 Trusted device and computing system
EP19759378.3A EP3980911A1 (en) 2019-08-27 2019-08-27 Trusted device and computing system
CN201980097445.7A CN113966510A (en) 2019-08-27 2019-08-27 Trusted device and computing system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2019/072849 WO2021037344A1 (en) 2019-08-27 2019-08-27 Trusted device and computing system

Publications (1)

Publication Number Publication Date
WO2021037344A1 true WO2021037344A1 (en) 2021-03-04

Family

ID=67770525

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2019/072849 WO2021037344A1 (en) 2019-08-27 2019-08-27 Trusted device and computing system

Country Status (3)

Country Link
EP (1) EP3980911A1 (en)
CN (1) CN113966510A (en)
WO (1) WO2021037344A1 (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080320308A1 (en) * 2007-06-20 2008-12-25 Nokia Corporation Method for remote message attestation in a communication system
EP2372592A1 (en) * 2009-12-14 2011-10-05 Nxp B.V. integrated circuit and system for installing computer code thereon
US20140108784A1 (en) * 2012-10-12 2014-04-17 International Business Machines Corporation Reducing noise in a shared media sesssion
US20150271152A1 (en) * 2010-03-25 2015-09-24 Virtustream Canada Holdings, Inc. System and method for secure cloud computing

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080320308A1 (en) * 2007-06-20 2008-12-25 Nokia Corporation Method for remote message attestation in a communication system
EP2372592A1 (en) * 2009-12-14 2011-10-05 Nxp B.V. integrated circuit and system for installing computer code thereon
US20150271152A1 (en) * 2010-03-25 2015-09-24 Virtustream Canada Holdings, Inc. System and method for secure cloud computing
US20140108784A1 (en) * 2012-10-12 2014-04-17 International Business Machines Corporation Reducing noise in a shared media sesssion

Also Published As

Publication number Publication date
CN113966510A (en) 2022-01-21
EP3980911A1 (en) 2022-04-13

Similar Documents

Publication Publication Date Title
US11809545B2 (en) Flexible container attestation
JP7416775B2 (en) Peripheral device
US11843705B2 (en) Dynamic certificate management as part of a distributed authentication system
US10019601B2 (en) Method and apparatus for securely saving and restoring the state of a computing platform
EP3275159B1 (en) Technologies for secure server access using a trusted license agent
JP5526450B2 (en) Method for changing hardware configuration, method for enabling hardware configuration change at a remote location, and apparatus therefor
US10771264B2 (en) Securing firmware
US8826391B2 (en) Virtualized trusted descriptors
JP6371919B2 (en) Secure software authentication and verification
US20080134321A1 (en) Tamper-resistant method and apparatus for verification and measurement of host agent dynamic data updates
US20180373863A1 (en) Remote attestation for multi-core processor
WO2018086469A1 (en) Data storage method utilized in non-volatile storage space in integrated circuit, and trusted integrated circuit
US11575672B2 (en) Secure accelerator device pairing for trusted accelerator-to-accelerator communication
TWI745629B (en) Computer system and method for initializing computer system
EP3757838B1 (en) Warm boot attack mitigations for non-volatile memory modules
US11909882B2 (en) Systems and methods to cryptographically verify an identity of an information handling system
US20230237155A1 (en) Securing communications with security processors using platform keys
CN116049825A (en) Managing storage of secrets in memory of baseboard management controller
WO2021037344A1 (en) Trusted device and computing system
US20060020785A1 (en) Secure distribution of a video card public key
US10938857B2 (en) Management of a distributed universally secure execution environment
CN112269980A (en) Processor architecture
CN111357003A (en) Data protection in a pre-operating system environment
US20230106491A1 (en) Security dominion of computing device
CN113496036A (en) Security component and preloading method

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19759378

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019759378

Country of ref document: EP

Effective date: 20220104

NENP Non-entry into the national phase

Ref country code: DE