A Hardware-based Remote Attestation Protocol in Wireless Sensor ...

0 downloads 0 Views 165KB Size Report
Apr 16, 2010 - with a Trusted Platform Module (TPM) board. The TPM is responsible for content verification of the program flash. To the best of our knowledge, ...
Poster Abstract: A Hardware-based Remote Attestation Protocol in Wireless Sensor Networks Hailun Tan

Wen Hu

Sanjay Jha

School of Computer Science and Engineering The University of New South Wales,Australia

ICT Centre,CSIRO Brisbane, Australia

School of Computer Science and Engineering The University of New South Wales,Australia

[email protected]

[email protected]

[email protected]

ABSTRACT Given the limited resources and computational power of current embedded sensor devices memory protection is difficult to achieve and generally unavailable. Hence, the buffer overflow that is used by the worm attacks in the Internet can be easily exploited to inject malicious code into Wireless Sensor Networks (WSNs). We designed a hardware-based remote attestation protocol to counter the buffer overflow attack. In our attestation protocol, each sensor node is equipped with a Trusted Platform Module (TPM) board. The TPM is responsible for content verification of the program flash. To the best of our knowledge, it is the first remote attestation protocol in WSNs with each sensor node equipped with TPM.

Categories and Subject Descriptors C.2.2 [Computer-Communication Networks]: Network Protocols; D.4.6 [Operating Systems]: Security and Protection

General Terms Security

Keywords remote attestation, Trusted Platform Module, Wireless Sensor Networks

1.

INTRODUCTION

Although security in Wireless Sensor Networks (WSNs) has remained an active research area, a potentially more severe attack called sensor worm attack has yet to be fully studied. At first, the attacker would need to capture one sensor node physically to check if there is any software vulnerability to exploit in application. The software vulnerability is a spot where the buffer overflow could occur. For example, due to lack of the memory protection in embedded devices, the attacker could send a malicious packet with the payload whose size is larger than the payload buffer array the application developer set aside in a processing routine upon packet reception. The extra data overwrites adjacent Copyright is held by the author/owner(s). IPSN’10, April 12–16, 2010, Stockholm, Sweden. ACM 978-1-60558-988-6/10/04.

378

memory, which could include the program variable or return address of functions in the application. Hence, a malicious program could inject itself into the program memory and self-propagate to other nodes by exploiting the buffer overflow. Since the data memory and program flash are separated from each other in the Harvard architecture,adopted in all AVR micro-controllers(e.g., Ateml128 in micaZ or Atmel1281 in Fleck[1]), it is widely believed that it is not practical, if not impossible, to launch the sensor worm attack. However, recent research has shown that the attacker could still exploit the self-programming routine in the bootloader so that the malicious code could be copied from the data memory to program flash [2].

2.

BACKGROUND

Trusted Platform Module (TPM) is a piece of tamperproof hardware following specification proposed by Trusted Computing Group (TCG)[3]. Each TPM device is initialized with an Endorsement Key (EK) - an RSA public/private key pair, which is burned into its non-volatile storage. Since the private part of the key pair never leaves TPM, the attacker can not get access to the EK despite node compromise. Hence, each message signed by EK must have been originated from an authentic TPM. In addition, TPM has several Platform Configuration Registers (PCRs), which monitor the system configuration and environments. Based on PCRs, TPM provides a special type of message encryption/decryption, which called seal/unseal. The sealed message could be associated with not only the encryption key, but also the specific PCR. Once the system has been compromised, the value of the corresponding PCR would be changed. Consequently, the sealed message could not be unsealed due to the change of PCR, even though the attacker might know the correct decryption key through node compromise.

3.

DESIGN AND IMPLEMENTATION

