IoT Secure Bootsrapping : ideas

I TBootstrapping & Security : An 8-weeks-internship view

It's all about ...

cloud !

But that's covered :

...

What can I do with theses clouds?

REST APIs

MQTTAMQP

CoAP

Security ?

REST APIs

MQTTAMQP

CoAP

Today answer

REST APIs

MQTTAMQP

CoAP

Let's TLS all the things !!

Provisioning

REST APIs

MQTTAMQP

????

Brand new connected lightbulb !

Provisioning

Provide Light-bulbMAC

Client certificate

Bake client + servercertificates in the light bulb

Provisioning

It works !

Provisioning

Brand new connected light-bulbs !

1000x

Use DNS Service Discovery

Hello world, I am bulb !Where is security service ?

RFC 6763

To DNS serverOR 224.0.0.251 OR FF02::FB

Here you go : CertificatesServer =

IPA + Port A

Open Source JAVA implementation : Eclipse TIAKI project

DNS SD : how does it works ? RFC 6763

- Designed to help with resources discovery.- The DNS server send you a list of the services available for the domain you asked.

jibou@issodake:~$ dig PTR _printer._tcp.dnssd.org.printer._tcp.dnssd.org. 45 IN PTR Sales._printer._tcp.dnssd.org._printer._tcp.dnssd.org. 45 IN PTR Marketing._printer._tcp.dnssd.org.

jibou@issodake:~$ dig SRV Sales._printer._tcp.dnssd.org.Sales._printer._tcp.dnssd.org. 10 IN SRV 0 0 49152 pretendserver.cheshire.org.

- 3 DNS records :- PTR : gives all the SRV records for a given service.

- SRV : Gives details for an instance of a service. Name of the server + port.- TXT : use to give additional details that doesn't fit in the SRV record.

Oh wait ! DNS spoofing !


Here you go : CertificatesServer =

IPA + Port A CertificatesServer =

rogueIP + Port A

Huehuehue... Little light-bulb, come to my serverz...

DNS SEC to the rescue


RFCs 4033 4035-

Signed DNS answer

Spoofed DNS answer

X

DNS SEC to the rescue

Example : Twitter got blocked in TurkeyIn 2014

RFCs 4033 4035-

DNS SEC : how does it works ? RFCs 4033 4035-

- Each record is signed with the the Zone Signing Key (ZSK).- The signature of each record is sent along the record.- You can verify the signature by decrypt it with the zone's public key.

jibou@issodake:~$ dig +short RRSIG trystram.netA 7 2 3600 20151217181123 20151117181123 45314 trystram.net. HxqTctoCvq[...]00ozFTvFHylLdYYr6cYciSeQBK1mG FBQ=

- There is one public/private key pair for each zone.- Signing a zone can be delegated : the Key Signing Key authenticate the delegation.

- A query on a non-existent domain results on a NSEC record, authenticating that no domain exists.

DNS SEC in brief

Root Key Signing Key

Only one key to bake into the bulb !

Eclipse Tiaki project supports DNSSEC as well

Good, but not enough

I can still do MIM with my dodgyCA.com cert !

The Public Key Infrastructure issue

Example : The DigiNotar hackIn 2011

XGmail.com

DNS-based Authentication for Named Endpointsa.k.a DANE RFC 6698

Rogue X509 cert

App server

DNS serverIs the cert I got from _443._ttcp.myapp.com. Supposed to be signed by dodgyCA.com ?

DNS-based Authentication for Named Endpointsa.k.a DANE RFC 6698

Rogue X509 cert

App server

DNS serverNope. Supposed to be Verisign.com

X

DANE : how does it works ? RFC 6698

- A TLSA record is added in the DNS zone.- TLSA = TLS Authentication- Contains details about the certificate the server is supposed to send.- Signed with DNSSEC

- The TLSA allow to specify : - Which CA's signature the certificate should contain- Which CA + which signature the certificate should contain- A CA certificate (if unknown by the client)- Which public key the certificate should contain

jibou@issodake:~$ dig +dnssec +noall +answer +multi _443._tcp.trystram.net. TLSA_443._tcp.trystram.net. 3600 IN TLSA 3 1 2 ( 02D4B2B6 [… ] EDBA03FB5FA )

Sounds better !

X

Obtaining credentials

Hello world, I am bulb !I am brand new, where do I get identity ?

Certificate Server found via DNS-SD

DNS server

Enrolment over Secure Transport RFC 7030

EST server

Client certificate requestwith Pre-Shared Key Authentication

EST RFC 7030

EST server

Bulb number 007 needs a certificate

Red Hat CA

This PSK belongs to Red Hat...

Generate the CSR in behalf of the light-bulb

EST RFC 7030

EST server

Signed X509 certificate

Red Hat CA

New certificate to replace the manufacturer PSK

EST : how does it works ? RFC 7030

- Over HTTPS- EST client & server need to be provided with authentication data (e.g. PSK)- A client can get a CA public certificate without being authenticated

- The client can ask for a certificate when authenticated via : - Another certificate (e.g. refreshing an old certificate)- Pre-Shared Key- HTTP-based auth (i.e. username & password)

- Based on HTTP URIs- Accept standard Certificate Signing Requests & others (Cryptographic Message Syntax compliant )

