Datagram Transport Layer Security in Constrained Environments draft-hartke-core-codtls-01 Klaus Hartke • Olaf Bergmann
Datagram Transport Layer Security in Constrained Environments • Smart Objects: want the security that DTLS provides • DTLS has not been designed with constrained devices and low-power, lossy networks in mind • This is actually not a problem for many constrained devices, but there are some challenges when it comes to implement DTLS for at least Class 1 devices • draft-hartke-core-codtls: Class 0: too small to securely run – trying to fjgure out challenges and on the Internet problems Class 1: ~10 KiB data, ~100 KiB code “quite constrained” – collect ideas for possible solutions Class 2: ~50 KiB data, ~250 KiB code and implementation guidance “not so constrained” Classes of Devices I-D.hartke-core-codtls 1
CoAP without DTLS Client Server Request Response 1 roundtrip I-D.hartke-core-codtls 2
Client Server CoAP with DTLS Flight Client Hello 1 Flight Hello Verify Request 2 Flight Client Hello 3 Server Hello Certifjcate Flight Server Key Exchange 4 Certifjcate Request Server Hello Done Certifjcate Client Key Exchange Flight Certifjcate Verify 5 Change Cipher Spec Finished Change Cipher Spec Flight 6 Finished Request Response 4 roundtrips I-D.hartke-core-codtls 3
Client Server CoAP with DTLS Flight Client Hello 1 Flight Hello Verify Request 2 DTLS handshake over 6LoWPAN: Flight Client Hello 3 max ~ 30-60 bytes per fragment Server Hello Certifjcate Flight Server Key Exchange 4 Certifjcate Request ECDSA P-256: 91 bytes Server Hello Done ECDSA P-384: 120 bytes ECDSA P-521: 156 bytes Certifjcate Client Key Exchange Flight Certifjcate Verify 5 Raw Public Key: Certifjcate sizes Change Cipher Spec Finished Change Cipher Spec Flight 6 Finished Request Response 4 roundtrips I-D.hartke-core-codtls 4
Client Server CoAP with DTLS Flight Client Hello 1 Flight Hello Verify Request 2 DTLS handshake over 6LoWPAN: Flight Client Hello 3 max ~ 30-60 bytes per fragment Server Hello Certifjcate Flight Server Key Exchange 4 Certifjcate Request ECDSA P-256: 91 bytes Server Hello Done ECDSA P-384: 120 bytes ECDSA P-521: 156 bytes Certifjcate Client Key Exchange Flight Certifjcate Verify 5 Raw Public Key: Certifjcate sizes Change Cipher Spec Finished Change Cipher Spec Flight 6 Finished Request Response 4 roundtrips I-D.hartke-core-codtls 5
Client Server CoAP with DTLS Flight Client Hello 1 Flight Hello Verify Request 2 DTLS handshake over 6LoWPAN: Flight Client Hello 3 max ~ 30-60 bytes per fragment Server Hello Certifjcate Flight Server Key Exchange 4 Certifjcate Request ECDSA P-256: 91 bytes Server Hello Done ECDSA P-384: 120 bytes ECDSA P-521: 156 bytes Certifjcate Client Key Exchange Flight Certifjcate Verify 5 Raw Public Key: Certifjcate sizes Change Cipher Spec Finished Change Cipher Spec Flight 6 Finished Request Response 4 roundtrips I-D.hartke-core-codtls 6
Client Server CoAP with DTLS Flight Client Hello 1 Flight Hello Verify Request 2 DTLS handshake over 6LoWPAN: Flight Client Hello 3 max ~ 30-60 bytes per fragment Server Hello Certifjcate Flight Server Key Exchange 4 Certifjcate Request ECDSA P-256: 91 bytes Server Hello Done ECDSA P-384: 120 bytes reassemble ECDSA P-521: 156 bytes Certifjcate Client Key Exchange Flight Certifjcate Verify 5 Raw Public Key: Certifjcate sizes Change Cipher Spec Finished reassemble Change Cipher Spec Flight 6 Finished Request Response I-D.hartke-core-codtls 7
Client Server CoAP with DTLS Flight Client Hello 1 Server Client Flight Hello Verify Request 2 Flight Client Hello 3 Server Hello Flight Retransmit Certifjcate 4 fmight Flight Server Key Exchange 4 Certifjcate Request Server Hello Done reassemble Message Certifjcate Flight lost Client Key Exchange 5 Flight Certifjcate Verify 5 Change Cipher Spec reassemble Finished reassemble CSS Flight 6 Finished Request Response 5 roundtrips I-D.hartke-core-codtls 8
Handshake protocol – Content type Record header Potential problems Version Epoch • Handshake messages are big We need many frames to transport keys Sequence number In principle: DTLS fragmentation is better than adaptation layer fragmentation Length • DTLS has 25 bytes overhead per packet Message type that carries a fragment Message length Handshake message header • Fills ~ 1/3 of usable frame Message sequence number • More fragments increase likelihood Fragment offset that messages get reordered or lost Fragment length • Every new packet uses energy = 25 bytes I-D.hartke-core-codtls 9
Handshake protocol – Possible solutions • (not to be decided here) • Compress headers so more data can be transmitted per fragment – Can 6LoWPAN GHC handle this? Literal copies are replaced by references Zero sequences can be compressed – Or should this better be done end-to-end? • Is reordering is unlikely enough that a recipient can simply ignore reordered messages and wait for retransmission? I-D.hartke-core-codtls 10
Application data protocol – Content type Potential problems Record header Version Epoch • DTLS has 21 bytes overhead per packet Sequence number DTLS version is always the same (2 bytes) Epoch is mostly 0 or 1 (2 bytes) Length Sequence number is 6 bytes Length is redundant in last record in datagram Epoch CCM doubles sequence number and epoch CCM explicit nonce • Fills ~ 1/3 of usable frame Sequence number • Every new packet uses energy = 21 bytes I-D.hartke-core-codtls 11
Application data protocol – Possible solutions • (not to be decided here) • Compress headers so more data can be transmitted per fragment – Can 6LoWPAN GHC handle this? Literal copies are replaced by references Zero sequences can be compressed – Or should this better be done end-to-end? I-D.hartke-core-codtls 12
State – Potential problems • Reassembling fragmented handshake messages • Queuing reordered handshake messages • Create connection state – can often be done per-fragment • Create verifjcation hash for Finished message – computed from sequence of messages – reordering requires queuing I-D.hartke-core-codtls 13
State – Possible solutions • (not to be decided here) • Possibly compute the hash in the Finished message from the negotiated session parameters? I-D.hartke-core-codtls 14
ECC and RSA on Arduino Library ROM AvrCryptolib 3.6 KB Wiselib 16.0 KB TinyECC 18.0 KB Relic 29.0 KB Other guidance Algorithm Library RAM Time RSA-512 AvrCryptolib 320 B 25.0 s RSA-1024 AvrCryptolib 640 B 199.0 s ECC 128r1 TinyECC 776 B 1.8 s • Adjust the timers... ECC 192k1 TinyECC 1008 B 3.4 s NIST K163 Relic 2804 B 0.3 s ~ RSA 1024! ~ RSA 2048! NIST K233 Relic 3675 B 1.8 s Time to sign (Arduino) [Mohit Sethi] Implementations SHOULD use an initial timer value of 1 second (the minimum defjned in RFC 6298 [RFC6298]) and double the value at each retransmission, up to no less than the RFC 6298 maximum of 60 seconds. Note that we recommend a 1-second timer rather than the 3-second RFC 6298 default in order to improve latency for time-sensitive applications. Because DTLS only uses re- transmission for handshake and not datafmow, the effect on con- gestion should be minimal. DTLS Timer Values I-D.hartke-core-codtls 15
ECC and RSA on Arduino Library ROM AvrCryptolib 3.6 KB Wiselib 16.0 KB TinyECC 18.0 KB Relic 29.0 KB Other guidance Algorithm Library RAM Time RSA-512 AvrCryptolib 320 B 25.0 s RSA-1024 AvrCryptolib 640 B 199.0 s ECC 128r1 TinyECC 776 B 1.8 s • Data size... ECC 192k1 TinyECC 1008 B 3.4 s • Code size... NIST K163 Relic 2804 B 0.3 s ~ RSA 1024! ~ RSA 2048! NIST K233 Relic 3675 B 1.8 s RAM usage (Arduino) [Mohit Sethi] Class 0: too small to securely run on the Internet Class 1: ~10 KiB data, ~100 KiB code “quite constrained” Code Size Description Class 2: ~50 KiB data, ~250 KiB code 1429 Bytes SHA-256 “not so constrained” 992 Bytes CCM Classes of Devices 9812 Bytes DTLS state machine Code footprint of minimal DTLS implementation [Olaf Bergmann] I-D.hartke-core-codtls 16
Possible actions Implementation guidance prefer Implementation techniques for light-weight implementations without affecting conformance → I-D.bormann-lwig-guidance Stateless header compression Compress record and handshake headers without explicitly building any compression context state Protocol profjle for constrained environments Use of DTLS in a particular way, e.g. • require or preclude certain extensions or cipher suites • change MAYs into MUSTs or MUST NOTs → CoRE WG (?) avoid Breaking changes → TLS WG I-D.hartke-core-codtls 17
Recommend
More recommend
