Device Proof Technology

Abstract

The present invention relates to device attestation technology. A method for providing attestation for enabling a device to attest an assertion about the device comprises: generating an attestation identifier and a base password corresponding to the attestation identifier; providing the attestation identifier and a verification password to a verification device for storage in combination with the assertion, wherein the verification password is based on the base password; providing the attestation identifier and a device password to a manufacturer or adapter for providing to the device, wherein the device password is based on the base password.

Description

Technical Field

[0001] The present technology relates to the field of electronic devices. More specifically, the present technology relates to providing an attestation for enabling a device to attest an assertion about the device. Background Art

[0002] Increasingly, electronic devices are used to access services that may involve the processing of potentially sensitive information, such as mobile banking, access to health services, or the processing of employment details. In addition, with the continued development of the Internet of Things (IoT), it is becoming more common to control systems such as heating, air conditioning, or street lighting based on information provided by electronic devices, which may provide sensor information such as temperature data or proximity information indicating whether a user is present. In these scenarios, it may be important for a service provider to be able to verify that an electronic device meets certain requirements in order to trust the security of interactions with the electronic device. The service provider may need to be assured that certain events have occurred during the manufacturing process for manufacturing the electronic device or in subsequent adaptations of the device during its life cycle. For example, such events can include a system on a chip being embedded into a component by a device manufacturer, a device undergoing a certain quality assurance step, or providing a certain specific software on the device.

[0003] Cryptographic techniques can be provided that store detailed attestation information on the device that allows an external entity to verify that such an event has occurred. However, such techniques typically require storing a large amount of information on the device itself. In very small computing devices such as sensors, actuators, or other devices in the IoT, memory storage capacity, processing power, and communication bandwidth may be extremely constrained, making such approaches infeasible. In addition, storing such information on the device may allow for the possibility of extracting the information and copying it to another device to create a "fake" device, which can falsely prove that the fake device has experienced the proven event.

[0004] At least some embodiments of the present disclosure address one or more of these issues as stated above. Summary of the invention

[0005] Particular aspects and embodiments are set out in the following claims.

[0006] From one perspective, a method for providing proof to enable a device to prove an assertion about the device can be provided, comprising: generating a proof identifier and a base password corresponding to the proof identifier; providing the proof identifier and verification password to a verification device for storage in conjunction with the assertion, wherein the verification password is based on the base password; providing the proof identifier and device password to a manufacturer or adapter for providing to the device, wherein the device password is based on the base password.

[0007] Providing different passwords to different entities mitigates the risk that a password can be extracted from one entity and used to create a counterfeit version of another entity. For example, extracting the verification password from the verification device may not allow for determining what device password was provided to the manufacturer or adapter, thereby mitigating the impact of data stolen from the verification device. In addition, the method allows the assertion itself to be stored away from the device, thereby saving storage space on the device. In some embodiments, a proof generator is used to generate a proof identifier. The proof generator can be a device that is physically separate from the verification device, or the proof generator and the verification device can both be located in the same physical device. In some embodiments, the proof generator generates the device password and / or the verification password.

[0008] In some examples, the attestation identifier and the device password are provided to the device by the manufacturer or adapter. Thus, the device password is distributed to the device under the control of the manufacturer or adapter. Thus, this distribution can be done without directly including or providing information about the distribution to the verification device or device (e.g., attestation generator) that generates the attestation identifier and base password.

[0009] In some examples, the device password is the same as the base password. Therefore, the need for additional processing to generate the device password can be avoided.

[0010] In some examples, the base password is not provided to the verification device. Therefore, because the verification device does not have access to the base password, stealing information from the verification device will not allow a malicious entity to generate a device password (which is based on the base password) and therefore cannot use this information to create a counterfeit device.

[0011] In some embodiments, the verification password is generated by hashing the base password using a first predetermined hash function. Thus, by using a one-way function (e.g., a hash function) to generate the verification password, it is generally not possible to invert the hash function to generate the base password from the verification password. In some embodiments, this generation of the verification password is performed by the proof generator before providing the verification password to the verification device. In other embodiments, the base password is provided to the proof generator and the proof generator generates the verification password itself.

[0012] In some examples, the device password is the same as the base password, and in response to providing the attestation identifier and the device password to the device, the device hashes the device password using a first predetermined hash function to generate the verification password. Thus, by generating the derived password (the verification password) on the device by using a one-way function (e.g., a hash function), the base password / device password does not need to be stored on the device, and thus stealing information from the device will not allow a malicious party to provide the base password / device password to a second device and thereby create a counterfeit device.

[0013] In some examples, the device further uses a second predetermined hash function to hash the verification password in combination with one or more items of locally available information to generate a hash value. Therefore, the device generates another derived password (hash value) that can only be generated using locally available information. This therefore means that the hash value can only be generated by a device that can access the locally available information of the device, thereby limiting the devices that can generate the hash value. For the purpose of verification (e.g., performed at the verification device), the verification entity only needs to be able to access the locally available information at the time of verification. In other words, the device can keep the locally available information confidential until this moment. In addition, this means that the device does not need to store the verification password, so stealing information from the device will not allow the verification of the certificate of the relevant device.

[0014] In some examples, the first predetermined hash function and the second predetermined hash function use the same calculation function but operate on different data inputs. Thus, only a single calculated hash function needs to be stored on the device, thereby saving space and, generally, allowing further hardware / software optimization of the performance of the hash function.

[0015] In some examples, one or more items of information locally available when the attestation identifier and the device password are an initial attestation identifier and an initial device password provided to the device include a device identifier, and one or more items of information locally stored when the attestation identifier and the device password are not the initial attestation identifier and an initial device password provided to the device include a previous hash value.

[0016] Thus, using the second predetermined hash function on the initial attestation identifier / device password generates a hash value bound to the device itself using the device's identifier. Further, by using the previous hash value when using the second predetermined hash function on the attestation identifier / device password subsequent to the initial attestation identifier / device password, the additional hash value generated will be based in part on the previous hash value(s).

[0017] Thus, the further hash value serves as a "digest" of all previous hash values ​​that were directly or indirectly input (i.e., a chain of previous hash values ​​corresponding to a plurality of previous attestation identifiers and device passwords in which the second predetermined hash function has been iteratively applied). Thus, the "digest" can be used in verifying attestations corresponding to all attestation identifiers / device passwords that participated in making the "digest" without the need to store all intermediate hash values ​​on the device.

[0018] In some examples, the previous hash value is the most recent previous hash value. Thus, the second predetermined hash function is iteratively applied to all previous hash values ​​so that the final hash value can be used when verifying attestations corresponding to all attestation identifiers / device passwords that have been received by the device.

[0019] In some examples, the device stores the hash value after it is generated, but does not store the device password or verification password. Therefore, even if a malicious party gains access to the information stored on the device, the stolen information will not allow the malicious party to create a counterfeit device or verify the certificate about the device.

[0020] In some examples, the device stores only the most recent hash value. Because the most recent hash value serves as a "digest" of all previous hash values, the storage of the most recent hash value is sufficient to verify the proof corresponding to each of the previous hash values ​​without consuming storage on the device by storing the previous hash values ​​themselves.

[0021] In some examples, the device further hashes the verification password in combination with the certification identifier to generate a hash value.Thus, by including more elements as inputs to the hash, security is enhanced by making the hash more difficult to reverse.

[0022] In some examples, the attestation identifier is stored after the device hash value is generated. Thus, the device itself can directly provide information that identifies which attestation or attestations the hash value corresponds to and, in some embodiments, is necessary to verify the attestation(s).

[0023] In some examples, one or more items of locally available information also include metadata. Thus, security can be enhanced by including more elements as inputs to the hash, making the hash more difficult to reverse. In addition, metadata can establish that specific information (e.g., information about the internal state of the device, information payload, information received by the device from an external source) is available to the device when the hash value is generated. In some embodiments, metadata may include some or all of the code present on the device and one or more public keys stored on the device. Additionally or alternatively, metadata may include information related to the state of the device software (e.g., software name, version, hash / public key used to sign the software), the time / date when the hash value was generated, the (one or more) human / machine operations involved, or the geographic location where the (one or more) operations occurred.

[0024] In some examples, the device stores the metadata after the hash value is generated. Thus, the device itself can directly provide the metadata that is necessary to verify the certificate(s) in some embodiments.

[0025] From one perspective, a method for a verification device to verify a proof of an assertion of an attestation from a device about the device may be provided, comprising: obtaining one or more entries from an attestation database, each entry comprising an attestation identifier, a verification password, and an assertion; obtaining one or more attestation identifiers and a hash value from the device; performing a verification operation on the one or more attestation identifiers obtained from the device together with the corresponding verification password obtained from the attestation database to verify the hash value obtained from the device; determining whether the one or more assertions associated with the one or more attestation identifiers obtained from the device are valid for the device based on the verification result of the verification operation. In other words, in some embodiments, the device only provides the verification device with one or more attestation identifiers and a hash value but does not provide the assertion itself (i.e., the actual semantic meaning of the attestation) retrieved from a separate attestation database. It is also explicitly contemplated that in some embodiments the assertion may additionally or alternatively be stored on the device itself.

[0026] By obtaining the proof identifier from both the proof database and the device, the hash value from the device can be matched with the verification password and the proof received from the proof device, and the verification device can verify whether various proofs about the device are correct without the need for the device itself to store the verification password or assertion, thereby saving space. This further reduces the risk of stealing information from the device or the proof database because neither entity stores information that would allow the creation of a counterfeit device alone or in combination. Further, in order to verify the proof, information must be obtained from both the device and the proof database. In some embodiments, the proof database is located on the same physical device and / or is part of the verification device. In other embodiments, the proof database is located on a physical device separate from the verification device.

[0027] In some examples, a device identifier is further obtained from the device, and wherein a verification operation is further performed on the device identifier. Thus, it can be determined that the assertion is valid specifically with respect to a specific device identifier, wherein typically at least the manufacturer / adapter knows which physical device the device identifier belongs to.

[0028] In some examples, metadata is further obtained from the device, and wherein a verification operation is further performed on the metadata. Thus, as part of the verification process, the verification device may prove that the metadata was known when the hash value was generated. Additionally or alternatively, metadata may be obtained from the device to prove that the metadata was known when the attempt to verify the attestation from the device was made.

[0029] In some examples, the verification operation includes at least one hash function for each attestation identifier obtained from the device, and wherein each hash function iteratively acts on the result of a previous hash function, wherein each successive hash function takes as input at least an attestation identifier that was not previously used as input in the previous hash function. Thus, as a result of the hash functions being computationally related to each other by taking the result(s) of the previous hash function(s), it can be verified that the plurality of attestations have been generated in a specific order.

[0030] In some examples, multiple attestation identifiers are obtained from the device and only one hash value corresponding to a most recent hash value is obtained from the device, and whether all or none of the multiple assertions associated with the multiple attestation identifiers obtained from the device are valid for the device is determined based on a verification result through a verification operation. Thus, multiple assertions can be verified while only having to receive a single hash value from the device, thereby saving communication bandwidth and the need for the device to store more than a single most recent hash value.

[0031] In some examples, multiple proof identifiers are obtained from the device and multiple hash values ​​are obtained from the device, and the verification operation includes multiple verification operations, thereby determining whether a subset of the multiple assertions associated with the multiple proof identifiers obtained from the device is valid based on the verification results of the multiple verification operations. Therefore, by receiving multiple hash values, the verification device is able to verify subsets of assertions separately, so that, in the case of negative verification, it is possible to at least partially identify which specific subset of (one or more) assertions is false. Therefore, for example, the source of the false assertions can be narrowed down (for example, to a specific interactive device or entity). For example, in some examples, a hash value can be obtained for every two, three, or four proof identifiers.

[0032] In some examples, the verification device obtains multiple verification passwords and assertions associated with a specific proof identifier from a proof database, and when the specific proof identifier is obtained from the device, each possible verification password is used to attempt a verification operation. Therefore, by using non-unique proof identifiers, shorter proof identifiers can be used (thereby saving storage space on the device) while still allowing the proof to be verified in a reasonable time. For example, if there are three verification passwords and three assertions for each proof identifier, the worst case verification operation needs to be attempted three times to determine whether any assertion is valid. However, if the first assertion tested is shown to be valid, then in some examples, the verification operation will not check the second and third assertions.

[0033] From one perspective, a method may be provided for a device to store information on the device that enables the device to prove assertions about the device, comprising: receiving a base password and a corresponding proof identifier at the device; hashing the base password at the device using a first predetermined hash function to generate a verification password; hashing the verification password at the device using a second predetermined hash function in combination with one or more items of locally available information to generate a hash value using the second predetermined hash function; wherein the device stores the hash value after the hash value is generated.

[0034] By performing two hashes at the device to generate the stored hash value, the device does not need to store the base password or the verification password. This therefore allows the device to save space but also resist copying because if the hash value is stolen from the device (for example, because only the hash value is stored on the device), then a counterfeit device cannot be created. The inability to create a counterfeit is because the base password cannot generally be recreated from the hash value because the two hash operations performed by the device are one-way operations, so the base password cannot be provided to a second device to create a counterfeit.

[0035] From one perspective, a computer program may be provided, the computer program being used to control a device to perform any of the above methods. In some examples, the computer program is stored on a storage medium.

[0036] From one perspective, there may be provided an apparatus comprising: a processing circuit for performing data processing; and a data storage device storing a computer program for controlling the processing circuit to perform any one of the above methods.

[0037] Other aspects will become apparent after reviewing the present disclosure, particularly after reviewing the drawings, detailed description and claims section. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Examples of the present disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0039] Figure 1 : Schematically illustrates an example system for implementing examples of the present disclosure.

[0040] Figure 2 : schematically illustrates a method for providing proof to enable a device to prove assertions about the device.

[0041] Figure 3 : Schematically illustrates a method for verifying an apparatus to verify a proof from a device of an assertion about the device.

[0042] Figure 4 : Schematically illustrates example information content of a proof database.

[0043] Figure 5 : Schematically illustrates a method for a device to store information on the device that enables the device to prove assertions about the device.

[0044] Figure 6 : Schematically illustrates an example of an electronic device.

[0045] Although the present disclosure allows various modifications and alternative forms, specific example methods are shown as examples in the drawings and described in detail herein. However, it should be understood that the drawings and the accompanying detailed description are not intended to limit the present disclosure to the specific forms disclosed, but on the contrary, the present disclosure will cover all modifications, equivalents and alternatives that fall within the spirit and scope of the claimed invention.

[0046] It will be appreciated that features of the above-described examples of the present disclosure may be used conveniently and interchangeably in any suitable combination. DETAILED DESCRIPTION

[0047] Figure 1A schematic diagram of a system 100 for implementing an example of the present disclosure is shown. The system includes a proof generator 110, a manufacturer / adapter 120, a device 130, a verification device 140, and a proof database 150. Each of these elements can be used as Figure 6 The electronic device stated in and the corresponding description below are implemented.

[0048] exist Figure 1 Additionally, many example links between various elements are shown. These links represent communication channels between the elements. These communication channels can use wired electrical connections (e.g., Ethernet), wired optical connections (e.g., fiber optic cables), wireless radio connections (e.g., ) or using any other suitable technique that allows elements to transfer data.

[0049] Although many principle links have been shown, other links may also exist in some examples. For example, the manufacturer / adapter 120 may have a direct link to the proof database 150, or the proof generator 110 may be directly linked to the device 130. It should also be appreciated that not all of the links shown may exist in some examples. For example, a link between the device 130 and the verification device 140 may not exist, but instead the device 130 may communicate with the verification device 140 via the manufacturer / adapter 120 and the proof generator 110.

[0050] It should also be appreciated that in some examples not all links may be permanent, but may instead be temporary or periodic. For example, the manufacturer / adapter 120 may only be connected to the device 130 during manufacturing or adaptation, and as another example the connection between the device 130 and the verification device 140 may only be available specifically while the device is being verified.

