Timestamped Hash-Chain Attestation

Each time a new attestation request arrives at the server, the input thread forks a new process. This process adds the incoming nonce to the NonceList and remembers the area of the ring buffer that is responsible for the process. The working thread runs continuously; this thread is responsible for passing data to and receiving data from the TPM. As soon as the working thread receives an answer from the TPM, the working thread writes the results in the ring buffer and rotates the tri-state ring buffer. This working thread then retrieves the newNonceList of the adjacent area, which he hashes to create the HashedNonceList and passes to the TPM. While the working thread is operating on the TPM, the processes that are responsible for answering the client’s attestation-requests are waiting until the tri-state buffer has been rotated one round and their data is ready. As soon as the requested data is present in the buffer, the processes that are responsible for the request can deliver the attestation-response, consisting of the signedHashedNonceList and PCR, to the requester.

This approach enables a very efficient realization of the Multiple-Hash Attestation.

Since the working thread that is responsible for the TPM is also responsible for the ring buffer, a maximum utilization of the TPM can be achieved. Incoming attestation requests must wait a maximum of two rotation steps of the ring buffer before the result is available. Thus, in the worst case, the response is available after two signature computations on the TPM have been performed.

4.4. SCALABLE SOLUTIONS 61

TTP

Figure 4.3: Protocol flow of the Timestamped Hash-Chain Attestation

Since the TTP issues a timestamp only for the first nonce, the verifying clients cannot directly validate whether the received nonce is valid in the current interval. To enable the clients to verify the validity of the nonce, the server has to provide a proof that he applied the hash function the correct number of times. This ensures freshness of integrity information and thus satisfies Requirement 1 of a secure attestation channel.

Since the attestation service of the server is part of the server’s platform configuration and thus its state is included in the SML, the clients can verify that the attestation service is in a trusted state. The proof is thus being made through validating the platform configuration of the service.

Figure 4.3 depicts the Timestamped Hash-Chain Attestation. After each interval, the server calculates a new hash-value with which the new attestation is performed.

The length of such an interval depends on how long it takes to create an attestation token (which is TPM related). As a result, one interval cannot be smaller than it takes to generate an attestation token. In Section 7.7.2, we present some evaluation results of a representative TPM. On our used TPM hardware, one interval cannot be smaller than approx. 1.4 seconds.

To enable the clients to validate the freshness of the platform configuration, the server delivers an attestation token (τ) to the requester. This attestation token consists of the TTP-signed seed nonce together with a timestamp, an AIK signed message with the current interval count, the nonce of the current interval, the PCRs and the public Diffie-Helman key of the server and the certificate of the AIK. We denote the initial TPM-signed nonce as seed nonce since this initial nonce is generated by the TTP and all further nonces are computed based on this nonce. The attestation token therefore

consists of all information that is necessary to validate the freshness of the attestation response:

τ = {Na₀, time₀}_K⁻¹

T T P,Cert(AIK, K_AIK) (4.3)

{h^v(Na₀), v, PCR, g^smodp}_K⁻¹

AIK.

The attestation token introduced here has similarities to the one introduced in [103].

However, the main difference is that a verifier can validate the platform configuration without requiring the prover to perform expensive TPM operations. To verify that the platform configuration of the server is trusted, the clients have to verify the validity of all certificates, all signatures and the validity of the timestamp. Note that this cost intensive validations must only be performed by the clients and not by the server.

Furthermore, the clients have to verify whether the received nonce is valid in the current active interval. For this purpose, the following equation must hold: time₀+v·t≤now ≤ time₀+ (v+ 1)·t+, wherev represents the interval number,tthe time length of the interval, andtime the point of time when the TTP generated thenonce. Moreover,now denotes the current time of the verifier anda certain error range. The time length of the interval is part of theSMLand thus represented by the platform configuration of the server. The protocol again integrates an authentication process to ensure Requirement 3 of a secure attestation channel. Requirement 2 of a secure attestation channel is again satisfied by delivering the SML in the established cryptographic channel. The resulting protocol is shown in Protocol 4.4.4.

Protocol 4.4.4: Timestamped Hash-Chain Attestation SUMMARY:S answers the attestation challenge of C_x

RESULT: Integrity reporting: key establishment with key confirmation 1. System setup.

C_x must acquire (and validate) the certificate of the Privacy-CA to validate Cert(AIK, K_AIK)

2. Protocol messages.

TTP → S : {Na0, time0}_K⁻¹

T T P (1)

C_x → S : g^cx modp (2)

C_x ← S : {Na₀,time₀}_K⁻¹

T T P,{h^v(Na₀), v, g^smodp,PCR}_K⁻¹

AIK, Cert(AIK, K_AIK)

(3) C_x → S : {Nb_x, g^cx modp}_KSCx (4) C_x ← S : {Na_v, Nb_x, SML, g^s modp}K_SCx (5)

4.4. SCALABLE SOLUTIONS 63 3. Protocol actions.

(a) S chooses a TTP for providing the seed nonce and the TTP transfers message (1) to S.

(b) Precomputation by S. S selects an appropriate prime p and generator g of Z^∗_p (2 ≤ g ≤ p−2). S chooses a random secret s, 2 ≤ s ≤ p−2, and computes g^smodp. S transmitsp and g to allC_x.

(c) Precomputation by C_x. C_x chooses a random secret c_x, 2≤c_x≤p−2, and computes g^cx modp.

(d) Attestation challenge. C_x, x= 1, . . . , n,deliver message (2) toS.

(e) Depending on the current interval v, S computes the current valid nonce Na_v by calculating:

Na_v =h(Na_v−1), with v= 1, . . . , k. (4.1) (f) S computes the attestation response message by signing Na_v, the current interval v and the set of requested PCRs using an AIK thereby obtaining {h^v(Na0), v, g^smodp,PCR}_K⁻¹

AIK.

(g) S transmits the attestation tokenτ in message (3) toC_x.

(h) Key confirmation. C_xcomputes the shared session key by computingK_SCx = (g^s)^cx modp. C_x then generates a second non-predictable nonce (N b_x) and transfers message (4) to S.

(i) S computes the shared session key by computing K_SCx = (g^cx)^smodp and decrypts the received message with K_SCx. S then transfers message (5) to C_x.

(j) C_x verifies all signatures and checks the freshness of the Na_v by checking whether Equations (4.2) and (4.3) hold:

time₀+v·t≤now≤time₀+ (v+ 1)·t+, (4.2) h^v(Na₀)=^? Na_v. (4.3) (k) Finally, C_x verifies that the platform configuration ofS is trusted based on

the SMLand thePCRs.