Integrity check of software by using randomized software

Abstract

Embodiments of the invention relate to a method for integrity check of a software by using a randomized version of the software. In this respect, an attestation service (100) transmits an attestation token (520) to a verification service (300), the attestation token (520) comprising: a first integrity value (VI) for a software, a random seed, and a randomization generator function. The verification service (300) determines a second integrity value (V2) for the software (710) based on a randomized software (710') which is obtained based on the random seed put into the randomization generator function. Based on the first integrity value (VI) and the second integrity value (V2) an appraisal of the software (710) is determined which is sent to the attestation service (100) in an integrity report (530). Furthermore, embodiments of the invention also relate to an attestation service (100) and a verification service (300).

Description

[0001] INTEGRITY CHECK OF SOFTWARE BY USING RANDOMIZED SOFTWARE

[0002] TECHNICAL FIELD

[0003] Embodiments of the invention relate to a method for integrity check of a software by using a randomized version of the software. Furthermore, embodiments of the invention also relate to an attestation service and a verification service.

[0004] BACKGROUND

[0005] A common feature of software (SW) code reuse attacks is the reliance on the knowledge of the layout of the program code and virtual address of functional and variables of the SW. The attacker assumes that the relative offsets of code instructions of the target executable of the SW are constant. That is, if an address of a symbol, such as a name or a function, is known, then the location of all other symbols in codebase are deterministic and thus allowing attacker to derandomize the whole process.

[0006] Retum-to-libc (ROP) attacks depend on knowing the exact address of instructions in the program or library of the SW. Address space layout randomization deters ROP exploits making them infeasible for attackers to guess the right address. To achieve this, address space layout randomization (ASLR) randomizes the base addresses of process memory layout (text segment) before execution thus making address prediction harder and therefore also make ROP attacks difficult. However, many industry-deployed randomization implementations suffer from information leakage attack, brute-force attack, and insufficient entropy.

[0007] SUMMARY

[0008] An objective of embodiments of the invention is to provide a solution which mitigates or solves the drawbacks and problems of conventional solutions.

[0009] Another objective of embodiments of the invention is to provide a solution with improved security compared to conventional solutions.

[0010] The above and further objectives are solved by the subject matter of the independent claims.

[0011] Further embodiments of the invention can be found in the dependent claims.

[0012] According to a first aspect of the invention, the above mentioned and other objectives are achieved with a method for an attestation service, the method comprising:

[0013] receiving a request from a relaying party, the request indicating a request for an integrity of a software running on a platform;

[0014] determining a first integrity value for the software based on a randomized version of the software, wherein the randomized software is based on inputting the software and a random seed associated with the software in a randomization generator function;

[0015] transmitting an attestation token to a verification service, the attestation token comprising: the first integrity value, the random seed, and the randomization generator function;

[0016] receiving an integrity report from the verification service, the integrity report indicating an appraisal of the software; and

[0017] transmitting a response to the relaying party, the response indicating the appraisal of the software. An advantage of the method according to the first aspect is that the method makes it possible for the verification service to compute second verification value by repeating the randomization procedure and therefore the verification service can identify and check the appraisal of even randomized software.

[0018] There are security reasons to randomize software for example ASLR makes attacks like return oriented programming and execution of malicious shell code more difficult. On the other hand, some remote parties want to identify the software by obtaining integrity value of the software. Since software randomization changes this integrity value in unpredictable way the verification service according to conventional solutions cannot identify and check the appraisal the software based on randomized integrity value.

[0019] In an implementation form of a method according to the first aspect, the attestation token further comprises an identity of the software.

[0020] An advantage with this implementation form is that the integrity value is not only identifying information of the software. The software can have other identifiers such as version number, java package, name, etc. The appraisal made by the verification service can therefore also be based on these alternative identifiers given by the attestation token. Hence, the attestation token may indicate one or more different identities of the software.

[0021] In an implementation form of a method according to the first aspect, the randomized software comprises one or more function blocks of the software relocated to new address offsets generated by the random seed.

[0022] An advantage with this implementation form is that code relocation has the same security benefits as ASLR. Thus, code relocation makes attacks against the software more difficult.

[0023] In an implementation form of a method according to the first aspect, the method comprises:

[0024] receiving the random seed and / or the randomization generator function from a loader of the software.

[0025] The attestation service is configured to communicate the used randomization generator function and the random seed to the verification service so that verification service can compute the second integrity value. For this reason, the attestation service may obtain the randomization generator function and the random seed. The loader is commonly the component that is performing actual software randomization using the randomization generator function and the random seed.

[0026] In an implementation form of a method according to the first aspect, the first integrity value is a first HASH value of the randomized software.

[0027] An advantage with this implementation form is that cryptographic hash values are secure against forgery. The attacker cannot find another software that would have the same hash value. Therefore, software identification using hash values is trustworthy. The hash values may be generated using any suitable secure hash2 algorithms such as the family comprising SHA256, SHA224, SHA384 and SHA512.

[0028] In an implementation form of a method according to the first aspect, the randomization generator function is a random refvalue generator, RRG. An advantage with this implementation form is that the attestation service does not need to compute integrity values by itself, because the RRG is computing these integrity values. This simplifies the implementation of the attestation service. Further, the RRG can be transferred to the verification service, which can compute expected integrity values for the software.

[0029] In an implementation form of a method according to the first aspect,

[0030] the attestation token further comprises an identity of the platform;

[0031] the integrity report further indicates an appraisal of the platform; and

[0032] the response further indicates the appraisal of the platform.

[0033] An advantage with this implementation form is that the appraisal of the platform by the verification service gives information whether the platform is trustworthy enough for the software. Thus, the relying party can be informed if the verification service has approved the software to be running in this specific platform.

[0034] In an implementation form of a method according to the first aspect, the method comprises:

[0035] transmitting the attestation token to the verification service via a secure channel; and

[0036] receiving the integrity report from the verification service via a secure channel.

[0037] The information in the attestation token is confidential information, because attackers should not know how the software is randomized. For this reason, the attestation token should be delivered to the verification service via a confidential communication channel. This prevents attacker eavesdropping the attestation token. Further, the secure channel can protect privacy of a user of the software, because possible identities of the software comprised in the attestation token cannot be eavesdropped.

[0038] In an implementation form of a method according to the first aspect, the appraisal comprises a Boolean value.

[0039] An advantage with this implementation form is that the signaling overhead can be held low. The Boolean value may be signaled with a single bit such as a bit flag.

[0040] According to a second aspect of the invention, the above mentioned and other objectives are achieved with a method for a verification service, the method comprising:

[0041] receiving an attestation token from an attestation service, the attestation token comprising: a first integrity value for a software running on a platform, a random seed associated with the software, and a randomization generator function;

[0042] randomizing the software into a randomized software by inputting the software and the random seed into the randomization generator function;

[0043] determining a second integrity value for the software based on the randomized software;

[0044] determining an appraisal of the software based on the first integrity value and the second integrity value; and transmitting an integrity report to the attestation service, the integrity report indicating the appraisal of the software.

[0045] An advantage of the method according to the second aspect is that the attestation service makes it possible for the verification service to compute second verification value by repeating the randomization procedure and therefore the verification service can identify and check the appraisal of even randomized software.

[0046] In an implementation form of a method according to the second aspect, the attestation token further comprises an identity of the software. An advantage with this implementation form is that the integrity value is not only identifying information of the software. The software can have other identifiers such as version number,java package, name, etc. The appraisal made by the verification service can therefore also be based on these alternative identifiers given by the attestation token. Hence, the attestation token may indicate one or more different identities of the software.

[0047] In an implementation form of a method according to the second aspect, the randomizing of the software comprises:

[0048] relocating one or more function blocks of the software to new address offsets generated by the random seed into the randomized software.

[0049] An advantage with this implementation form is that code relocation has the same security benefits as ASLR. Thus, code relocation makes attacks against the software more difficult.

[0050] In an implementation form of a method according to the second aspect, the first integrity value is a first HASH value of the randomized software and the second integrity value is a second HASH value of the randomized software.

[0051] An advantage with this implementation form is that cryptographic hash values such as SHA2 family are secure against forgery. The attacker cannot find another software that would have the same hash value. Therefore, software identification using hash values is trustworthy.

[0052] In an implementation form of a method according to the second aspect, the randomization generator function is an RRG.

[0053] An advantage with this implementation form is that the attestation service does not need to compute integrity values by itself, because the RRG is computing these integrity values. This simplifies the implementation of the attestation service. Further, the RRG can be transferred to the verification service, which can compute expected integrity values for the software.

[0054] In an implementation form of a method according to the second aspect,

[0055] the attestation token further comprises an identity of the platform; and

[0056] the integrity report further indicates an appraisal of the platform.

[0057] An advantage with this implementation form is that the appraisal of the platform by the verification service gives information whether the platform is trustworthy enough for the software. Thus, the relying party can be informed if the verification service has approved the software running on this specific platform.

[0058] In an implementation form of a method according to the second aspect, the method comprises:

[0059] determining the appraisal of the platform based on the identity of the platform in the attestation token and an identity of the platform obtained from a trusted source.

[0060] An advantage with this implementation form is that not only the software is validated but also the trustworthiness of the platform is also validated based on the identity of the platform. Thus, improving the security further.

[0061] In an implementation form of a method according to the second aspect, the method comprises:

[0062] receiving the attestation token from the attestation service via a secure channel; and transmitting the integrity report to the attestation service via a secure channel. The information in the attestation token is confidential information, because attackers should not know how the software is randomized. For this reason, the attestation token should be delivered to the verification service via a confidential communication channel. This prevents attacker eavesdropping the attestation token. Further, the secure channel can protect privacy of a user of the software, because possible identities of the software comprised in the attestation token cannot be eavesdropped.

[0063] In an implementation form of a method according to the second aspect, the appraisal comprises a Boolean value.

[0064] An advantage with this implementation form is that the signaling overhead can be held low. The Boolean value may be signaled with a single bit such as a bit flag.

[0065] According to a third aspect of the invention, the above mentioned and other objectives are achieved with an attestation service, wherein the attestation service comprises a processor and a memory, the memory is configured to store instructions, and the processor is configured to read the instructions to perform the method according to the first aspect.

[0066] The advantages of the attestation service according to the third aspect are the same as those for the corresponding implementation forms of the method according to the first aspect.

[0067] According to a fourth aspect of the invention, the above mentioned and other objectives are achieved with a verification service, wherein the verification service comprises a processor and a memory, the memory is configured to store instructions, and the processor is configured to read the instructions to perform the method according to the second aspect.

[0068] The advantages of the verification service according to the fourth aspect are the same as those for the corresponding implementation forms of the method according to the second aspect.

[0069] Embodiments of the invention also relate to a computer program, characterized in program code, which when run by at least one processor causes the at least one processor to execute any method according to embodiments of the invention. Further, embodiments of the invention also relate to a computer program product comprising a computer readable medium and the mentioned computer program, wherein the computer program is included in the computer readable medium, and may comprises one or more from the group of: read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), flash memory, electrically erasable PROM (EEPROM), hard disk drive, etc.

