3.6 Security Analysis
3.6.2 Formal Security Analysis
To formally analyze the proposed protocol, we use the AVISPA protocol prover [182].
AVISPA provides a High Level Protocol Specification Language (HLPSL) [10, 33] for describing security protocols and specifying their intended security properties. Proto-cols specified in HLPSL are then translated into an Intermediate Format (IF). This intermediate format can then directly be used as input for different model checkers supplied by AVISPA (see the AVISPA website for more details2).
AVISPA is a powerful tool to formally analyze cryptographic protocols. However, all tools which can be used to formally analyze cryptographic protocols have in common that they only implement the Dolev-Yao attacker model and are, thus, not capable of detecting special types of insider attacks. Insider attacks are a very powerful attack type, since these attackers can also create authentic messages. The relay attack pre-sented in this chapter is some type of inside attack since the adversary controls a second machine including the private TPM key. Therefore, present cryptographic protocol an-alyzers cannot detect protocol weaknesses against inside attackers. However, since our proposed protocols also include an authentication phase and a key-establishment, it is verifiable whether both authentication phase and key-establishment are secure against Dolev-Yao attackers [50].
In the following, we present the different roles specified in HLPSL of our attestation protocol. We will first present the challenging entity (Alice), followed by the prover (Bob), the attacker model and the intended security properties.
State Transitions
For specifying the challenger, we will first look at a fragment of the challenger’s role.
In this fragment, the variables and the challenger’s knowledge are specified.
role challenger (A, B: agent,
Ka, Ks: public_key, H: function,
G: text,
SND, RCV: channel (dy)) played_by A def=
local State : nat, Na, Nb: text, X:text,
AIK: public_key, PCR:text,
SK:message, KEr:message
2www.avispa-project.org
The prover’s role is specified analogously.
role attestor(A, B: agent,
AIK: public_key, Ks : public_key, H: function, G: text,
SND, RCV: channel (dy)) played_by B def=
The protocol flow is specified through state transitions. The initial state is set to state 0 and the challenger generates a random nonce (Na) and the secret part of his Diffie-Helman keyX’. HLPSL provides for this process the new() command. The chal-lenger then puts on his SND line the generated nonceNa’ and the public Diffie-Helman key. The exponentiation to compute a public Diffie-Helman key is specified in HLPSL through the functionexp(G,X’), which stands for GX0 modn. After the package is put on the SND line, the challenger’s state is set to 2.
init State := 0 transition
0. State = 0 /\ RCV(start) =|>
State’:= 2 /\ Na’ := new() /\ X’ := new()
/\ SND(Na’.exp(G,X’))
The prover receives the sent package in state one and generates his own secret part of his Diffie-Helman key by assigningY’:=new(). He also obtains the current PCR values, which is abstracted, since HLPSL does not provide any means of directly modeling TPMs. The generated public key is then hashed together with the nonce and the PCRs and signed with theAIK. After sending the attestation response, the prover also computes the secret key SK and witnesses the challenger that he is able to compute a valid signature on the challenge.
init State := 1 transition
1. State = 1 /\ RCV(Na’.KEi’) =|>
State’:= 3 /\ Y’ :=new() /\ PCR’ :=new()
/\ SND({B.AIK}_inv(Ks).{Na’.exp(G,Y’).PCR’}_inv(AIK)) /\ SK’ := H(exp(KEi,Y’))
/\ witness(B,A,challenger_attestor_na,Na’)
3.6. SECURITY ANALYSIS 39 The challenger receives the attestation response in state 2 and computes the shared secret SK’. He then generates a new nonce Nb’, encrypts the nonce and delivers the encrypted package to the prover.
2. State = 2 /\ RCV({B.AIK’}_inv(Ks).{Na.KEr’.PCR}_inv(aik)) =|>
State’:= 4 /\ SK’:=H(exp(KEr’,X)) /\ Nb’ := new()
/\ SND({Nb’}_SK’)
The prover receives the encrypted package, decrypts the nonce with the negotiated key SK’ and sends the decrypted nonce Nb’ to the challenger. Sending this nonce in plaintext does not result in a security problem since this message only acknowledges correct receipt of the previous message.
3. State = 3 /\ RCV({Nb’}_SK) =|>
State’:= 5 /\ SND(Nb’) /\ witness(B,A,sk1,SK)
/\ witness(B,A,challenger_attestor_nb,Nb’)
The challenger receives the answer in state 4 and checks whether the specified security properties are satisfied.
4. State = 4 /\ RCV(Nb’) =|>
State’:= 6 /\ secret(SK,sk1,{A,B})
/\ request(A,B,challenger_attestor_na,Na) /\ request(A,B,challenger_attestor_nb,Nb’) /\ request(A,B,sk1,SK)
Intruder Model and Environment
We use the Dolev-Yao intruder model [50] to model the attacker and the environment.
In this intruder model the attacker is a legitimate user of the network and has full control over all messages that are sent over the network. The attacker can therefore intercept, analyze or modify messages, as well as compose new messages and send the messages to whoever he wants. The channels are named SA, RA, SB, RB, which stands for send/receive Alice and send/receive Bob respectively. To abstract from the negotiation of a common generator g and a common group p, we assume that these are global parameters. These parameters are modeled with the variable Gand are also known to a potential attacker.
role session(A, B: agent, Ka, AIK, Ks: public_key, H: function, G: text) def=
local SA, RA, SB, RB: channel (dy)
composition
challenger(A,B,Ka,Ks,H,G,SA,RA) /\ attestor (A,B,AIK,Ks,H,G,SB,RB) end role
The environment role contains the global constants as well as a composition of sessions that the intruder is able to play as legitimate user.
role environment() def=
const a, b : agent,
aik, ka, ks, ki : public_key, h : function,
g: text,
na, nb, challenger_attestor_nb,
attestor_challenger_na, sec_a_SK, sk1,nb1 : protocol_id intruder_knowledge = {a, b, aik, ka, ks, ki, inv(ki),
{i.ki}_(inv(ks)),g,h}
composition
session(a,b,ka,aik,ks,h,g) /\ session(a,i,ka,ki,ks,h,g) /\ session(i,b,ki,aik,ks,h,g) end role
The following code fragment defines the security properties of our proposed protocol.
The goal of the protocol is to authenticate Bob and to establish a secret key between both entities. The intruder should not be able to learn the secret keySK; furthermore he should not be able to perform a valid authentication.
goal
authentication_on alice_bob_na authentication_on alice_bob_nb authentication_on Kab
secrecy_of Kab
To specify the different security goals, we added in the respective state transitions the necessary events. These events are specified using the witness, request and secret structure (see [10], pp. 28 for more details). In our case, we use the witness and request for specifying the following security goals:
• A authenticates a genuine and authentic TPM on the valueNa. This holds since only an authentic TPM is able to sign Na with a corresponding non-migratable key (AIK or special purpose key).
3.6. SECURITY ANALYSIS 41
• A authenticates the TPM of B on the value KAB. This holds since given the first statement, only the owner of the TPM possesses the corresponding private Diffie-Helman key. As a consequence, only A is able to compute the secret key based on the provided public key.
• Aauthenticates the TPM ofBon the valueNb. This holds since given the second statement, only B can decrypt Nb and send it back to A.
• A and B share the key KAB, which is confidential and is kept secret.
It should be noted that we do not directly authenticate B to A. A only determines whether she is currently communicating with the platform that has provided authentic measurements and that this channel is authentic.
For specifying authentication goals, AVISPA provides thewitness and request com-mands and for specifying the secrecy goal, it provides the secret command. We again refer to the AVISPA technical documentation [10] for further information on these commands and security goals. Here, we will only exemplary discuss how we specified authentication on Na.
For this purpose, the prover witnesses in state 1 the challenger that he answered his challenge.
/\ witness(B,A,challenger_attestor_na,Na’)
This statement can be understood as follows: Agent B declares that he wants Agent A agreeing on the value Na’. The counterpart of this statement is required in state 4 and stated as:
/\ request(A,B,alice_bob_na,Na)
This statement is read as follows: Agent A accepts the value Na and now relies on the guarantee that agent B exists and agrees with her on this value.
Results
After specifying the protocol, we analyzed the model with the model checkers provided by AVISPA. We found no attack trace; thus the protocol analyzer reports that all security properties are satisfied and Protocol 3.5.2 is secure against Dolev-Yao attackers.
Protecting the Stored Measurement Log
To further enhance the security of our proposed protocol, we move transmitting the privacy-related SML into an cryptographically protected message. This has the advan-tage that the protocol must not necessarily be integrated into another cryptographic channel to satisfy Requirement 2. Our protocol then satisfies an additional security requirement (the secrecy of the SML). However, in that case, the challenger can only validate the platform configuration of B after receiving the last message. We also
modify messages (2), (3) and (4) of our protocol to provide complete confidentiality of all messages sent over the channel. This modification is comparable to the Finished messages as they are used in the TLS-protocol to detect potential tampering on the exchanged messages. The resulting protocol flow is shown in Protocol 3.6.3. We do not present the detailed protocol actions since they are rather similar to Protocol 3.5.2. The protocol was also modeled in AVISPA to formally analyze its security properties. Be-sides the security properties of Protocol 3.5.2, we analyzed whether the SML is always confidential and always protected by cryptographic measures. This security property is summarized through the following goal:
• Aand B share the Stored Measurement Log (SML), which is privacy related and is confidential.
Protocol 3.6.3: Enhanced Robust Integrity Reporting Protocol SUMMARY:B answers the attestation challenge of platformA
RESULT: Key establishment with key confirmation: confidential integrity reporting 1. Notation.
KAB denotes the negotiated key betweenA andB. 2. System setup.
A must possess the certificate of the Privacy-CA to validateCert(AIK, KAIK).
3. Protocol messages.
A → B :Na,gamodp, g,p (1)
A ← B :Cert(AIK, KAIK),{Na, PCR,gbmodp}K−1
AIK (2)
A → B :{Nb,gamodp}KAB (3)
A ← B :{Nb, Na, SML,gb modp}KAB (4)
Results
After modeling the protocol and analyzing it with AVISPA, we found no attack trace;
thus, the protocol analyzer reports that the enhanced version of the protocol satisfies all security properties and is secure against Dolev-Yao attackers. We also implemented both our proposed protocols (Protocol 3.5.2 and Protocol 3.6.3) and run performance
3.7. ATTESTATION AS TLS EXTENSION 43