Property Based Token Attestation in Mobile Computing Thinh Le Vinh, Hervé Cagnon, Samia Bouzefrane, Soumya Banerjee

Property based Token Attestation in Mobile Computing Thinh Le Vinh, Hervé Cagnon, Samia Bouzefrane, Soumya Banerjee

To cite this version:

Thinh Le Vinh, Hervé Cagnon, Samia Bouzefrane, Soumya Banerjee. Property based Token Attes- tation in Mobile Computing. Concurrency and Computation: Practice and Experience, Wiley, 2020, 10.1002/cpe. hal-02920654

HAL Id: hal-02920654 https://hal.archives-ouvertes.fr/hal-02920654 Submitted on 24 Aug 2020

HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. CONCURRENCY AND COMPUTATION: PRACTICE AND EXPERIENCE Concurrency Computat.: Pract. Exper. 2010; 00:1–24 Published online in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/cpe

Property based Token Attestation in Mobile Computing

Thinh Le Vinh1, Herve´ Cagnon1, Samia Bouzefrane1∗, Soumya Banerjee2

Conservatoire National des Arts et Me´ tiers Paris, France1, Birla Institute of Technology Mesra, India2

SUMMARY

The surge of the presence of personal mobile devices in multi-environment makes a signiﬁcant attention to the mobile cloud computing. Along with this concern, security issues also appear as a barrier to prevent the propagation of this trend. This paper focuses on an important feature in many security protocols and application, which is the device attestation in the Mobile Cloud Computing (MCC). The existing remote attestation mechanisms are currently used in trusted computing environment such as Binary Attestation and Property based Attestation. In this paper, by taking advantage of the combination of technologies and trends, such as Trusted Platform Module (TPM), Cloud Computing, and Bring Your Own Device (BYOD), we introduce Property based Token Attestation (PTA) to secure the mobile user in the enterprise cloud environment. In order to accomplish a secure MCC environment, security threats need to be studied and acted accordingly, and therefore, we ﬁrst represent the common threats and then explain a novel attestation schema for addressing these threats by providing security proofs. In addition, Scyther is in use to verify the correctness of our protocol. Copyright c 2010 John Wiley & Sons, Ltd.

Received . . .

KEY WORDS: Security; TPM; Mobile Computing; Attestation; BYOD; MCC.

1. INTRODUCTION

As the proliferating quickly of the pace of mobile devices, we are aware that each year a wide variety of devices in different factors, improved capabilities, and more intelligence are published to the market. According to Cisco [1], global mobile devices and connections grow to around 8.3 billion in 2016. It predicts that this trend will grow to 11.6 billion by 2020. Mobile devices have become an essential part of human life for serving daily activities. Since cloud computing has been recognized as the next generation of computing infrastructure, mobile computing takes full advantage of the availability of Cloud computing facilities to reduce its limitation such as user scalability, data storage, data processing ability in heterogamous resources environment, and energy saving [2]. In addition, with the existing of personal mobile devices in workplace, most organizations have realized the business beneﬁts like cost savings, job satisfaction and increased employee productivity

∗Correspondence to: Samia Bouzefrane; E-mail: [email protected]; 292 Rue Saint-Martin, 75003 Paris †

Copyright c 2010 John Wiley & Sons, Ltd. Prepared using cpeauth.cls [Version: 2010/05/13 v3.00] 2 THINH ET AL. as personally o wned de vices can serv e for either corporate purposes or personal needs. This concept is called Bring Y our Own De vice. By turning b usinesses mobile, it is considered as a significant trend that transcends both industry and geographical boundaries [3, 4]. Ho we v er , in BY OD concept, it also poses a number of security risks which threaten compan y’ s sensiti v e b usiness data. Furthermore, with the constrained resource, mobile de vices lack of sophisticated methods to secure themselv es against the risks associated with security and pri v ac y . In the end, information is vital and all possible measures need to be e v aluated and implemented for security purpose. By supporting hardware to pro vide security primiti v es independent from other system components, the concept of trusted computing is not ne w and is described in man y researches. A specific example of trusted computing technology is Remote Attestation which enables a computing system to measure properties of a remote system in such a way that the remote system will be detected if it is compromising. The properties of platform or application can be used to define security requirements in order to satisfy the basic term C.I.A (Confidentiality , Inte grity , Authentication) of system security . The T rusted Platform Module (TPM), as de v eloped by the T rusted Computing Group (TCG), has been specifically designed to be a b uilding block for trusted computing. It is a significant use in industry and go v ernment, for e xample: Bitlocker for dri v er encryption in Microsoft and security solution for laptops in the United States Department of Defense [5]. W ith its functionalities, the TPM protects the computing system be yond the user’ s control to against a deliberate or accidental attack. By considering the TPM’ s functionalities, we of fer suggestions about a no v el schema of property-based attestation suitable for use with the token based authentication. The main contrib utions of this paper are two-fold: First, we present a Pr operty based T oken Attestation (PT A) as well as the T oken of random properties that relied on the literature of property-based attestation. Second, our proposed protocol is v erified by using Sc yther which is a cryptographic protocol v erification tool. The rest of the paper is or ganised as follo ws: we be gin in Section 2 by representing the background related to our work including the e xisting remote attestation mechanisms. T o achie v e a secure MCC, the possible scenario and its threats are pointed out in Section 3. W e then figure out ho w to address these threats by introducing a proposed protocol in Section 4. After analysing the security proofs in Section 5, we discuss the main concerns of security with the proposed protocol including the Sc yther in Section 6. Section 7 presents the e xisting solutions with their pros and cons while e xplaining ho w dif ferent between our solution and theirs. Finally , we dra w the conclusion and refer to the ne xt step.

2. B A CKGR OUND

2.1. Mobile Cloud Computing

In the recent years, the term of Cloud has become the technology trend and ubiquitous in the computing ecosystem. T o address the challenges in the computing world such as user scalability , data storage, data processing ability in heterogeneous resources en vironment, and ener gy sa ving, Cloud Computing deli v ers the latest services; namely Network as a Service (NaaS), Infrastructure as a Service (IaaS), Platform as a Service (P aaS), Software as a Service (SaaS) and Storage as a Service (ST aaS) to abstract all types of computing resources as services [2]. As a result, the shared

Copyright c 2010 John W iley & Sons, Ltd. Concurr ency Computat.: Pract. Exper . (2010) Copyright c 2010 John Wiley & Sons, Ltd. Pr epar ed using cpeauth.cls DOI: 10.1002/cpe Prepared using cpeauth.cls [Version: 2010/05/13 v3.00] PR OPER TY B ASED T OKEN A TTEST A TION IN MOBILE COMPUTING 3

(a) MCC Architecture (b) Client-Server Mode

Figure 1. Mobile Cloud Computing architecture and Client-Server Model

Cloud infrastructure services work as the utility: the users with their de vices can access and pay for what services the y need from remotely hosted resources o v er the Internet. These services not only upgrade automatically b ut also easily scale up or do wn. Mobile Cloud Computing (MCC) is vie wed as the combination of Cloud Computing and mobile networks to bring benefits for mobile users, while augmenting the resource-constraint mobile de vices with v aried Cloud-based resources in terms of data storage, computation and ener gy . Although MCC’ s architectures can be classified into man y cate gories, the figure 1a [6] represents the general architecture of MCC. T o propose a global security solution for MCC in this paper , the traditional Client- Serv er model of MCC is used to adapt for a proposed solution. Theoretically , Mobile Cloud computing aims to prolong the capabilities of storage/computation-limited de vices and to pro vide seamless access to data/application on a remote resource rich serv er from an ywhere. In Figure 1b, a remote Cloud serv er acts as a service pro vider to mobile de vices. The network connecti vity from the de vice to the Cloud serv er needs to be optimized to ensure the quality of service and seamless hando v er . Based on this model, our work is to answer the question on ho w to b uild a secure and trust en vironment for MCC. In common computing en vironment, security issues remain a challenge, such as inte grity , anon ymity , confidentiality , authenticity , and non-repudiation. T o address these issues, there are man y solutions to protect our system, namely anti-virus, fire walls and cryptography . Ho we v er , these solutions require a platform that the y can trust to work. This platform refers to the trusted platform. According to Balachef f et al. [7], the trusted platform is defined as a computing platform that has a trusted component, which is used to create a foundation of trust for software processes. In our conte xt, the T rusted Platform Module (TPM) is implemented to enable this foundation of trust to pro vide a set of security features.

2.2. T rusted Platform Module

The T rusted Platform Module (TPM) is a hardware platform with encryption computing unit and secure storage component. TPM is dedicated to PCs, serv ers, printers, or mobile phones to enhance security in an ordinary and non-secure computing platform and to con v ert them into trust en vironments. F or mobile de vices, Mobile T rusted Module (MTM) [8] refers to this secure hardware chip. TPM is the core component of T rusted Computing Group (TCG) which is a consortium

Copyright c 2010 John W iley & Sons, Ltd. Concurr ency Computat.: Pract. Exper . (2010) Pr epar eCd oupsyinrgig chpt e cau2t0h1.c0l sJohn Wiley & Sons, Ltd. DOI: 10.1002/cpe Prepared using cpeauth.cls [Version: 2010/05/13 v3.00] 4 THINH ET AL. of companies: Compaq, HP , IBM, Intel, Microsoft, AMD, etc. [9, 10]. By supporting protection of cryptographic ke ys, random number generation, cryptographically binding data to certain system configuration, sealing data in the configuration of the application and platform/application authentication [11], TPM implements mechanisms and protocols to ensure that a platform has loaded its software properly . By protecting the system at hardware le v el, TPM is also kno wn as the primiti v e security that allo ws af fordable authentication, encryption, and network access to be e x ecuted on a v ariety of computing platforms. It stores secret ke ys to encrypt data files/messages, to sign data, etc. In addition, TPM is equipped with a set of special re gisters like the PCR (Platform Configuration Re gister) to store inte grity metrics. These metrics are used to measure the inte grity of an y code from BIOS to applications. Therefore, P CR0 → P CRn (n= 23 with TPM 2.0) pro vide e vidence of a certain state of the system. F or e xample, each time when the system e v ent occurs, TPM computes the hash of a metric v alue and e xtends to the PCR associated with the occurred e v ent. The operation to e xtend ne w v alue to the PCR is

