Denial of Service prevention in the IoT

Transcription

1 Lund, May 19 th, 2015 Marco Tiloca Denial of Service prevention in the IoT

2 Denial of Service (DoS) Main goal Make a victim host unavailable Compromise service availability DoS criteria Consume non renewable resources Destroy/alter configuration information Destroy/alter physical components Countermeasure approaches Network-based (smart monitoring routers) Host-based (enhanced DoS targets) 2

3 Two specific DoS attacks DoS #1 Target: Goal: Strategy: Battery powered devices Energy exhaustion Denial of Sleep Dos #2 Target: Goal: Strategy: DTLS handshake Compromise service availability Establish invalid secure sessions 3

4 DoS #1 Denial of Sleep Attack target Resource constrained hosts Directly connected to the Internet Battery powered Attack goal Run the victim to battery depletion Compromise resource availability Attack strategy Repeatedly send (in)valid messages Force continuous message processing Prevent switching to power saving modes 4

5 DoS #1 Reduce the attack impact Check message validity Is the source legitimate? Efficiently and ASAP! Intrusion Detection System Energy expensive Storage demanding Link-layer security Security operations hop-by-hop Complicated key management DTLS protocol Not extremely efficient and fast Complex initial handshake Handskake vulnerable to DoS! 5

6 DoS #1 SMACK (Short MAC check) Early and efficient message check Lightweight authentication Based on Galois Field arithmetic Reduced output size Robust against forgery Embedded short MAC Only 16 bits in size No handshake is required No extra information is sent Adaptation for CoAP Same message format Easy adoption in the IoT Adaptable to other protocols 6

7 DoS #1 SMACK Application scenario Authorization Engine (AE) Secure trusted third party Device (D) is associated to one AE Consistent with IoT architectures [1] Key material D and AE pre-share the long term K MS K MS used to generate additional keys Keys provided to the client Keys derived on the device side [1] L. Seitz, G. Selander, C. Gehrmann, "Authorization framework for the Internet-of-Things," IEEE 14th International Symposium and Workshops on a World of Wireless, Mobile and Multimedia Networks (WoWMoM), pp.1-6, June

8 DoS #1 SMACK Application scenario SMACK session establishment Client (C) contacts AE C receives a Message ID ID* C receives a key K S =PRF(K MS,ID*) Communication with D Use the first request has ID* as MID MID incremented by C at every request AE centrally manages initial MIDs SMACK session management Sessions have limited pre-fixed lifetime New request to AE after session expiration 8

9 DoS #1 SMACK message processing Client side Derive key K J from K S and MID Compute a MAC through K J and K S Embed the MAC in the Token field Device side Perform anti-replay checks Derive K S =PRF(K MS,MID) (1 st message only) Derive K J through K S and MID Recompute and check the MAC Discard messages with invalid MAC Short MAC Computation input Embedded short MAC 9

10 DoS #1 SMACK evaluation Implementation on Contiki CoAP library Erbium TI CC2538 constrained devices Comparison with DTLS (tinydtls) SMACK +1.01% (1.65 KB) DTLS % (37.39 KB) Memory footprint First transaction Steady state SMACK is preferable against Denial of Sleep! [2] C. Gehrmann, M. Tiloca, R. Hoglund, SMACK Short Message Authentication ChecK against battery exhaustion in the Internet of Things," IEEE 12th International Conference on Sensing Communication and Networking (SECON 2015), pp.1-9, June 2015 (To appear) 10

11 DoS #2 DTLS overview Designed with TLS in mind Session established through a handshake Message transmitted as secure records Same security services Secure communication End-to-end security Prevent eavesdropping Prevent tampering and message forgery Mandated choice for the CoAP protocol Constrained networks M2M applications Internet of Things May 19th, 2015 Security Seminar 2015 (Lund, Sweden) 11

12 DoS #2 - DTLS Handshake Secure session establishment Mutual authentication Agreement on security algorithms Derivation of security material Complex process Time consuming Resource demand Three message round-trips Denial of Service protection Cookie exchange (optional) Actually not so effective! 12

13 DoS #2 - Handshake weakness Cookie protection DoS is only (slightly) complicated Ineffective against valid (spoofed) addresses Main flaw ClientHello are always accepted DoS attack is possible up to Flight 4 Effective DoS is easy to be performed Effects Many half-open sessions on the server Exhaustion of server resources Amplification attack on innocent clients 13

14 DoS #2 - Our approach Denial of Service protection Identify invalid ClientHello messages DoS effects are minimized One less message round trip Benefits Standards are not broken Reusable with TLS Achievements Avoid establishment of half-open sessions Preserve server availability Avoid side effects (e.g. reflection) 14

15 DoS #2 - Application scenario Trust Anchor (TA) Trusted by server S Pre-share the long term K MS with S Provide security material to clients Can provide additional services K MS ClientHello extension Admitted by the (D)TLS standard 12 additional bytes Authentication procedure Based on Galois Field multiplication Unconditionally secure MAC Efficient computation Sequence number SN Authentication key K AUTH =PRF(SN,K MS ) 15

16 DoS #2 Our solution Client side Include SN in Flight1 Authenticate Flight1 through K AUTH Send Flight1 to the server Server side Retrieve SN from Flight1 Derive K AUTH =PRF(SN,K MS ) Verify Flight1 through K AUTH Proceed with the handshake DoS effects are minimized! Flight2 and Flight3 are not needed! Sequence number SN Authentication key K AUTH =PRF(SN,K MS ) 16

17 DoS #2 - Evaluation Prototype implementation Java libraries Californium and Scandium DoS countermeasure Anti-replay checks Experimental evaluation Session length Memory footprint Message processing time Attack effectiveness Test environment Original DTLS vs. Extended DTLS Local network scenario 17

18 DoS #2 - Evaluation Performance improves! Reduced handshake duration Reduced computing overhead Two DTLS messages less! Reduced TX/RX overhead Reduced Round Trip Time Overview of client performance Invalid clients are recognized earlier! Overview of server performance 18

19 DoS #2 - Evaluation Continuous DoS attack Three parallel adversary processes Different attack intensities One legitimate client Handshake + CoAP transaction Repeat every 500 ms Session open on the server Server configuration Up to M open DTLS sessions Different values of M Service availability is preserved! Clients served by the server 19

20 Thank you so much! Marco Tiloca