Keywords

1 Introduction

In order to obtain security assurance, many computing platforms or embedded devices make use of cryptographic devices, such as Trusted Platform Modules (TPM), Hardware Security Modules (HSM), to provide essential cryptographic operations. These cryptographic devices protect cryptographic keys in the untrusted environment from physical tampering attacks. Applications running on this environment can communicate with the cryptographic devices via various programming interfaces that are called cryptographic APIs.

Starting 2006, many new PCs/laptops have been sold with a TPM chip built in. TPM technology also has been developed by industry to protect computing infrastructure and billions of end points. For instance, Microsoft has its Windows 10 equipped with TPM technology. Moreover, TPM 2.0 Library Specification was approved as a formal international standard under ISO/IEC [10].

We refer to the cryptographic APIs in TPM 2.0 specifications [15] as cryptographic support commands, including symmetric/asymmetric encryption, HMAC and signature, etc. To our knowledge, there are no previous formal-analysis works that focus on these new-added commands. But plenty of works have been done in related fields (i.e., formal analysis of APIs), such as TPM 2.0 key management commands [13, 18], TPM 2.0 authentication commands [14, 16] or PKCS #11 cryptographic APIs [9, 11].

Most of the early works of API analysis aim to find flaws or attacks. Some vulnerabilities have been found, such as the attack on the key duplication mechanism of TPM 2.0 [18]. However, some other research works aim to provide the provable security guarantee for API framework. Cortier and Steel [7] presented a new symmetric key management API framework which has a formal security policy and manual proofs of security in the symbolic model. Daubignard et al. [8] extended their work with asymmetric cryptography. Cachin and Chandran [5] presented a novel, provably secure, cryptographic API interface. They used the notion of modern cryptography to manually prove the security policy of the API interface and then provided an emulation of the security policy in the PKCS #11 interface. Then Chu and Feng [6] used their method to prove the security of TPM 2.0 cryptography APIs (but not a formally-analyzed way). Recently, Scerri and Stanley-Oakes [12] presented an analysis of key wrapping APIs with generic policies and used their result to propose a secure refinement of PKCS #11. Their work obtains computational guarantees by a indirect way that uses symbolic formalism to prove computational security statements.

Following up this research line, we want to provide provable security guarantee for the newly-added cryptographic support commands in TPM 2.0, and the most interesting aspect is that we attempt to gain an automated result. Specifically, we model the relevant cryptographic support commands in TPM 2.0 specification. Then similar to the work of Cachin and Chandran, we define the security of commands in the notion of modern cryptography via a game running between a challenger and an adversary. The adversary may try to break the security of the commands by distinguishing left-world encryption from right-world encryption or by contradicting the integrity of the authentication operations. Finally we express the model in a probabilistic polynomial-time process calculus and automatically prove it by a formal analysis tool – CryptoVerif.

Note that our model cannot be treated as a complete solution although we show how to prove the commands in TPM 2.0 with suitable abstractions. For example, we omit abstracting the attribute duplication used for duplication commands in the key structure. As the paper of Cachin and Chandran said, the higher level goal of this line of research is “To lay a foundation for the design of future token interfaces with provable security guarantees”.

2 Cryptographic Support Commands in TPM 2.0

In TPM 2.0, the cryptographic primitives are exposed for general purpose use, hence the cryptographic support commands appear. To use the commands, keys are critical. A key has a public area and a sensitive area, and both areas consist of some elements. In this section, we will describe the key structure firstly, and then introduce the commands w.r.t our work.

2.1 Key Structure Elements

Each key has two components. The first is a public area that contains the attributes of the key and a public identity. The second is the sensitive area that contains the elements that require TPM protections. The elements of a key structure related to our work are described in Table 1.

Table 1. Key structure elements
Full size table

2.2 Cryptographic Support Commands