PCRne w v alue= Digest of (PCR old v alue|| data to e xtend) [10]

In remote attestation as discussed later , it is important to kno w that the user communicates with a genuine TPM. The computing platform uses its TPM’ s Attestation Identity K e y (AIK) to sho w its identity and pro vide its v alid e vidence with other parties. The pri v ate part of AIK is also used to sign message/data.

Remote Attestation. Remote Attestation (RA) is a mechanism for either authenticating to a remote entity or v alidating the inte grity of the application/ platform. Currently , the point of vie w in remote attestation is full of change and v ariety . Depending on dif ferent research aspects, RA can be cate gorized into two mechanisms and three techniques to serv e for the same goal of the remote attestation which is to ensure the trustworthy of the current platform/applications. The former is Binary Attestation and Property Based Attestation [12]. The latter is Hardware-based, Software-based, and Hybrid technique [13]. The remote attestation is also one of the most important functionalities supported by the TPM. It is used for software or hardware to pro v e its identity /trusted state/configuration with the third party . Generally speaking (See Fig. 3), when platform A (Attester) requests access to the protected resources on the platform V (V erifier), before granting a right to access, V requires a de vice attestation to confirm the trusted state of A. Platform A then pro vides some measurement data which represent the state of the de vice as an e vidence of its inte grity . T o appro v e the resource request, the platform V v erifies recei v ed e vidence to determine whether the platform is in an e xpected state.

The TCG attestation mechanism is sometime called Binary Attestation. It enables the Attester to pro vide its e vidence for the V erifier . V then e v aluates the kno wledge of the recei v ed AIK called Certificate of AIK, which can be pro vided by a trusted third party (Pri v ac y Certification Authority), to v erify the signature on the A ’ s PCR v alue. After recalculating/comparing the recei v ed v alue of PCR, the platform V determines the platform A ’ status and the reporting content’ s authenticity . Besides the adv antages of Binary Attestation (B A), it remains some dra wback as described in [11, 12, 14]: 1) Pri v ac y violation: it discloses the complete information about the hardware and

Copyright c 2010 John W iley & Sons, Ltd. Concurr ency Computat.: Pract. Exper . (2010) Pr epar ed using cpeauth.cls DOI: 10.1002/cpe PR OPER TY B ASED T OKEN A TTEST A TION IN MOBILE COMPUTING 5

Figure 2. Remote Attestation software configuration of all platforms; 2) Fle xibility limit: data is sealed to a certain platform configuration. As a consequence, this data is inaccessible after a change of system configuration such as update, patch, and back up; 3) Scalability: it does not necessarily imply that the platform complies with desired properties. In the other hand, another approach of attestation is founded on the Binary Attestation, called Property-based Attestation (PB A). This approach not only relies on the TPM functionalities to v erify the e vidence of platform b ut also requires a trusted third party to issue a Certificate of Property . Instead of attesting binary v alues, platform/ application’ s properties, functions, or beha viors are attested to pre v ent binary information leaking. The principle of PB A is that v arious platforms may ha v e the same properties which fulfilling the same requirement re gardless a v ariety of platforms and components. In comparison with B A, Aarthi et al. [12] stated the follo wing adv antages of PB A: 1) Properties do not re v eal implementation details of a system and can therefore hide system vulnerabilities; 2) Properties may not identify components and may pro vide a certain le v el of pri v ac y . 3) Properties of components may not change as often as hash v alues particularly during updates; 4) Properties are easier to understand and can be useful to write meaningful access control policies rather than using an e xcess of binary v alues. Ho we v er , each mechanism has its o wn pros and cons. By taking the adv antage of a v ailability of either B A or PB A facilities, our work not only lo wers the shortcomings of e xisting mechanisms b ut also proposes a ne w schema of attestation based on the token which contains particular authenticated information for obtaining a specific data.

3. SCEN ARIO AND THREA TS

3.1. Scenario

Bring Y our Own De vice (BY OD); this term has become a signiﬁcant trend not only no w b ut also in the future as it combines the beneﬁts of the enterprises and the employees. Besides its adv antages, BY OD still remains a dark side probably putting a compan y’ s b usiness system at risk. In the BY OD conte xt, we consider our proposed solution to address the e xisting challenges: 1) The employee with her o wn de vice which can be compromised to access restricted b usiness data; 2) The user tries to access data which is not a v ailable for his le v el; 3) The employee quits her job b ut keeps accessing b usiness data. By o v ercoming these issues, our work interests a real-world use case. Considering in b usiness conte xt, the employee can use her o wn phone for personal purposes such as F acebook, T witter

Copyright c 2010 John W iley & Sons, Ltd. Concurr ency Computat.: Pract. Exper . (2010) Pr epar ed using cpeauth.cls DOI: 10.1002/cpe 6 THINH ET AL. etc.; she can also install a compan y application for carrying out her work responsibilities. F or daily working, depending on her working role and le v el, she wants to access or recei v e sensiti v e b usiness data such as b usiness contract, strate gy; these data can be stored locally or globally . In this case, her phone needs to be pro v ed its secure e vidence before being granted a right to access or recei v e speciﬁc information.

3.2. Thr eats

Although BY OD is quickly becoming the ne w standard in workplace technology , there are a number of security risks associated with it. W ithout fully understanding and controlling, the term BO YD can be turned into Bring Y our Own Danger/Disaster . In fact, threats on BY OD are quite similar to that of the mobile cloud computing. The dif ference only is that the user increases the risks by more e xposing her de vices because of multi-working en vironments and the enterprise is out of control in the de vice’ s using circumstances, such as selling, b uying, or maintaining. F or this moment, there are only three in v olv ed parties in our protocol. W e assume that the cloud side, including the T rusted Third P arty and the enterprise serv er , is secure. W ithin this scope of article, vulnerabilities in Cloud are ne glected. Before discussing the goal of our proposed solution to address the follo wing listed threats in Section 6, we be gin by shortlisting the common threats rele v ant to the enterprise mobile user .

1. V ulnerability. The mobile de vice is considered as the resource-constraint de vice with the limitation of data storage, computation, and ener gy . So it is not often installed with sophisticated anti-virus application. F or pri v ate using, the mobile also contains man y pri v ac y issues and insuf ﬁcient data encryption processing. This makes the mobile or tablet prone to attack. 2. Leakage of data. There is a risk that software can deliberately/accidently leak data; or a bad user can use a compromised application to obtain le gitimate access. In BY OD conte xt, the mobile user is responsible for de vices/ software patch updates. It is to increase the risk of data leakage due to b uggy/ malicious software or untrustworthy employees. 3. Miscellaneous data. The enterprise as well as personal data are often stored in the same local de vice storage. In some cases, a malware injected without an y user a wareness could ﬁnd a way to harm the enterprise data. 4. Car eless using. There are man y attracti v e mobile applications for daily using. Ho we v er , these apps are not always free or suitable for mobile platforms. As a result, the user tends to modify her mobile platform by rooting/ jailbreaking it. Root/Jailbreak is not really bad b ut it is not suitable in the BO YD conte xt where the platform cannot be e xposed. In addition, lost and stolen are the other risk factors to breach the security of mobile de vices.

4. PR OPOSED SOLUTION

In pre vious sections, we present the current techniques and the use case for moti v ating the creation of software token based TPM. In this section, we present our proposed solution, namely Pr operty based T oken Attestation (PT A), which takes the adv antage of the e xisting solutions to adapt the

Copyright c 2010 John W iley & Sons, Ltd. Concurr ency Computat.: Pract. Exper . (2010) Pr epar ed using cpeauth.cls DOI: 10.1002/cpe PR OPER TY B ASED T OKEN A TTEST A TION IN MOBILE COMPUTING 7 security of mobile de vice in the Mobile Cloud Computing. Generally , in our solution (See Fig. 3), the Employee needs a v alid T oken pro vided by the trusted Third P arty to access compan y’ s resources. T o obtain this T oken, she has to sho w her secure e vidence of hardware/software platform to the Third P arty , which pro vides cloud-based security . After e v aluating user’ s e vidence, the Third P arty then issues the corresponding T oken based on recei v ed v alid e vidence. The T oken, in this case, works as The Letter of Intr oduction. W ith this T oken, the Employee can access her speciﬁc data for a limited time. The Enterprise’ s role is to e v aluate the recei v ed T oken to enable the employee to access its resource by outsourcing its security service to the Third P arty . P articularly , the enterprise can dele gate its security to a Cloud acting as a Security as a Service platform b ut it can be a pri v ate or a hybrid Cloud as well.

4.1. Deﬁnition of pr operty and trust token

