Bruno Vernay: Integrating TLS in constrained devices (IoT)

Keywords: [[Certificate]] [[Certificate enrollment]] [[PAKE]]

What you want to authenticate is your particular device identity, not an IP or a Domain Name. Browsers do not address this use-case. They are made for the Internet.

The trend is to have IoT connect to the Cloud and you meet your device in the Cloud. No more embedded Web Server.
The worst is to fiddle with your browser, like adding trust to local CA and such ...
Maybe, the CABForum could trust IoT vendors (Sony, LG, Siemens, Whirlpool, Samsung, ...)
- That would allow to authenticate Vendor, Model name and Serial Number.
- At least if you are confident that you connect to a Samsung Fridge, even if you do not check the complete S/N. That is still a progress.
- Contrary to the Internet CAs. A Vendor CA would only certify its own devices.
  - Browsers embed hundreds of Internet CAs. Obviously vendors CA would be downloaded only when needed. (With authentication, maybe via their public web site)
- CABForum could set rules and audit them. Same as Internet CA.
- There are still tons of challenges, typically in browser UI.
- Currently browsers have no incentive to engage in supporting IoT device embedded web servers.
Maybe we should not use a browser to connect to local devices?

Browsers are de facto THE Human Interface to almost everything
Developing secure clients is hard (close to impossible).
Having one Samsung app for Samsung devices ; one Sony app for Sony devices ; one Siemens app for Siemens devices ... is a nightmare

The user experience is tricky given the variety of IoT devices. Is there a QR code, a discovery protocol ... Not only the browsers, but the OSs might have to participate.
Conclusion: It is still far far away.

In the meantime having Opportunistic Encryption (AKA Opportunistic Security) would at least improve a bit.

Most solutions are based on Let's Encrypt, ACME protocol. (Does not solve IoT use-case as it requires domain names.)

https://letsencrypt.org/docs/certificates-for-localhost/ on 2017
Lets Encrypt for internal hostnames by [[Julien Savoie]] on 2021

Should you use Let's Encrypt for internal hostnames? by [[Terence Eden]] on 2022
Domains Names are public, the

HOW PLEX IS DOING HTTPS FOR ALL ITS USERS by [[Filippo Valsorda]] on 2015

They issue wildcard certs for , and then have a [[DNS]] rule that means that returns .
Interesting but end up with a super long domain name. Only works because the user connects to public server, which is doing XHR requests to local [[Plex]].

OpenWRT and self-signed certificates by [[Jake Edge]] 2020 in [[LWN]]
Using Let’s Encrypt for internal servers by [[Philipp C. Heckel]] on 2018

They manage about 90.000 appliances. They had to request a higher rate limit to [[Let's Encrypt]] (= huge success)
Very well explained

Implementation in [[Python]] https://github.com/Corollarium/localtls

Discussions

Where is HTTPS for IoT? by [[Daniel Albuschat]] on 2018
There's no HTTPS for the Internet of Things by [[Terence Eden]] on 2017
TLS Outside The Web by [[David Evans]]'s students(?) on 2017 summarize several papers
- Sizzle: TLS For Embedded Devices (2005)
- [[DTLS]] based security and two-way authentication for the Internet of Things (2013)
- The Most Dangerous Code In The World: Validating SSL Certificates in Non-Browser Software (2012)
- AWS IoT Security Overview
- AWS, Microchip deliver trust anchor for end-to-end IoT security (2016)