Individual Attestation Protocol (IAP)

In contrast to the PBAP, the IAP can be used to individually verify whether the plat-form configuration of a SN is trusted. A CN needs only to perplat-form symmetric operations and two short messages need to be exchanged. The messages are very small, because no long public key primitives, e.g., keys, signatures need to be transmitted. Since trans-mitting messages is the most cost intensive factor in WSNs [190], this is of particular

interest, especially if the sink wants to verify the platform configuration of a SN. In this case, messages are transferred along several hops.

The protocol we propose is again divided in initialization phase and attestation phase. The initialization phase is performed only once after deployment of the sensor nodes while the attestation phase can be performed every time a CN (or the sink) wants to verify the platform configuration of a SN. In the embedded world, this initialization phase could for example performed directly before a vehicle leaves the factory site.

Initialization EachCN_j establishes a shared, symmetric keyK_CNj,SNi with itsSN_i. For this purpose, existing (non TPM-based) techniques, e.g., [191], might be used.

However, we recommend using a key establishment protocol that uses the functionality of a TPM, e.g., [66]. This approach has the advantage that key generation within a TPM is inherently more secure than key generation on off-the-shelf embedded platforms.

As in [191], we assume that this short period of time to establish pairwise keys is secure and nodes cannot be compromised. The keys K_CNj,SNi are sealed onSN_i to its valid platform configuration P_SNi. Thus, SN_i can only access these keys if it is in its valid state.

To enable the sink to perform the attestation with SN_i, a shared symmetric key K_Sink,SNi is preconfigured on SN_i before deployment and sealed likewise.

Attestation Protocol 6.4.4 shows howCN_j can verify the platform configuration of SN_i. First, CN_j sends a challenge to SN_i. The challenge consists of an encrypted block containing anonce and the identifier ID_CNj of CN_j, and an additionally ID_CNj in plaintext. K_CNj,SNiis used for encryption. After receiving the challenge,SN_iunseals K_CNj,SNi related toID_CNj. This is only possible if the platform configurationP_SNi is valid. Using this key, SN_i decrypts the encrypted block and verifies if the decrypted identifier is equal to the identifier received in plaintext. If they match, SN_i knows that this message originates fromCN_j, encrypts thenonce⁰ usingK_CNj,SNi, and sends it back.¹ Otherwise, SN_i aborts. SN_i then deletes K_CNj,SNi from the RAM. CN_j decrypts the received response message and checks if the decrypted nonce⁰⁰ matches the nonce it has sent in the first step. If they match, SN_i is declared trusted and CN_j can send data to SN_i. This data is encrypted using K_CNj,SNi. The attestation of SN_i by the sink is performed likewise, using the key K_Sink,SNi. Protocol 6.4.4 uses a challenge-response authentication involving the TPM to verify freshness of integrity information and thus satisfies Requirement 1. In addition, the ID of the CN is also injected to prevent replay attacks. Requirement 3 is also satisfied by binding further transaction data sent over the channel to a specific cryptographic key shared between theSN_i and CN_j. In contrast to the PBAP, this approach ensures authenticity of the attestation channel and, thus, establishes a secure attestation channel.

1However, the trust level ofCNj cannot be assumed, because the node could be potentially com-promised and the key is not protected by a TPM.

6.4. ATTESTATION PROTOCOLS 99

Protocol 6.4.4: Individual Attestation Protocol SUMMARY: A CN verifies the integrity of a SN RESULT: Integrity validation

1. Notation.

SN_i is a super node CN is a cluster node

P_SNi denotes the actual platform configuration

K_CNj,SNi denotes the shared key betweenCN_j and SN_i 2. Protocol steps.

CN_j →SN_i: ID_CNj,{nonce, ID_CNj}_KCNj,SNi (1) SN_i Unseal(P_SNi, d_SNi,{K_CNj,SNi}^e_P^SNi_SNi) =K_CNj,SNi (2) SN_i D({nonce, ID_CNj}_KCNj,SNi, K_CNj,SNi) = (nonce⁰, ID⁰_CNj) (3) SN_i checkID⁰_CN

