Advancing IoT Communication Security with TLS and DTLS v1.3

Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Advancing IoT
Communication Security
with TLS and DTLS v1.3
Hannes Tschofenig
Senior Principal Engineer
Arm

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

#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

#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’)

#ArmTechCon
It is a re-design
Roundtrips
Features
Message sizes
Code Size
Cryptographic operations

#ArmTechCon
Roundtrips
Features
Message sizes
Code Size

#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.

#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
roundtrip.
Harmonized three PSK modes
available in TLS 1.2 into one

#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
roundtrip.
Danger of replay.
Application layer
needs to check for
replay.
Requires API changes

#ArmTechCon
Roundtrips
Features
Message sizes
Code Size

#ArmTechCon
Privacy Protection
TLS 1.3
TLS 1.2
+PFS, -key transport, +padding, +various unlinkability properties.

#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/

#ArmTechCon
Regular DTLS Communication
DTLS
Handshake
NATClient Server
DTLS
Handshake
Key &
algorithm
parameters
Security Parameter DatabaseNAT Bindings

#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

#ArmTechCon
IoT Device wakes up
NATClient Server
Key &
algorithm
parameters
Security Parameter Database
DTLS packets get
dropped by the
server.
NAT Bindings

#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.

#ArmTechCon
Roundtrips
Features
Message sizes
Code Size

#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

#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

#ArmTechCon
Roundtrips
Features
Message sizes
Code Size

#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)
… … … … …

#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

#ArmTechCon
Flash Size (TLS 1.3, PSK, AES-128-CCM)

#ArmTechCon
Flash Size (TLS 1.3, ECDSA-ECDHE (P2561), AES-128-CCM)

#ArmTechCon
Roundtrips
Features
Message sizes
Code Size

#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

#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]

#ArmTechCon
Summary and next steps

#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

#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

#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

#ArmTechCon
Backup Slides

#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)

#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

#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]

#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;

#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;

#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.

#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.

Advancing IoT Communication Security with TLS and DTLS v1.3

More Related Content

What's hot (20)

Similar to Advancing IoT Communication Security with TLS and DTLS v1.3 (20)

More from Hannes Tschofenig (9)

Recently uploaded (20)

Advancing IoT Communication Security with TLS and DTLS v1.3