The TPM 2.0 exposes the cryptographic primitives for general purpose use. Here we explain these commands, together with key creation commands.

  • TPM2_CreatePrimary. This command is used to create a SRK (Storage Root Key). But it will not return the sensitive area, which never leaves the TPM.

  • TPM2_Create. This command is used to create a key that is generated with values from the TPM RNG.

  • TPM2_Load. This command is used to load a created key into TPM.

  • TPM2_EncryptDecrypt. This command performs symmetric encryption or decryption.

  • TPM2_RSA_Encrypt. This command performs RSA encryption.

  • TPM2_RSA_Decrypt. This command performs RSA decryption.

  • TPM2_HMAC. This command performs an HMAC on the supplied data, which can be seen as symmetric signature.

  • TPM2_Sign. This command causes the TPM to sign a externally provided hash with a asymmetric signing key.

  • TPM2_VerifySignature. This command uses loaded keys to validate a symmetric or asymmetric signature on a message.

Note that in the TPM specification, ECC is not used directly for encryption. Therefore, there are not explicit commands for ECC encryption here.

3 Security Definition

We define the security of cryptographic support commands in the way that is similar in spirit to Cachin and Chandran [5], who adopt the notion of modern cryptography via a game played between a challenger \(\mathcal {C}\) and an adversary \(\mathcal {A}\).

Specifically, We assume a challenger \(\mathcal {C}\) owns a TPM implementing all commands described in Session 2. The challenger initializes this TPM and chooses the challenge key set \(\mathcal {C}\mathbb {K} \subseteq \mathbb {K}\) from the initialized TPM. The adversary can make any queries to the challenger. The set \(\mathcal {A}\mathbb {K} \subseteq \mathbb {K}\) denotes the key generated or derived by the adversary.

Initial. The challenger \(\mathcal {C}\) initializes a TPM, chooses the challenge key set \(\mathcal {C}\mathbb {K}\) (consists of a storage root key SRK a symmetric key SK, an asymmetric key pair PK, a parent key WK, a MAC key MK, a signing key pair SSK). It sends the handles of these keys to adversary \(\mathcal {A}\), together with public keys if they exist. In the end, \(\mathcal {C}\) picks a bit b at random.

Phase 1. The adversary \(\mathcal {A}\) makes queries on cryptographic support commands defined in Sect. 2 for any \(K,L \in \mathbb {K}\), and the created keys must be added to the set \(\mathcal {A}\mathbb {K}\) indicating that they belong to the adversary.

Challenge. The adversary \(\mathcal {A}\) submits two messages \(m_0\) and \(m_1\) to challenger \(\mathcal {C}\) and obtains a ciphertext under the key in \(\mathcal {C}\mathbb {K}\).

  1. 1.

    Test symmetric encryption (testSENC,\(m_0\),\(m_1\)): \(\mathcal {C}\) verifies that the input messages have not been queried in Phase 1 first and then executes operation \(c^* \leftarrow \) TPM2_EncryptDecrypt(\(SK,encrypt,m_b\)) and returns \(c^*\).

  2. 2.

    Test asymmetric encryption (testPENC,\(m_0\),\(m_1\)): \(\mathcal {C}\) also verifies that the input messages have not been queried in Phase 1 first. Then he executes operation \(\bar{c}^* \leftarrow \) TPM2_RSA_Encrypt(\(PK,m_b\)) and responds with \(\bar{c}^*\).

For other challenges from the adversary \(\mathcal {A}\), The challenger \(\mathcal {C}\) calls the corresponding commands and responds with what the commands output.

Phase 2. The adversary \(\mathcal {A}\) continues to make queries on the commands as done in Phase 1, but is explicitly forbidden to query the return values \(c^*\) and \(\bar{c}^*\).

