Embedded Security: From Sensor Networks to Internet of Things (IoT)

Embedded Security: From Sensor Networks to Internet of Things (IoT) Dr. Wen Hu, Michael Bruenig, Thomas Kothmayr (TUM), Corinna Schmitt (U Zurich) Principal Research Scientist/Research Project Leader CSIRO Digital Productivity Flagship, Australia DIGITAL PRODUCTIVITY FLAGSHIP

Wireless Sensor Networks Homogenous devices Resource, energy and form factor limited

Cryptography challenges in sensor networks Very limited resources 8-bit/16-bit microcontrollers Less than 10KB RAM AA batteries Security algorithms are computational and memory intensives

SKC vs. PKC Symmetric Key Cryptography (SKC) Low computation cost Smaller key sizes Public Key Cryptography It provides more security than SKC but it requires a nontrivial amount of processing power and memory Past 2004 2007 Imposible to use PKC Doubt in using PKC Possible to use PKC Future

Cryptography engines Symmetric cryptography engine AES 128-bit, new transceivers such as Atmel AT86RF212 and AT86RF230 Asymmetric cryptography engine SHA-1, 1024/2048-bit RSA

secfleck CSIRO ICT Centre Marine Robotics & Sensor Networks

Evaluation (I)

Evaluation (II) CSIRO ICT Centre Marine Robotics & Sensor Networks

Examples --- secure communications Node A Base Generates a random number N a ( b y fos_tpm_rand) Decrypt with SkA, (fos_tpm_decryption) E(Pkbase, Na, Req) fos_tpm_encryption E(PkA, Na, KBA) (fos_tpm_encryption) Decrypt with Skbase, Generate a new session key (KBA), (fos_tpm_decryption fos_tpm_rand) Secure communication using SKC with K BA CSIRO ICT Centre Marine Robotics & Sensor Networks

Examples --- remote attestation Attestator A During boot time, update PCR I (Pi) (fos_tpm_pcrextend) Challenger C Generates a random number N a ( b y fos_tpm_rand) Obtain Pi and generate a signature (fos_tpm_pcrquote) Issue PCR challenge (index = i, Na) Ask for A s public key Base A s public key (Pka) Challenge response S(Pi, Na, Ska) Verify the value Pi and the signature (fos_tpm_verifypcrquote)

Summary Strong (2048-bit) asymmetric key cryptography for message authenticity and integrity, strong symmetric key cryptography for message confidentiality Affordable (financially, form factor, and energy consumption) Remote (platform and data) attestation for content trustworthiness 11

Internet of Things Heterogeneous devices (cortex M*) Standard approach (802.15.4, RPL/6LoWPAN, COAP )

Motivation Current situa2on: Many different use cases exist: Building system, medical apps, acquisi2on of resources. Main task of sensor networks is the collec2on and transmission of different data. Problem: Data can include sensi2ve informa2on. Trend: Integra2on of wireless sensor networks into the Internet (Internet of Things). Trustworthiness of par2cipants can differ. Requests for the security solu2on: Confiden2ality Data Integrity Data authen2city A DTLS Based End-To-End Security Architecture for the Internet of Things with Two-Way Authentication 13

Usage of standards Wireless Sensor Networks are comparable to Peer- to- Peer networks: Self- organizing network of sensor nodes Basic tasks of a node: Collect data, simple data processing, and forward data Constrained memory, barery and compua2onal power IPv6 Connec2vity à Nodes connected to Internet Different standardized security solu2ons exist: Technologies and implementa2ons (e.g. OpenSSL) exist and are well proven Exis2ng infrastructures (e.g. cer2ficate authori2es) can be used again. Different standards for network stack in WSNs already exist: Physical & MAC Layer: IEEE 802.15.4 Rou2ng & Transport Layer: 6LoWPAN, RPL Applica2on Layer: CoAP A DTLS Based End-To-End Security Architecture for the Internet of Things with Two-Way Authentication 14