The property in PB A mechanism is used to describe the beha viour of a platform or program without re v ealing its configuration. Ho we v er , the definition of property to be attested is a broader scope. Thus, e v erything related to platform or application can be considered as property [12]. In this issue, we attest abstract properties of program’ s classes to define the security requirements. F or instance, the application has three classes: Class A has properties where (α1, . . . , αN) ∈ α. Similarly , Class B and C ha v e β and γ respecti v ely . The acti v e TTP has a kno wledge of this property collection, namely a property list (P L) = (α, β, γ). Meanwhile, Ω ∈ (α ∪ β ∪ γ) is a subset of property; SP = {Low, Med, Hi} is a set of security le v els which is defined by the enterprise security polic y . Depending on the v alue of SP , Ω will be generated by the application service. As a result, the random property list Pi is established at run time as P i = P L\Ω. The inte grity of Pi is ensured and v erified by a reserv ed PCR and the acti v e TTP respecti v ely . In addition, we use a recomputed Nonce of in v olv ed parties using Dif fie-Hellman e xponentiation function as security property as well. After recei ving and v erifying the e vidences from the client, the TTP signs a trust credential to certify the trustworthy of the specific application. This trust credential is referred to a trust T oken for the authentication of the client. The T oken consists of the proof, such as Pi, T imestamp, and r ecomputed Nonce etc. to pro v e the client’ s trustworthiness to the enterprise.

Figure 3. Property based T oken Attestation

Copyright c 2010 John W iley & Sons, Ltd. Concurr ency Computat.: Pract. Exper . (2010) Pr epar ed using cpeauth.cls DOI: 10.1002/cpe 8 THINH ET AL.

4.2. Assumptions

In this work, we present the Property T oken which contains random properties. The quantity of the property is used to set the polic y for accessing or for security le v el. W e assume each application has its o wn property list (PL). The third party who pro vides Software/Security as a Service to the Enterprise manages this list. In the client side, the mobile de vice can generate a list of random properties (Pi) which is compared to the third party’ s property list (PL) later . W e also assume that the TPM is equipped for all in v olv ed parties, especially for the mobile client. This TPM generates a ke y pair to perform asymmetric cryptography . Before describing the protocol, the follo wing pre- conditions need to be satisﬁed. The Enterprise (V)

• V is the enterprise who outsources its security service for the T rusted Third P arty (TTP) • V and TTP set a security polic y for the employee M based on the T oken issued by TTP . • V grants permission for its employees to access resources if the employees satisfy its requirements.

The T rusted Third Party (TTP)

• TTP is the or ganization which pro vides Cloud based security (XaaS) i.e. Software/Security as a Service • TTP is responsible for checking v alid M, either hardware or software. • TTP has kno wledge of its pro vided services and clients such as Application ID, Pr operty List, and Certiﬁcate of Attestation Identity K e y of M (See Fig. 3). • The Public-K e y Cryptosystem is used for securing data transmission between TPP and V only to pre v ent the compromised M.

The Mobile client (M)

• M is an employee who asks to access V’ s data or carries out some tasks in e xtension model, for e xample of ﬂoading or migration. • Depending on M’ s role in the enterprise, she can access a speciﬁc data only . • M installs an application securely and logs in with the user ID and password successfully .

The T oken (Tk)

• Tk can be considered as a trusted proof for the employee M to access a secure resource. • Tk is issued to M by TTP if M’ s hardware/software platform e vidences pass the attestation process. • As discussed earlier , Tk consists of the le v el of security based on the random property list (Pi). It is assumed, for a specific application, that the software pro vider (TTP) has a full list of application properties (PL) which can be defined in class le v els. The application also has a special service for picking and generating a random property list for the mobile client. F or e xample, as demonstrated in the figure 4, the PL consists of twenty six properties (a-z) of application while a quantity of matched properties (Pi) refers to a le v el of security as higher number higher le v el. Let call p a property; M1 and M2 are clients with their le gal Pi. Then their inte grity is v erified successfully . While M3 with its compromised Pi, M3 will be discarded. W e ha v e the follo wing attestation conditions.

Copyright c 2010 John W iley & Sons, Ltd. Concurr ency Computat.: Pract. Exper . (2010) Pr epar ed using cpeauth.cls DOI: 10.1002/cpe PR OPER TY B ASED T OKEN A TTEST A TION IN MOBILE COMPUTING 9

P i ⊂ P L | P i 6 = 0 W ith p ∈ P i & p ∈ P L If (∀p ∈ (P i ∪ P L))T hen P ass If (∀p ∈ P i & ∃p ∈/ P L)T hen F ail

Figure 4. Property e vidence

4.3. System Ar c hitectur e

In this architecture, there are three in v olv ed parties in working out a solution. The TPM is equipped to both mobile de vice and remote serv er . The Figure 5, which is a high le v el architecture, sho ws the communication among them. These parties include the Client who be gins the process with her mobile phone by asking indirectly for a property token (PT) from the T rusted Pr operty P arty (TPP); the Enterprise (V), which is considered as a resource pro vider or a v erifier . Note that the Certificate of AIK can be obtained easily by either Pri v ac y- Certification Authentication (P-CA) or Direct Anon ymous Attestation (D AA) [15, 16, 17]. Hence, in this conte xt, we assume that TPM has its o wn Certificate of AIK.

Figure 5. Property based T oken Attestation model

Copyright c 2010 John W iley & Sons, Ltd. Concurr ency Computat.: Pract. Exper . (2010) Pr epar ed using cpeauth.cls DOI: 10.1002/cpe 10 THINH ET AL.

4.4. Pr operty based T oken Attestation Pr otocol

W e start the section by e xplaining the structure of PT A protocol in high le v el. After recalling the necessary notations, we present the detail of message sequence charts of PT A protocol in 4.4.2.

4.4.1. Gener al Overvie w of the PT A pr otocol. Before discussing the structure of the proposed protocol, we recall the follo wing notations that ha v e been used in this article.

- TTP: is the software pro vider with a ke y pair (SKTT P , PKTT P ). TTP has a Property List (PL).

- M: is the mobile identiﬁed by MID that has an App installed from TTP with a ke y

pair(SKAIK, PKAIK). This ke y pair is the result of remote attestation protocol used to attest the trust of M.

- the Enterprise (V) that has data to be accessed by App of M with a ke y pair (SKV , PKV ).

- V has a list of mobile identities authorized to access to V’ s data. Hence, MIDmust be re gistered within V . - Application can be an y software or speciﬁc software of V a v ailable from TTP . App is installed with its o wn properties which represent App’ s beha viors. - Hash (Message) computes the hash of Message.

- (Hash(Message), Message)PKX demonstrates the hash is follo wed with the same data in clear te xt. The whole encrypted by the public ke y of X to guarantee the conﬁdentiality of the message.

- XID denotes the identity of party X.

- TX refers to the timestamp which is generated by party X to a v oid replay attacks

- NX is the nonce of party X.

- NX ∗ NY is the shared nonce v alue which is computed by Dif ﬁe-Hellman e xponentiation [18] between X and Y only . - ML is the measurement list that contains the measurement v alue of all the entity in the computing platform, for e xample the measurement of random desired properties in this conte xt. In other words, ML contains the ﬁngerprint list of the entities. ML is used for the inte grity measurement with TPM.

- (Message)PKX is the Public-K e y Cryptosystem for secure data transmission among in v olv ed parties.

Before using the protocol, there are two initial steps. One is related to remote attestation to attest that the mobile de vice is a trust en vironment based on TPM and that allo ws getting the Certificate of AIK. The other described in the follo wing is related to the way to obtain properties Pi for the app. W ithin the scope of the paper , we do not discuss the process to obtain the Certificate of AIK that is described in detail [17]. W e assume that the user logs in with his Id and P assword successfully to V’ s platform. After v erifying online user information (this is the user authentication step) by V , the v erified result, which may indicate user’ s access le v el, user role, or re gistered services, will return to the application. Based on this result, the trusted service/ trusted part of application within M will generate a random Pi. The Pi cannot either be af fected by application/platform’ s update or re v eal app/platform’ s configuration. It satisfies the feature of property based attestation.

Copyright c 2010 John W iley & Sons, Ltd. Concurr ency Computat.: Pract. Exper . (2010) Pr epar ed using cpeauth.cls DOI: 10.1002/cpe PR OPER TY B ASED T OKEN A TTEST A TION IN MOBILE COMPUTING 11

T o pre v ent a compromised Pi, TTP also has kno wledge of user le v el by e xchanging information with V . F or example, if the attacker can modify the Pi before TPM’ s e xtend operation, TTP will terminate a process due to the in v alid quantity or quality (matched properties) of compromised Pi. In case the user loses his Id and password, the attacker with their o wn de vices can obtain the v eriﬁed result. Ho we ver , asking for the token to access data is denied thanks to the remote attestation of TPM.

4.4.2. Dataﬂow of PT A pr otocol. T o depict the general o v ervie w of PT A protocol, the message sequence is represented as the follo wing chart.

Figure 6. The overvie w message exchange of PT A protocol

In which, M has an app that wants to access to V’ s data according to BY OD concept. Because V dele gates its mobile user authentication to TTP , V requests TTP the certificate of M pro ving its platform attestation. After some v erification, TTP sends the certificate to V so that V can discuss with the le gitimate M. M requests the token from TTP , by pro ving that V and M are authentic entities. Then, TTP sends the token either to M or to V . Hence, V can check that the token recei v ed from M is the same with the one recei v ed from TTP , which allo ws V to grant access to M’ s app. In flow 1, M initiates a message with MID, nonce NM and a timestamp TM to start the communication. The generation of these parameters is achie v ed thanks to the TPM of M. Only recei v er V can decrypt this message using his pri v ate ke y . Ho we v er , due to a lack of kno wledge of

CERTAIK, V cannot decrypt the hash v alue. V needs this certificate to e xtract the hash v alue to compare it with the calculated one and check the identity of M. It is why in flow 2, V asks TTP for CERTAIK by sending its o wn NV 1 and MID. According to our assumption, TTP (acting as a V erifier) has obtained this certificate from PCA or D AA during binary attestation. TTP decrypts the message using its secret ke y , and checks the inte grity of (MID, NV 1). It then uses MID to