[0051] The attestation generator 110 is responsible for the generation of attestation identifier(s) and corresponding base password(s).In some examples, the attestation generator is a centralized server controlled by a first party that controls the attestation process overall.

[0052] The manufacturer / adapter 120 is the entity responsible for providing the certification identifier(s) and the corresponding base password(s) to the device 130. In some examples, the manufacturer / adapter 120 corresponds to a manufacturing, assembly, or adaptation device controlled by a second party that is at least partially responsible for producing the finished device 130.

[0053] Device 130 is an entity that is performing proof of assertions about the device. In some examples, the device corresponds to an Internet of Things (IoT) device. Such IoT devices are typically very small computing devices, such as sensors, actuators, or other devices in the IoT, whose storage capacity, processing power, and communication bandwidth may be extremely constrained.

[0054] Verification device 140 is an entity that acts to verify whether the assertion about the device is valid. In some examples, the verification device is a server controlled by a first party (ie, the same party as the proof generator). In some examples, the verification device is a cloud-hosted web service.

[0055] The attestation database 150 is an entity that stores information linking attestation identifiers to assertions and passwords used when verifying assertions about devices. In some examples, the attestation database is located on the same physical device and / or is part of the verification device. In other examples, the attestation database is located on a physical device separate from the verification device and is connected via a communication channel (link).

[0056] In addition to selecting the location of the proof database, other elements can also be combined. In some examples, the elements can be implemented as software or hardware modules of a larger entity. For example, the proof generator 110 and the verification device 140 can be located on the same physical / logical device. As another example, the manufacturer / adapter 120 and the verification device 140 can be located on the same physical / logical device.

[0057] It should also be appreciated that the system 100 may include a plurality of various elements. For example, the system 100 may function on a plurality of devices 130 such that each device may cause assertions about itself to be verified. As another example, the system 100 may include a plurality of manufacturers / adapters 120 that may all function on a single device 130 or may each function on a different device 130.

[0058] Figure 2 A schematic illustration of a method 200 for providing attestation to enable a device 130 to attest to assertions about the device 130 is shown, the method 200 comprising the following steps.

[0059] At step S210 , a proof identifier and a base password corresponding to the proof identifier are generated. In a specific example, the generation is performed by the proof generator 110 .

[0060] At step S220, the proof identifier and the verification password are provided to the verification device 140, the verification password being based on the base password. In a specific example, the proof identifier and the verification password are provided by the proof generator 110. In some examples, the base password is not provided to the verification device 140.

[0061] In some examples, the verification password is generated by hashing the base password using a first predetermined hash function. The first predetermined hash function can be a cryptographic hash function to further enhance the security of the "one-way" function. Examples of suitable hash algorithms include MD5, SHA family (e.g., SHA-256), or any other suitable hash algorithm. It is also explicitly contemplated that in some examples the first predetermined hash function can be a non-cryptographic hash function such as a cyclic redundancy check. In some examples, a verification password is generated at the proof generator 110 and sent to the verification device 140 so that the verification device 140 is never able to access the base password. In other examples, the base password is sent to the verification device 140, which performs a hash using the first hash algorithm to derive the verification password.

[0062] At step S230, the attestation identifier and the device password are provided to the manufacturer or adapter 120 for provision to the device 130. In certain examples, the attestation identifier and the device password are provided by the attestation generator 110. In some examples, the device password is the same as the base password.

[0063] At step S240, the attestation identifier and the device password are provided to the device 130 by the manufacturer or adapter 120. In some examples, the device password is the same as the base password, and wherein, in response to providing the attestation identifier and the device password to the device 130, the device 130 hashes the device password using a first predetermined hash function to generate a verification password. This first predetermined hash function is the same as the hash function used to provide the verification password to the verification device 140, so that the verification device 140 and the device 130 both end up with a copy of the same verification password without distributing this code to both devices.

[0064] In some examples, the device then further hashes the verification password using a second predetermined hash function in combination with one or more items of locally available information to generate a hash value. The second predetermined hash function can be the same computational function (e.g., SHA-256) as that used for the first predetermined hash function but simply operating on different inputs.