Benefits of a standards based approach Reuse of: Implementa2ons (OpenSSL, etc..) Engineering techniques Infrastructure (Cer2ficate Authori2es, etc..) Exper2se and Experience à Easier security uptake Application Security Transport Network Medium Access / Physical CoAP, XML,... DTLS UDP IPv6 BLIP, RPL IEEE 802.15.4 Hardware used: TelosB / IRIS OPAL- Mote 50kbyte SRAM 48 MHz Microcontroller Trusted Plaaorm Module A DTLS Based End-To-End Security Architecture for the Internet of Things with Two-Way Authentication 15

Opal node (front) Microcontroller (32-bit) LED Radio

Opal node (back) Radio Micro SD card slot TPM CSIRO ICT Centre Marine Robotics & Sensor Networks

DTLS Ultra short introduction Flight 1 Flight 3 Flight 5 Client ClientHello* ClientHelloVerify* ClientHello ServerHello Certificate [CertificateRequest] ServerHelloDone [Certificate] ClientKeyExchange [CertificateVerify] ChangeCipherSpec Finished ChangeCipherSpec Finished Server Flight 2 Flight 4 Flight 6 DTLS: Adap2on of TLS for datagram transport Server and Client nego2ate Hash algorithm and Cipher in Handshake Different authen2ca2on methods RSA, DAS, DH, ECC, PSK, For us: RSA and later PSK [ ] Omission during server authenticated handshake. * Optional messages Encrypted up now A DTLS Based End-To-End Security Architecture for the Internet of Things with Two-Way Authentication 18

Connecting to data sink A DTLS Based End-To-End Security Architecture for the Internet of Things with Two-Way Authentication 19

P2P Connection A DTLS Based End-To-End Security Architecture for the Internet of Things with Two-Way Authentication 20

Evaluation - DTLS Handshake Least understood component in IoT context Previous work evaluated other components Sizzle: A standards- based end- to- end security architecture for the embedded internet à Server authen2cated handshake with RSA and ECC Securing Communica2on in 6LoWPAN with Compressed IPSec à Compression techniques for IPSec header during applica2on data transfer Challenge: IoT embedded nodes are limited to their resources! System s performance Packet handling DTLS handshake performance Energy consump2on Memory consump2on A DTLS Based End-To-End Security Architecture for the Internet of Things with Two-Way Authentication 21

Evaluation - System s performance (packet handling) Linear increase of round trip 2me Jumps approximately every 100 bytes à 128 bytes maximum MTU in layer 2 by IEEE 802.15.4 à Including header and tailer Jumps occur earlier when sending DTLS protected packets à Addi2onal DTLS header, HMAC size, Ini2aliza2on Vector Round- Trip- Time (ms) 600 500 400 300 200 100 0 8 32 64 96 128 160 192 224 255 Data packets per Template packet AES- 128 Multihop (4) AES- 128 Single Hop SHA- 1 Multihop (4) SHA- 1 Single Hop Ping Multihop (4) Ping Single Hop à Increasing packet size and processing overhead lead to an increased end-to-end transmission latency for DTLS packets compared to plaintext packets. à The decreased performance for transmission latency is mostly due to the large packet overhead of up to 64 bytes. à Calculation times DOES NOT contribute significantly: - SHA-1 hash of 255 bytes plain text message: 9 ms - Encryption with AES-128: 12 ms A DTLS Based End-To-End Security Architecture for the Internet of Things with Two-Way Authentication 22

Evaluation - System s performance (DTLS handshake) Measurement duration: Beginning of the handshake establishment Client received a FINISHED message 15 measurements for each type of handshake Timeout: 5 sec Average latency for a fully authenticated and a server authenticated DTLS handshake à Large standard deviation is caused by implementation behavior when messages lost. - DTLS states that an implementation should wait for an answer for a set amount of time after sending a flight. - Retransmission if no answer is received during this period. à Time to execute a handshale is shorter for smaller RSA-keys and reduced by almost 2 sec when client authentication is omitted in the handshake. à Packet loss mainly in multi-hop environment and larger DTLS messages are sent. à Total energy consumption of client does not increase significantly - All TPM operations are only executed after successful receipt of all relevant server messages. A DTLS Based End-To-End Security Architecture for the Internet of Things with Two-Way Authentication 23