[0070] Further applications and advantages of embodiments of the invention will be apparent from the following detailed description.

[0071] Brief Description of the Drawings

[0072] The appended drawings are intended to clarify and explain different embodiments of the invention, in which:

[0073] - Fig. 1 shows an attestation service according to embodiments of the invention;

[0074] - Fig. 2 shows a flow chart of a method for an attestation service according to embodiments of the invention;

[0075] - Fig. 3 shows a verification service according to embodiments of the invention;

[0076] - Fig. 4 shows a flow chart of a method for a verification service according to embodiments of the invention;

[0077] - Fig. 5 illustrates signaling overview of embodiments of the invention;

[0078] - Fig. 6 shows an exemplary system architecture in which embodiments of the invention may be implemented; - Fig. 7 illustrates a RRG according to embodiments of the invention; and

[0079] - Fig. 8 shows an example of a platform boundary according to embodiments of the invention. DETAILED DESCRIPTION

[0080] Remote attestation allows a remote party (RP) to establish trust by verifying the authenticity and integrity of a target SW running on a remote platform device, such as mobile device, laptop or computer. Through remote attestation, remote servers ensure that they are interacting with an authentic and trusted SW running on the remote platform device with a certain security attribute.

[0081] In this respect an attestation token, a.k.a. an evidence, may be constructed by a remote attestation service (AS) and sent to a verification service (VS). The attestation token may comprise of platform security features, and a state of a platform of the target SW. The VS evaluates the integrity, i.e., the correctness, of the platform of the target SW by comparing integrity values against the known rightful state. It is imperative that the VS needs to have integrity reference values before-hand to make runtime integrity verdict.

