IoT Secure Bootsrapping : ideas
-
Upload
jean-baptiste-trystram -
Category
Technology
-
view
657 -
download
2
Transcript of 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
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 !
Hello world, I am bulb !Where is security service ?
Here you go : CertificatesServer =
IPA + Port A CertificatesServer =
rogueIP + Port A
Huehuehue... Little light-bulb, come to my serverz...
DNS SEC to the rescue
Hello world, I am bulb !Where is security service ?
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)
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.
MAC ADDRESS Serial number
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
MAC ADDRESS Serial number
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
4 messages + ACKs = 8 TCP messages !
Handshake
Done.
Then data.
Light application
Great, let's quit
4 messages + ACKs = 8 TCP messages !
4 messages + ACKs = 8 TCP messages !
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