Datagram Transport Layer Security in Constrained Environments - - PowerPoint PPT Presentation

▶
datagram transport layer security in constrained
SMART_READER_LITE
LIVE PREVIEW

Datagram Transport Layer Security in Constrained Environments - - PowerPoint PPT Presentation

Apr 08, 2024 265 likes •461 views

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

slide-1
SLIDE 1

Datagram Transport Layer Security in Constrained Environments

draft-hartke-core-codtls-01 Klaus Hartke • Olaf Bergmann

slide-2
SLIDE 2

1 I-D.hartke-core-codtls

Datagram Transport Layer Security in Constrained Environments

Class 0: too small to securely run

  • n the Internet

Class 1: ~10 KiB data, ~100 KiB code “quite constrained” Class 2: ~50 KiB data, ~250 KiB code “not so constrained” Classes of Devices

  • 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:

– trying to fjgure out challenges and problems – collect ideas for possible solutions and implementation guidance

slide-3
SLIDE 3

2 I-D.hartke-core-codtls

Request Response Client Server

1 roundtrip

CoAP without DTLS

slide-4
SLIDE 4

3 I-D.hartke-core-codtls Flight 3 Flight 2 Flight 1

Client Server Client Hello Hello Verify Request Client Hello Server Hello Certifjcate Server Key Exchange Certifjcate Request Server Hello Done Certifjcate Client Key Exchange Certifjcate Verify Change Cipher Spec Finished Change Cipher Spec Finished Request Response

Flight 4 Flight 5 Flight 6

4 roundtrips

CoAP with DTLS

slide-5
SLIDE 5

4 I-D.hartke-core-codtls Flight 3 Flight 2 Flight 1

Client Server Client Hello Hello Verify Request Client Hello Server Hello Certifjcate Server Key Exchange Certifjcate Request Server Hello Done Certifjcate Client Key Exchange Certifjcate Verify Change Cipher Spec Finished Change Cipher Spec Finished Request Response

Flight 4 Flight 5 Flight 6

4 roundtrips

CoAP with DTLS

ECDSA P-256: 91 bytes ECDSA P-384: 120 bytes ECDSA P-521: 156 bytes Raw Public Key: Certifjcate sizes DTLS handshake over 6LoWPAN: max ~ 30-60 bytes per fragment

slide-6
SLIDE 6

5 I-D.hartke-core-codtls Flight 3 Flight 2 Flight 1

Client Server Client Hello Hello Verify Request Client Hello Server Hello Certifjcate Server Key Exchange Certifjcate Request Server Hello Done Certifjcate Client Key Exchange Certifjcate Verify Change Cipher Spec Finished Change Cipher Spec Finished Request Response

Flight 4 Flight 5 Flight 6

4 roundtrips

CoAP with DTLS

ECDSA P-256: 91 bytes ECDSA P-384: 120 bytes ECDSA P-521: 156 bytes Raw Public Key: Certifjcate sizes DTLS handshake over 6LoWPAN: max ~ 30-60 bytes per fragment

slide-7
SLIDE 7

6 I-D.hartke-core-codtls Flight 3 Flight 2 Flight 1

Client Server Client Hello Hello Verify Request Client Hello Server Hello Certifjcate Server Key Exchange Certifjcate Request Server Hello Done Certifjcate Client Key Exchange Certifjcate Verify Change Cipher Spec Finished Change Cipher Spec Finished Request Response

Flight 4 Flight 5 Flight 6

4 roundtrips

CoAP with DTLS

ECDSA P-256: 91 bytes ECDSA P-384: 120 bytes ECDSA P-521: 156 bytes Raw Public Key: Certifjcate sizes DTLS handshake over 6LoWPAN: max ~ 30-60 bytes per fragment

slide-8
SLIDE 8

7 I-D.hartke-core-codtls Flight 3 Flight 2 Flight 1

Client Server Client Hello Hello Verify Request Client Hello Server Hello Certifjcate Server Key Exchange Certifjcate Request Server Hello Done Certifjcate Client Key Exchange Certifjcate Verify Change Cipher Spec Finished Change Cipher Spec Finished Request Response

Flight 4 Flight 5 Flight 6

CoAP with DTLS