find M’ s certificate CERTAIK that he will send in the ne xt step. In response to V , TTP flow 3 generates the nonce NTT P 1 and sends it to V along with the hash v alue of NV 1 ∗ NT T P 1 and the public ke y AIK of TPM/M that he has. V then decrypts the message to get PKAIK, NTT P 1. T o a v oid the compromised message, V re-computes and compares a ne w hash v alue with recei ved hash v alue such as Hash(P KAIK, SavedNV 1 ∗ ReceivedNT T P 1) and Hash(PKAIK, NV 1 ∗ NT T P 1)

Copyright c 2010 John W iley & Sons, Ltd. Concurr ency Computat.: Pract. Exper . (2010) Pr epar ed using cpeauth.cls DOI: 10.1002/cpe 12 THINH ET AL. respecti v ely . No w V has the public ke y AIK of M/TPM. Ha ving a proof of AIK public ke y , V generates a nonce NV to work with M and computes NV and recei v ed NM as NV ∗ NM. Then, V sends the message as presented in ﬂow 4 to M. Using its secret AIK ke y , M obtains the recei v ed message and then decrypts the hash v alue with the public ke y of V . T o ensure the inte grity of recei v ed message, M computes a shared secret nonce NV ∗ NM by using its o wn NM and the recei v ed NV .

The result of NV ∗ NM is hashed together with VID and TV to make a comparison with the v alue of Hash(MID, VID, NV ∗ NM, TV ). If the y match, then M is sure about the identity of V . In the ne xt step, the mobile user M e xtends a random Pi to a reserv ed PCR by calling TPM Extend() command. Note that the PCR is e xtended with the random Pi for each attestation. As presented in flow 5, the message in pre vious flo w and the ML consisting of the fingerprint of Pi is sent together with an AIK signed v alue of the reserv ed PCR generated through the TPM Quote() command. When TTP recei v es the message from the mobile user , it first uses the kno wledge of AIK to v erify and decrypt the first sub-message, (P CR, P i)SKAIK. TTP then compares this PCR v alue against ne w PCR v alue, which is recalculated from the fingerprint of Pi within ML by applying the PCR’ s e xtend operation. If the y do not match, it implies that the inte grity of application is violated. TTP should terminate the communication. In addition, Pi is always used to check if Pi v alues are coherent compared to PL that is held by TTP as discussed earlier . Finally , the second hash v alue is used to ensure that the interaction is done ef fecti v ely with M. After v alidating the correctness of M and V’ s e vidence, TTP decides to generate and send a token either to M or V . TTP is sure that M is authentic thanks to the hash v alues (authentic TPM and M) recei v ed in flow 3, and that the app has consistent properties Pi thanks to flow 5. The token is signed by TTP to be sure that he is the issuer of the token. Only TTP has the ke y to perform this operation. Thus, this trust credential is composed of: (Hash(P i, MID, VID, NTT P ∗

NV ∗ NM, TT T P ))SKTT P where NTT P is a ne w nonce of TTP to create a shared secret nonce

NTT P ∗ NV ∗ NM and the duration of the token is decided by TT T P . The token is only v alid within

TTT P , otherwise it will be discarded automatically . In flow 6 and 7, the token has been deli v ered to M and V . Ha ving the essential data from pre vious flo ws, the recei v ers check the v alidity of the recei v ed token by re-computing the shared secret nonce NTT P ∗ NV ∗ NM. F or instance, M takes the v alue of NV ∗ NM obtained in flow 4 and the recei v ed NT T P to create the ne w shared nonce for the comparison. Finally , the mobile user (flow 8) can obtain the right to access to the specific data within the v alid duration TTT P . Thanks to the kno wledge of this trust token, Enterprise V can manage the access of their employees.

4.4.3. Security Pr operties Re vie w . In this part, we discuss briefly the follo wing security properties associated with the messages e xchanged for attestation purposes and sho w ho w our proposed protocol can be adapted to them. - Confidentiality : each message m sent from A to B is confidential. The confidentiality is guaranteed thanks to the encryption of m with the B’ s public ke y allo wing B to be the only entity that can decrypt m because the ke y used to decrypt the message is secret and held only by B. This property is applied for each flo w as sho wn in the protocol. F or e xample, in flow 1, when M sends a request to V , M encrypts with the public ke y of V to guarantee the confidentiality of the request containing sensiti v e data.

Copyright c 2010 John W iley & Sons, Ltd. Concurr ency Computat.: Pract. Exper . (2010) Pr epar ed using cpeauth.cls DOI: 10.1002/cpe PR OPER TY B ASED T OKEN A TTEST A TION IN MOBILE COMPUTING 13

- A uthenticity of the sender : to guarantee that sender A is the one who sends ef fecti v ely data d, A signs d with its secret ke y . F or e xample, in ﬂow 2 sent by V to TTP , the d =

(Hash(MID, NV 1)) is signed by V using its secret ke y SKV to ensure that only V can be the sender . - Data integrity:each time data d is sent by A to B; d is sent with the hash v alue of d. This process guarantees data inte grity because if clear data d is compromised, the computed hash v alue of d will be dif ferent from the one sent in the ﬂo w . F or e xample, in ﬂow 2,

d = (MID, NV 1) is compared with Hash(MID, NV 1). Moreo v er , Hash Extend operation is used throughout the TPM for the inte grity measurement. The v alue e xtended into PCR can reflect the entity’ s state. This operation is represented in flow 5 where the sender e xtends Pi into specific PCR and the recei v er has to re-calculate this v alue by using the same hash e xtend operation. - Shar ed secr et: the nonce is used to create a secret that is kno wn to all in v olv ed parties. The party outputs data to be stored for later use with the shared secret. When this data is later input, the party v erifies the shared secret to detect the v alidity of data. T ake flow 3 for a

speciﬁc e xample, instead of sending a whole v alue of shared secret NV 1 ∗ NT T P 1, a partial

v alue NTT P 1 is sent from TTP to V . The recei v er V should re-calculate and v erify this shared

v alue with its sa v ed NV 1.

5. SECURITY AN AL YSIS

Since V and TTP are assumed to be trust en vironments, our proof is related only to the beha vior of the mobile de vice M that may host malicious software and/or harmful data.

Pr oof 1: r elated to the r eception of messages by M. Compromising messages ﬂow 4 and ﬂow

6 means that we can ha v e access to the secret ke y SKAIK to decrypt the message. This can be possible if the ke y SKAIK is sa v ed within the memory of a malicious mobile de vice M. But since

M has been attested using its TPM (according to our assumption), this means that SKAIK is safely sa v ed in the EEPR OM of the TPM. By assumption, TPM cannot under go physical attacks, that is, TPM is a secure and trust en vironment. In addition, all the cryptographic operations are performed inside the TPM. In case M is not a le gitimate mobile de vice, M cannot decrypt the messages of ﬂow

4 and 6 because the malicious M does not ha v e the appropriate secret ke y SKAIK. This ke y is sa v ed in the TPM of M and changes each time the remote attestation protocol is used.

1. Flow 4 fr om V to M ((Hash(MID, VID, NV ∗ NM, TV ))SKV , VID, NV , TV )PKAIK

Let the message D=((Hash(MID, VID, NV ∗ NM, TV ))SKV , VID, NV , TV ) 0 2. Suppose there is a malicious mobile M who snif fs the message D. The secret ke y SKAIK of M is stored safely EEPR OM of TPM. By our assumption TPM cannot under go an y physical 0 attacks. So, M cannot get in an y way the ke y SKAIK. It is not possible to deri v e SKAIK from

PKAIK. As in public ke y cryptography , a public ke y and a secret ke y are mathematically related using one-way function, thereby making a unique combination of ke ys. No w , M0 has 0 0 an inappropriate secret ke y SKAIK where SKAIK 6 = SKAIK.

Copyright c 2010 John W iley & Sons, Ltd. Concurr ency Computat.: Pract. Exper . (2010) Pr epar ed using cpeauth.cls DOI: 10.1002/cpe 14 THINH ET AL.

0 0 3. No w , using the secret ke y SKAIK, M tries to decrypt the message. 0 0 0 0 0 0 d = [D]SKAIK = (A , VID, NV , TV ) 0 0 [A = decrypted value of Hash(MID, VID, NV ∗ NM, TV ))SKV using SKAIK] Whereas, if message D is decrypted by SKAIK, then we would get

d = [D]SKAIK = (A, VID, NV , TV )

[A = decrypted value of Hash(MID, VID, NV ∗ NM, TV ))SKV using SKAIK] 0 Here as, V is a trusted en vironment, M will not kno w VID, NV , TV , because D is encrypted 0 0 0 0 0 by PKAIK, not by the public ke y PKAIK of M . So, VID 6 = VID, NV 6 = NV , TV 6 = TV . T o a le gitimate M, [A]PKV = hv . . . .(i)

Le gitimate M kno ws MID, NM.

So, it calculates Hash(MID, VID, NV ∗ NM, TV ) = hv . . . .(ii) From (i) and (ii), M is sure about the identity of V . 0 0 0 0 But, to a malicious M , [A ]PKV = hv. Malicious M does not kno w NM, b ut it may or may