[0082] On attestation request, a platform service generates the integrity values or measurements of the target SW to be checked as part of the attestation token. The integrity measurements can be either static (file-based) or dynamic (runtime state). For evaluating the integrity of the SW, runtime attestation reflects true state of process compared against static integrity. Ascertaining runtime integrity for target process may be done by generating integrity values for all deterministic and non-volatile process segments in the memory and comparing them with known in-memory rightful state.

[0083] Remote attestation is a widely used technology for ensuring the trustworthiness and integrity of SWs and computer systems. In conventional solutions, the integrity value of the operating system (OS) kernel is measured during the secure boot process. This measured integrity value is later used as an attestation claim in an attestation token. Any possible kernel code randomizations occur after the kernel has been measured, ensuring the integrity of the initial measurement.

[0084] Remote attestation service requires reference values for successful integrity verification of the target SW. The reference values are provided to remote attestation service by a trusted SW vendor or original equipment manufacturers (OEMs) in order to be used verifying against runtime values provided as part of attestation evidence. Pre-generating reference values for randomized processes makes little sense as the SW to be verified / validated would be randomized in memory and hence the final integrity values would be in-deterministic. The integrity value depends on factors such as random seed and randomization approach involved.

[0085] Embodiments of the invention therefore provide a reliable integrity check mechanism where the VS can verify a randomized SW in a deterministic way. More specifically, embodiments of the invention provide a deterministic methodology for validating the integrity of memory footprint for randomized SW and data that is remotely hosted e.g., in a cloud server. Thus, any large language model (LLM) providers can attest and validate the randomized model’s memory footprint before any inference takes place. Additionally, embodiments of the invention, among other things, provide the ability for any third-party verification service providers to reliably verify the integrity of any randomized SW in a secure fashion.

[0086] Fig. 1 shows an attestation service 100 according to an embodiment of the invention. In the embodiment shown in Fig. 1, the attestation service 100 comprises a processor 102, a transceiver 104 and a memory 106. The processor 102 is coupled to the transceiver 104 and the memory 106 by communication means 108 known in the art. The attestation service 100 may be configured for wireless and / or wired communications in a communication system. The wireless communication capability may be provided with an antenna or antenna array 110 coupled to the transceiver 104, while the wired communication capability may be provided with a wired communication interface 112 e.g., coupled to the transceiver 104. The processor 102 may be referred to as one or more general-purpose central processing units (CPUs), one or more digital signal processors (DSPs), one or more application-specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs), one or more programmable logic devices, one or more discrete gates, one or more transistor logic devices, one or more discrete hardware components, or one or more chipsets. The memory 106 may be a read-only memory, a random access memory (RAM), or a non-volatile RAM (NVRAM). The transceiver 104 may be a transceiver circuit, a power controller, or an interface providing capability to communicate with other communication modules or communication devices, such as network nodes and network servers. The transceiver 104, memory 106 and / or processor 102 may be implemented in separate chipsets or may be implemented in a common chipset.

[0087] That the attestation service 100 is configured to perform certain actions can in this disclosure be understood to mean that the attestation service 100 comprises suitable means and devices, such as e.g., the processor 102 and the transceiver 104, configured to perform the actions.

[0088] According to embodiments of the invention and with reference to Fig. 1 and 5, the attestation service 100 is configured to: receive a request 510 from a relaying party 600, the request 510 indicating a request for an integrity of a software 710 running on a platform 700; determine a first integrity value VI for the software 710 based on a randomized version of the software 710', wherein the randomized software 710' is based on inputting the software 710 and a random seed associated with the software 710 in a randomization generator function; transmit an attestation token 520 to a verification service 300, the attestation token 520 comprising: the first integrity value VI, the random seed, and the randomization generator function; receive an integrity report 530 from the verification service 300, the integrity report 530 indicating an appraisal of the software 710; and transmit a response 540 to the relaying party 600, the response 540 indicating the appraisal of the software 710.

