The problem is that the only way to get a certificate that a web browser
will trust is to prove possession of a domain name. However, the device
does not own any globally-valid domain names! It owns a .local domain
name, but .local domains are not globally valid, so a publicly-trusted
certification authority cannot issue certificates for them. One can
work around this by using a private certification authority, but this is
infeasible for non-technical users. The result is that most local
communication is either unencrypted or uses self-signed unpinned
certificates, neither of which are secure. Furthermore, this provides
an incentive for device manufacturers to use cloud-based solutions,
which support HTTPS without any hurdles.
This problem can be solved by embedding the fingerprint of a public key in the domain name, producing a cryptographically-generated domain name, or CGDN. Only the owner of the corresponding private key can issue a certificate for such a domain or sign DNSSEC RRSIGs for them. Such domain names are no longer human-memorable, but phones nowadays generally have a camera, which allows for the CGDN to be included in a QR code. QR codes are public, but critically the optical signal cannot be practically tampered with except by physical alteration of the hardware.
The domain name is generated by hashing a public key. The private half of this key can be used for two purposes:
It can, but usually should not be, used for these purposes too:
It is cryptographically sound to use the same key for all five purposes because all five require that the data to be signed have a distinct prefix. The prefix is:
The private key MUST NOT be used for any purpose not listed here unless an extension to the specification explicitly permits such use. Forbidden purposes include, but are not limited to:
An implementation that uses the key for any purpose not listed in this specification MUST be assumed to have a security vulnerability unless there is a sound cryptographic reason to believe that no exploit will ever be possible, even in the presence of future extensions to this protocol. If it is necessary to sign additional data, the SSH signature format with a specific namespace can be used.
A cryptographically generated domain can use one of the following forms:
<hash of public key>.localSOMETHING.<hash of public key>.local.local is reserved for multicast DNS, which is suitable for home networks.
The device itself would advertise the CGDN. CGDNs should also be supported
on the public Internet, with one of the following formats for the domain name:
<hash of public key>.keyhash.arpaSOMETHING.<hash of public key>.keyhash.arpa.keyhash.arpa is a placeholder; the real domain name chosen might be different.
For CGDNs to be reachable over the public Internet, the owner of the corresponding
public key must be able to set DNS records for them. I have
not yet figured out what the mechanism for this should be.
Computing the public key hash is trickier than it sounds, because there are multiple distinct formats in which the public key will be received. Therefore, a canonical format must be chosen. This version of this document chooses the encoding used by SSH as canonical and requires all other formats to be converted to it.
SSH uses a simple and extensible encoding scheme, whereas X.509 requires complicated ASN.1 DER encoding. DNSSEC also uses a simple encoding scheme, but DNSSEC is extremely severely impacted by large signature and public key sizes, so its future in a post-quantum world is less clear.
The hash includes only the algorithm field and the public key. It is encoded into a domain name the same way that Tor v3 onion service domain names are encoded, except that the 32-byte public key is a SHA256 hash. Security of this scheme depends on second-preimage resistance (not collision resistance!) of the hash function, so SHA256 will be secure for a very, very long time.
Tor onion service domains are already cryptographically generated. However, onion sevices are only available on the Tor network, which is a dealbreaker for general use. Furthermore, v3 onion services always use ed25519, which is not post-quantum secure.
Reserving special domain names for CGDNs also started with the Tor network’s
use of .onion, which has been officially reserved by RFC7686.
Self-authenticating traditional domain names have been proposed before, but these proposals are tied to traditional DNS names rather than only using a hashed public key for the domain name. In contrast, this proposal focuses on use-cases that do not require any human-memorable domain name to be present, which significantly simplifies the design.
How should registration work? The intent is that anyone will be able to register a CGDN by proving possession of the corresponding secret key. Is DNS TSIG the best way to implement this?
What is the best way to get this adopted? Writing up an idea is easy, but getting it implemented by major browsers is much harder. Is this something that should be hard-coded in their TLS libraries?
Who should run the public registration service for non-.local CGDNs?
At the very least, one or more such services need to exist so that domain
names can be resolved to IP addresses.
Should there be a public relay service that avoids devices needing to accept incoming connections themselves? This would make life easier for those behind NAT, but someone needs to run the relay service, and there are privacy and abuse concerns.
Is there experience from Tor onion services that is relevant? Anonymity is explicitly not a goal of CGDNs, mostly because Tor already serves that role, but also for performance reasons.
Due to their limited computing power, embedded devices are very vulnerable to denial of service attacks. Is there a good solution to this? Since CGDNs implicitly use certificate pinning, any DDoS-prevention solution that does not require access to plaintext traffic can be used without risking confidentiality or integrity, except against traffic analysis attacks.
Thanks to Matthew Finkel of Apple for helpful feedback.
]]>Bluetooth’s pairing process guarantees that you securely connected to some device. However, it does not guarantee that you securely connected to the correct device! If one pairs with a malicious or compromised device, the device might be able to act as a keyboard and inject keystrokes. Other devices have even worse provisioning protocols, some of which require vendor-provided apps (eww!). If you are lucky, you have to hope that nobody is performing an active monster-in-the-middle (MITM) attack on the pairing process. If you aren’t, you have to hope that nobody is sniffing on your wireless communication, either during setup (for the somewhat-bad devices) or at all (for the really bad ones).
The reason that secure setup is so hard, and so rarely implemented, is that many devices have incredibly poor I/O capabilities. You can’t reasonably enter a passcode on a device with no keyboard, and a device without a display can’t display a code.
The device comes with a QR code. You scan it with your phone, and it tells what kind of device the device is. You press the “Connect” button, and your phone tells you to push a button on the device. Afterwards, your phone and the device are connected. You can then control the device via standardized Bluetooth protocols or via a web interface.
This proposal is to fix the problem once and (hopefully) for all, by using a QR code on the device containing the device’s public key. It requires only that the device have two buttons and (unlike SmartStart) has no timing dependencies at all. This means that you can take a break and come back, and the device will always be in the exact state you left it as far as the protocol is concerned. Furthermore, it is secure against an attacker who can perform monster-in-the-middle attacks on all traffic except for scanning a QR code. Since visual MITM is easy to exclude with the human eye, that’s enough.
How does this work? The key idea is for the controlling device, or controller (such as a laptop or smartphone), to establish a secure connection to the device being controlled. Since the controlled device accepts only one controller at a time, a controller knows that there are no other controllers connected. Therefore, the controller can tell the user to press a button labeled “Confirm Connection,” which tells the device that it can trust the host and accept commands from it.
The device either has zero or one long-term host keys stored in its non-volatile memory. The host key may either be trusted (able to send commands to the device) or untrusted (not able to send commands). A device with no host key stored will store the host key of the first host that connects, but MUST NOT mark it as trusted until the user presses a button on the device. Otherwise, any host could take control of the device. If the device has a stored host key, it MUST NOT accept connections from any host with a different key. Otherwise, another host could connect to the device before the user presses the “Confirm Connection” button. However, it MUST accept connections from a host with the same key, ensuring that an interrupted connection can always be resumed. A device MUST NOT accept commands from a host with a key that is not marked as trusted, as any host can connect to a device if no other host has connected already.
Devices MUST allow the user to clear a host key. This SHOULD take the form of a button on the device. This MUST NOT require that the host be present or available, as the host might not be exist anymore, and MUST require physical or otherwise privileged access to the device. The only exception is if allowing one to reuse the device with a different host without authorization would create a specific, exploitable security vulnerability. For instance, an alarm control panel might not consider anyone with physical access to be trusted.
If the key provided by the host is different than the one the device has stored, the device MUST indicate this in its reply to the host. This allows the host to display a useful error message, such as “Device is already paired to a different host. Please press button ABC to reset the device and connect anyway.” Resetting the device MUST erase any sensitive information that is accessible to the host for security reasons.
The host side is simpler. The host obtains the device key and some other information (such as the connection type) by scanning a QR code on the device itself. Hosts MUST prompt the user with the type of connection being used and the type of device that will be connected to before they continue with a connection attempt, unless the host will only be checking if the device has a stored host key.
What should the format of the public key be? What should the format of the protocol messages be? This is just a high-level description, and doesn’t provide any of the details needed for a concrete implementation.
Should devices be required to expose their status via LEDs, or is it sufficient for them to expose their status to any host that asks them?
Should there be mandatory rotation of host and device keys?
What algorithms should be supported?
Should the long-term device key be required to be in a secure hardware module, such as a secure element? This is logical as it is a long-term key, but might create obstacles to adoption.