[0065] In some examples, device 130 may use different locally available information depending on whether the attestation identifier and device password it receives is the initial (i.e., first) such attestation identifier and device password received or a subsequently received attestation identifier and device password. In a certain example, when the attestation identifier and device password are the initial attestation identifier and initial device password provided to device 130, one or more items of locally available information include the device identifier, and when the attestation identifier and device password are not the initial attestation identifier and initial device password provided to device 130, one or more items of locally stored information include a previous hash value. In other words, the second predetermined hash function is iteratively applied whenever a new attestation identifier and device password are received taking a previous hash value of a previous iteration of the second predetermined hash function. This can be considered to make the final hash value a "digest" of at least some of the previous hash values ​​and therefore a "digest" of its corresponding attestation identifier and device password that participated in generating these previous hash values. In some examples, the previous hash value is a previous hash value such that the final hash value serves as a digest of all hash values ​​generated on device 130 through this iterative operation. In some examples, after any given hash value is generated, the hash value is stored by device 130, but the corresponding device password and verification password are discarded so that they are not stored on device 130. Further, in some examples, only the most recent hash value is stored, while all previous hash values ​​are discarded after the most recent hash value is generated. As previously described, since the most recent hash value can serve as a summary of all previous hash values, the validity of all previous hash values ​​can still be checked even if the hash value itself has been discarded.

[0066] In some examples, other items of data may be included as inputs to the hash function to further enhance its security. For example, in some examples the second predetermined hash function may additionally take a proof identifier and / or metadata (e.g., information about the internal state of the device, information payload, information received by the device from an external source) as input. In some examples, the metadata may include some or all of the code present on the device and one or more public keys stored on the device. Additionally or alternatively, the metadata may include information related to the state of the device software (e.g., software name, version, hash / public key used to sign the software), the time / date when the hash value was generated, the (one or more) human / machine operations involved, or the geographic location where the (one or more) operations occurred. When these additional inputs are used, they may also be stored on the device 130 after the hash values ​​have been generated.

[0067] It should be appreciated that although the method steps have been depicted in a particular order, it is explicitly contemplated that the steps may be performed in any suitable order. For example, step S230 may be performed before step S220, and step S240 may be performed at any time after step S230 has been performed.

[0068] Figure 3 A schematic illustration of a method 300 for verifying an apparatus 140 for verifying an attestation from a device 130 attesting an assertion about the device 130 is shown, said method 300 comprising the following steps.

[0069] At step S310, the verification device 140 obtains one or more entries from the certification database 150, each entry including a certification identifier, a verification password, and an assertion. In some examples, multiple verification passwords and assertions associated with a specific certification identifier are obtained by the verification device 140 from the certification database 150. In other words, the certification identifier may not uniquely identify a specific verification password and assertion.

[0070] At step S320, verification device 140 obtains one or more certification identifiers and hash values ​​from device 130. In some examples, a device identifier and / or metadata is also obtained from the device. Additionally or alternatively, in some examples, multiple certification identifiers are obtained from the device but only one hash value corresponding to the most recent hash value is obtained from device 130. In other examples, multiple certification identifiers are obtained from the device and multiple hash values ​​are obtained from the device.

[0071] At step 330, verification device 140 performs a verification operation on one or more certification identifiers obtained from device 130 together with the corresponding verification password obtained from certification database 150 to verify the hash value obtained from device 130. In some examples, when a device identifier and / or metadata is also obtained from the device, a verification operation is further performed on the device identifier and / or metadata.

[0072] In some examples, the verification operation includes at least one hash function for each attestation identifier obtained from device 130. Each hash function iteratively acts on the result of the previous hash function, wherein each successive hash function takes as input at least an attestation identifier that was not previously used as input in the previous hash function. In other words, for example, where a hash value received by verification apparatus 140 is generated by iterative operations performed on device 130 (i.e., where the sent hash value has been generated on device 130 based in part on one or more previous hash values), the verification operation can iteratively act on this "digest" hash value to successively verify each "layer" of received hash values ​​and thereby ultimately verify the entire chain of hash values.

