WO2017085159A1 - Method to verify the execution integrity of an application in a target device - Google Patents

Method to verify the execution integrity of an application in a target device Download PDF

Info

Publication number
WO2017085159A1
WO2017085159A1 PCT/EP2016/077932 EP2016077932W WO2017085159A1 WO 2017085159 A1 WO2017085159 A1 WO 2017085159A1 EP 2016077932 W EP2016077932 W EP 2016077932W WO 2017085159 A1 WO2017085159 A1 WO 2017085159A1
Authority
WO
Grant status
Application
Patent type
Prior art keywords
function
challenge
application
attestation
target device
Prior art date
Application number
PCT/EP2016/077932
Other languages
French (fr)
Inventor
Brecht Wyseur
Original Assignee
Nagravision S.A.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities

Abstract

The present invention concerns the field of software verification, in particular to check whether the run-time integrity of a software application can be demonstrated. It is therefore proposed a method to verify, by a verification server, the execution integrity of an application in a target device wherein the verification server receives an application signature generated from run time application information on the target device, said signature being used to verify the execution integrity of the application in the target device, said application comprising an array of blocks, each block producing a digest, thus producing an array of digests related to the array of blocks, comprising the steps of : - sending to the target device a message comprising a challenge and a first function, said first function defining an aggregation method, said challenge defining an aggregation instruction, - receiving an attestation from the target device, this attestation being generated by the target device by determining for each block, the corresponding digest for said block, aggregating the digests of the blocks according to the aggregation method of the first function and the challenge to produce the attestation related to the application, - applying a second function to the attestation by the verification server, said second function undoing the effect of the challenge thus producing an application signature independent of the challenge, - verifying the execution integrity of the application by comparing the produced application signature with a reference signature.

Description

METHOD TO VERIFY THE EXECUTION INTEGRITY OF AN APPLICATION IN A TARGET DEVICE Introduction

The present invention concerns the field of software verification, in particular to check whether the run-time integrity of a software application can be demonstrated. Background art

Remote attestation is a method to detect changes to the user's computer (or any software embedded in a device) by authorized parties. For example, trusted centers can identify unauthorized changes to software, including users tampering with their software to circumvent technological protection measures. The target device generates a certificate (an attestation) making an expression on the execution of software and/or the execution platform. The target device can then present this certificate to a remote party to show that unaltered software is currently executing.

Remote attestation may be combined with public-key encryption so that the information sent can only be read by the programs that presented and requested the attestation, and not by an unauthorized third party. The verification method is based on the transmission, by a verification center, of a challenge to the target device. This challenge is used by the software to produce a result, this result being dependent of the software code and execution-time information and the challenge. The result is then transmitted back to the verification center for verification.

The key to verify the result is a precise knowledge of the software of the target device so as to produce a reference result for comparison.

Brief description of the invention

It is an aspect of the present invention to propose a method and system to verify the software embedded in a target device. In the frame of the present description it is proposed a method to verify the execution integrity of an application in a target device by producing an application signature from run time application information, said signature being used to verify the execution integrity of the application by a verification server, said application comprising an array of blocks, each block producing a digest, thus producing an array of digests related to the array of blocks, comprising the steps of :

- receiving by the target device a message comprising a challenge and a first function, said first function defining an aggregation method, said challenge defining an aggregation instruction,

- determining for each block, the corresponding digest for said block, - aggregating the digests of the blocks according to the aggregation method of the first function and the challenge to produce an attestation related to the application,

- sending the attestation to the verification server,

- applying a second function to the attestation by the verification server, said second function undoing the effect of the challenge thus producing an application signature independent of the challenge,

- verifying the execution integrity of the application by comparing the produced application signature with a reference signature.

Brief summary of the figures The following Detailed Description will be better understood thanks to the attached figures in which

- Figure 1 illustrates the system comprising a head end and a target device as well as the steps to verify an application,

- Figure 2 illustrates the generation of the attestation,

- Figure 3 illustrates the verification of the attestation, - Figure 4 illustrates the target device.

Detailed description

Attestation schemes are schemes where a run-time environment or application produces a proof of integrity (an attestation). Remote attestation schemes are challenge-response protocols, where an application is requested to compute such an attestation based on the challenge it received from a verification server. Based on the received response (the attestation), the verifier (a remote trusted entity such as a Head-End) is able to make a trustworthiness verdict on the integrity of the execution of that application. Usual attestation schemes compute such an attestation from run-time information such as memory content. There are for example schemes published where the challenge defines a predefined visit through memory; the attestation being the hash of the values encountered during this visit.