Final Phase. In the end, \(\mathcal {A}\) proceeds as follows:

  1. 1.

    \(\mathcal {A}\) outputs a bit \(b'\), its guess as to the value of b. The advantage of \(\mathcal {A}\) can be defined as \(\alpha _1=|\text {Pr}[b'=b]-\frac{1}{2}|\).

  2. 2.

    \(\mathcal {A}\) outputs (\(m',t'\)) for \(MK \in \mathcal {C}\mathbb {K}\) such that \(t'\) was never returned by \(\mathcal {C}\) in a query \(\mathbf {TPM2\_HMAC}(MK,m')\). The advantage of \(\mathcal {A}\) can be defined as \(\alpha _2=|\text {Pr}[\mathbf {TPM2\_VerifySignature}(MK,m',t')=true]|\).

  3. 3.

    \(\mathcal {A}\) outputs (\(m'',s''\)) for \(SSK \in \mathcal {C}\mathbb {K}\) such that \(s''\) was never returned by \(\mathcal {C}\) in a query \(\mathbf {TPM2\_Sign}(SSK,m'')\). The advantage of \(\mathcal {A}\) can be defined as \(\alpha _3=|\text {Pr}[\mathbf {TPM2\_VerifySignature}(SSK,m'',s'')=true]|\).

  4. 4.

    \(\mathcal {A}\) outputs a key blob (\(K',(w',l')\)) such that \((w',l')\) can be successfully loaded as \(K'\) by the TPM while \(K'\) was never created by the creation command TPM2_Create. The advantage of \(\mathcal {A}\) can be defined as \(\alpha _4=|\text {Pr}[\mathbf {TPM2\_Load}(SSK,(w',l'))=K']|\).

Definition 1

The Cryptographic Support Commands in TPM 2.0 are secure if the advantages \(\alpha _1,\alpha _2,\alpha _3,\alpha _4\) are negligible for all efficient adversaries \(\mathcal {A}\).

4 Proving the Security in CryptoVerif

In this section, we want to prove that the cryptographic support commands satisfy Definition 1 by CryptoVerif. Before that, we give a brief overview of CryptoVerif and then model the commands and security definition in CryptoVerif’s calculus. The results will be presented in the end. Note that the complete input of CryptoVerif will appear in [17].

4.1 CryptoVerif Basics

There are two main approaches to the verification of cryptographic protocols. One approach is known as the computational model and another approach is known as the symbolic or Dalev-Yao model. The CryptoVerif, proposed by Blanchet [2,3,4], can directly prove security properties of cryptographic protocols in the computational model.

CryptoVerif builts proofs by sequences of games. It starts from the initial game given as input, which represents the protocol to prove in interaction with an adversary (real mode). Then, it transforms this game step by step using a set of predefined game transformations, such that each game is indistinguishable from the previous one. CryptoVerif transforms one game into another by applying the security definition of a cryptographic primitive or by applying syntactic transformations. In the last game of a proof sequence the desired security properties should be obvious (ideal mode).

CryptoVerif is sound: whatever indications the user gives, when the prover shows a security property of the protocol, the property indeed holds assuming the given hypotheses on the cryptographic primitives.

4.2 Modelling the Game in CryptoVerif

We adopt a probabilistic polynomial-time process calculus (CryptoVerif’s calculus) to model the game defined in Session 3. Before this, we will identify the key structure and some tricks in expressing the commands.

CryptoVerif provides tables for persistent storage. Processes may populate and access tables, but deletion is forbidden. Therefore, to express key structure, we declare a table keystruct:

The \(\texttt {handle,keytype}\) represents the key handle and key type according to the literal meaning. The \(\texttt {keytype} \in \{\texttt {srkey,symmetric,asymmetric,wrap,mac,si}\)- \(\texttt {gnature}\}\) captures two fields type and usage in the TPM key structure elements. For example, if the \(\texttt {keytype}\) is an asymmetric encryption key (i.e., \(\texttt {=asymmetric}\)), then correspondingly \(type=TPM\_ALG\_RSA\) and \(descrypt=SET\) in the TPM key structure. The Boolean flag \(\texttt {bool}\) is an assistant flag to help our process identify whether the corresponding key can be stored outside. It is not a real field in the structure. We add this flag for convenience in the decision condition of the process. We use key seed instead of key value. This is equivalent to what we describe in Sect. 2, since either symmetric key or asymmetric key pair can be generated by a key seed (using a key generation algorithm). Hence \(\texttt {keyseed1}\) corresponds to field unique and sensitive. The second key seed \(\texttt {keyseed2}\) corresponds to the field seedValue.