[0073] In some examples, when multiple attestation identifiers are obtained from a device and only one hash value corresponding to a most recent hash value is obtained from the device, a verification operation determines whether all or none of the multiple assertions associated with the multiple attestation identifiers obtained from the device are valid about the device based on a verification result of the verification operation.

[0074] In other examples, when multiple attestation identifiers are obtained from a device and multiple hash values ​​are obtained from the device, the verification operation includes multiple separate verification operations, thereby determining whether a subset of the multiple assertions associated with the multiple attestation identifiers obtained from the device are valid based on the verification results of the multiple verification operations.

[0075] In another example, where the verification device 140 obtains multiple verification passwords and assertions associated with a specific proof identifier from the proof database 150, the verification operation is attempted with each possible verification password with respect to the proof identifier obtained from the device. In other words, the verification operation is attempted for each possible verification password associated with the non-unique proof identifier.

[0076] At step 340 , verification apparatus 140 determines whether one or more assertions associated with one or more attestation identifiers obtained from device 130 are valid with respect to device 130 based on the verification result of the verification operation.

[0077] It should be appreciated that although the method steps have been depicted in a particular order, it is explicitly contemplated that the steps may be performed in any suitable order. For example, step S320 may be performed before step S310.

[0078] Figure 4 Schematically illustrates example information content 400 of a certification database 150. In the particular example depicted, five fields are shown: a certification identifier, a verification password, an assertion, additional field 1, and additional field 2. Three example entries are shown. The first row has a certification identifier of 1001, a verification password of AB47EF89, and an assertion of device attribute 1 (e.g., having a secure area 630 of a data storage device 620). The second row has a certification identifier of 1002, a verification password of 749DABE6, and an assertion of event 1 (e.g., having a communication I / F 640 installed by a specific manufacturer / adapter 120). The third row has a certification identifier of 1003, a verification password of BF56DEF0, and an assertion of quality assurance 1 (e.g., the integrity of the OS stored in the data storage device 620 has been verified).

[0079] In addition, each row has two additional fields 1 and 2. These may contain any additional information desired, such as the specific manufacturer / adapter to which a particular attestation identifier has been assigned twice or the number of times a request to verify a particular assertion has been made. It is contemplated that essentially any desired information can be stored in these fields. In some examples, the field(s) may include identifiers of one or more devices (e.g., device identifiers) that have previously seen an attestation and where the field(s) are updated during verification of the attestation.

[0080] As described above, this example information content 400 of the proof database 150 is only one possible format. For example, the information content can have fewer or greater numbers of rows and columns. For example, the information content can have zero, one, three, four, or five additional fields. The information content can have substantially any number of rows as desired. It should be further explicitly recognized that the specific format shown for entries for proof identifiers, verification passwords, and assertions is only an example format. For example, proof identifiers and verification passwords can include a greater or lesser number of symbols, and these symbols can, for example, consist of decimal numbers, hexadecimal numbers, or ASCII character sets.

[0081] Figure 5 A schematic diagram of a method 500 for a device 130 to store information on the device 130 that enables the device 130 to prove assertions about the device 130 is shown, the method 500 comprising the following steps.

[0082] At step S510 , a base password and a corresponding attestation identifier are received at device 130 .

[0083] At step S520 , the base password is hashed using a first predetermined hash function at the device 130 to generate a verification password.

[0084] At step S530, the verification password is hashed at the device using a second predetermined hash function in combination with one or more items of locally available information to generate a hash value.

[0085] At step S540 , the hash value is stored on the device 130 .