not kno w v alid MID. 0 0 0 (a) If M does not kno w MID, then it generates a MID and NM. No w , 0 0 0 0 0 0 0 Hash(MID, VID, NV ∗ NM, TV ) = hv1 6 = hv 6 = hv. The reasons are as follo ws: 0 0 - NM is a randomly generated number , so it is almost impossible to get NM = NM - It is v ery dif ficult to kno w an input x from h, where Hash(x) = h - Also finding another input z is v ery dif ficult where Hash(z) = h (b) Due to the same reasons as abo v e, when M0 kno ws MID, 0 0 0 0 0 0 Hash(MID, VID, NV ∗ NM, TV ) = hv2 6 = hv 6 = hv. As it is not possible by an y means for M0 to kno w hv and the inputs used in the Hash function, 0 0 M cannot get access in an y way VID, NV , TV , NM. So, it does not matter whether M kno ws MID or not; the message used in flow 4 will not be compromised unless it kno ws SKTT P . In case of message in flow 6 from TTP to M also, M0 cannot kno w in an y way

P i, VID, NTT P , NV , NM, TTT P , thanks again to the Hash function. So, the message used in ﬂow 6 will not be compromised unless it kno ws SKTT P . The same process follo ws for e v ery secret ke y of M, changed in each session the remote attestation protocol is used.

Pr oof 2: man in the middle. Assume that when M wants to send messages like in ﬂow 1 and 5, an attacker R intercepts the message on the network channel and tries to b uild the same message and send it to V . In this case, the information MID, nonce, etc. will be generated by the attacker . When V recei v es this request, it sends the information to the trust entity TTP . In this case, we can ha v e two situations:

- MID is not kno wn because it is for ged by the attacker; hence the attacker request will be rejected.

- MID is a v alid ID, the interaction is pursued between TTP/R and V/R. According to the

security le v el of MID of R and the properties Pi of R’ s app, the data access rights are dif ferent with those of the le gitimate M. In case the attacker R wants to decrypt the message m to modify m’ s data, it cannot because since the whole message is encrypted with a public ke y , only the recei v er (V in ﬂow 1 or TTP in ﬂow 5) of the message can decrypt the message and has access to its content.

Copyright c 2010 John W iley & Sons, Ltd. Concurr ency Computat.: Pract. Exper . (2010) Pr epar ed using cpeauth.cls DOI: 10.1002/cpe PR OPER TY B ASED T OKEN A TTEST A TION IN MOBILE COMPUTING 15

1. Message (intended to V from M in Flow 1)

((Hash(MID, NM, TM))SKAIK, MID, NM, TM)PKV

At this stage, public ke y of M is only a v ailable to TTP . V and others do not kno w PKAIK. Attacker R present in between M and V intercepts the message to make V think that R is the actual sender of the message and to make M think that R is the actual V . So, R no w has

the message: ((Hash(MID, NM, TM))SKAIK, MID, NM, TM)PKV . R kno ws the public ke y

of V b ut does not kno w the secret ke y SKV of V . From pr oof 1, we kno w that a message encrypted by the public ke y of the recei v er can only be decrypted by the actual recei v er using appropriate secret ke y . Thus, R cannot decrypt the message and therefore it has no access to the contents of the message. No w , R tries to b uild the same message as recei v ed and generates 0 0 0 MID and NMand TM. Also, R does not kno w the secret ke y SKAIK of M. So, R generates a 0 0 public ke y and pri v ate ke y pair as (PKAIK, SKAIK). No w , it tries the b uild the same message. 0 0 0 0 0 0 0 Hence, the message is no w: ((Hash(MID, NM, TM))SKAIK, MID, NM, TM)PKV . R sends this message to V . 2. V has no information to check whether it has come from M or not, because V does not kno w

MID, NM, TM. As, V has not CERTAIK, V cannot decrypt the hash v alue. So, V cannot check the identity of R or M. 0 0 0 0 0 0 0 V :[((Hash(MID, NM, TM))SKAIK, MID, NM, TM)PKV ]SKV 0 0 0 0 0 0 0 = ((Hash(MID, NM, TM))SKAIK, MID, NM, TM) 0 0 0 So, V kno ws MID, NM, TM. No w , V generates NV 1. 3. T o kno w the identity of the sender , V requests certiﬁcate CERTAIK to TTP , by sending the 0 0 message from V to TTP: ((Hash(MID, NV 1))SKV , MID, NV 1)PKTT P . 0 0 4. TTP:[((Hash(MID, NV 1))SKV , MID, NV 1)PKTT P ]SKTT P 0 0 0 = ((Hash(MID, NV 1))SKV , MID, NV 1) So, TTP has no w MID, NV 1. TTP also checks the 0 inte grity of (MID, NV 1). T o adapt to two abo v ed situations we ha v e: 0 Case 1: MID is not known to TTP . 0 TTP: CERTAIK[MID] is not found. So, TTP rejects the request of V . So, in this case1, Man in the Middle attack cannot occur . 0 Case 2: MID is a valid ID and known to TTP . 0 0 0 TTP : CERTAIK[MID] found. So, the public ke y against MID which is PKAIK is obtained. 0 0 TTP to V : ((Hash(PKAIK, NV 1 ∗ NT T P 1))SKTT P , PKAIK, NTT P 1)PKV 0 0 5. V : [((Hash(PKAIK, NV 1 ∗ NT T P 1))SKTT P , PKAIK, NTT P 1)PKV ]SKV 0 0 = ((Hash(PKAIK, NV 1 ∗ NT T P 1))SKTT P , PKAIK, NTT P 1) 0 0 0 0 So, no w V has MID, NM, TM, NV 1, PKAIK, NTT P 1. 0 0 0 6. V to R:((Hash(MID, VID, NV ∗ NM, TV ))SKV , VID, NV , TV )PKAIK 0 0 0 0 7. R: [((Hash(MID, VID, NV ∗ NM, TV ))SKV , VID, NV , TV )PKAIK]SKAIK 0 0 = ((Hash(MID, VID, NV ∗ NM, TV ))SKV , VID, NV , TV ), because we assume that there 0 is only one correspondence between the public and the pri v ate ke ys, PKAIK has the 0 correspondence only with pri v ate ke y SKAIK. W e here ignore the fact that multiple public ke ys can be associated with one pri v ate ke y , because it is a v ery rare case. So, R no w kno ws

VID, NV , TV . But kno wing only these v alues does not fulﬁl the purpose of R, because it does

not yet kno w original MID, NM, TM. It e v en does not kno w PKAIK of M. So, R cannot be able to compromise the message in ﬂow 1.

Copyright c 2010 John W iley & Sons, Ltd. Concurr ency Computat.: Pract. Exper . (2010) Pr epar ed using cpeauth.cls DOI: 10.1002/cpe 16 THINH ET AL.

8. No w R poses as V to the original M and therefore sends the follo wing to M: 0 0 0 R to M: ((Hash(MID, VID, NV ∗ NM, TV ))SKV , VID, NV , TV )PKAIK When M tries to decrypt the message using its secret ke y SKAIK, the combination of SKAIK 0 and PKAIK will not match, thereby producing a garbage v alue. But, as M does not kno w VID, NV , TV , M will not be able to identify whether the message has come from R, after

decrypting the message with SKAIK. 0 0 0 M: [((Hash(MID, VID, NV ∗ NM, TV ))SKV , VID, NV , TV )PKAIK]SKAIK 0 0 0 0 0 0 0 = (A , VID, NV , TV ), where A = [(Hash(MID, VID, NV ∗ NM, TV ))SKV ]SKAIK. No w , 0 0 M:[A ]PKV = h . Again, M calculates the v alue of Hash function in re v erse way with its

o wn MID, NM. 0 0 00 0 M: Hash(MID, VID, NV ∗ NM, TV ) = h 6 = h . No w , M is sure that the message did not come from the original V . So, M discards the message and does not establish connection with V and TTP in this session. Thus, Man in the Middle attac k also could not occur in case 2. Therefore, message in ﬂow 1 is not vulnerable to Man-in-the-Middle attac k.

9. R: ((P CR, P i))SKAIK, P i, ML, (Hash(MID, VID, NV ∗ NM, TV ))SKV , MID, VID,

NV ∗ NM, TV )PKTT P . As, R does not ha v e the secret ke y SKTT P of TTP , R cannot be able 0 to decrypt the message. No w , R tries to b uild the message generating MID (which may be 0 0 0 0 a v alid ID), P CR , ML , P i , NM. R may kno w VID (as sho wn pre viously). R has its o wn 0 0 0 secret ke y SKAIK and may kno w the v alue of (Hash(MID, VID, NV ∗ NM, TV ))SKV [from 7 sho wn pre viously]. 0 0 0 0 0 0 0 0 R: ((P CR , P i )SKAIK, P i , ML , (Hash(MID, VID, NV ∗ NM, TV ))SKV , MID, VID, 0 NV ∗ NM, TV )PKTT P . 0 0 0 0 0 0 0 0 10. R to TTP: ((P CR , P i )SKAIK, P i , ML , (Hash(MID, VID, NV ∗ NM, TV ))SKV , MID, 0 VID, NV ∗ NM, TV )PKTT P . 0 0 0 0 0 0 0 0 11. TTP:[((P CR , P i )SKAIK, P i , ML , (Hash(MID, VID, NV ∗ NM, TV ))SKV , MID, VID, 0 NV ∗ NM, TV )PKTT P ]SKTT P 0 0 0 0 0 0 0 0 = ((P CR , P i )SKAIK, P i , ML , (Hash(MID, VID, NV ∗ NM, TV ))SKV , MID, VID, 0 NV ∗ NM, TV ). 0 0 0 0 TTP no w has P i , ML , MID, VID, NV ∗ NM, TV . 0 0 0 0 TTP: [(P CR , P i )SKAIK]PKAIK 0 0 0 [ CERTAIK tells that MID has public ke y PKAIK and secret ke y SKAIK] = Hash(P CR0, P i0) = x1. 0 TTP: Corresponding to MID, we assume that the corresponding ML that is stored in TPM is 0 ML1 and from ML1, the obtained PCR v alue is PCR1. [ If R kno ws a v alid MID, it is not possible for it to kno w the corresponding ML and PCR v alue, that are stored securely in TPM. 0 Also, the property Pi’ of R will not match with one in PL corresponding to MID that is held 0 by TTP . Let the original property of de vice with MID is Pi1] TTP: Hash(P CR1, P i1) = x2 6 = x1. Therefore, TTP is sure that the sender of the message is not the intended and original sender , thereby discarding the token request of R. As a result, message in ﬂow 5 is not vulnerable to Man-in-the-Middle attac k.

