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 checking the digital signature or by generating 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 because the recipient of the first message 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 validated the certificate owner’s bona fides, but some CAs were compromised, invalidating the trust.
A 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.
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 using a challenge/response protocol as suggested earlier. If the party registering the public key and its associated IP address has to show significant bona fides to the registry, this might produce a kind of TOFU-plusa that gives the party reaching the computer at the destination 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.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment