Communications of the ACM

PUBLIC KEY CRYPTOGRAPHY (PKC) has the elegant property that requires two keys—one public and one private. Either key can be used to encrypt or decrypt, but the peculiar property that makes PKC interesting is that you must use one key to encrypt and the other to decrypt.

For example, the private key could be used to encrypt the digital hash of a binary message. The recipient of the message could compute the same hash and then decrypt the encrypted digital hash with the public key. If they match, the recipient can be more certain the sender holds the private key and is the originator of the message. Of course, the recipient must know the public key to do this confirmation. The concept is called a digital signature and led to the creation of certificate authorities (CAs)

that could issue certificates binding an identifier (for example, a domain name) to the public key of a PKC pair.

The other function for confidentiality uses the public key to encrypt the message to be sent to the public key owner. Assuming only the owner has the private key, only the owner can decrypt the message, providing confidentiality. The sender of such a confidential message uses the certificate to determine which public key to use to send to the recipient.

These mechanisms lead to a concept called trust on first use or TOFU.

If a party sends a message and says
“this is my public key,” at best, the
recipient can use this information to
confirm that a second message has
come from the same source by check-
ing the digital signature or by gener-
ating a random number, encrypting
it in the putative public key of the
sender, sending it to the originator
of the second message, challenging
the sender to decrypt the challenge
and return it (perhaps encrypted in
the public key of the challenger). The
trust part enters into the picture be-
cause the recipient of the first mes-
sage must trust that the public key is
associated with a known or knowable
party. The certificate idea was used to
confirm that a third party has validat-
ed the certificate owner’s bona fides,
but some CAs were compromised, in-
validating the trust.

Suppose, in lieu of domain names,
one used a public key as an identifier
and associated this with an Internet
Protocol (IP) address. If one looked up
the IP address in a registry of public key
identifiers, one could then challenge
the device at that IP address to show it
still has the associated private key us-
ing a challenge/response protocol as
suggested earlier. If the party register-
ing the public key and its associated IP
des to the registry, this might produce a
kind of TOFU-plusa that gives the party
reaching the computer at the destina-
tion IP address more confidence that
this is the intended destination.

One might imagine applying this to the Internet of Things (IOT) in which the IOT device self-generates a public- and private-key pair and registers the public key. For example, with a hub or controller so the hub can confirm it has reached the right IOT device. By the same token, configuration of the IOT device into an ensemble could include incorporation of the public key of the controller into a list of valid devices that can command or obtain data from the now-configured IOT device.

Both ends can verify they are talking to the originally configured devices, assuming no device has lost its private key. While perhaps not obvious, a failure to validate an identifier by this method does not give much information to the user (or program)

seeking validation. Of course, the act of registering a device with the hub or controller must be a trusted process that might involve physical presence, Bluetooth key pairing, or other action such as proximity NFC that increases confidence in the registration process. One could imagine QR codes or even public key strings associated with the registering device that must be captured by a mobile camera or keyed in by the configuring party to increase trust in the process.