Embed Size (px)
Citation preview
Denial of Service prevention in the IoT
Lund, May 19th, 2015
Marco Tiloca
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)
May 19th, 2015 2Security Seminar 2015, Lund (Sweden)
Two specific DoS attacks
DoS #1• Target: Battery powered devices
• Goal: Energy exhaustion
• Strategy: Denial of Sleep
Dos #2• Target: DTLS handshake
• Goal: Compromise service availability
• Strategy: Establish invalid secure sessions
May 19th, 2015 3Security Seminar 2015, Lund (Sweden)
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
May 19th, 2015 4Security Seminar 2015, Lund (Sweden)
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!
May 19th, 2015 5Security Seminar 2015, Lund (Sweden)
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
May 19th, 2015 6Security Seminar 2015, Lund (Sweden)
DoS #1 – SMACK Application scenario
May 19th, 2015 7Security Seminar 2015, Lund (Sweden)
Authorization Engine (AE)
• Secure trusted third party
• Device (D) is associated to one AE
• Consistent with IoT architectures [1]
[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 2013
Key material
• D and AE pre-share the long term KMS
• KMS used to generate additional keys
• Keys provided to the client
• Keys derived on the device side
DoS #1 – SMACK Application scenario
May 19th, 2015 8Security Seminar 2015, Lund (Sweden)
SMACK session establishment
• Client (C) contacts AE
• C receives a Message ID ID*
• C receives a key KS=PRF(KMS,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
DoS #1 – SMACK message processing
May 19th, 2015 9Security Seminar 2015, Lund (Sweden)
Client side
• Derive key KJ from KS and MID
• Compute a MAC through KJ and KS
• Embed the MAC in the Token field
Device side
• Perform anti-replay checks
• Derive KS =PRF(KMS,MID) (1st message only)
• Derive KJ through KS and MID
• Recompute and check the MAC
Discard messages with invalid MACShort MAC
Computation input
Embedded
short MAC
DoS #1 – SMACK evaluation
May 19th, 2015 10Security Seminar 2015, Lund (Sweden)
Implementation on Contiki
• CoAP library Erbium
• TI CC2538 constrained devices
• Comparison with DTLS (tinyDTLS)
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)
SMACK DTLS
+1.01%(1.65 KB)
+22.71%(37.39 KB)
Memory footprint
First transaction Steady state
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 11Security Seminar 2015 (Lund, Sweden)
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!
May 19th, 2015 12Security Seminar 2015, Lund (Sweden)
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
May 19th, 2015 13Security Seminar 2015, Lund (Sweden)
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)
May 19th, 2015 14Security Seminar 2015, Lund (Sweden)
DoS #2 - Application scenario
Trust Anchor (TA)• Trusted by server S
• Pre-share the long term KMS with S
• Provide security material to clients
• Can provide additional services
ClientHello extension• Admitted by the (D)TLS standard
• 12 additional bytes
Authentication procedure• Based on Galois Field multiplication
• Unconditionally secure MAC
• Efficient computation
May 19th, 2015 15Security Seminar 2015, Lund (Sweden)
SN
KAUTH=PRF(SN,KMS)Authentication key
Sequence number
KMS
DoS #2 – Our solution
Client side• Include SN in Flight1
• Authenticate Flight1 through KAUTH
• Send Flight1 to the server
Server side• Retrieve SN from Flight1
• Derive KAUTH=PRF(SN,KMS)
• Verify Flight1 through KAUTH
• Proceed with the handshake
DoS effects are minimized!
Flight2 and Flight3 are not needed!
May 19th, 2015 16Security Seminar 2015, Lund (Sweden)
SN
KAUTH=PRF(SN,KMS)Authentication key
Sequence number
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
May 19th, 2015 17Security Seminar 2015, Lund (Sweden)
DoS #2 - Evaluation
Performance improves!• Reduced handshake duration
• Reduced computing overhead
Two DTLS messages less!• Reduced TX/RX overhead
• Reduced Round Trip Time
Invalid clients are recognized earlier!
May 19th, 2015 18Security Seminar 2015, Lund (Sweden)
Overview of client performance
Overview of server performance
DoS #2 - Evaluation
Continuous DoS attack• Three parallel adversary processes
• Different attack intensities
One legitimate client• Handshake + CoAP transaction
• Repeat every 500 ms
Server configuration• Up to M open DTLS sessions
• Different values of M
Service availability is preserved!
May 19th, 2015 19Security Seminar 2015, Lund (Sweden)
Session open on the server
Clients served by the server
