DTLS- based Mul/cast Security for Low- Power and Lossy Networks (LLNs) dra$- keoh- dice- mul/cast- security

Size: px

Start display at page:

Download "DTLS- based Mul/cast Security for Low- Power and Lossy Networks (LLNs) dra$- keoh- dice- mul/cast- security"

Mavis Carter
6 years ago
Views:

1 DTLS- based Mul/cast Security for Low- Power and Lossy Networks (LLNs) dra$- keoh- dice- mul/cast- security Sandeep S. Kumar, Sye Loong Keoh, Oscar Garcia- Morchon, Esko Dijk IETF88 Nov 4, 2013, Berlin sandeep.kumar AT philips.com

Group Communica/on Use Cases Light-1 Light-2 Light

Router) Network Backbone (IPv6 Mul/cast enabled)

Multicast Group (Room-A-Lights) Source: Group

Use- cases Group light control Firmware updates

2 Group Communica/on Use Cases Light-1 Light-2 Light Switch LoWPAN- 1 LoWPAN- 2 Router-1 (6LoWPAN Border Router) Network Backbone (IPv6 Mul/cast enabled) Light-3 Router-2 (6LoWPAN Border Router) Room- A IP Multicast Group (Room-A-Lights) Source: Group CommunicaNon for CoAP (drar- ies- core- groupcomm) Use- cases Group light control Firmware updates Parameter distribu/on dral- keoh- dice- mul/cast- security 2

3 Mo/va/on & Requirements Group communica/on (in LLNs): also vulnerable to eavesdropping, tampering, message forgery, replay, etc. Limited resources and memory: reduce the number of cryptographic protocols on device. DTLS is chosen security solu/on for unicast CoAP: beneficial for constrained devices if it can be used also for COAP group communica/on. Requirements Goals of this drar Group level data integrity and authen/ca/on Data confiden/ality (op/onal) Replay protec/on Out- of- scope (possible future drar) Data source authen/ca/on: applicanon level, e.g., object security A Group Security Associa/on (GSA): distribute keying materials, specify the ciphersuite for encrypnon and authenncanon Mul/cast key management: update/renew group keys periodically. dral- keoh- dice- mul/cast- security 3

4 Reuse of DTLS Record Layer Assump/ons: Group Security Associa/on (group session key and cipher for authen/ca/on & encryp/on to use) are known to all group members out- of- band. Mul/ple senders and mul/ple listeners/receivers in the group communica/on. Proposal: Each sender gets a unique SenderID (2- byte) either chosen by a controller or randomly or derived from the IPv6 address Fallback mechanism if Sender- ID s are not unique In the DTLS Record Layer, split the 6- byte sequence number field into: 2 bytes Sender ID and 4 bytes truncated sequence number. Content Type Version Major Minor Epoch Sequence Number Encrypted (op/onal) Length DTLS Ciphertext MAC Encrypted (op/onal) Content Type Version Major Minor Sender Sequence Epoch Length DTLS Ciphertext MAC ID Number drar- keoh- dice- mulncast- security 4

5 Why split sequence number? Reuse of nonce breaks security of CCM and GCM modes of opera/on (AEAD ciphersuites in TLS) In (D)TLS struct { opaque salt[4]; opaque nonce_explicit[8]; } CCMNonce; In DTLS specifically struct { uint32 server_write_iv; // low order 32- bits uint64 seq_num; // TLS sequence number } CCMServerNonce. 64- bit sequence number = 16- bit epoch 48- bit seq_num If mul/ple senders send messages with the same key Either synchronize seq. number => hard in prac/ce Provide separate seq. number space for each sender => our approach drar- keoh- tls- mulncast- security 5

6 Protec/ng Group Messages (1) GSA is set out- of- band => DTLS SecurityParameters are set for all senders and listeners All devices derive (or provided out- of- band) the same six DTLS key material client write MAC key server write MAC key client write encrypnon key server write encrypbon key client write IV server write IV For Senders : SecurityParameters.ConnecNonEnd= server For Listeners : SecurityParameters.ConnecNonEnd= client dral- keoh- dice- mul/cast- security 6

7 Protec/ng Group Messages (2) Content Type Version Major Minor Epoch Sequence Number Encrypted (op/onal) Length DTLS Ciphertext MAC Senders Content Type Version Major Minor Encrypted (op/onal) Sender Sequence Epoch Length DTLS Ciphertext MAC ID Number write state is instan/ated with server write parameters. Each sender manages its own epoch and truncated sequence number no synchroniza/on is needed with other senders in the group. Ini/alized to 0. The sender include its Sender ID in the DTLS Record Layer header and increments the truncated sequence number when sending a group message. The epoch will be increased, and the trunc. sequence number will be reset once the group session key is renewed or updated (out- of- scope: to be defined as part of key management) dral- keoh- dice- mul/cast- security 7

8 Protec/ng Group Messages (3) Content Type Version Major Minor Epoch Sequence Number Encrypted (op/onal) Length DTLS Ciphertext MAC Listeners Content Type Version Major Minor Sender Sequence Epoch Length DTLS Ciphertext MAC ID Number Mul/ple read states are instan/ated with server write parameters for each sender linked by SenderID Keying material same but the epoch and the "truncated" sequence number of the last received packets needs to be kept different for different senders. Listeners use the mulncast desnnanon IP address of the packet to lookup the server write key. Message is decrypted and the MAC of the message is checked Using the Sender ID field, receivers retrieve the last used epoch and sequence number to detect replayed messages. If success: update last seen seq number from the SenderID in the read state dral- keoh- dice- mul/cast- security Encrypted (op/onal) 8

9 Other issues (1) Epoch update and change cipher spec security Sequence number wraps need to be handled as part of key management (out of scope) Late joiners (John Foley) Use technique similar to AERO (Authen/cated Encryp/on with Replay protec/on) First seen packet used to ini/alize the epoch&seq number but drop it. Check replay of next messages. What if a chain of packets are being replayed? drar- keoh- tls- mulncast- security 9

10 Other issues (2) SenderIDs are not unique Fallback: All senders are also listeners to the group If sender sees a message from a different device with the same SenderID then stop using SenderID Contact controller and inform about clash - > controller provides new SenderIDs to one or both Use specific ciphersuite suitable for mul/cast AERO (Authen/cated Encryp/on with Replay protec/on) (drar- mcgrew- aero) mode provides inbuilt mechanism to support mul/- senders Should it be mandated as the only ciphersuite for DTLS mul/cast or keep it flexible to support all exis/ng AEAD modes? drar- keoh- tls- mulncast- security 10

11 Summary Group communica/on is olen used in machine- to- machine (M2M) applica/ons. Group communica/on is equally vulnerable and requires security. Preferably re- use exis/ng security protocols on constrained devices in LLNs. Propose to reuse DTLS Record layer to support secure group communica/on, with key management out- of- scope. dral- keoh- dice- mul/cast- security 11

12 Next Steps Is this dral ready to be adopted as a WG document? drar- keoh- dice- mulncast- security 12

Crea:ng a pla>orm of trust Meter data transmission the secure way

Crea:ng a pla>orm of trust Meter data transmission the secure way Chris&an Giroux EUW 2014 Landis+Gyr November 4, 2014 Focus of this presenta&on n The informa:on flow between smart meters and head end