[0089] Furthermore, in an embodiment of the invention, the attestation service 100 comprises a transceiver 104 configured to: receive a request 510 from a relaying party 600, the request 510 indicating a request for an integrity of a software 710 running on a platform 700. The attestation service 100 comprises a processor configured to: determine a first integrity value VI for the software 710 based on a randomized version of the software 710', wherein the randomized software 710' is based on inputting the software 710 and a random seed associated with the software 710 in a randomization generator function. The transceiver 104 is further configured to: transmit an attestation token 520 to a verification service 300, the attestation token 520 comprising: the first integrity value VI, the random seed, and the randomization generator function; receive an integrity report 530 from the verification service 300, the integrity report 530 indicating an appraisal of the software 710; and transmit a response 540 to the relaying party 600, the response 540 indicating the appraisal of the software 710.

[0090] Moreover, in yet another embodiment of the invention, the attestation service 100 comprises a processor and a memory having computer readable instructions stored thereon which, when executed by the processor, cause the processor to: receive a request 510 from a relaying party 600, the request 510 indicating a request for an integrity of a software 710 running on a platform 700;determine a first integrity value VI for the software 710 based on a randomized version of the software 710', wherein the randomized software 710' is based on inputting the software 710 and a random seed associated with the software 710 in a randomization generator function; transmit an attestation token 520 to a verification service 300, the attestation token 520 comprising: the first integrity value VI, the random seed, and the randomization generator function; receive an integrity report 530 from the verification service 300, the integrity report 530 indicating an appraisal of the software 710; and transmit a response 540 to the relaying party 600, the response 540 indicating the appraisal of the software 710.

[0091] Moreover, the AS 100 may also be configured to provide an attestation API for client applications to request platform attestation token. The RP may provide nonce and request a signed attestation token describing the claims representing the platform state at the time of request. The AS 100 or the RRG may in embodiments of the invention, generate a hash value for the randomized SW 710' which means that the first integrity value VI is a first HASH value Hl of the randomized software 710' in such cases. The reference values are generated for the predictable and deterministic memory sections or executable & read-only memory segments.

[0092] Fig. 2 shows a flow chart of a corresponding method 200 which may be executed in an attestation service 100, such as the one shown in Fig. 1. The method 200 comprises: receiving 202 a request 510 from a relaying party 600, the request 510 indicating a request for an integrity of a software 710 running on a platform 700; determining 204 a first integrity value VI for the software 710 based on a randomized version of the software 710', wherein the randomized software 710' is based on inputting the software 710 and a random seed associated with the software 710 in a randomization generator function; transmitting 206 an attestation token 520 to a verification service 300, the attestation token 520 comprising: the first integrity value VI, the random seed, and the randomization generator function; receiving 208 an integrity report 530 from the verification service 300, the integrity report 530 indicating an appraisal of the software 710; and transmitting 210 a response 540 to the relaying party 600, the response 540 indicating the appraisal of the software 710.

[0093] Fig. 3 shows a verification service 300 according to an embodiment of the invention. In the embodiment shown in Fig. 3, the verification service 300 comprises a processor 302, a transceiver 304 and a memory 306. The processor 302 is coupled to the transceiver 304 and the memory 306 by communication means 308 known in the art. The verification service 300 may be configured for wireless and / or wired communications in a communication system. The wireless communication capability may be provided with an antenna or antenna array 310 coupled to the transceiver 304, while the wired communication capability may be provided with a wired communication interface 312 e.g., coupled to the transceiver 304.

[0094] The processor 302 may be referred to as one or more general-purpose CPUs, one or more DSPs, one or more ASICs, one or more FPGAs, one or more programmable logic devices, one or more discrete gates, one or more transistor logic devices, one or more discrete hardware components, one or more chipsets. The memory 306 may be a read-only memory, a RAM, or a NVRAM. The transceiver 304 may be a transceiver circuit, a power controller, or an interface providing capability to communicate with other communication modules or communication devices. The transceiver 304, the memory 306 and / or the processor 302 may be implemented in separate chipsets or may be implemented in a common chipset.

[0095] That the verification service 300 is configured to perform certain actions can in this disclosure be understood to mean that the verification service 300 comprises suitable means and devices, such as e.g., the processor 302 and the transceiver 304, configured to perform the actions.

[0096] According to embodiments of the invention and with reference to Fig. 3 and 5, the verification service 300 is configured to: receive an attestation token 520 from an attestation service 100, the attestation token 520 comprising: a first integrity value VI for a software 710 running on a platform 700, a random seed associated with the software 710, and a randomization generator function; randomize the software 710 into a randomized software 710' by inputting the software 710 and the random seed into the randomization generator function; determine a second integrity value V2 for the software 710 based on the randomized software 710'; determine an appraisal of the software 710 based on the first integrity value VI and the second integrity value V2; and transmit an integrity report 530 to the attestation service 100, the integrity report 530 indicating the appraisal of the software 710.

[0097] Furthermore, in an embodiment of the invention, the verification service 300 comprises a transceiver 304 configured to: receive an attestation token 520 from an attestation service 100, the attestation token 520 comprising: a first integrity value VI for a software 710 running on a platform 700, a random seed associated with the software 710, and a randomization generator function. The verification service 300 comprises a processor configured to: randomize the software 710 into a randomized software 710' by inputting the software 710 and the random seed into the randomization generator function; determine a second integrity value V2 for the software 710 based on the randomized software 710'; determine an appraisal of the software 710 based on the first integrity value VI and the second integrity value V2. The transceiver 304 is further configured to: transmit an integrity report 530 to the attestation service 100, the integrity report 530 indicating the appraisal of the software 710.