ECDSA P-256: 91 bytes ECDSA P-384: 120 bytes ECDSA P-521: 156 bytes Raw Public Key: Certifjcate sizes DTLS handshake over 6LoWPAN: max ~ 30-60 bytes per fragment

reassemble reassemble

slide-9
SLIDE 9

8 I-D.hartke-core-codtls Flight 3 Flight 2 Flight 1

Client Server Client Hello Hello Verify Request Client Hello Server Hello Certifjcate Server Key Exchange Certifjcate Request Server Hello Done Certifjcate Client Key Exchange Certifjcate Verify Change Cipher Spec Finished

Flight 4 Flight 5

CoAP with DTLS

reassemble reassemble Message lost

CSS Finished Request Response

Flight 6

Client Server

Flight 4 Flight 5 Retransmit fmight

5 roundtrips

reassemble

slide-10
SLIDE 10

9 I-D.hartke-core-codtls

  • Handshake messages are big

We need many frames to transport keys In principle: DTLS fragmentation is better than adaptation layer fragmentation

  • DTLS has 25 bytes overhead per packet

that carries a fragment

  • Fills ~ 1/3 of usable frame
  • More fragments increase likelihood

that messages get reordered or lost

  • Every new packet uses energy

Handshake protocol – Potential problems

Record header Handshake message header

= 25 bytes

Version Epoch Sequence number Length Content type Message length Message type Message sequence number Fragment offset Fragment length

slide-11
SLIDE 11

10 I-D.hartke-core-codtls

  • (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?

Handshake protocol – Possible solutions

slide-12
SLIDE 12

11 I-D.hartke-core-codtls

  • DTLS has 21 bytes overhead per packet

DTLS version is always the same (2 bytes)

Epoch is mostly 0 or 1 (2 bytes) Sequence number is 6 bytes Length is redundant in last record in datagram CCM doubles sequence number and epoch

  • Fills ~ 1/3 of usable frame
  • Every new packet uses energy

Version Epoch Sequence number Length Content type Epoch Sequence number Record header CCM explicit nonce

= 21 bytes

Application data protocol – Potential problems

slide-13
SLIDE 13

12 I-D.hartke-core-codtls

  • (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?

Application data protocol – Possible solutions

slide-14
SLIDE 14

13 I-D.hartke-core-codtls

  • 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

State – Potential problems

slide-15
SLIDE 15

14 I-D.hartke-core-codtls

  • (not to be decided here)
  • Possibly compute the hash in the Finished message

from the negotiated session parameters?

State – Possible solutions

slide-16
SLIDE 16

15 I-D.hartke-core-codtls

  • Adjust

the timers...

Other guidance

ECC and RSA on Arduino

Library ROM AvrCryptolib 3.6 KB Wiselib 16.0 KB TinyECC 18.0 KB Relic 29.0 KB 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 ECC 192k1 TinyECC 1008 B 3.4 s NIST K163 Relic 2804 B 0.3 s NIST K233 Relic 3675 B 1.8 s

~ RSA 1024! ~ RSA 2048!

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

  • f 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 Time to sign (Arduino) [Mohit Sethi]

slide-17
SLIDE 17

16 I-D.hartke-core-codtls

Code Size Description 1429 Bytes SHA-256 992 Bytes CCM 9812 Bytes DTLS state machine

  • Data size...
  • Code size...

Other guidance

ECC and RSA on Arduino

Library ROM AvrCryptolib 3.6 KB Wiselib 16.0 KB TinyECC 18.0 KB Relic 29.0 KB 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 ECC 192k1 TinyECC 1008 B 3.4 s NIST K163 Relic 2804 B 0.3 s NIST K233 Relic 3675 B 1.8 s

~ RSA 1024! ~ RSA 2048!

Code footprint of minimal DTLS implementation [Olaf Bergmann] RAM usage (Arduino) [Mohit Sethi] Class 0: too small to securely run

  • n the Internet

Class 1: ~10 KiB data, ~100 KiB code “quite constrained” Class 2: ~50 KiB data, ~250 KiB code “not so constrained” Classes of Devices

slide-18
SLIDE 18

17 I-D.hartke-core-codtls

Possible actions

avoid

Implementation guidance Implementation techniques for light-weight implementations without affecting conformance 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

Breaking changes

prefer

→ I-D.bormann-lwig-guidance → TLS WG → CoRE WG (?)