Copyright c 2010 John W iley & Sons, Ltd. Concurr ency Computat.: Pract. Exper . (2010) Pr epar ed using cpeauth.cls DOI: 10.1002/cpe PR OPER TY B ASED T OKEN A TTEST A TION IN MOBILE COMPUTING 17

Pr oof 3: r eplay attacks. T imestamps TX in ﬂo w messages are used to a v oid replay attacks. Consider , for e xample, ﬂow 1. An attacker that intercepts this message m can try to send it again after m is recei v ed by V . In this case, V notices that the time has passed and that m has been already initiated at time TM. Hence, using timestamps a v oid replaying the same messages.

1. At time TM, M generates a message and sends it to V :

((Hash(MID, NM, TM))SKAIK, MID, NM, TM)PKV . No w , an attacker R gets this

message.Ho we v er , R does not ha v e secret ke y SKV of V , so it cannot decrypt the message.

2. Suppose, V recei v es the message from M at time TM1 due to permissible delay in network. V no w decrypts the message.

V : [((Hash(MID, NM, TM))SKAIK, MID, NM, TM)PKV ]SKV

= ((Hash(MID, NM, TM))SKAIK, MID, NM, TM). So, V no w kno ws NM, TM.

3. No w at a dif ferent time TN, R sends the same message to V . That is, at time TN, R to V :

((Hash(MID, NM, TM))SKAIK, MID, NM, TM)PKV

4. At time TN+1, V recei v es the message and then it decrypts the message.

V : [((Hash(MID, NM, TM))SKAIK, MID, NM, TM)PKV ]SKV

= ((Hash(MID, NM, TM))SKAIK, MID, NM, TM)

At this time also, V gets the duplicate message with NM, TM. V checks that TM 6 = TN+1−δ, where δ is a permissible delay in network for propagation of a message from sender to

recei v er . Also, the nonce NM is also same in both the messages, which is not possible because nonce is a randomly generated number and two nonces cannot be the same at two dif ferent time instants. Then, V discards this message. So, Replay Attac k is not possible in this protocol.

Pr oof 4: r elated to Pi. A compromised App0 can generate a false set of properties Pi0 sent to TTP in ﬂow 5. Then we ha v e two cases:

- The compromised App0 is on the compromised M0. It returns to the Pr oof 2. - The compromised App0 is on the le gitimate M. By checking Pi0 against PL (Property List), TTP terminates a token request due to the in v alid quantity or quality (matched properties) of compromised Pi0. This is used to pre v ent a bad user who does not ha v e a right to access a higher le v el of data.

Let us assume that a compromised application App0 has false set of properties Pi0. Case 1: A pp0 is on compr omised M0. 0 0 0 So, M has MID (which may or may not be a v alid ID). M may kno w VID (as sho wn pre viously in 0 0 0 Proof 2). M has its o wn secret ke y SKAIK and may kno w the v alue of (Hash(MID, VID, 0 NV ∗ NM, TV ))SKV [from Pr oof 2]. 0 0 0 0 0 0 0 0 R: ((P CR , P i )SKAIK, P i , ML , (Hash(MID, VID, NV ∗ NM, TV ))SKV , MID, VID, 0 NV ∗ NM, TV )PKTT P . Then, R sends this message to TTP . No w , it returns to pr oof 2 (for ﬂow 5). TTP discards the token request. So, in this case a bad user cannot get access to higher le v el of data. A pp0 is on legitimate M. So, the property Pi0 of App0 is only the in v alid entity here in the message sent from M to TTP . That is, M to TTP:

Copyright c 2010 John W iley & Sons, Ltd. Concurr ency Computat.: Pract. Exper . (2010) Pr epar ed using cpeauth.cls DOI: 10.1002/cpe 18 THINH ET AL.

0 0 (P CR, P i )SKAIK, P i , ML, (Hash(MID, VID, NV ∗ NM, TV ))SKV , MID, VID,

NV ∗ NM, TV )PKTT P 0 0 TTP: [(P CR, P i )SKAIK, P i , ML, (Hash(MID, VID, NV ∗ NM, TV ))SKV , MID, VID,

NV ∗ NM, TV )PKTT P ]SKTT P 0 0 = ((P CR, P i )SKAIK, P i , ML, (Hash(MID, VID, NV ∗ NM, TV ))SKV , MID, VID,

NV ∗ NM, TV ) 0 TTP no w has P i , ML, MID, VID, NV ∗ NM, TV . 0 0 TTP: [(P CR, P i )SKAIK]PKAIK = Hash(P CR, P i ) = y1. [Hash e xtend operation]

[CERTAIK tells that M has public ke y PKAIK and secret ke y SKAIK] TPM has safely stored ML corresponding to M and the property Pi corresponding to v alid app in M is also stored in TTP . TTP: Hash(P CR, P i) = y2 6 = y1, because though the PCR v alue was the same, P i 6 = P i0. Therefore, TTP discards the token request of M.

Pr oof 5: r elated to the duration of the token. T o e xplain the v alidity duration of the token, assuming that the mobile de vice M obtains the token from TTP and M has no battery; if the token is stored in the TPM RAM, then after the mobile battery is fully char ged up, the mobile de vice needs to launch the protocol again to get a ne w token. In case the token is stored in the TPM EEPR OM, we check the v alidity duration to see if it’ s not e xpired. If not, the token is used otherwise the protocol is launched to get a ne w token.

1. After ﬂow 6, at time TTT P , TTP send the token to M:

((Hash(P i, MID, VID, NTT P ∗ NV ∗ NM, TT T P ))SKTT P , NTT P , TTT P )PKAIK.

TTP stores the token (Hash(P i, MID, VID, NTT P ∗ NV ∗ NM, TT T P ))SKTT P in its TPM

EEPR OM along with the timestamp TTT P . W e assume that the v alidity of the token is σ1.

2. M: [((Hash(P i, MID, VID, NTT P ∗ NV ∗ NM, TT T P ))SKTT P , NTT P , TTT P )PKAIK]SKAIK

= ((Hash(P i, MID, VID, NTT P ∗ NV ∗ NM, TT T P ))SKTT P , NTT P , TTT P )

The token that M recei v es is (Hash(P i, MID, V ID, NTT P ∗ NV ∗ NM, TT T P ))SKTT P . This is stored in M’ s RAM. No w , M has no battery .

3. When M is fully char ged, it cannot restore the token because RAM is v olatile. At time TX, M launches the protocol again to get a ne w token from TTP . Launching the protocol means repeating the steps from Flow 1 to Step 5 with dif ferent time stamps and dif ferent nonce. No w ,

the public ke y , pri v ate ke y pair of M has changed to (PKAIK1, SKAIK1) and this pair is stored in TPM EPR OM.

4. W e assume that, at time TY , TTP recei v ed the token request message from M:

[(P CR, P i)SKAIK1, P i, ML, (Hash(MID, VID, NV 2 ∗ NM2, TV 2))SKV , MID, VID,

NV 2 ∗ NM2, TV 2)PKTT P ]SKTT P

= ((P CR, P i)SKAIK1, P i, ML, (Hash(MID, VID, NV 2 ∗ NM2, TV 2))SKV , MID, VID,

NV 2 ∗ NM2, TV 2).

Where NV 2, NM2 are dif ferent Nonce and TV 2 is one timestamp dif ferent from the pre vious

session. TTP no w has MID which is the same as the MID in the pre vious session.

TTP: [(P CR, P i)SKAIK1]PKAIK1 = Hash(P CR, P i) = y . . . .(iii) [Hash(PCR, Pi) is the

Hash e xtend operation of PCR in TPM and CERTAIK tells that MID has public ke y PKAIK1

and secret ke y SKAIK1 at another session]

Copyright c 2010 John W iley & Sons, Ltd. Concurr ency Computat.: Pract. Exper . (2010) Pr epar ed using cpeauth.cls DOI: 10.1002/cpe PR OPER TY B ASED T OKEN A TTEST A TION IN MOBILE COMPUTING 19

TPM has safely stored ML corresponding to M and the property Pi corresponding to v alid app in M is also stored in TTP . TTP: Hash(PCR, Pi) = y. . . .(i v) From (iii) and (i v), TTP can check the v alidity and authenticity of M.

5. No w TTP can check in its EEPR OM that there was a token generated at time TTT P against

MID.

(a) If (T T P : TY − TT T P ≤ σ1), then [TTP to M]:

((Hash(P i, MID, VID, NTT P ∗ NV ∗ NM, TT T P ))SKTT P , NTT P , TTT P )PKAIK1.

M: [((Hash(P i, MID, VID, NTT P ∗ NV ∗ NM, TT T P ))SKTT P , NTT P , TTT P )

PKAIK1]SKAIK1

= (Hash(P i, MID, VID, NTT P ∗ NV ∗ NM, TT T P ))SKTT P , NTT P , TTT P ) So, M no w has the same token

(Hash(P i, MID, VID, NTT P ∗ NV ∗ NM, TT T P ))SKTT P as pre vious.