The known remote attestation schemes require that the run-time environment of the application is emulated or that at least the application (or part thereof) is available by the trusted entity, such that it can compute the expected result given the challenge and verify the correctness of the received attestation. This introduces significant complexity that in practice is very hard to deal with, because of, e.g., the diversity of application versions; and the number of application instances that needs to be verified. According to the present specification, it is proposed an attestation scheme where the verdict computation is reduced to verifying if a tuple {version, appsign} exists in a given set, which heavily reduces the complexity of deployment in practice. This is achieved by delegating a part of the remote attestation scheme (i.e., the part that ensures that there is a proper challenge-response protocol) to a "Remote Attestation Frontend" (RAF). The solution is designed for the RAF to have no information on the application that needs to be verified; it only supports the challenge-response protocol, and extracts from the response an application signature (appsign) that the verification entity (VE) can use to make its trustworthiness verdict on the execution of the client application (App).

The high-level view of this solution is presented in Figure 1. The head end HE comprises a Verification Entity VE and a Remote Attestation Frontend RAF. The Verification Entity VE requests the Remote

Attestation Frontend RAF to perform a query to a target device TD. The Remote Attestation Frontend RAF prepares a challenge CH and sends it to the target device TD. It is to be noted that a target device can be any type of electronic device embedding a processing unit executing a program.

The step A is the transmission of the challenge to the target device. A challenge is a value unpredictable by the target device. It can be for example randomly generated by the Remote

Attestation Frontend RAF. The transmission between the Remote Attestation Frontend RAF and the target device TD can be a bidirectional channel such as an Internet connection, or can be a broadcast connection in which the challenge CH is sent to a plurality of target devices TD.

Once the challenge is received, the generation of the attestation can start (step B). The target device TD comprises an attestation module AM in charge of producing the attestation. This attestation module AM can be a dedicated program of the target device or an independent processor connected to the main communication bus of the main processor. In this latter case, the independent processor has access to the memory storing the variables and can calculate the digest on these variables.

Attestation R = F (CH, APP), where F represents the function that computes the attestation based on the received challenge CH, and some (run-time) information of the Application (APP) such as the application memory space. Given the challenge CH and the response R, the RAF computes the app signature, which is a value that should only depend on the application information independent from the challenge.

Below, we present a concrete construction to achieve this. One skilled in the art will recognize that alternative constructions, variations, and extensions on this proposed construction are possible.

According to an embodiment, a set of vector of digests [ hO, hi, ... , hn ] is built, which solely depend on (parts of) the application (run-time) information, and define the attestation as some function on this vector; the function being instantiated by the challenge and being invertible. Using this challenge, the RAF can compute the inverse function, such that from the attestation (response), he can reconstruct this vector of digests. The app signature is then the result of some function computed onto this vector of digests (or a part thereof).

The figure 2 explains in more detail the process of the attestation generation. The program to be verified is divided into blocks (BO ... B3), and the attestation module AM comprises a memory to store the map of the blocks taking part of the attestation generation. The attestation module generates for each block a digest H representing the block. This digest H can be calculated as follows:

- static : a hash value of the block, or any operation on the content of the memory block,

- dynamic : the content of run-time memories including for example registers, stack, heap content at the end of the execution of the block. In order to generate the same values in the run-time memories each time the block is executed, the run-time memories are set to predefined values before the execution.

Once the set of digests (HO, H I, ... Hn) is obtained, the next step is the calculation of the attestation, this operation being dependent of the challenge. A function F(CH) is applied on the set of digests to produce the attestation (ΗΟ', Η ... Ηη'). A large number of possibilities exist for the function F, the key factor is the possibility to have the inverse function F 1 allowing to retrieve the set of digests.

Example of function F

Shuffling function: the challenge CH is used as a parameter to shuffle each member of the set. The resulting set contains all digests, only the position into the set is randomly modified based on the challenge CH.

Mathematical operation: the resulting digest H' is the result of an operation of at least two digests. Example: HO' = H3 X H6; H I' = H2 x H5, or HO' = H3 + H6 ; H I' = HO + H7. The selection of the digests participating to the operation is based on the challenge CH. Complex operations can be executed such as HO' = H3 X H6 + H7; H I' = H2/H4 x H 12 Affine function: Affine functions represent vector-valued functions of the form of, for example

HO' = A0. H0 + A1. H 1 + ... An. Hn in which the AO to An coefficients are given by the challenge.

Examples of affine transformations include linear functions such as additions or multiplication with a constant (the constant could be the coefficient of the challenge).

The set of di ests (HO ... Hn) can be expressed as a matrix of digests of x lines and y columns such as H

