Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Advancing IoT
Communication Security
with TLS and DTLS v1.3...
2Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Today’s IoT security experience
Vulnerable IoT products
To...
3Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Communication security is a must-have feature
Unsurprising...
4Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Which TLS & DTLS version?
With RFC 7925 and RFC 7525 we ha...
5Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
It is a re-design
Roundtrips
Features
Message sizes
Code S...
6Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Roundtrips
Features
Message sizes
Code Size
Cryptographic ...
7Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
TLS 1.3 Public Key based Authentication
ServerClient
Clien...
8Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
TLS 1.3 Pre-Shared Key (PSK) Authentication
ServerClient
C...
9Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
TLS 1.3 0-RTT Data
ServerClient
ClientHello (+early_data, ...
10Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Roundtrips
Features
Message sizes
Code Size
Cryptographic...
11Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Privacy Protection
TLS 1.3
TLS 1.2
+PFS, -key transport, ...
12Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Eavesdropping and intercepting TLS handshakes
became much...
13Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Regular DTLS Communication
DTLS
Handshake
NATClient Serve...
14Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
IoT Device Sleeps
Note: According to [HomeGateway], the m...
15Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
IoT Device wakes up
NATClient Server
Key &
algorithm
para...
16Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
CID Solution
Demultiplexing based on a new field, the Con...
17Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Roundtrips
Features
Message sizes
Code Size
Cryptographic...
18Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Over-the-Wire Overhead
620
2395
854
3260
532
1836
840
240...
19Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
DTLS Record Layer Header
DTLS 1.2 Plaintext Header DTLS 1...
20Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Roundtrips
Features
Message sizes
Code Size
Cryptographic...
21Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Implementations - a long list …
Live servers available fo...
22Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Flash size
PSK (AES-128-CCM)
PSK (AES-128-CCM + AES-256-
...
23Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Flash Size (TLS 1.3, PSK, AES-128-CCM)
24Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Flash Size (TLS 1.3, ECDSA-ECDHE (P2561), AES-128-CCM)
25Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Cryptographic operations
Roundtrips
Features
Message size...
26Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Key Hierarchy
Differences between 1.2 and 1.3:
 Most han...
27Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Compatibility Mode
Making TLS 1.3 work in today’s Interne...
28Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Summary and next steps
29Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
• TLS & DTLS 1.2 following profiles are secure, and widel...
30Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Next steps
For the IETF TLS Working Group
Completing the ...
31Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Trademark and copyright statement
The trademarks featured...
32Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Backup Slides
33Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Detailed List of Changes to TLS / DTLS 1.3
Summary
Simpli...
34Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
TLS 1.2 Pre-Shared Key based Authentication
and Session R...
35Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
TLS 1.2 Session Resumption without Server-Side State
Shar...
36Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
TLS 1.3 Ticket Exchange
ServerClient
[NewSessionTicket]
T...
37Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
TLS 1.3 Record Layer
All ciphers are modelled as “Authent...
38Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
 Each encrypted record consists of
 a plaintext header
...
39Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
CID Solution
Differences
DTLS 1.2
• CID value unchanged o...
Prochain SlideShare
Chargement dans…5
×

Advancing IoT Communication Security with TLS and DTLS v1.3

349 vues

Publié le

Missing communication security is a common vulnerability in Internet of Things deployments. Addressing this vulnerability is, in theory, relatively easy: with TLS and DTLS, two widely used security protocols are available. They are used to secure web and smart phone apps.

In this talk Hannes Tschofenig explains how the TLS/DTLS 1.3 protocols work and how they differ from previous versions. Hannes also speaks about the performance improvements and how they help in IoT deployments.

Publié dans : Internet
  • Soyez le premier à commenter

Advancing IoT Communication Security with TLS and DTLS v1.3

  1. 1. Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Advancing IoT Communication Security with TLS and DTLS v1.3 Hannes Tschofenig Senior Principal Engineer Arm
  2. 2. 2Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Today’s IoT security experience Vulnerable IoT products Top 5 IoT device security vulnerabilities: 1. No or Limited software update mechanism 2. Missing key management 3. Inappropriate access control 4. Missing communication security 5. Vulnerability to physical attacks Lots of security recommendations
  3. 3. 3Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Communication security is a must-have feature Unsurprisingly, our PSA Threat Models and Security Analysis (TMSA) reference examples also demand communication security. Designing your own communication security crypto is almost always a bad idea. Luckily, with TLS & DTLS standardized communication security protocols are available. Arm Platform Security Architecture (PSA) Asset Tracker TMSA Smart Water Meter TMSA Network Camera TMSA
  4. 4. 4Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Which TLS & DTLS version? With RFC 7925 and RFC 7525 we have TLS & DTLS profiles that exclude problematic algorithms. There are also lots of extensions that provide security and performance enhancements. TLS/DTLS 1.2 with these profiles is a perfectly fine way to secure IoT communication efficiently. TLS/DTLS 1.3 provides 1. A performance improvement, and 2. better privacy protection (influenced by BCP 188 ‘Pervasive Monitoring Is an Attack’)
  5. 5. 5Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon It is a re-design Roundtrips Features Message sizes Code Size Cryptographic operations
  6. 6. 6Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Roundtrips Features Message sizes Code Size Cryptographic operations
  7. 7. 7Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon TLS 1.3 Public Key based Authentication ServerClient ClientHello (+key_share, +signature_algorithms, +supported_groups, +supported_versions) ServerHello(+key_share), {EncryptedExtensions(+supported_groups*)}, {CertificateRequest*}, {Certificate*}, {CertificateVerify*}, {Finished}, [Application Data*] {Certificate*}, {CertificateVerify*}, {Finished}, [Application Data] [Application Data] Legend: *: optional message, []: Not a handshake message, {}: Encrypted message Application data is already sent by the client after the first roundtrip. Public key-based exchange always uses perfect forward secrecy using an ephemeral Diffie- Hellman exchange.
  8. 8. 8Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon TLS 1.3 Pre-Shared Key (PSK) Authentication ServerClient ClientHello (+key_share*, +psk_key_exchange_modes, pre_shared_key) ServerHello(+key_share*, +pre_shared_key), {EncryptedExtensions}, {Finished}, [Application Data*] {Finished}, [Application Data] [Application Data] Legend: *: optional message {} Indicates messages protected using keys derived from handshake_traffic_secret. []: Indicates messages protected using keys derived from traffic_secret_N Key_share extension only needed when perfect forward secrecy is required. Contains psk identity and “binder” (= one or multiple MAC values) Application data is already sent by the client after the first roundtrip. Harmonized three PSK modes available in TLS 1.2 into one
  9. 9. 9Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon TLS 1.3 0-RTT Data ServerClient ClientHello (+early_data, +key_share*, +psk_key_exchange_modes, pre_shared_key), (Application Data*) ServerHello(+pre_shared_key, +key_share*), {EncryptedExtensions, early_data*}, {Finished}, [Application Data*] (EndOfEarlyData), {Finished}, [Application Data] Legend: *: optional message () Indicates messages protected using keys derived from client_early_traffic_secret. {} Indicates messages protected using keys derived from [sender]_handshake_traffic_secret. []: Indicates messages protected using keys derived from [sender]_application_traffic_secret_N Application data is already sent by the client after the first roundtrip. Danger of replay. Application layer needs to check for replay. Requires API changes
  10. 10. 10Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Roundtrips Features Message sizes Code Size Cryptographic operations
  11. 11. 11Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Privacy Protection TLS 1.3 TLS 1.2 +PFS, -key transport, +padding, +various unlinkability properties.
  12. 12. 12Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Eavesdropping and intercepting TLS handshakes became much more difficult. Claimed to cause problems for enterprise network management. Resulted in delayed publication of the TLS spec and polarized IETF engineering community. Additional extensions are being developed that even encrypt the Server Name Indication (SNI). Firewall vendors are not happy Article reference: https://www.theregister.co.uk/2018/03/23/tls_1_3_approved_ietf/
  13. 13. 13Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Regular DTLS Communication DTLS Handshake NATClient Server DTLS Handshake Key & algorithm parameters Security Parameter DatabaseNAT Bindings
  14. 14. 14Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon IoT Device Sleeps Note: According to [HomeGateway], the mean for TCP and UDP NAT binding timeouts is 386 minutes (TCP) and 160 seconds (UDP). Shorter timeout values require keepalive messages to be sent more frequently. [HomeGateway] Haetoenen, S., et al., "An experimental study of home gateway characteristics", Proceedings of the 10th ACM SIGCOMM conference on Internet measurement, November 2010. NATClient Server The NAT binding expired after some time. NAT Bindings Key & algorithm parameters Security Parameter Database
  15. 15. 15Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon IoT Device wakes up NATClient Server Key & algorithm parameters Security Parameter Database DTLS packets get dropped by the server. NAT Bindings
  16. 16. 16Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon CID Solution Demultiplexing based on a new field, the Connection ID (CID). This CID value is carried in the DTLS Record Layer. Extension to handshake to negotiate feature, i.e., optional to use. CID value is directional. Specification available for DTLS 1.2 and DTLS 1.3. Still work in progress in the IETF TLS working group! Prototype (for DTLS 1.2) available that uses Mbed TLS. The DTLS 1.2 and the 1.3 solution different in their privacy protection capabilities.
  17. 17. 17Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Roundtrips Features Message sizes Code Size Cryptographic operations
  18. 18. 18Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Over-the-Wire Overhead 620 2395 854 3260 532 1836 840 2403 0 500 1000 1500 2000 2500 3000 3500 PSK (AES-128-CCM) ECDSA-ECDHE (AES-128-CCM + P256r1) PSK (AES-256-CCM) ECDSA-ECDHE (AES-256-CCM + P512r1) TLS 1.2 TLS 1.3
  19. 19. 19Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon DTLS Record Layer Header DTLS 1.2 Plaintext Header DTLS 1.3 Optimized Header (Complete) DTLS 1.3 Optimized Header (Minimal) Removed unused fields. Shorten existing fields Variable length header encoding with optional fields
  20. 20. 20Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Roundtrips Features Message sizes Code Size Cryptographic operations
  21. 21. 21Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Implementations - a long list … Live servers available for testing. Many implementations not yet at RFC version and do not implement all features. name language role(s) version features/limitations fizz C++ C/S -28 Based on libsodium, includes secure design abstractions. Zero-copy for advanced performance. NSS C C/S RFC 8446 Almost everything, except post-handshake auth and X448 Mint Go C/S -18 PSK resumption, 0-RTT, HRR nqsb OCaml C/S -11 PSK/DHE-PSK, no EC*, no client auth, no 0RTT ProtoTLS JavaScript C/S -13 EC/DHE/PSK, no HelloRetryRequest miTLS F* C/S RFC 8446 EC/DHE/PSK/0-RTT, no RSA-PSS, no post-HS-auth, no ESNI Mbed TLS C C/S RFC 8446 Prototype implementation only. ECDSA+ECDHE, external PSK, PSK resumption, PSK-ECDHE, 0-RTT, Client auth, HelloRetryRequest (+ a DTLS 1.3 implementation of an earlier draft version) … … … … …
  22. 22. 22Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Flash size PSK (AES-128-CCM) PSK (AES-128-CCM + AES-256- CCM) ECDSA-ECDHE (AES-128-CCM + P256r1) ECDSA-ECDHE (AES-256-CCM + P512r1) All of the above+0RTT+Compatibility+Tic ket TLS 1.2 19 24 57 64 TLS 1.3 22 27 51 68 72 0 10 20 30 40 50 60 70 80 KiB TLS 1.2 TLS 1.3
  23. 23. 23Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Flash Size (TLS 1.3, PSK, AES-128-CCM)
  24. 24. 24Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Flash Size (TLS 1.3, ECDSA-ECDHE (P2561), AES-128-CCM)
  25. 25. 25Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Cryptographic operations Roundtrips Features Message sizes Code Size
  26. 26. 26Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Key Hierarchy Differences between 1.2 and 1.3:  Most handshake messages are encrypted  The HMAC-based Extract-and-Expand Key Derivation Function (HKDF, RFC 5869) with TLS-specific input parameters is used. Results:  Easier to analyse for cryptographers  More secure  More complex to implement, and larger number of hash calculations Key derivation for exchange stages Key derivation for Negotiated cipher HKDF HKDF
  27. 27. 27Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Compatibility Mode Making TLS 1.3 work in today’s Internet A number of middleboxes misbehave when a TLS client/server pair negotiates TLS 1.3. Three changes got introduced: 1. Pretend to do a session resumption. 2. Use bigger ServerHello instead of optimized HelloRetryRequest message 3. Transmit fake ChangeCipherSpec messages Luckily not a problem for DTLS 1.3 ServerClient ClientHello ServerHello, ChangeCipherSpec, {EncryptedExtensions}, {CertificateRequest*}, {Certificate*}, {CertificateVerify*}, {Finished}, [Application Data*] ChangeCipherSpec, {Certificate*}, {CertificateVerify*}, {Finished}, [Application Data] [Application Data]
  28. 28. 28Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Summary and next steps
  29. 29. 29Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon • TLS & DTLS 1.2 following profiles are secure, and widely deployed today. Use it. • TLS 1.3 is a redesign offering improved speed, and privacy. • DTLS 1.3 follows the design of TLS 1.3 with optimizations for IoT. The latest version can be found in draft-ietf-tls-dtls13. • TLS standardization has seen a new level of engineering professionalism with the number of working group participants and the extensive use of formal methods. Summary
  30. 30. 30Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Next steps For the IETF TLS Working Group Completing the DTLS 1.3 and the Connection ID specifications in the next few months. The IETF is an open organization and welcomes your input. For Arm We are constantly adding features to make security on IoT faster and more efficient. Example: fragmentation and segmentation of handshake msgs in Mbed TLS 2.13.0 TLS and DTLS are used in
  31. 31. 31Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Trademark and copyright statement The trademarks featured in this presentation are registered and/or unregistered trademarks of Arm (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. All other marks featured may be trademarks of their respective owners. Copyright © 2018 Thank You! 31
  32. 32. 32Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Backup Slides
  33. 33. 33Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Detailed List of Changes to TLS / DTLS 1.3 Summary Simplified Design • Cleaned-up list of supported algorithms (List will, however, grow very soon…) • Removed RSA key transport • Removed custom Diffie-Hellman groups • Removed compression and renegotiation • Removed password-based key exchanges • Streamlined session resumption (with and without servers-side state) and PSK extension Improvements • New ciphersuite concept that separates key exchange mechanism from cipher negotiation • Added solid version negotiation • Support for a more aggressive use of Diffie-Hellman for perfect forward secrecy • Key hierarchy easier to analyse (but more complex for implementers) • Encrypting messages earlier in the handshake (for privacy reasons) • Relies on standardized key derivation function based on HKDF (HMAC-based Extract-and-Expand Key Derivation Function)
  34. 34. 34Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon TLS 1.2 Pre-Shared Key based Authentication and Session Resumption TLS 1.2 PSK-Auth TLS 1.2 Session Resumption ServerClient ClientHello ServerHello ServerKeyExchange* ServerHelloDone ClientKeyExchange, [ChangeCipherSpec] Finished [ChangeCipherSpec] Finished [Application Data] ServerClient ClientHello (+SessionID) ServerHello [ChangeCipherSpec] Finished [ChangeCipherSpec] Finished [Application Data] Legend: *: optional message, []: Not a handshake message, {}: Encrypted message
  35. 35. 35Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon TLS 1.2 Session Resumption without Server-Side State Shares benefits with plain session resumption mechanism. + Increased scalability due to distributed session state storage Very popular on the web. ServerClient ClientHello (+SessionTicket extension) ServerHello (empty SessionTicket extension) NewSessionTicket [ChangeCipherSpec] Finished [ChangeCipherSpec] Finished [Application Data]
  36. 36. 36Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon TLS 1.3 Ticket Exchange ServerClient [NewSessionTicket] TLS 1.3 Handshake NewSessionTicket message is a post handshake message. Ticket is contained either “per-value” or “per-reference”. Ticket becomes psk_identity in a subsequent handshake. struct { uint32 ticket_lifetime; uint32 ticket_age_add; opaque ticket<1..2^16-1>; Extension extensions<0..2^16-2>; } NewSessionTicket;
  37. 37. 37Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon TLS 1.3 Record Layer All ciphers are modelled as “Authenticated Encryption with Additional Data” (AEAD). AEAD algorithms take as input • a single key (client_write_key or server_write_key), • a nonce (see next slide), • a plaintext, • and “additional data” (which is empty). struct { opaque content[TLSPlaintext.length]; ContentType type; uint8 zeros[length_of_padding]; } TLSInnerPlaintext;
  38. 38. 38Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon  Each encrypted record consists of  a plaintext header  an encrypted body. struct { ContentType opaque_type = 23; /* application_data */ ProtocolVersion legacy_record_version = 0x0301; /* TLS v1.x */ uint16 length; opaque encrypted_record[length]; } TLSCiphertext; TLS 1.3 Record Layer, cont.
  39. 39. 39Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon CID Solution Differences DTLS 1.2 • CID value unchanged over the lifetime because CID values are only exchanged at the beginning of the handshake. • Tracking possibilities exist but are not different than re-running the DTLS handshake itself. DTLS 1.3 • Post-handshake message to update Connection ID using RequestConnectionID/ NewConnectionID messages. • Offers better privacy protection against tracking by on-path observer. • Unlinkability requires sequence number to be encrypted as well.

×