[0098] Moreover, in yet another embodiment of the invention, the verification service 300 comprises a processor and a memory having computer readable instructions stored thereon which, when executed by the processor, cause the processor to: receive an attestation token 520 from an attestation service 100, the attestation token 520 comprising: a first integrity value VI for a software 710 running on a platform 700, a random seed associated with the software 710, and a randomization generator function; randomize the software 710 into a randomized software 710' by inputting the software 710 and the random seed into the randomization generator function; determine a second integrity value V2 for the software 710 based on the randomized software 710'; determine an appraisal of the software 710 based on the first integrity value VI and the second integrity value V2; and transmit an integrity report 530 to the attestation service 100, the integrity report 530 indicating the appraisal of the software 710.

[0099] Fig. 4 shows a flow chart of a corresponding method 400 which may be executed in a verification service 300, such as the one shown in Fig. 3. The method 400 comprises: receiving 404 an attestation token 520 from an attestation service 100, the attestation token 520 comprising: a first integrity value VI for a software 710 running on a platform 700, a random seed associated with the software 710, and a randomization generator function; randomizing 404 the software 710 into a randomized software 710' by inputting the software 710 and the random seed into the randomization generator function; determining 406 a second integrity value V2 for the software 710 based on the randomized software 710'; determining 408 an appraisal of the software 710 based on the first integrity value VI and the second integrity value V2; and transmitting 410 an integrity report 530 to the attestation service 100, the integrity report 530 indicating the appraisal of the software 710.

[0100] Fig. 5 illustrates general signaling and a system overview of embodiments of the invention. As shown in Fig. 5, an AS 100 is configured to on one hand interacting with a RP 600 and on the other hand with a VS 300 for performing an integrity check of the SW 710, which is arranged in and running in a target platform 700 which may also comprise a loader 720 which will be described in the following disclosure.

[0101] In embodiments of the invention, both the AS 100 and the VS 300 may establish one or more secure channels 900 for safe and secure communication between each other. Thus, the attestation token 520 may be transmitted in a secure channel 900 from the AS 100 to the VS 300, and the integrity report 530 may be sent on the same or a different secure channel 900 from the VS 300 to the AS 100. The secure channel 900 may be a TLS, or a VPN, or any other suitable secure channel 900 known in the art for secure communication.

[0102] The AS 100 is configured to receive an attestation request 510 from the RP 600. The RP 600 may be a server providing services to a target platform 700 which may act as a client to the server. The RP 600 may be configured to provide services to the platform 700 on which the SW 710 is running. The SW 710 may be a client program such as an application (APP). Thus, the RP 600 wants to know the integrity / validity of the SW 710 running on the target platform 700.

[0103] The AS 100 upon reception of the attestation request 510 from the RP 600 determines a first integrity value VI for the SW 710 based on a randomized SW 710'. The SW 710 is randomized according to embodiments of the invention, which means that a random seed and the SW 710 is used as input to a randomization generator function (RGF) which outputs a randomized version of the SW 710. In embodiments of the invention, the randomization of the SW 710 is done by the RGF on request from the loader. The AS 100 thereafter produces an attestation token 520 comprising the first integrity value VI , the random seed, and the RGF. The attestation token 520 is sent to the VS 300 via the secure channel 900.

[0104] The attestation token 520 may further comprise of so-called claims related to the platform, security characteristics, runtime integrity state of critical platform services running in the platform and random seed used for randomizing the SW 710. The memory footprint of the executable code and deterministic sections of the memory is measured and is presented as part of the attestation token 520.

[0105] The VS 300 upon reception of the attestation token 520 derives the information therein and produces a randomized SW 710' using the RGF and the random seed in the attestation token 520 received from the AS 100. Based on the produced randomized SW 710', the VS 300 determines a second integrity value V2 for the SW 710 based on the produced randomized software 710'.

[0106] Further, based on a comparison of the first integrity value VI with the second integrity value V2, an integrity / appraisal report 530 for the SW 710 is thereafter produced. For example, if the first integrity value VI is the same as the second integrity value V2 it is determined that the SW 710 can be trusted. However, if the first integrity value VI is different to the second integrity value V2, the SW 710 cannot be trusted.

[0107] In embodiments of the invention, the appraisal report comprises a Boolean value which may be signaled as a bit flag. However, in further embodiments of the invention, the appraisal may also include further information such as observations about the integrity of the SW 710. The observations may e.g., include claims describing the details of the AS 100 e.g., if genuine and non-malicious SW is running or not on the target platform 700; details of the type of the attesting environment such as the hardware platform may be given e.g., Intel software guard extension (SGX) or AMD secure encrypted virtualization (SEV) or trusted execution environment (TEE); and if the attesting environment supports file system storage that is secure from attackers.

[0108] In embodiments of the invention, the VS 300 may further sign the appraisal report with a key and a certificate issued by a trusted third party before the integrity report 530 is sent to the AS 100. The RP 600 may need to verify the authenticity of the VS 300 before consuming the appraisal report received from the VS 300. Therefore, the VS 300 may sign the appraisal report with one or more keys that are certified by third parties trusted by the RP 600 to help to establish trust and belief between the RP 600 and the VS 300.

