Stateful Security Protocol Verification
A long-standing research problem in security protocol design is how to efficiently verify security protocols with tamper-resistant global states. In this paper, we address this problem by first proposing a protocol specification framework, which explicitly represents protocol execution states and state transformations. Secondly, we develop an algorithm for verifying security properties by utilizing the key ingredients of the first-order reasoning for reachability analysis, while tracking state transformation and checking the validity of newly generated states. Our verification algorithm is proven to be (partially) correct, if it terminates. We have implemented the proposed framework and verification algorithms in a tool named SSPA, and evaluate it using a number of stateful security protocols. The experimental results show that our approach is not only feasible but also practically efficient. In particular, we have found a security flaw on the digital envelope protocol, which could not be detected by existing security protocol verifiers.
Many widely used security protocols, e.g., [GM99, BW00, MR08, AR10], keep track of the protocol execution states. These protocols maintain a global state among several sessions and can behave differently according to the values stored in the global state. More importantly, the protocol’s global state is tamper-resistant, i.e., it cannot be simply cloned, faked, or reverted. As the result, we cannot treat the global state as an input from the environment so that the protocol becomes stateless. In practice, such global states are usually extracted from trusted parties in protocols like central trustworthy databases, trusted platform modules (TPMs), etc.
The global state poses new challenges for the existing verification techniques as discussed below. First, most existing verification tools, e.g., ProVerif [Bla01] and Scyther [Cre08], are designed for stateless protocols. When they are used to verify stateful protocols, false alarms may be introduced in the verification results. For instance, when the protocol state is ignored in these tools, a value generated in a later global state can be used in a former global state. However, the execution trace is actually impractical. Second, stateful protocols usually have sub-processes that can be executed for infinitely many times. However, the state-of-the-art tools, e.g., [Bla01, Cre08, ARR11], cannot handle loops. As a consequence, only a finite number of protocol execution steps can be modeled and checked. Therefore, valid attacks could be missed in the verification. Even though some tools like Tamarin [MSCB13] can specify loops, the verification cannot terminate for most stateful protocols as they do not consider the states as tamper-resistant in the multiset rewriting rules [DLM04]. Third, some of the abstractions made in the existing works tend to either make the verification non-terminating for stateful protocols or introduce false alarms. For instance, fresh nonces generated in ProVerif [Bla01] are treated as functions to the preceded behaviors in a session so that the nonces with the same name could be merged under the same execution trace. On one hand, if a stateful protocol receives some data before generating any nonce in its session, the nonce generated in one session can be received before the same nonce is generated in a different session. According to the abstraction method, the nonce becomes a function applied to itself, which could lead to infinite function applications. Thus the verification cannot terminate. On the other hand, if a nonce is generated without performing any session-specific behavior, then the nonce will be the same for multiple sessions. The query of asking whether the nonce for a particular session can be deduced may give false alarms, because the nonce that can be deduced is actually coming from another session. As these nonces are merged, they cannot be differentiated in the verification process.
To address the above identified challenges for verifying stateful security protocols, we first propose a protocol specification framework (see Section IV) that explicitly models the protocol execution state as tamper-resistant. We specify how states are used in the protocol as well as how states are transferred. As a result, stateful protocols can be modeled in our framework in an intuitive way. The protocol specification is introduced with a motivating example of the digital envelope protocol [AR10]. Second, a solving algorithm is developed to verify stateful protocols. During solving, we apply a pre-order to the states and converge the states into a valid state trace. The secrecy property checked in this work is then formulated into a reachability problem. The partial correctness of our method is formally defined in Section LABEL:sub:query and proved in Section LABEL:sec:verification. However, as the security protocol verification problem is undecidable in general [MSDL99], our algorithm does not guarantee the termination. The experiments show that our method can terminate for many stateful security protocols used in the real world. Third, we develop a tool named SSPA (Stateful Security Protocol Analyzer) based on our approach. Several stateful protocols including the digital envelop protocol and the Bitlocker protocol [BL11] have been analyzed using SSPA. The experiment results show that our method can both find security flaws and give proofs efficiently. Particularly, we have found a security flaw in the digital envelope protocol which has not been identified before.
Structure of the paper. Related works are discussed in Section II and a motivating example is given in Section III. In Section IV, we present our protocol specification framework and describe how to specify cryptographic primitives, protocols and queries. In Section LABEL:sec:verification, we show how the verification algorithm works and prove its partial correctness. We show the implementation details and the experiment results in Section LABEL:sec:experiments. Finally, we conclude the paper with some discussions in Section LABEL:sec:discussions.
Ii Related Works
Mödersheim developed a verification framework that works with global states [Mod10]. His framework extends the IF language with sets and abstracts the names based on its Set-Membership. According to [Mod10], this method works well for several protocols. However, its applicability in general is unclear since sets should be explicitly identified for the protocols and no general solution for identifying the set is given in the paper. Guttman extended the strand space with mutable states to deal with stateful protocols [Gut09, Gut12], but there is no tool support for his approach. Our approach presented in this paper is different from theirs, as the protocol specification does not need to be changed in our framework and we provide automatic tool support.
StatVerif is introduced by Arapinis et al. [ARR11] to verify protocol with explicit states. It extends the process calculus of ProVerif [Bla01] with stateful operational semantics and translates the resulting model into Horn clauses. ProVerif is then used as an engine to perform verification. Comparing with their method that can only work with a finite number of (global) states, our approach is more general and works for protocols with infinite states.
In [DKRS11], Delaune et al. modeled TPMs with Horn clauses and have verified three protocols using ProVerif. However, the specifications need to be adapted according to the different protocols under study. For instance, an additional parameter is added into the global state when it is used for the digital envelope protocol (DEP) [AR10] to prevent false attacks. More importantly, they also modified the specification of the DEP in a way that false negatives can happen (attacks are missing) comparing with the original DEP proposed in [AR10]. This is because their method does not work for infinite steps of the stateful protocols. Specifically, they have constrained the protocol so that its second phase is not repeatable. More discussions on the DEP can be found in Section III. Notice that all of the previous methods can only work with protocols with finite steps. while this is not the case with our approach.
Iii Motivating Example
We introduce the digital envelope protocol (DEP) [AR10] in this section as a motivating example. Before going into the details of the protocol, we give a brief introduction on the trusted platform module (TPM) [TPM] used in the protocol first.
TPM is an embedded cryptographic device proposed to give higher level security guarantees than those can be offered by software alone. Every TPM has several tamper-resistant platform configuration registers (PCRs) that maintain the current state of the TPM. The values stored in the PCRs can only be extended. One possible implementation of extending a PCR with a value could be , where is a one-way hash function applied to the concatenation of and . Hence, the extending actions are irreversible unless the TPM reboot is allowed (the PCRs are reset to the default value ) and the previous extending actions are replayed in an identical order. TPM provides several APIs to help the key management, including key generation, key usage, etc., under PCR measurement.
TPMs use several types of keys, including the attestation identity keys (AIKs) and the warp keys. The AIK represents the identity of the TPM in the protocol and can be used for signing. In order to differentiate the TPMs, we assume every TPM has a unique AIK. However, this assumption does not prevent the adversary from using multiple AIK values as he could initiate multiple TPMs. The warp keys form a tree structure rooted under the permanent loaded storage root key (SRK). We usually use two kinds of warp keys in the TMP, i.e., the binding keys and the storage keys. Data can be encrypted with the binding public key remotely, or can be sealed with the loaded storage key in the TPM. Typically, the TPM supports the following operations.
Extend. Extend the PCR value by any value to a new PCR value .
Read. Read the current PCR value from the TPM.
Quote. Certify the current PCR value.
CreateWrapKey. Generate a warp key under a loaded parent key and bind it to a specific PCR value. The new key is not yet loaded into the TPM but stored in a key blob, which is a storage place for holding the key.
LoadKey2. Load the key into TPM by providing the key blob and its parent key.
CertifyKey. Certify a loaded key.
UnBind. Decrypt the data with a loaded binding key. The PCR value for the key should be matched.
Seal. Encrypt the data with a storage key. The PCR value for the key should be matched and the encrypted data can be sealed to a particular PCR value.
UnSeal. Decrypt the data with the loaded storage key. The PCR value of the seal key, the PCR value of the sealed storage and the current PCR value are required to be the same.
As the storage key and seal/unseal operation are not used in the DEP, we omit their specification in the following discussions.
By using TPMs, the DEP allows an agent Alice to provide a digital secret to another agent Bob in a way that Bob can either access without any further help from Alice, or revoke his right to access the secret so that he can prove his revocation. This protocol consists of two phases as shown in Figure 1. In the first phase, Alice generates a secret nonce and uses it to extend a given PCR in Bob’s TPM with an encrypted session. The transport session is then closed. Since the nonce is secret, Bob cannot re-enter the current state of the TPM if he makes any changes to the given PCR. In the second phase, Alice and Bob read the value of the given PCR as and Bob creates a binding key pair locked to the PCR value and sends the key certification to Alice, where is an agreed constant in the protocol. This means the generated binding key can be used only if the value is first extended to the PCR of value . After checking the correctness of the certification, Alice encrypts the data with her public key and sends it back to Bob. Later, Bob can either open the digital envelope by extending the PCR with or revoke his right to open the envelope by extending another pre-agreed constant . If Bob revokes his right, the quote of PCR value can be used to prove Bob’s revoke action. The protocol is illustrated in Figure 1.
In fact, through our approach and the implemented tool, we have found a cold-boot attack for this DEP when the TPM reboot is allowed. According to the DEP proposed in [AR10], the authors only mentioned that Bob may lose his ability to open the envelope or to prove his revoke action if the TPM reboot is allowed. To the best of our knowledge, this attack has not been described before. We present the attack scenario in Figure 2. When the TPM reboot is allowed, Bob can reboot his TPM immediately after the first phase. As a consequence, the secret nonce extended to the given PCR is lost. When Alice checks the PCR value in the beginning of the second phase, she actually reads a PCR value that is unrelated to her previous extend action. Hence, Bob can re-enter the current TPM state by simply performing TPM reboot again. This attack is caused by the fact that the PCR value in the second phase can be unrelated to the PCR value in the first phase. On the other hand, if the TPM reboot is not allowed, the secret nonce could never get lost. So Alice can conduct the second protocol phase for multiple times and the claimed properties of the DEP are always preserved. In this way, if the TPM is maintained by a trusted server and remotely controlled by both Alice and Bob without the right to reboot TPM, this protocol is secure.
This protocol was previously verified in [DKRS11]. However, the modifications made in [DKRS11] to the original DEP prevent the authors from detecting the attack. In the modified version [DKRS11], Bob always does the TPM reboot before the first phase and Alice assumes that the PCR is without actually reading the value in the beginning of the second phase. As a result, TPM reboot can never happen before the second phase. The reason why they need to make such modifications is because ProVerif, which is used in their verification, can only model finite protocol steps. Unfortunately, this makes it impossible to find the attack as described in Figure 2. On the contrary, in this work, we provide a framework where protocols like this can be modeled faithfully and verified automatically.
Iv Protocol Specification
In this section, we describe our specification framework for modeling (stateful) protocols, crypto primitives and queries as a set of first order logic rules with the protocol execution states explicitly maintained. There are two categories of rules that can be specified in our approach, i.e., state consistent rules and state transferring rules. The state consistent rules specify the knowledge deductions, while the state transferring rules describe the state transitions. Since the protocol global state is tamper-resistant, we assume that it can only be changed by the state transition rules. The adversary model we consider in this work is the standard active attacker, who can intercept all communications, compute new messages and send any messages that he can obtain or compute. For instance, he can use all the public available functions including encryptions, decryptions and etc. He can also ask the legitimate protocol participants to take part in the protocol. That is, every rule specified in the framework describes a logic capability of the adversary. Our goal is to check whether he can deduce a target fact or not.
Iv-a Framework Overview
In our framework, every entity and device in the protocol is treated as an object when it is tamper-resistant. Every object have an object global state with a unique identity. The protocol global state then consists of several object global states. For simplicity, we name object global state after state for short, and call protocol global state as protocol state in the remaining of this paper. For instance, every TPM has a state which records the AIK value and the PCR value . The AIK value uniquely identifies the TPM. Initially, the protocol state of DEP is , where stands for the AIK constant for Bob’s TPM. After the first phase of the DEP, Alice enters a state where is the secret value that she extends to Bob’s TPM. When Alice obtains the state, she can initiate the second phase of the protocol. Because Alice could start several sessions to Bob’s TPM, we treat as the identity of Alice’s state. When Alice extends the nonce to Bob’s TPM, the protocol state becomes . A protocol state can contain several TPM states with different AIK values.
The states of the same object should be ordered in a timeline of protocol execution, forming a state trace. For instance, the following sequence of four states is a legitimate TPM state trace in the DEP.
The first state is the initial state. Then, in the first phase of the DEP, Alice extends a secret nonce into Bob’s TPM (the second state). Later, Bob extends a value into his TPM for other purposes (the third state) and the second phase of the DEP begins. At the beginning, Alice and Bob record the PCR value as . When Bob receives Alice’s sealed secret, Bob extends the pre-agreed constant to revoke his right of opening the envelope (the fourth state). In most protocols, one state can be used for multiple times. For instance, in the above example, Bob needs to use the third TPM state for several times to generate key, load key, generate certifications and etc. As these states are actually the same, we need to identify them as one state when they are used in different places. On the other hand, the first state used in the protocol is precedent to the third state. Thus, we should also identify how states are updated, namely the transformation an old state to a new state.
The protocol rules specified in our framework are of the form . is a set of premises such as the terms that the adversary should know and the events that the protocol should engage. is a set of states. Both of and must be satisfied so that the rule is applicable. For example, when the adversary wants to load a key into the TPM, the adversary should know its parent key and obtain the TPM state with matched PCR value. is the conclusion of the rule with two types of values. One type of conclusion is a fact. Take the TPM loading key as an example, its conclusion is a fact that the adversary can get the loaded key in the TPM. The other type of conclusion represents how the states are transferred from old ones to new ones. As the states in our framework are attached to the objects, the conclusion consists of pairs of old state and new state for the same object, denoting that state is converted from one to another. In TPM extending operation, the conclusion is one pair of states in which the PCR value in the second state is extended. and help us to organize the correspondences between facts and states. maps the facts to the states indicating that the facts should be known at which states. is the orderings of the states generated from the knowledge deduction. For instance, when a fact required by a rule can be provided as the conclusion of another rule , we can compose these two rules together to remove the requirement of . Since the is provided by and used in , the states mapped by in are required later than requirement of the states in . The orderings are specified in the verification process to make sure that the state trace is practical for the protocol. We name the rule as state consistent rule when is a fact and call the rule as state transferring rule when is a set of state conversions.
In addition, we use events and states to distinguish the protocol sessions. The events are engaged in the rule predicates to indicate the generation of fresh nonces. Since fresh nonces are random numbers, we assume their values can uniquely identify the events. Whenever the nonces generated in different events have the same value, these events should be merged. On the other hand, the states are used to describe the objects or entities presented in the protocol. Basically, we use states to differentiate the different phases of the objects. As we do not bound the number of events and states, the verification is conducted for an infinite number of sessions.