OUR ROAD TO IOT: SECURE DEVICE GRID · 5 October 2015 OUR ROAD TO IOT: SECURE DEVICE GRID Kresten...

5 October 2015

OUR ROAD TO IOT: SECURE DEVICE GRID

Kresten Krab Thorup @drkrab

Introduction

IoT and SSL/TLS landscape

Secure Device Grid design

Lessons Learned

ABOUT THE SPEAKER

Kresten Krab Thorup, Ph.D.

Trifork CTO - since 1999

JAOO, QCon, YOW!, GOTO Conferences

Language Hacker

HOW TO REMOTE CONTROL YOUR IOT DEVICES?

IOT REMOTE CONTROL

ACCESS

Device/Mobile behind NAT

SECURITY

Secure Traffic (Secrecy, Integrity)

Authentication

Privacy

DESIGN #1

GATEWAY

MOBILE DEVICE

TRUSTED? MAN IN THE MIDDLE

FIREWALL FIREWALL

DESIGN #2

GATEWAY

MOBILE DEVICE

END-TO-END TRUST

FIREWALL FIREWALL

DESIGN #2

GATEWAY

MOBILE DEVICEPAIRING

KEY EXCHANGE

PIN

DESIGN #2

GATEWAY

MOBILE DEVICE

Secure

Authenticated

Private

HOW TO SECURE THIS?

PUBLIC KEY CRYPTOGRAPHY

SecretKey PublicKey

Alice BobI’m Home!

SecretKey PublicKey

ENCRYPTION

Alice Bobciphertext

encode(“I’m Home!”, PublicKey)

decode(ciphertext, SecretKey)

Only Bob can decode it

Eve

SIGNING

Alice Bobsigned

sign(“I’m Home!”, SecretKey)

verify(signed, PublicKey)

Only Alice could have created the signed message

Eve

TRUST

Alice Bob

Eve

Carl

PublicKey PublicKey

sign(PublicKey, SecretKey)

sign(PublicKey, SecretKey)

SSL/TLS

SSL/TLS

Standardized approach to Public Key Crypto

Public Key Infrastructure (CA’s)

Standard Protocols

15+ years of history

SSL/TLS

iOS

Android

Windows

OpenSSL

ARM

Broadcom

WinCE

GATEWAY

Many platforms ⇒ weakest link defines level

PROBLEMS

Implementation errors / limitations

Protocol errors

Configuration/use errors

SSL/TLS WOES

NATIVE STACK LIMITATIONS

Client certificate capability

Validate/control connection status?

Who are you connected to?

Support proper (modern) ciphers

WELL KNOWN SSL/TLS BUGS

FREAK - downgrade to ‘export grade’ crypto

POODLE - downgrade makes keys guessable

HeartBleed (OpenSSL)- expose contents of server memory

Logjam - Exploits standard config (DH) params

Many individual implementation bugs

TLS VULNERABILITIES

SSL VULNERABILITIES

LESSON #1

IMPLEMENT UPGRADE OF SOFTWARE IN THE FIELD

LESSON #2

OPENSSL IS A ATTACK TARGET BECAUSE IT IS POPULAR

(Just like Windows)

COMPLEXITY

TLS COMPLEXITY

Creeps in as standards develop

15+ years backwards compatible

ASN.1, X509 Certificates, Revocations, …

Protocol negotiation (and renegotiations)

Diversity of features available on platforms

Diversity of configurations

DIVERSITY

iOS

Android

Windows

OpenSSL

ARM

Broadcom

WinCE

OUR TLS SOLUTION

OpenSSL

OpenSSL

OpenSSL

OpenSSL

OpenSSL

OpenSSL

OpenSSLONE CONFIGURATION: TLS 1.2 ECC BrainPool P384One cipher ECDH_ECDSA_AES

LESSON #3

ANY SSL/TLS IMPLEMENTATION IS LARGE AND COMPLEX

(ARM JUST OPEN SOURCED A NEW STACK ‘mbed TLS’)

A NEW START:

GOING SMALL

A NEW START: NACL (CURVE 25519)

Crypto library from Daniel Bernstein (of qmail fame)

Used in ZeroMQ, Tor, SSH, HomeKit, AirPlay, Chrome/QUIC, countless open source tools.

“An attacker who spends a billion dollars on special-purpose chips to attack Curve25519, using the best attacks available today, has about 1 chance in 1027 of breaking Curve25519 after a year of computation.”

NACL: CRYPTO SIMPLIFIED

One way to do things

ECC crypto (Curve25519)

Stream cipher (Salsa20)

SHA25

CurveCP: Control Protocol (like SSL/TLS)

NACL: CRYPTO SIMPLIFIED

Multiple implementations

NaCl, the original (compiles to ~30k ARM code)

libsodium (with fast ASM for popular platforms)

TweetNacl, compiles to 10k ARM code

Java, .NET, JavaScript, … you name it.

NACL: WHAT’S NOT THERE?

Key Management

Certificate Chains / X509 / ASN.1

Protocol negotiation, downgrade, …

Many ciphers, hashes, …

RANDOM SOURCE

LESSON #4

WHEN YOU CONTROL BOTH ENDS, CONSIDER SIMPLIFYING

RANDOM

LESSON #5

RANDOMNESS IS HARD IN EMBEDDED DEVICES

RANDOM IS HARD

Initialize when product is ‘installed’ at factory

product’s public key

entropy data file

Recent JEEP hack was lack of entropy

Android also had a serious random bug in 2013

PRIVACY

PRIVACY

GATEWAY

MOBILE DEVICE

NEED-TO-KNOW

Gateway/router has no knowledge of peer identity — It only knows that they trust each other

A break-in of cloud infrastructure does not compromise peers

Individual peers being compromised will not compromise other peers.

LESSON #6

SAVE ONLY WHAT’S NECESSARY (PRIVACY BY DESIGN)

TRUST SCHEMES?

Establish trust by means of a 3rd party

SMS

3rd party SSO

Certificate authority

Trust direct between devices

TRUST

Alice BobEve

Carl

PublicKey PublicKey

sign(PublicKey, SecretKey)

sign(PublicKey, SecretKey)

Carl2sign(PublicKey, SecretKey)

sign(PublicKey, SecretKey)

Carl3sign(PublicKey, SecretKey)

sign(PublicKey, SecretKey)

TRUST

SecretKey PublicKey

Alice Bob

SecretKey PublicKey

OTPOTP

LESSON #7

AVOID CERTIFICATE AUTHORITIES (CA’S) WHEN POSSIBLE

TRUST ON FIRST USE

SSH shows a fingerprint to verify on first use

Our product you enter a PIN to verify the peer

Henceforth, trust the holder of that key

END-TO-END LIMITATIONS

Sometimes you want an OPEN API - Most web-enabled IOT devices do that

IFTTT (open programmable interation platform) - Holds on to all your credentials

- Email, google, facebook, devices, …

- Ideal targt for a hacker

Make this a special case, not the default.

SUMMARY

SUMMARY

SSL/TLS is more complex than you think

CA’s introduce trust in 3rd parties

Implement software upgrade

Control both ends? Consider a simpler solution.

Randomness is hard

Remember (log/store) only what’s necessary

Aarhus Copenhagen Zurich Amsterdam Berlin Budapest Buenos Aires Krakow Leeds London San Francisco Seattle Stockholm

our product securedevicegrid.com

Aarhus Copenhagen Zurich Amsterdam Berlin Budapest Buenos Aires Krakow Leeds London San Francisco Seattle Stockholm

Kresten Krab Thorup krab@trifork.com

@drkrab