The command TPM2_Create requires that the new key must be under protection of its father key via a wrapping operation. However, the father key may also be created by this command. CryptoVerif’s calculus cannot handle the complex state transition and control flow. Therefore, we model this command into two separate process: TPM2_CreateK and TPM2_CreateWrap. The former is used to model the process of generating a new key. The later is used to model the wrapping process of the new key by its father key. More details is below.

Modelling the Initial Phase. The oracle Ogen described in Table 2 generates the challenge key set \(\mathcal {C}\mathbb {K}\) and chooses a random bit b. It returns the key handles and public keys, therefore, immediately corresponding to the initial phase of our description.

Table 2. Initial phase
Full size table

The SPS is a seed persistently stored in a TPM. We use a function RNG to model different key generated from the same seed SPS. Since the SRK is never stored off the TPM in any form, we set the boolean flag \(\texttt {bool}=false\).

Table 3. Phase 1 & 2
Full size table

Modelling Phase 1 & 2. The processes named after the cryptographic support commands allow the adversary \(\mathcal {C}\) to perform requests, capturing Phase 1 & 2 of our description. Note that we do not distinguish between Phase 1 & 2. This is acceptable since both Phase 1 and Phase 2 are in parallel with the challenge phase in our formalization. These processes provide some oracles for modelling the capacity of adversary to invoke the commands. For limited space, we present some of them, which are described in Table 3.

The processes TPM2_CreateK and TPM2_CreateWrap model the create operation. The former presents in the table. It provides an oracle OCK waiting for a message ktype from \(\mathcal {C}\) and then generates a corresponding key according to ktype and returns the key handle and public portion. The attribute \(\texttt {type}\) of the new key is set to be ktype and \(\texttt {bool}\) is set to be true.

The process TPM2_RSA_Encrypt provides an asymmetric encryption oracle OPE waiting for a query on a plaintext pm to be encrypted by \(PK_3\). It looks up the encryption key (i.e., a key seed that can generates public key) with handle \(PK_3\) in keystruct. Then it encrypts the plaintext using the public key and returns the ciphertext. The process TPM2_RSA_Decrypt provides a decryption oracle OPD waiting for a query on a ciphertext \(pc_4\) to be decrypted by the private key of \(PK_4\) and returns the corresponding plaintext. The find clause guarantees the challenge ciphertext would not be queried to the decryption oracle.

Modelling the Challenge Phase. The Challenge phase models the test oracles for challenger \(\mathcal {C}\). The adversary \(\mathcal {A}\) tries to break the security of the cryptographic support commands by confirming which world he was talking to (the world of \(b=0\) and the world of \(b=1\)), or creating a forged tag or signature to against the integrity of the authentication operations. Therefore, the adversary would make a query \((m_0,m_1)\) to its oracles, and whenever he does, the oracle computes the return value depending on the pre-selected random boolean value b. The adversary would make a query to its authentication oracles as well and get the return value in favor of a forgery. We also present part of the Challenge phase, as described in Table 4.

The process testPENC models a test oracle taking a tuple \((pm_0,pm_1)\) as input from \(\mathcal {A}\) and returning the asymmetric encrypted value of \(pm_b\) under the key \(PK \in \mathcal {C}\mathbb {K}\). Also, the two find clauses guarantee the input messages can not be queried to the encryption oracle in advance.

Table 4. Challenge phase
Full size table