[0109] The VS 300 transmits the integrity report 530 to the AS 100 via the secure channel 900 which in turn forwards the signed integrity report 530 to the RP 600 in a response 540.

[0110] The RP 600 when receiving the integrity report 530 in the response 540 checks the content of the integrity report 530. The RP 600 thus upon reception of the integrity report 530 analyses the received report and validates a nonce and the verdict on the SW 710 integrity. The RP 600 may parse the appraisal report and evaluate the integrity verdict and the nonce after which it decides to take appropriate decisions. Two important assessments here are platform integrity meaning that a genuine and verified SW 710 is running on authenticated hardware, and the nonce which provides freshness information of the appraisal report. The RP 600 therefore uses the nonce to validate the freshness, i.e., recentness of the appraisal report. Hence, the nonce helps the RP 600 to know if the appraisal report is the most recent one and not an outdated or obsolete appraisal report that have been generated in the past for an attestation token that was generated when the platform 700 was in good state.

[0111] Depending on the outcome of the integrity report 530, the RP 600 may act in different ways. If the SW 710 is considered trustworthy such as all integrity is found in rightful state, the RP 600 will activate the account and / or continue streaming of provided services. However, if the SW 710 is considered untrustworthy, e.g., tampered or running on non-authentic hardware or does not have the latest SW or firmware updates with all security patches, the RP 600 will not enable services on the platform. For example, a service provider will not activate an account or provide access to data and functions.

[0112] Fig. 6 illustrates further embodiments of the invention, which are set in a protocol that works in accordance with the internet engineering task force (IETF) remote attestation procedure (RAT) described passport topology. Thus, the devices and components in the proposed solution may be constructed based on the IETF RAT's passport topology. In these topologies, the platform provider owns both the AS 100, the RRG and the SW 710 running on the same platform. The VS 300 can be provided either from the platform provider or any third-party services e.g., implementing open governance verification frameworks. It is however noted that embodiments of the invention are not limited to such a passport topology.

[0113] In Fig. 6, the presented topology comprises a RP 600, a target device platform 700, a verifier boundary, and a remote database 800. The device platform 700 in turn comprises a SW 710, a loader 720 of the SW 710, a RGF and an AS 100, while the verifier boundary comprises of VS 300 and an RGF.

[0114] In the platform 700, the AS 100 generates the attestation token 520, passes it to the VS 300 to verify the integrity of the SW 710. For this, the AS 100 interacts with the RGF and the loader 720 to produce the attestation token 520.

[0115] In the verifier boundary, the VS 300 evaluates the attestation token 510 and produces an integrity report which is communicated to the relaying party 600 via the AS 100. The input artifacts needed by the VS 300 to produce the include: platform attestation token from target platform's attestation service, comprising the platform identity, security characteristics and integrity measurements of runtime state of critical platform services; a random seed that is used for randomization of the SW 710; and a RGF a lean and migratable lambda function that takes as input random seed and SW image sources. The VS 300 may obtain the SW 710 from a trusted database source 800.

[0116] In yet further embodiments of the invention, the integrity of the platform 700 on which the SW 710 is running is also checked. From the perspective of the AS 100 this involves that the attestation token 520 further comprises an identity ID2 of the platform 700 so that the platform 700 can be identified by the VS 300. The AS 100 receives the integrity report 530 from the VS 300 which further indicates an appraisal of the platform 700. The appraisal of the platform 700 is thereafter sent to the RP 600 in the response 540 message. Platforms (i.e., devices) from vendors (OEMs) come with unique identification materials such as a cryptographic key or a platform identification number. The AS 100 thus obtains the cryptographic key or the platform identification number from the platform 700 and adds the cryptographic key or the platform identification number as part of the attestation token 520.

[0117] From the perspective of the VS 300, the attestation token 520 received from the AS 100 comprises the identity ID2 of the platform 700. The VS 300 therefore also determines the appraisal of the platform 700 based on the identity ID2 of the platform 700 in the attestation token 520 and an identity ID2' of the platform 700 obtained from the trusted source 800.

[0118] If both identities are the same, i.e., ID2 = ID2 ' , the meaning is that the identity fetched from in attestation token 520 corresponds to ID2' provided by the trusted source. This proves that the identity of the platform that runs the AS 100 is authentic and can be trusted. However, if ID2 ID2', the platform identity cannot be trusted and hence the VS 300 will produce a negative integrity verdict as part of the appraisal report 530. The trusted source 800 may herein by any trusted entity that provides access to database or access to a trusted service who can provide ID2’ to the VS 300. Thus, the integrity report 530 sent to the AS 100 in these cases further indicates the appraisal of the platform 700. In embodiments of the invention, the RGF is a Random Refvalue generator (RRG) as shown in Fig. 7. The RRG may as mentioned be a self-contained, lean and migratable lambda randomization function that randomizes a SW 710 in memory and produces a new program layout of the SW 710 in a randomized form. Thus, the RRG is a self-contained process that can take a loaded image of the SW 710, parse the file format, generate random offsets for function execution blocks and reload the image in-accordance with the newly generated address offsets and fix the relocations. The RRG may also generate HASH values for the randomized program layout, i.e., the randomized SW 710'.

[0119] The randomization of the SW 710 may be performed by relocating one or more function blocks of the SW to new address offsets generated by the random seed into the randomized software 710' according to embodiments of the invention.

[0120] The inputs parameters to the RRG as shown in Fig. 7 may be:

[0121] • A random number considered as a random seed by RRG to use for randomization. Image source which is a file location (link) that corresponds to location of the SW 710. The RRG can fetch the SW 710 from link and then use this to randomize. OR

[0122] • Load address which is the address where the loader 720 loaded the SW 710 to a memory and this is provided to the RRG.

[0123] The random seed can be any big randomly generated number which is hard to predict.

[0124] It is further noted that to gain access to the SW 710, the RRG would only need one of the alternatives above.

[0125] The RRG randomizes the SW 710 and generates hash values for the SW 710 and returns the following to the loader 720:

[0126] • Reference hash values of non-randomized SW 710.

[0127] • Reference hash values V2 of randomized SW 710'.

[0128] • Load address of the randomized SW 710’, i.e., the memory address where the randomized SW 710’ is loaded in the memory.

[0129] Moreover, in further embodiments of the invention, the RRG may parse the SW 710 loaded by loader 720, and generate the second integrity value V2 which is computed by the VS 300. If a SW handle is provided, the RRG may also fetch the SW 710 from a trusted database 800 as shown in Fig. 7. The trusted database 800 may further comprise: a kernel, a bootloader, and platform services which may be retrieved by the RRG via a suitable communication interface. Thus, the trusted database 800 acts as a storage for all SW components that should be randomized. The SW handle may be a link to the SW 710 provided by the loader 720 for the RRG to fetch the SW 710.

[0130] The RRG may further generate load offsets from host provided random seed, and parse the SW formats, interpret the relocation metadata, and fix the references for all relocation data. In other words, the RRG may be configured to fetch the SW 710 from a trusted database, load the SW 710 in the memory, and randomizes the memory layout to produce the randomized SW 710'.

[0131] Fig. 8 shows more in detail the target platform 700 of Fig. 6 and summarizes the steps involved in capturing the integrity values on process loading which all may be performed in the target platform 700.

[0132] In step I in Fig. 8, the SW is loaded by the loader 720 in a memory of the platform when the loader 720 receives a request to load the SW 710 in the memory. The loader 720 generates a random seed using entropy provided by the target platform 700 and also loads the SW 710. The loader 720 launches the RRG engine with the random seed and load address which is where the loader 720 has loaded the SW 710 to the memory and is provided to the RRG. The loader 720 is usually a platform component that is responsible for loading the processes, setting up the process stack, heap, mapping the process to memory and setting up the environment for the SW 710 to run, and so on.

[0133] In step II in Fig. 8, the RRG:

[0134] 1. Fetch the SW 710: the RRG fetches the SW 710 from the trusted database if the SW handle is provided by loader 720. If the loader 720 provides the load address, this is not required.

[0135] 2. Generate pre-random reference values: these reference hash values are generated for the SW 710 before it is

[0136]

[0137] randomized.

[0138] 3. Randomize the SW 710’: This includes multiple sub-steps comprising:

[0139] a) Extract the metadata from executable linkable format (ELF) file format corresponding to the SW 710. The metadata holds the function addresses in the SW 710.

[0140] b) Generate new address from entropy.

[0141] c) Relocate or shuffle the functions blocks of the SW 710 to new addresses in memory.

[0142] 4. Generate the first integrity value VI which is generated based on the shuffled SW 710’.

[0143] These parameters and values are transmitted by the RRG to the loader 720.

[0144] In step III in Fig. 8, the loader 720 receives new Process_load_address (i.e., address where the SW is loaded in memory), RandRefValues (i.e., hash digest values where the target SW generated after randomization), Non-RandValues (i.e. hash digest values of target SW generated before randomization), and random seed from the RRG and thereafter communicates the values to the AS 100 arranged in the platform 700.

[0145] In step IV in Fig. 8, the loader 720 sends a package comprising reference values (i.e., non-randomized and randomized values), random seed, image offsets, and the RRG to the AS 100. The randomized SW reference value VI is part of claims in the attestation token 520, but the non-randomized values are not. The AS 100 will decide which one would be presented as claims in the attestation token 520, and thus the loader 720 will not have any say in what will be the content of the claims, which means that the loader 720 does not have any role in determining what the content of the attestation token will have.

[0146] Hence, in embodiments of the invention, the AS 100 is configured to receive the random seed and / or the RGF from the loader 720 of the SW 710. Thus, such examples extend the existing platform loader functionality to invoke RRG engine to randomize the target SW 710, capture the initial measurements and communicate the measurements sent to the AS 100.

[0147] In step V in Fig. 8, the AS 100 upon receiving the package from the loader 720 receives the information, such as initial measurements of randomized SW 710’, the random seed, and the RRG engine from loader 720. This information is stored securely and used later to perform attestation of the platform 700. When an attestation request arrives, the AS 100 constructs the attestation token 520 where value VI is presented as one of the claims and embeds them as part of the attestation token 520. The RRG engine and random seed is communicated to the VS 300 in a secure channel within the attestation token 520.

[0148] Finally in step VI in Fig. 8, the loader 720 starts to set up the SW 710 e.g., by allocating required memory and start to execute the SW 710.

[0149] Furthermore, any method according to embodiments of the invention may be implemented in a computer program, having code means, which when run by processing means causes the processing means to execute the steps of the method. The computer program is included in a computer readable medium of a computer program product. The computer readable medium may comprise essentially any memory, such as previously mentioned a ROM, a PROM, an EPROM, a flash memory, an EEPROM, or a hard disk drive.