* Java implementation : github.com/jscep/jester* Cisco implementation : github.com/cisco/libest

+ test server at https://testrfc7030.cisco.com:8443/(http://testrfc7030.cisco.com/ for instructions)

https://testrfc7030.cisco.com:8443/

http://testrfc7030.cisco.com/

OverviewDNS serverInitial Situation

Light application

EST server

Red Hat CA

MAC ADDRESS Serial number

Root dns key

OverviewDNS serverDNS Service

Discovery

Light application

DNS SD request for EST service

EST server

Red Hat CA

DNSSEC signed answer.


Root dns key

1

OverviewDNS server

Light application

Initiate HTTPS connection

EST server

Red Hat CA

X509 certificate

DNS DANE

TLSAquery

TLS details in TLSA


Root dns key

23

OverviewDNS server

Light application

Auth with PSKQuerry certificate

EST server

Red Hat CA

X509 client-side certificate

EST

Client X509 Certificate

Root dns key

4

5

6

6Insert TLSA record

OverviewDNS serverDNS Service

Discovery

Light application

DNS SD request for Lighting application service at iot.redhat.com.

EST server

Red Hat CA

DNSSEC signed answer.

Root dns keyX509 Certificate

7

OverviewDNS serverDNS DANE

Light application

Initiate HTTPS connectionClient X509 Certificate

EST server

Red Hat CA X509 certificate

Root dns keyX509 Certificate

TLSA request for _5671._tcp.light.iot.redhat.com

TLSA request for _5671._tcp.bulb007.iot.redhat.com

8

9

9

OverviewDNS serverApplication

Light application

Sends ambient light data

EST server

Red Hat CA Switch on or/off

Root dns keyClient X509 Certificate

10

Then what ?

Client

Remote control

Light application

Nice secured TLS connection- Encrypted- Authenticated- Tamper-proof

I can switch off kitchen light from my bed !!

Let's have a closer look

Light application

TLS Handshake Then Data

TLS Handshake

Light application

Client Hello ~ Supported ciphersServer Hello ~ Chosen cipher + cert

Negotiate security parametersClient certificateIntegrity check

4 messages + ACKs = 8 TCP messages !

Then data.

Light application

Please turnthe light off


Handshake

Done.

Then data.

Light application

Great, let's quit



Handshake

Data + quit

OK, Bye.

That's a lot

Light application

At least 16 TCP messages to switch a light off

TLS Handshake with RSA mutual authentication :

2388 bytes [1]

[1] : with 1024 bits lengths keys Comparison Studies between PSK and PKE Mechanisms for TLS (Fabian Meyer et al. 2006)

A few ideas- Use Pre-Shared Keys Authentication Method (~ 500 bytes handshake, see RFC4279)- Use Eliptic Curve Cryptography (Certificates are much lighter due to short keys)- Use session resumption (handshake down to 3 TCP messages + ACKs)

- Tune TLS to fit your application requirements : - Use NULL cipher-suites (see RFC 4785)- Use Raw Public Keys (see RFC 7250)- TLS 1.3...

- Write good implementations of DTLS- TinyDTLS fits in 100KB flash and requires 10KB RAM[2]

[2] : A Hitchhiker's Guide to the DTLS Protocol for Smart Objects and Constrained Node Networks (2014)tools.ietf.org/html/draftietflwigtlsminimal01

TLS handshake with PSK authentication

Source : Comparison Studies between PSK and PKE Mechanisms for TLS (Fabian Meyer et al. 2006)

Amount of transited data Processing time

Elliptic Curve Certificates

jibou@issodake:~$ openssl speed[...]

sign/s verify/sRSA 2048 bits 1 403.5 43 197.7256 bit ecdsa (nistp256) 22 996.8 10 164.9

(early 2015 laptop Intel i5)

Faster signing Key Length comparison [3]

Symmetric Key Elliptic Curve RSA

64 128 816

72 144 1008

80 160 1248

96 192 1776

112 224 2432

128 256 3248

256 512 15424

Source : ECRYPT II recommendations (2012)

TLS session resumption

Source : Tim Taubert - Mozilla

Full RSA handshake Session resumption

TLS v1.3 handshakes

Full handshake

0-RTT resumption

For more details : Tim Taubert blog (timtaubert.de), see 16/11/15 article.

Some other things to think about- Time matters.

- Are sensors vulnerable to DDos ?

- PSK doesn't always provide Forward Secrecy (neither do RSA-auth).

- Raspberry-Pi Zero is £4 and full TLS capable.

- What about IPSec in IPv6 devices?

- Initial key provisioning in factory? How can you trust the factory?

- What happen if the building is sold and you need to send data to another cloud provider?

- Firmware management & update without failure (LightWeight M2M maybe).

- Data security in the device.

Thanks

● Dave Ingham for answering my questions● Everyone at Red Hat for being nice and paying for the beers● IETF for writing understandable RFCs● Google for finding awesome things to read● Tim Taubert from Mozilla for the TLS handshake drawings● Freepik for providing a lot of the icons used in there

IoT Secure Bootsrapping : ideas

Technology

Transcript of IoT Secure Bootsrapping : ideas