Modelling the Final Phase. The final phase of our formalization is captured by secrecy property and correspondence property. We model the statement 1 in the final phase as one-session secrecy of b. A process Q preserves the one-session secrecy of b when, with overwhelming probability, the adversary interacting with Q cannot distinguish any element of the array b from an uniformly-distributed random number by a single test query. Hence, if our processes preserve the one-session secret of b, then with overwhelming probability, the adversary can not distinguish a test query that outputs b from one that outputs a random boolean value (true or false). Then naturally, the adversary can not distinguish which message has been selected.

We model the statements 2 & 3 & 4 in the final phase as correspondence assertions, which are properties of the form “if some events have been executed, then some other events have been executed” or “if some events have been executed, then some formula holds”. We define an event forge that would be executed after a forgery happens and prove that forge has not been executed.

4.3 Results

We use CryptoVerif to prove the secret and correspondence properties for the cryptographic support commands in the computation model. Before we show the results, we present the cryptographic assumptions in our proof.

Modelling the Cryptographic Assumptions. The symmetric encryption scheme is assumed to be indistinguishable under chosen plaintext attacks (IND-CPA) and satisfies ciphertext integrity (INT-CTXT). These two properties guarantee indistinguishability under adaptive chosen ciphertext attacks(IND-CCA2), as shown in [1]. The asymmetric encryption scheme is also assumed to be IND-CCA2 secure. The MAC and signature scheme are both assumed to be strongly unforgeable under chosen message attacks (SUF-CMA). The key-wrapping scheme implements an Encrypt-then-MAC scheme. The encryption scheme is IND-CPA secure and the MAC scheme is SUF-CMA secure. As show in [1], this composite encryption scheme is IND-CCA2 secure. For these assumption, we use the definitions built in CryptoVerif library except for a slight modification in the definitions of IND-CPA and INT-CTXT. As an example, we show the definition of IND-CPA as follows.

figure a

In this definition, \(Z_T\) is a const of the same length as the plaintext, consisting only of zeros. Hence it denotes a situation that one can not distinguish the ciphertext of an arbitrary message x from that of a constant \(Z_T\). Our modification is embodied in \(Z_T\). The original definition in [3] is a function \(Z:bitstring \rightarrow bitstring\). But the authors also claim that they can prove that Z(x) does not depend on x when x is of a fixed-length type. We assume the symmetric encryption scheme is a block cipher such that the length of the plaintext is fixed. Therefore, the replacement of function Z by const \(Z_T\) is valid.

Mechanized Proof. The security properties presented in the final phase can be mechanically proved using CryptoVerif. The validity of the result depends on the soundness of CryptoVerif.

The security result for the cryptographic support commands in TPM 2.0 can be formalized as the following theorem.

Theorem 1

The cryptographic support commands defined in Sect. 2 are secure, under the assumptions of a symmetric encryption scheme against adaptive chosen-ciphertext attack, a public-key encryption scheme against adaptive chosen-ciphertext attack, a strong existentially unforgeable message-authentication code and a strong existentially unforgeable signature scheme.

CryptoVerif can then automatically prove the theorem by querying the following properties:

figure b

The proof done by CryptoVerif consists of applying cryptographic transformations for the security assumptions, with some simplifying processes and other syntactic transformations between two of them. As a consequence, all queries are proved in the final game generated by CryptoVerif. We refers the readers to get the input of CryptoVerif in [17] and execute it by oneself.

5 Conclusion

In this paper, we use an unusual, peculiar but interesting way to automatically prove the cryptographic support commands in TPM 2.0. These commands includes key creations, encryption, signature, etc. We model these commands with a security policy expressed in the notion of modern cryptography. Then we express the security policy using a probabilistic polynomial-time process calculus. We prove that these commands satisfy this security policy with the assistance of automated tool CryptoVerif who works in the computational model.

A possible extension of this work lies in modelling a more complex control flow and handling a situation of state transition. This can lead to a more precise proof.