[0150] Moreover, it should be realized that the AS 100 and the VS 300 comprise the necessary communication capabilities in the form of e.g., functions, means, units, elements, etc., for performing or implementing embodiments of the invention. Examples of other such means, units, elements and functions are: processors, memory, buffers, control logic, encoders, decoders, rate matchers, de-rate matchers, mapping units, multipliers, decision units, selecting units, switches, interleavers, de-interleavers, modulators, demodulators, inputs, outputs, antennas, amplifiers, receiver units, transmitter units, DSPs, TCM encoder, TCM decoder, power supply units, power feeders, communication interfaces, communication protocols, etc. which are suitably arranged together for performing the solution.

[0151] Therefore, the processor(s) of the AS 100 and the VS 300 may comprise, e.g., one or more instances of a CPU, a processing unit, a processing circuit, a processor, an ASIC, a microprocessor, or other processing logic that may interpret and execute instructions. The expression “processor” may thus represent a processing circuitry comprising a plurality of processing circuits, such as e.g., any, some or all of the ones mentioned above. The processing circuitry may further perform data processing functions for inputting, outputting, and processing of data comprising data buffering and device control functions, such as call processing control, user interface control, or the like.

[0152] Finally, it should be understood that the invention is not limited to the embodiments described above, but also relates to and incorporates all embodiments within the scope of the appended independent claims.

Claims

CLAIMS1. A method (200) for an attestation service (100), the method comprising:receiving (202) a request (510) from a relaying party (600), the request (510) indicating a request for an integrity of a software (710) running on a platform (700);determining (204) a first integrity value (VI) for the software (710) based on a randomized version of the software (710'), wherein the randomized software (710') is based on inputting the software (710) and a random seed associated with the software (710) in a randomization generator function;transmitting (206) an attestation token (520) to a verification service (300), the attestation token (520) comprising: the first integrity value (VI), the random seed, and the randomization generator function;receiving (208) an integrity report (530) from the verification service (300), the integrity report (530) indicating an appraisal of the software (710); andtransmitting (210) a response (540) to the relaying party (600), the response (540) indicating the appraisal of the software (710).

2. The method (200) according to claim 1, wherein the attestation token (520) further comprises an identity (IDl)ofthe software (710).

3. The method (200) according to claim 1 or 2, wherein the randomized software (710') comprises one or more function blocks of the software (710) relocated to new address offsets generated by the random seed.

4. The method (200) according to any one of the preceding claims, comprising:receiving the random seed and / or the randomization generator function from a loader (720) of the software (710).

5. The method (200) according to any one of the preceding claims, wherein the first integrity value (VI) is a first HASH value (Hl) of the randomized software (710').

6. The method (200) according to any one of the preceding claims, wherein the randomization generator function is a random refvalue generator, RRG.

7. The method (200) according to any one of the preceding claims, whereinthe attestation token (520) further comprises an identity (ID2) of the platform (700);the integrity report (530) further indicates an appraisal of the platform (700); andthe response (540) further indicates the appraisal of the platform (700).

8. The method (200) according to any one of the preceding claims, comprising:transmitting the attestation token (520) to the verification service (300) via a secure channel; andreceiving the integrity report (530) from the verification service (300) via a secure channel.

9. The method (200) according to any one of the preceding claims, wherein the appraisal comprises a Boolean value.

10. A method (400) for a verification service (300), the method comprising:receiving (402) an attestation token (520) from an attestation service (100), the attestation token (520) comprising: a first integrity value (VI) for a software (710) running on a platform (700), a random seed associated with the software (710), and a randomization generator function;randomizing (404) the software (710) into a randomized software (710') by inputting the software (710) and the random seed into the randomization generator function;determining (406) a second integrity value (V2) for the software (710) based on the randomized software (710'); determining (408) an appraisal of the software (710) based on the first integrity value (VI) and the second integrity value (V2); andtransmitting (410) an integrity report (530) to the attestation service (100), the integrity report (530) indicating the appraisal of the software (710).

11. The method (400) according to claim 10, wherein the attestation token (520) further comprises an identity (ID1) of the software (710).

12. The method (400) according to claim 10 or 11, wherein the randomizing of the software (710) comprises:relocating one or more function blocks of the software (710) to new address offsets generated by the random seed into the randomized software (710').

13. The method (400) according to any one of claims 10 to 12, wherein the first integrity value (VI) is a first HASH value (Hl) of the randomized software (710') and the second integrity value (V2)is a second HASH value (H2) of the randomized software (710').

14. The method (400) according to any one of claims 10 to 13, wherein the randomization generator function is an RRG.

15. The method (400) according to any one of the preceding claims, whereinthe attestation token (520) further comprises an identity (ID2) of the platform (700); andthe integrity report (530) further indicates an appraisal of the platform (700).

16. The method (400) according to claim 15, comprising:determining the appraisal of the platform (700) based on the identity (ID2) of the platform (700) in the attestation token (520) and an identity (ID2') of the platform (700) obtained from a trusted source (800).

17. The method (400) according to any one of claims 10 to 16, comprising:receiving the attestation token (520) from the attestation service (100) via a secure channel; andtransmitting the integrity report (530) to the attestation service (100) via a secure channel.

18. The method (400) according to any one of claims 10 to 17, wherein the appraisal comprises a Boolean value.

19. An attestation service (100), wherein the attestation service (100) comprises a processor and a memory, the memory is configured to store instructions, and the processor is configured to read the instructions to perform the method (200) according to any one of claims 1 to 9.

20. A verification service (300), wherein the verification service (300) comprises a processor and a memory, the memory is configured to store instructions, and the processor is configured to read the instructions to perform the method (400) according to any one of claims 10 to 18.

Images