j

=? ID_CNj (4)

SN_i E({nonce⁰, ID_SNi}, K_CNj,SNi) ={nonce⁰, ID_SNi}_KCNj,SNi (5) SN_i →CN_j : ID_SNi,{nonce⁰, ID_SNi}K_CNj,SNi (6)

SN_i deleteK_CNj,SNi from RAM (7)

CN_j D({nonce⁰, ID_SNi}K_CNj,SNi, K_CNj,SNi) = (nonce⁰⁰, ID⁰_SNi) (8) CN_j ifnonce⁰⁰=^? nonce, state of SN_i is valid (9) 3. Protocol actions.

(a) In the first step, CN_j transfers an encrypted nonce together with its ID using the shared key to SN_i.

(b) SN_i performs the TPM Unsealcommand and unseals the shared key.

(c) SN_i decrypts the sent message an verifies in (4) whether the ID of the decrypted message matches the ID sent in plaintext.

(d) SN_iencrypts the decrypted nonce and theIDofCN_j with the unsealed key.

The obtained message is transferred to CN_j in (6).

(e) SN_i deletes the unsealed key from its RAM.

(f) CN_j decrypts the received message and verifies (9) if the received nonce matches the nonce sent in (1).

It might also be preferable to directly transmit data in an attestation challenge rather than waiting until an attestation response has been received and a SN is declared

trusted. This might be preferable in scenarios where an immediate receipt of data is important or where CNs send data very infrequently to a SN. Therefore, the protocol is modified in steps (1) and (3). Protocol 6.4.5 shows the resulting protocol and also satisfies Requirement 1 and Requirement 3 of a secure attestation channel (see Chapter 3. In step (1) CN_j sends the data to SN_i within the encrypted block. SN_i can only decrypt this message in step (3) if its platform configuration is valid and access the data.

All other steps remain the same as shown in Protocol 6.4.4. Thus, if CN_j receives the message in step (6) and the checks in steps (7) and (8) succeed, CN_j can be assured that SN_i has successfully received the data and is still trusted.

Protocol 6.4.5: Modified Individual Attestation Protocol

SUMMARY: A CN delivers data that is bound to a specific state to a SN RESULT: Data transfer with data confirmation and integrity reporting 1. Notation.

SN_i is a super node CN is a cluster node

P_SNi denotes the actual platform configuration

K_CNj,SNi denotes the shared key betweenCN_j and SN_i 2. Protocol steps.

CN_j →SN_i : ID_CNj,{nonce, ID_CNj, data}K_CNj,SNi (1) SN_i Unseal(P_SNi, d_SNi,{K_CNj,SNi}^e_P^SNi_SNi) =K_CNj,SNi (2) SN_i D({nonce, ID_CNj, data}_KCNj,SNi, K_CNj,SNi) =

(nonce⁰, ID_CN⁰

j, data)

(3)

SN_i checkID⁰_CN

j

=? ID_CNj (4)

SN_i E({nonce⁰, ID_SNi}, K_CNj,SNi) ={nonce⁰, ID_SNi}K_CNj,SNi (5) SN_i →CN_j : ID_SNi,{nonce⁰, ID_SNi}_KCNj,SNi (6)

SN_i delete K_CNj,SNi from RAM (7)

CN_j D({nonce⁰, ID_SNi}K_CNj,SNi, K_CNj,SNi) = (nonce⁰⁰, ID⁰_SNi) (8) CN_j ifnonce⁰⁰=^? nonce, state of SN_i is valid (9) 3. Protocol actions.

(a) In the first step,CN_j transfers an encrypted nonce together with itsIDand the sensed data using the shared key toSN_i.

(b) SN_i performs theTPM Unsealcommand and unseals the shared key.

6.5. ANALYSIS 101