Evaluation - Energy consumption Energy draw for a fully authenticated DTLS handshake on OPAL node Energy cost = A DTLS Based End-To-End Security Architecture for the Internet of Things with Two-Way Authentication 24

Evaluation - Memory consumption Fully authenticates handshake with 2048-bit RSA keys OPAL resources: 48 kb RAM / 256 kb ROM RAM consumption (byte) à Total: 17,839 byte RAM ROM consumption (byte) à Total: 63,383 byte ROM A DTLS Based End-To-End Security Architecture for the Internet of Things with Two-Way Authentication 25

Established WSN at Department 2222 2232 T 2270 T 1104 S 2222 1108 2250 T S S 2243 1103 1101 12 S S S X S S S S 1107 2270 12 2243 1110 2232 1101 2250 1104 1102 1105 1106 1103 1108 Gateway Nodes with data collection purpose: S T IRIS with mts300 or mts400 TelosB with activated sensors 1105 1102 1106 Gateway (TelosB) TelosB with aggregation purpose X Opal 1107 1110 DTLS handshake messages Data transmission via secure connection Wireshark recording on tun0 (only UDP packets) Recording of received TinyIPFIX messages in Listerner provided by TinyOS A DTLS Based End-To-End Security Architecture for the Internet of Things with Two-Way Authentication 26

Summary Today s challenge: Connec2on of different infrastructures on base of IP- communica2on Internet of Things Adop2on of powerful and well known protocols is suitable! A standard based security architecture with two- way authen2ca2on for the Internet of Things was developed. The authen2ca2on is performed during a fully authen2cated DTLS handshake. Exchange of X.509 cer2ficates containing RSA keys Secure provisioning: Message integrity Confiden2ality Authen2city Solu2on has affordable energy, end- to- end latency, and memory overhead Interoperability can be ensured with different vendors Applica2on scenarios exchangeable A DTLS Based End-To-End Security Architecture for the Internet of Things with Two-Way Authentication 27

On- going work Opal on a chip (TI CC2538) Cortex M3 (32KB RAM and 512KB ROM) IEEE 802.15.4 radio RSA, ECC in hardware ~$6 OpenMote Has the dominated factor moved back to wireless transmissions? More advanced crypto approaches? Bluetooth LE security?

References 1. "secfleck: A Public Key Technology Plaaorm for Wireless Sensor Networks", Wen Hu, Peter Corke, Wen Chan Shih, Leslie Overs. In Proceedings of 6th European Conference on Wireless Sensor Networks (EWSN 09), February 11th- 13th, Cork, Ireland. 2. "Towards Trusted Wireless Sensor Networks". Wen Hu, Hailun Tan, Peter Corke, Wen Chan Shih, Sanjay Jha. ACM Transac2ons on Sensor Networks (TOSN), Volume 7, Issue 1, August 2010. 3. "DTLS based Security and Two- Way Authen2ca2on for the Internet of Things", Thomas Kothmayr, Corinna SchmiR, Wen Hu, Michael Bruenig and Georg Carle. Ad Hoc Networks (Elsevier), Vol. 11 Issue 8, Page 2710-2723 Nov 2013. 4. TLS- based Security with two- way Authen2ca2on for IoT, C. SchmiR, B. S2ller, T. Kothmayr and Wen Hu, IETF Internet Drav, July 2013. 5. "Towards Trustworthy Par2cipatory Sensing, Akshay Dua, Nirupama Bulusu, Wuchang Feng, Wen Hu. In Proceedings of 4th USENIX Workshop on Hot Topics in Security (HotSec '09), August, 2009, Montreal, Canada. 29