[The assumption here is that though NV , NM are nonces from pre vious session and

TTT P is pre vious time stamp, there is no possibility of replay attack, because TTP is a trusted en vironment.]

(b) If (T T P : TY − TT T P > σ1) , then [TTP to M]:

((Hash(P i, MID, VID, NTT P 2 ∗ NV 2 ∗ NM2, TT T P 2))SKTT P , NTT P 2, TTT P 2)PKAIK1.

M: [((Hash(P i, MID, VID, NTT P 2 ∗ NV 2 ∗ NM2, TT T P 2))SKTT P , NTT P 2, TTT P 2)

PKAIK1]SKAIK1

= (Hash(P i, MID, VID, NTT P 2 ∗ NV 2 ∗ NM2, TT T P 2))SKTT P , NTT P 2, TTT P 2).

The token that M gets is Hash(P i, MID, VID, NTT P 2 ∗ NV 2 ∗ NM2, TT T P 2))SKTT P , which is dif ferent from the pre vious one.

6. SECURITY DISCUSSION

T o address the common threats in section 3, we analyze the security of our proposed protocol while using Sc yther tool for v eriﬁcation of security protocol. In this part, we discuss the follo wing security concerns.

1. Security based har dwar e. T o lessen the well-kno wn vulnerability with re gard to the resource- constraint, each TPM is equipped with a special set of re gisters (PCRs) and cryptography unit which is a couple of public/pri v ate ke y pair (RSA) at manufacturing time. This can pro vide security functions like secure storage, attestation of platform state and identity by performing cryptographic algorithms of encrypting, authenticating and attesting data. The mobile users can take adv antage of beneﬁts of TPM’ s functionality , especially the remote attestation, as a virtual anti-virus application (Thr eat 1). Furthermore, the design of TPM is to of fer hardware protection for cryptographic ke ys. It means that the pri v ate part of ke y pair is stored in the Non-V olatile memory of TPM; and ne v er lea v es the TPM. As a result, the secret still remains safe e v en if the system is compromised like Rooting/ Jailbreaking (Thr eat 4). 2. Softwar e T oken. In our work, security and pri v ac y depend mainly on the proposed T oken. This token deﬁnes the security polic y for its o wner by either the quantity of random property or

Copyright c 2010 John W iley & Sons, Ltd. Concurr ency Computat.: Pract. Exper . (2010) Pr epar ed using cpeauth.cls DOI: 10.1002/cpe 20 THINH ET AL.

matched properties (Pi). It pre v ents malicious application/user to use a v alid token to access enterprise data ille gally (Thr eats 2 and 3). T o obtain a v alid token, the client application has been e xamined to get its o wn appropriate confidence le v el. The user is only permitted to access enterprise data with limited pri vile ge. In addition, depending on the polic y of the enterprise, the finite time (T) of token is set for each access session. This turns the token into One T ime T ic ket to access specific data in a specific en vironment for pre v enting damage of malware (Thr eat 3). 3. Attestation based T oken Pr operty.Based on the binary attestation and property based attestation, we proposed the Property based T oken Attestation to secure the enterprise cloud mobile de vice in BO YD conte xt. Dif ferently from [6] and [8], we discuss ho w properties can be e v aluated as presented in Section 4. The proposed attestation mechanism makes a specific application and platform bind a token together to pre v ent another malicious application with v alid token to gain secure data (Thr eat 2). 4. Scyther. Sc yther has been de v eloped by CAS Cremer [18]. It is a tool for the formal analysis of security protocols under the perfect cryptography assumption. Sc yther uses the Dole v-Y ao adv ersarial model [9]. In order to establish the security analysis with Sc yther , protocols must be specified in its input language, namely Security Protocol Description Language (SDPL). It is easy for a fresh user to get used to working on Sc yther due to the syntax of SDPL being familiar with the e xisting object oriented languages such as C++/Ja v a. T o pre v ent the attacker to control the network and all the communication, it is assumed that all cryptographic functions are perfect: the attacker learns nothing from an encrypted message unless he kno ws the decryption ke y . The tool can be not only used to find problems that arise from the way the protocol is [19] b ut also automatically find attacks on cryptographic protocols. Once v erification is completed, the v erification results are represented in OK or F ail status which demonstrates the protocol whether it is correct or false. In our e xperimental test, the output of the v erification is OK. On behalf of the in v olv ed parties three roles M, V and TTP were defined within a scope of P{M, V , TTP} . W e could split the whole protocol into three sub-protocols: P1{M, V}, P2{V , TTP} and P3{M, TTP} to simplify the codes and take less v erification time. Ho we v er , to pro v e a rob ust protocol, we decide to v erify our work in one protocol, though the v erification time is quite long.

7. RELA TED WORK

The proliferation of mobile de vices has changed the requirement of computing ecosystem. The end- user would rather use their personal mobile de vices than personal computers for either entertainment or work. Ho we v er , the mobile de vice is still considered as the resource-constraint de vice in terms of ener gy , storage, processing po wer , and especially for security . T o fulﬁll the requirement of security , there are man y useful tools, anti virus application, and cryptography techniques in use. Ho we v er , the y require a trusted computing platform to run. T rusted Computing Group (TCG) with its TPM pro vides a standard that enables authentication, authorization, encryption and inte grity to be achie v ed on a v ariety of computing platforms. As we discussed earlier , remote attestation is one of the important functionalities pro vided by TPM, namely Binary Attestation (B A). Man y

Copyright c 2010 John W iley & Sons, Ltd. Concurr ency Computat.: Pract. Exper . (2010) Pr epar ed using cpeauth.cls DOI: 10.1002/cpe PR OPER TY B ASED T OKEN A TTEST A TION IN MOBILE COMPUTING 21 authors ha v e used the adv antage of B A to pro v e the trustworthiness of their research objects such as platforms, applications, and agents [20, 21, 22]. In other hand, some researchers ar gue that this attestation mechanism has its o wn shortcomings, such as pri v ac y , fle xibility and scalability [11, 12, 14, 23]. F or this reason, the literature [14, 24, 25] proposed Property-Based Attestation (PB A) which is established on Binary Attestation. This mechanism attests not only binary v alues b ut also security properties, functions or beha vior of systems to o v ercome the limitation of B A. Based on this notation, Xin et al. [26] proposed a model of PB A oriented to cloud computing that enables users to attest the security property of cloud service platform before e xchanging data or performing tasks to the cloud. Another approach is to combine the certificate of Attestation Identity K e y of TPM, which is deli v ered by Pri v ac y Certificate Authorization and Secure Socket Layer certificate to form Platform Property Certificate as presented in [25]. T o consider the problems of trust in cloud monitoring system, A wad et al. [27] introduced a trusted frame work to establish a chain of trust for the clients in the cloud en vironment by relying on PB A. In addition, to impro v e the fle xibility , Liu et al. [28] with their model, CORA, allo w the cloud tenants not only choose the node in cloud that matches to their o wn security requirements b ut also v erify the trustworthiness of this node dynamically . T o impro v e the security model for virtual machines and services in the cloud, V ijay et al. [29] brought in a ne w trust model to detect and pre v ent security attacks in cloud en vironment by using PB A. In their model, the authors considered the basic communication properties between the tenant virtual machine and the cloud user as the security properties for attesting, such as the source address, the traf fic and the state v alidation of the tenant virtual machine. Excepting the method accounts for the security properties, this work has some similar points with ours as it will be discussed in high le v el in the Section 8 where we come up with the fact that V irtual Mac hines is e verywher e term for discussion. In the mobile computing context, although without the e xistence of hardware root of trust, Mohammad et al. [30] implemented B A for Android platform. By emulating the TPM as a part of the kernel, the authors created a root-of-trust to establish the chain-of-trust from this root-of-trust to the Dalvik virtual machine, and then to the entire entities within the virtual machine. Similarly , the authors in [31] in v estigated the practicable of remote attestation for lo w cost embedded computing de vices without trusted hardware. T o support secure remote attestation, the y claimed that only the essential and suf ficient properties for a lo w cost de vice were identified and mapped into a minimal collection of system component. Meanwhile, K ostiainen et al. [32] applied PB A for the in-v ehicle communication system enabling mobile de vices to e xchange data to car head units. The authors presented a ne w model of property-based attestation that bootstraps from e xisting mobile application certification infrastructure. In which, the y omitted a trusted party which is responsible for translation between software measurement and properties. All in all, the pros and cons of most e xisted approaches in remote attestation are summarized in [13]. Most of them ha v e pointed out the e xisting dra wbacks of current remote attestation mechanisms. Re garding to application attestation, the deficiencies of B A ha v e been sho wn clearly in man y discussed abo v e researches. Ho we v er , in term of property-based attestation, the questions that what useful properties need to be attested; and ho w to generate them automatically ha v e not been answered suf ficiently by the abo v e mentioned works. This is the major dif ference of our work in comparison with others. In our work, we consider e v erything is property i.e. functions, attrib utions,

Copyright c 2010 John W iley & Sons, Ltd. Concurr ency Computat.: Pract. Exper . (2010) Pr epar ed using cpeauth.cls DOI: 10.1002/cpe 22 THINH ET AL. re-computed nonce, etc. W e propose to use a token with random properties to authenticate mutually the mobile user and the in v olv ed parties. While not mentioning clearly about the token based authentication [31], we define in detail the token content and ho w it works. Due to the re v ocation and the update of property that happen highly in nature, the approach without trusted third party [33] may increase the comple xity of the system when the v erifier is not a ware of re v oked properties in real time [34]. T o o v ercome this, we introduce the random properties list which is generated by the application service automatically , re gardless the update or backup. Its inte grity is ensured and v erified by a reserv ed PCR and an acti v e TTP respecti v ely . Last b ut not least, since TCG has introduced the second generation of TPM [35], TPM 2.0, with more functionalities to support mobile de vices in 2014, this makes the e xistence of hardware root of trust in mobile de vices to be more popular . W e also take this opportunity for the feasibility of our research.