[0086] Figure 6An example of an electronic device 600 is schematically illustrated. The device has a processing circuit 610 for performing data processing in response to program instructions, and a data storage device 620 for storing data and instructions to be processed by the processing circuit 610. The data storage device 620 may have a secure area 630 protected by a hardware mechanism (e.g., using a memory protection unit or security mechanism that provides a trusted execution environment) or by a software mechanism (e.g., encryption), so that the data stored in the secure area 630 is inaccessible to software that is not executed in a trusted environment. The device 600 has a communication interface 640 for communicating with an external device. For example, the communication interface 640 can use any other range of different communication protocols, such as Ethernet, The device may have one or more sensors 650 for sensing certain external conditions such as temperature, pressure, proximity of a nearby user. The specific sensors 650 provided may depend on the purpose of the device. It should be appreciated that Figure 6 These are merely examples of possible hardware that may be provided in a device, and other components may also be provided. For example, some devices that expect user interaction may be provided with a display and / or user interface module to display information to the user and receive input from the user. Other types of devices may simply be sensors that capture data and send the data to an external device, so these types of devices may not require a user interface or display. It should be appreciated that when any one of the proof generator 110, the manufacturer / adapter 120, the verification device 140, or the proof database 150 is implemented compared to when the device 130 is implemented, the processing circuitry may be more powerful and the data storage device may be larger for the electronic device 600.

[0087] The methods discussed above may be performed under the control of a computer program executed on the device. The computer program may thus include instructions for controlling the device to perform any of the methods discussed above (including methods performed on any of the attestation generator 110, the manufacturer / adapter 120, the device 130, the verification device 140, and the attestation database 150). The program may be stored on a storage medium. The storage medium may be a non-transitory recording medium or a transient signal medium.

[0088] In this application, the words "configured to..." are used to mean that elements of a device have a configuration that is capable of performing a defined operation. In this context, "configuration" means the arrangement or manner of interconnection of hardware or software. For example, a device may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to" does not imply that the device elements need to be changed in any way in order to provide the defined operation.

[0089] Although illustrative teachings of the present disclosure have been described in detail herein with reference to the accompanying drawings, it should be understood that the invention is not limited to those precise teachings and that various changes and modifications may be made therein by those skilled in the art without departing from the scope and spirit of the invention as defined by the appended claims.

Claims

1. A method for providing an attestation for enabling a device to attest to an assertion about the device, comprising: generating a certification identifier and a base password corresponding to the certification identifier; providing the certification identifier and verification password to a verification device for storage in conjunction with the assertion, Wherein, the verification password is based on the basic password; providing the certification identifier and device password to a manufacturer or adapter for provision to the device, Wherein, the device password is based on the basic password, The verification password is generated by hashing the basic password using a first predetermined hash function. wherein the device password is the same as the base password, and wherein, in response to providing the attestation identifier and the device password to the device, the device hashes the device password using the first predetermined hash function to generate the verification password; and The device further uses a second predetermined hash function to hash the verification password in combination with one or more items of locally available information to generate a hash value.

2. The method according to claim 1, wherein: The basic password is not provided to the verification device.

3. The method according to claim 1, wherein: The first predetermined hash function and the second predetermined hash function use the same calculation function but operate on different data inputs.

4. The method according to claim 1, wherein: When the attestation identifier and the device password are an initial attestation identifier and an initial device password provided to the device, the one or more items of locally available information include a device identifier, And wherein, when the attestation identifier and device password are not an initial attestation identifier and initial device password provided to the device, the one or more items of locally stored information include a previous hash value.

5. The method according to claim 4, wherein: The previous hash value is the most recent previous hash value.

6. The method according to claim 4 or claim 5, wherein: The device stores the hash value after the hash value is generated, but does not store the device password or the verification password.

7. The method according to claim 6, wherein: The device only stores the most recent hash value.

8. The method according to any one of claims 1 to 5, wherein: The device further hashes the verification password in combination with the certification identifier to generate the hash value.

9. The method according to claim 8, wherein: The device stores the attestation identifier after the hash value is generated.

10. The method according to any one of claims 1 to 5, wherein: The one or more items of locally available information also include metadata.

11. The method according to claim 10, wherein: The device stores the metadata after the hash value is generated.

12. A computer program product for controlling a device to perform the method according to any one of claims 1 to 11.

13. A storage medium storing a computer program for executing the method according to any one of claims 1 to 11.

14. A device, comprising: a processing circuit for performing data processing; as well as Data storage means storing a computer program for controlling the processing circuit to perform the method according to any one of claims 1 to 11.

Images