In the following description, we assume that node A issues an attestation challenge (i.e., node A is challenger) and node B is attested (i.e., node B is attestor). The attestation protocol consists of three stages: initialization, bootloader stage and application stage. Both node A and node B have the same procedure at initialization and bootloader stage. The initialization phase precedes deployment and hence it is safe to assume that nodes have not been compromised. The system administrator needs to load the bootloader into sensor node and pre-configures the TPM board (e.g., load

AB

K

Challenge: EKAB(NA) AB

K

KAB

A

Response:

PCRp

A EK

Figure 2: Fleck with TPM board. PCRp

A EK

Table 1: attestation latency in Figure 1

Figure 1: stage.

Attestation process at the application

Latency(s)

Power(µJ)

Challenge creation

5

71.9(C)

and response receipt

8

151.24(R)

Response verification

9

14.85(C)

Entire attestation process

22

252.84(C & R)

Challenge transmission

the RSA key pairs into TPM) and establish the shared secrets between A and B (KAB , sealed in TPM with EK and PCRk ) and the shared secret between the B and the base station (KBS ). At bootloader stage, the bootloader (denoted as Mb ) is running but the application (denoted as Mp ) is not yet loaded into the program flash. The node to be attested will be reboot with the application after the execution of bootloader. We could assume the nodes are vulnerable to physical capture but not susceptible to malware injection as bootloader can not be overwritten overthe-air. The attestation response is a digest of application code concatenated with KBS using an algorithm like SHA1. The resulting digest is stored into a PCR(PCRp ), whose value is denoted as VP CRp . Similarly, the digest of Mb is stored into another PCR(PCRk ). At the application stage, the application is running on node B once the nodes are rebooted after bootloader stage. We assume that the attacker can compromise a small number of sensor nodes, exploit a software vulnerability and launch the code injection attack over the air. The attestation process begins when node A issues a challenge, which is a random nonce (NA ) encrypted by KAB (EKAB (NA )). On receiving the challenge request, node B would attempt to unseal KAB and retrieve NA . If the unseal operation fails, it means that bootloader in node B has been compromised because the unseal operation is associated with PCRk at bootloader stage. Node B then returns VP CRp , concatenated with NA , signed by EK. Node A verifies the authentication of the attestation response by checking its corresponding signature. Moreover, node A is able to detect the replay attack of an authentic response by checking the nonce(NA ) included in the attestation response. The entire process is shown in Figure 1. Even though the attacker compromises node B, it can not generate the correct response since it can not get access to EK, which is securely stored in TPM. The attacker can not replay the authentic response since each response is associated with a different random nonce NA .

4.

Attestation phases

EVALUATION AND CONCLUSION

We implemented our attestation protocol on Fleck and TPM daughter board based on secFleck[4] (see Figure 2). We further evaluated the attestation latency, which is shown in Table 1. The entire attestation process takes less than

379

half a minute. More than 60% latency is incurred at the challenger(C in Table 1). This result is expected as the challenger can be the sink or the trusted third party, which has sufficient power and resources to perform the TPM commands in challenger side. As to the responder (R in Table 1), it takes 8 seconds to complete the response, including the network propagation delay, which shows that TPM-enabled attestation protocol is efficient in terms of latency. Since the responder generates the signature for the attestation response, the signature operation incurs the most signficant power consumption(143.44µJ out of 151.24µJ). On the challenger side, the most signficant power consumption incurs when KAB is unsealed, which is 70.33µJ out of 71.9µJ. These power consumption data are computed based on the measured currents, execution time of TPM commands and 3V power supply. In this poster abstract, we presented a hardware-based remote attestation protocol in WSNs with the assistance of Trusted platform Module (TPM). To our knowledge, our hardware-based attestation protocol is the first one in WSNs with each sensor node equipped with the tamper-proof hardware. Our future works includes the scalability test of out attestation protocol such as multi-hop attestation.

5.

REFERENCES

[1] CSIROs smart sensor network technology. http://www.csiro.au/resources/smart-sensor-networktechnology.html. [2] Aur´elien Francillon and Claude Castelluccia. Code injection attacks on harvard-architecture devices. In CCS ’08, pages 15–26, New York, NY, USA, 2008. ACM. [3] Tcg specification architecture overview. Technical report, Trust Computing Group, August 2007. [4] Wen Hu, Peter Corke, Wen Shih, and Leslie Overs. secfleck: A public key technology platform for wireless sensor networks. In EWSN ’09, pages 296–311. 2009.