8. CONCLUSION AND FUTURE WORK

By considering the token with random property , our work not only lessens the remaining demerit of remote attestation mechanisms b ut also adapts to the conte xt-a ware. Depending on the conte xt, attestation mechanism has its o wn adv antages and disadv antages. The paper describes the no v el attestation schema based on the e xisting attestation mechanisms. In order to pro v e the correctness, we ha v e v eriﬁed the proposed protocol under Sc yther and analysed it with the security proofs. In this paper , our work enables the in v olv ed parties, i.e. the enterprise and the trusted third party , to transparently deploy and manage digital tokens for mobile de vices not only to accomplish authentication b ut also grant secure access to enterprise networks. This work is the foundation for the ne xt steps where we consider the term of V irtual Mac hines is e verywher e, since Ber ger et al. [36] designed a virtual TPM (vTPM) architecture enabling physical TPM to be serv ed by multi virtual en vironments on the trusted platform and the approach in [37] allo wing to implement property-based sealing and attestation in vTPM. Our future work is to adapt this PT A protocol to secure another mobile cloud computing model based on the Cloudlet notion. In that work, we aim to make our solution more adapti v e and conte xt-a ware by relying on the reputation of the Cloudlets.

REFERENCES

1. Henky Agusleo & Neeraj Arora, The Road to Cloud Nine’ How Service Pr oviders Can Monetize Consumer Mobile Cloud, Whitepaper , Cisco Internet Business Solutions Group (IBSG), Feb . 2013. 2. T . Le V inh, S. Bouzefrane, J.-M. Farinone, A. Attar , and B. P . K ennedy , Middlewar e to Inte grate Mobile Devices, Sensors and Cloud Computing, Procedia Comput. Sci., v ol. 52, pp. 234243, 2015. 3. Best Practices for Enabling Employee-owned Smart Phones in the Enterprise, Intel Whitepaper Dec, 2011 . 4. Best Practices for Enabling Employee-owned Smart Phones in the Enterprise, Intel Whitepaper Feb 2012 . 5. A. M. D. O. S. Hofmann and B. W . E. W itchel, Cloaking Malwar e with the T rusted Platform Module. SEC 2011 Proceedings of the 20th USENIX conference on Security . 6. A. N. Khan, M. L. Mat Kiah, S. U. Khan, and S. A. Madani, T owar ds secur e mobile cloud computing: A surve y , Future Gener . Comput. Syst., v ol. 29, no. 5, pp. 12781299, Jul. 2013. 7. S. Pearson, T rusted Computing Platforms: TCP A T echnology in Conte xt. Upper Saddle Ri ver , NJ, USA: Prentice Hall PTR, 2002.

Copyright c 2010 John W iley & Sons, Ltd. Concurr ency Computat.: Pract. Exper . (2010) Pr epar ed using cpeauth.cls DOI: 10.1002/cpe PROPERTY BASED TOKEN ATTESTATION IN MOBILE COMPUTING 23

8. K. N. McGill, Trusted mobile devices: Requirements for a mobile trusted platform module, Johns Hopkins Apl Tech. Dig., vol. 32, no. 2, p. 544, 2013. 9. S. Bouzefrane and L. V. Thinh, Trusted Platforms to Secure Mobile Cloud Computing,IEEE HPCC 2014, pp. 10681075. 10. T. C. G. Admin, TPM Library Specification, Trusted Computing Group, 01-Oct-2014. . 11. L. Chen, R. Landfermann, H. Lhr, M. Rohe, A.-R. Sadeghi, and C. Stble, A Protocol for Property-based Attestation, in Proceedings of the First ACM Workshop on Scalable Trusted Computing, New York, NY, USA, 2006, pp. 716. 12. A. Nagarajan, V. Varadharajan, M. Hitchens, and E. Gallery, Property Based Attestation and Trusted Computing: Analysis and Challenges, 2009, pp. 278285. 13. R. V. Steiner and E. Lupu, Attestation in Wireless Sensor Networks: A Survey, ACM Comput. Surv., vol. 49, no. 3, pp. 131, Sep. 2016. 14. A.-R. Sadeghi and C. Stble, Property-based Attestation for Computing Platforms: Caring About Properties, Not Mechanisms, in Proceedings of the 2004 Workshop on New Security Paradigms, New York, NY, USA, 2004, pp. 6777. 15. E. Brickell, J. Camenisch, and L. Chen, Direct anonymous attestation, in Proceedings of the 11th ACM conference on Computer and communications security, 2004, pp. 132145. 16. B. Smyth, M. Ryan, and L. Chen, Direct Anonymous Attestation (DAA): Ensuring privacy with corrupt administrators, in European Workshop on Security in Ad-hoc and Sensor Networks, 2007, pp. 218231. 17. G. Coker, J. Guttman, P. Loscocco, J. Sheehy, and B. Sniffen, Attestation: Evidence and trust, in International Conference on Information and Communications Security, 2008, pp. 118. 18. C. Cremers and S. Mauw, Operational Semantics and Verification of Security Protocols. Berlin, Heidelberg: Springer Berlin Heidelberg, 2012. 19. C. J. Cremers, The Scyther Tool: Verification, falsification, and analysis of security protocols, in International Conference on Computer Aided Verification, 2008, pp. 414418. 20. H. Tan, W. Hu, and S. Jha, A TPM-enabled remote attestation protocol (TRAP) in wireless sensor networks, in Proceedings of the 6th ACM workshop on Performance monitoring and measurement of heterogeneous wireless and wired networks, 2011, pp. 916. 21. J. G. Beekman, J. L. Manferdelli, and D. Wagner, Attestation Transparency: Building secure Internet services for legacy clients, 2016, pp. 687698. 22. D. Fu and X. Peng, TPM-based remote attestation for Wireless Sensor Networks, Tsinghua Sci. Technol., vol. 21, no. 3, pp. 312321, 2016. 23. T. Rauter, A. Hller, N. Kajtazovic, and C. Kreiner, Privilege-Based Remote Attestation: Towards Integrity Assurance for Lightweight Clients, 2015, pp. 39. 24. E. Gallery, A. Nagarajan, and V. Varadharajan, A Property-Dependent Agent Transfer Protocol, in Trusted Computing, vol. 5471, L. Chen, C. J. Mitchell, and A. Martin, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2009, pp. 240263. 25. N. Borhan and R. Mahmod, Platform Property Certificate for Property-based Attestation Model, Int. J. Comput. Appl., vol. 65, no. 13, 2013. 26. S. Xin, Y. Zhao, and Y. Li, Property-Based Remote Attestation Oriented to Cloud Computing, 2011, pp. 10281032. 27. A. Awad, S. Kadry, B. Lee, and S. Zhang, Property Based Attestation for a Secure Cloud Monitoring System, in Proceedings of the 2014 IEEE/ACM 7th International Conference on Utility and Cloud Computing, 2014, pp. 934940. 28. Z. Liu, X. Wang, Y. Liu, D. Guo, and X. Zhu, Client Oriented Remote Attestation Model in Cloud Environment, Int. J. Secur. Its Appl., vol. 9, no. 10, pp. 395404, Oct. 2015. 29. V. Varadharajan and U. Tupakula, Counteracting security attacks in virtual machines in the cloud using property based attestation, J. Netw. Comput. Appl., vol. 40, pp. 3145, Apr. 2014. 30. M. Nauman, S. Khan, X. Zhang, and J.-P. Seifert, Beyond kernel-level integrity measurement: enabling remote attestation for the android platform, in International Conference on Trust and Trustworthy Computing, 2010, pp. 115. 31. Aurelien Francillon, Quan Nguyen, Kasper B.Rasmussen, Gene Tsudik, A minimalist approach to remote attestation, 2015. DATE’14 Proceedings of the conference on Design, Automation & Test in Europe . 32. K. Kostiainen, N. Asokan, and J.-E. Ekberg, Practical Property-Based Attestation on Mobile Devices, in Trust and Trustworthy Computing, vol. 6740, J. M. McCune, B. Balacheff, A. Perrig, A.-R. Sadeghi, A. Sasse, and Y. Beres, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2011, pp. 7892. 33. L. Chen, H. Lhr, M. Manulis, and A.-R. Sadeghi, Property-Based Attestation without a Trusted Third Party, in Information Security, vol. 5222, T.-C. Wu, C.-L. Lei, V. Rijmen, and D.-T. Lee, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2008, pp. 3146.

Copyright c 2010 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. (2010) Prepared using cpeauth.cls DOI: 10.1002/cpe 24 THINH ET AL.

34. Y . Qin, D. Chang, S. Zhao, and Q. Zhang, A Pr operty-Based Attestation Scheme with the V ariable Privacy , 2011, pp. 16161623. 35. TPM Library Speciﬁcation, T rusted Computing Group, 01-Oct-2014. . 36. R. Perez, R. Sailer , L. v an Doorn, and others, vTPM: virtualizing the trusted platform module, in Proc. 15th Conf. on USENIX Security Symposium, 2006, pp. 305320. 37. A.-R. Sadeghi, C. Stble, and M. W inandy , Pr operty-based TPM virtualization, in Information Security , Springer , 2008, pp. 116.

Copyright c 2010 John W iley & Sons, Ltd. Concurr ency Computat.: Pract. Exper . (2010) Pr epar ed using cpeauth.cls DOI: 10.1002/cpe