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.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Hardware Design (AREA)
• General Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Software Systems (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Computing Systems (AREA)
• Storage Device Security (AREA)

Applications Claiming Priority (1)

Publications (1)

Family

ID=67770525

Family Applications (1)

Country Status (3)

Families Citing this family (1)

Family Cites Families (4)

• 2019
  • 2019-08-27 WO PCT/EP2019/072849 patent/WO2021037344A1/en unknown
  • 2019-08-27 EP EP19759378.3A patent/EP3980911A1/en active Pending
  • 2019-08-27 CN CN201980097445.7A patent/CN113966510A/zh active Pending

Also Published As

Similar Documents

Legal Events