Figure imgf000005_0001
And the resulting attestation H' may be a matrix such as H' = F(CH,H). Once the attestation H' is calculated by the attestation module of the target device, the result is sent to the Remote

Attestation Frontend RAF together with an identifier of the application's version (VER).

Another example of the function F is an encryption function of the matrix of digests, the key used for that encryption could be the challenge or information derived from the challenge according to a derivation function known by the RAF and the target device.

The function used to determine the attestation can be a multivariate function that computes the attestation based on the challenge and the matrix of digests. This is preferably an invertible linear function. This can be defined unambiguously by generating an invertible function based on the challenge. The resulting matrix is then multiplied with the matrix of digests in order to obtain an attestation that is sent (as a matrix of the same length of the matrix of digests) to the RAF.

The RAF can use the same algorithm to compute the same matrix from the challenge CH that it persisted, and then compute its inverse matrix. This applies on the response producing the original matrix of digests, which is then in turn used to compute the app signature. On the figure 3, the operations executed by the RAF are illustrated. The attestation ATT is received (step C, figure 1) together with the identifier of the application (VER). The attestation ATT comprises a set of values (ΗΟ', HI' ... Hn') which is unique per challenge. The RAF, as the generator of the challenge C, can use it with the inverse function F 1 on the attestation ATT (step D, figure 1). This will produce the set of calculated digests HO, HI ... Hn. According to an embodiment, a signature S is generated from the calculated digests, for example by mixing the digests to produce a single value S. The mixing function can be a hash function on the digests. This signature S is sent to the Verification Entity VE for verification.

The Verification Entity VE comprises data storage to store a pair of reference data, said pair comprising at least the reference signature SR and the version of the application. Once the pair if the current signature S and the current version V is received (step E) by the Verification Entity, the version V of the received pair is used to retrieve the reference signature SR from the data storage.

During a previous initialization step, the Verification Entity VE has generated the set of reference digests (HOR, H1R ... HnR) and produced the reference signature SR, the set of reference digests being produced on a reference client device. A comparison is carried out between the current signature S and the reference signature SR and the result of the verification allows determining if the application of the target device is genuine. The Verification Entity can then inform a service provider which is in charge of delivering content to the target device or send a validation message to the target device.

According to an embodiment, the step of producing the attestation from the set of digests can be combined with the operation that computes the digests. For example, when the attestation generation function is a multivariate function, and the function to compute the digests from the block (the sub-digests) is a multivariate function too, these can be combined. The block BO of the application APP is divided into a plurality of sub-digests BOa, BOb ... BOn. The function F then defines the operations, parameterized with the challenge C, on the sub-digests. Example :

If HO = BOa + BOb and H I = Bla x Bib define how the digests can be computed from the sub-digests and HO' = CO x HO x H I + CI x H I and H I' = CO x H I + CI x HO, then HO' and H I' can be computed directly by a definition F that depends on the inputs CH and the sub-digests as follows:

HO' = CO x (BOa + BOb) x (Bla x Bib) + CI x Bla x Bib

H I' = CO x Bla x Bib + CI X (BOa + BOb).

This computation can be represented as such that it becomes difficult to separate the 2 operations. The multiplications and additions are given as an example. Any type of mathematical operations can be applied with two or more sub-digests. So the set of digests HO' ... Hn' is produced directly from the sub-digests of a plurality of blocks, generalizing the example above.

According to an embodiment, the attestation module of the target device has a definition of the blocks BO ... Bn. This definition is stored in the memory of the attestation module of the target device or directly implemented into the attestation module software.

In another embodiment, the Verification Entity VE comprises in its data storage, a plurality of definitions with the corresponding set of reference signatures and the version of the application. A definition is to be understood as defining the blocks in the application taking part of the generation of the digests (this can be in the form of a set of memory range or a set of memory addresses) or defining the initialization parameters of the run-time execution of the block. For each set of initialization parameters and for a given version, a reference signature is stored in the database. The attestation module can then comprises several definitions of array of blocks stored in a memory table. The RAF include in the message sent to the target device the indication (table index) of which definition should be used for the determination of the attestation. Example of the definition table

Figure imgf000008_0001

Each block can be identified by a starting and ending address of the target software.

According to another example, the attestation module receives from the RAF the definition of the blocks taking part of the attestation.

Preferred examples of target devices are audio/video receivers and in particular the application which is responsible of the verification of the right to process said audio/video. However, the verification can take place in any device having software that needs verification, such as a smartphone or device used in critical environment (plant security for example). The figure 4 illustrates de target device. It comprises a communication module COMM to receive the challenge with the request to perform the generation of an attestation. This module is used also to send the attestation to the RAF. The target device TD comprises a processing unit PROC to execute the operations related to the generation of the attestation. Alternatively, the processing module can delegate the generation of the attestation to an attestation module AM. Both the processing unit and the attestation module have access to the memory from which attestation procedure can take place.

Although embodiments of the present disclosure have been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader scope of these embodiments. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof, show by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived there from, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

Such embodiments of the inventive subject matter may be referred to herein, individually and/or collectively, by the term "invention" merely for convenience and without intending to voluntarily limit the scope of this application to any single inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other

embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.

Claims

Claims
1. Method to verify, by a verification server, the execution integrity of an application in a target device wherein the verification server receives an application signature generated from run time application information on the target device, said signature being used to verify the execution integrity of the application in the target device, said application comprising an array of blocks, each block producing a digest, thus producing an array of digests related to the array of blocks, comprising the steps of :
- sending to the target device a message comprising a challenge and a first function, said first function defining an aggregation method, said challenge defining an aggregation instruction, - receiving an attestation from the target device, this attestation being generated by the target device by determining for each block, the corresponding digest for said block, aggregating the digests of the blocks according to the aggregation method of the first function and the challenge to produce the attestation related to the application,
- applying a second function to the attestation by the verification server, said second function undoing the effect of the challenge thus producing an application signature independent of the challenge,
- verifying the execution integrity of the application by comparing the produced application signature with a reference signature.
2. Method of claim 1, wherein the first function is a shuffle function, shuffling the array of digests according to the challenge.
3. Method of claim 1, wherein the first function is an affine function on the array of digests according to the challenge.
4. Method of claim 1, wherein the first function is a multivariate function applied on the array of digests according to the challenge.
5. Method of any of the claims 1 to 4, wherein the message further comprises a description of the blocks of the application taking part of the integrity verification.
6. Method of any of the claims 1 to 5, wherein one block comprise a plurality of sub-blocks, each producing a sub-digest, the attestation is produced directly from the sub-digests among the blocks using the first function and the challenge.
7. System to verify the execution integrity of an application in a target device (TD) comprising a Verification Entity (VE) and a Remote Attestation Frontend (RAF), said Remote Attestation Frontend (RAF) being configured to :
- generate a challenge (C), - transmit the challenge (C) with a first function to the target device, said first function defining an aggregation method, said challenge defining an aggregation instruction,
- receive an attestation (ATT) from the target device, this attestation being generated by the target device by determining for each block, the corresponding digest for said block, aggregating the digests of the blocks according to the aggregation method of the first function and the challenge to produce the attestation related to the application,
- apply a second function to the attestation (ATT), said second function undoing the effect of the challenge thus producing a set of digests (HO, HI, ... Hn) independent of the challenge,
- transmit the array of digests (HO, HI, ... Hn) or a signature (S) which is a mix on the array of digests (HO, HI, ... Hn) to the Verification Entity (VE), and the Verification Entity is configured to :
- verify the execution integrity of the application by comparing the received array of digests (HO, HI, ... Hn) or the signature (S) with a reference.
8. System of claim 7, wherein the Remote Attestation Frontend (RAF) is configured to transmit to the target device (TD) the definition of the blocks taking part of the attestation (ATT).
9. System of claim 7 or 8, wherein the first function is a shuffle function, shuffling the array of digests according to the challenge.
10. System of claim 7 or 8, wherein the first function is an affine function on the array of digests according to the challenge.
11. System of claim 7 or 8, wherein the first function is a multivariate function applied on the array of digests according to the challenge.
PCT/EP2016/077932 2015-11-19 2016-11-17 Method to verify the execution integrity of an application in a target device WO2017085159A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP15195379.1 2015-11-19
EP15195379 2015-11-19

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
SG11201803707PA SG11201803707PA (en) 2015-11-19 2016-11-17 Method to verify the execution integrity of an application in a target device
CN 201680067368 CN108292341A (en) 2015-11-19 2016-11-17 A method for performing a verification of the integrity of the application of the target device
EP20160797889 EP3378005A1 (en) 2015-11-19 2016-11-17 Method to verify the execution integrity of an application in a target device
KR20187014060A KR20180084053A (en) 2015-11-19 2016-11-17 How to verify the integrity of the applications running on the target device

Publications (1)

Publication Number Publication Date
WO2017085159A1 true true WO2017085159A1 (en) 2017-05-26

Family

ID=54843588

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2016/077932 WO2017085159A1 (en) 2015-11-19 2016-11-17 Method to verify the execution integrity of an application in a target device

Country Status (4)

Country Link
EP (1) EP3378005A1 (en)
KR (1) KR20180084053A (en)
CN (1) CN108292341A (en)
WO (1) WO2017085159A1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050132031A1 (en) * 2003-12-12 2005-06-16 Reiner Sailer Method and system for measuring status and state of remotely executing programs
EP2282474A1 (en) * 2009-07-08 2011-02-09 Uniloc Usa, Inc. System and method for secured mobile communication
US20110173643A1 (en) * 2008-10-10 2011-07-14 Nicolson Kenneth Alexander USING TRANSIENT PCRs TO REALISE TRUST IN APPLICATION SPACE OF A SECURE PROCESSING SYSTEM

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050132031A1 (en) * 2003-12-12 2005-06-16 Reiner Sailer Method and system for measuring status and state of remotely executing programs
US20110173643A1 (en) * 2008-10-10 2011-07-14 Nicolson Kenneth Alexander USING TRANSIENT PCRs TO REALISE TRUST IN APPLICATION SPACE OF A SECURE PROCESSING SYSTEM
EP2282474A1 (en) * 2009-07-08 2011-02-09 Uniloc Usa, Inc. System and method for secured mobile communication

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
JUAN A GARAY ET AL: "Software Integrity Protection Using Timed Executable Agents", PROCEEDINGS OF THE 2006 ACM SYMPOSIUM ON INFORMATION, COMPUTER AND COMMUNICATIONS SECURITY, ASIACCS 2006, 21 March 2006 (2006-03-21), Taipei, Taiwan, XP055271649, Retrieved from the Internet <URL:https://pdfs.semanticscholar.org/3e09/516be0436e6aecd77c993ee88542fef1e24c.pdf> [retrieved on 20160510] *
None
XIN HUANG ET AL: "An Effective Approach for Remote Attestation in Trusted Computing", PROCEEDINGS. THE 2009 INTERNATIONAL SYMPOSIUM ON WEB INFORMATION SYSTEMS AND APPLICATIONS (WISA 2009), 22 May 2009 (2009-05-22), Nanchang, P. R. China, pages 80 - 83, XP055271456 *

Also Published As

Publication number Publication date Type
EP3378005A1 (en) 2018-09-26 application
KR20180084053A (en) 2018-07-24 application
CN108292341A (en) 2018-07-17 application

Similar Documents

Publication Publication Date Title
Levin et al. TrInc: Small Trusted Hardware for Large Distributed Systems.
US6871276B1 (en) Controlled-content recoverable blinded certificates
US6647494B1 (en) System and method for checking authorization of remote configuration operations
US20070300057A1 (en) Dynamic Web Services Systems and Method For Use of Personal Trusted Devices and Identity Tokens
US20120324236A1 (en) Trusted Snapshot Generation
US20130283362A1 (en) Authenticating user through web extension using token based authentication scheme
US20120066510A1 (en) Methods, systems, and computer program products for performing homomorphic encryption and decryption on individual operations
Bellissimo et al. Secure Software Updates: Disappointments and New Challenges.
US20130318357A1 (en) System and Method for Secure Software Update
US7080249B1 (en) Code integrity verification that includes one or more cycles
US20100082987A1 (en) Transparent trust validation of an unknown platform
US20120110337A1 (en) Method and system for restricting execution of virtual applications to a managed process environment
US7891012B1 (en) Method and computer-usable medium for determining the authorization status of software
US20080083039A1 (en) Method for integrity attestation of a computing platform hiding its configuration information
US20140258736A1 (en) Systems and Methods for Maintaining Integrity and Secrecy in Untrusted Computing Platforms
US20100169654A1 (en) Method for author verification and software authorization
US20120324229A1 (en) System and method for generating keyless digital multi-signatures
US20090252327A1 (en) Combination white box/black box cryptographic processes and apparatus
JPH10301773A (en) Information processor and method therefor and recording medium
US20090132830A1 (en) Secure processing device, secure processing method, encrypted confidential information embedding method, program, storage medium, and integrated circuit
Stumpf et al. Improving the scalability of platform attestation
US20040153646A1 (en) Distributed control of integrity measurement using a trusted fixed token
US20080104403A1 (en) Methods and apparatus for data authentication with multiple keys
Yuan et al. Public integrity auditing for dynamic data sharing with multiuser modification
CN101834860A (en) Method for remote dynamic verification on integrality of client software

Legal Events

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

Ref document number: 16797889

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 11201803707P

Country of ref document: SG

ENP Entry into the national phase in:

Ref document number: 20187014060

Country of ref document: KR

Kind code of ref document: A

NENP Non-entry into the national phase in:

Ref country code: DE

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112018010120

Country of ref document: BR