[From the last episode: We looked at an example of how authenticationThis is the act of proving to some other entity that you are truly who you are representing yourself to be. That is, you're not pretending to be someone else. "You," of course, means a computer or IoT device or any other entity trying to make a network connection with another computer or device. ensures that, when you establish a secureRefers to whether or not IoT devices or data are protected from unauthorized viewers. web connectionThis refers to some kind of electrical connection. It might be through a network cable, a cable connection, a wireless connection, or a phone - just to name some options. The connection might be to the internet or to some other local device., everyone is who they say they are.]

Let’s talk some more about keysA number used to encrypt (or encode) information so that no one can read it. Keys are used when encoding and decoding. You shouldn't have to mess with keys yourself.. And I’ll warn you: as hard as I’m going to try to make things clear, you may need to reread a couple times, since there are several types of key, and it matters which one is which. And it’s going to be a little longer than usual… hopefully it’s worth it! And there will be videos at the end to illustrate the concepts visually. So buckle up!

We saw that we can have asymmetric public/private keys and symmetric private keysA key that should be known only by your device and, possibly, by someone or something else that your device is communicating with. It must be kept secret.. With public/private keys, you can share the public keyA key that you (or your device) can publicly share with someone or something else. This key can be used only to encode (or encrypt) data; it can't be used to read that data. Each public key has a matching private key, and the private key is used for decoding (or decrypting) data. This lets you have a secure conversation with someone or something that you've never shared keys with before. openly, and you can use it for encrypting messages. But here’s the thing: the math used with public/private keys is ok for encrypting short messages (like that random number), but if you’re going to be sending volumes of data, it’s not so good for that. There are other encryptionEncryption refers to encoding and decoding (or encrypting and decrypting) data so that it can't be read unless you have the right key. It's critical for good security. schemes that work better.

One such scheme is called AES (for Advanced Encryption Standard). It’s good for encrypting blocks of data more efficiently than the public/private keys. But it’s a symmetric-key approach, meaning that both sides have to have the same key. How do you get the keys to each side without sending them in the clear, where they can be snooped?

Handling Pre-Stored Private Keys

This takes us on a bit of a voyage to explore different keys. There are systems that use only private keys, so, for those systems, the key has to be programmed into the IoTThe Internet of Things. A broad term covering many different applications where "things"  are interconnected through the internet. device when it’s manufactured. With some families of IoT device, every unit gets the same key, but, the challenge there is that, if someone hacks the key out of one device, then they have it for all devices. If a manufacturer makes that choice, then they must store the key in a way that makes it super hard to hack.

In other cases, each device gets its own key, so that hackingThis can mean a couple things. A quick-and-dirty (but not elegant) trick to get something done is a hack. A computer security break-in is also a hack (because inelegant tricks are used to break in). It can be a noun or a verb ("he hacked my computer"). one device gets you into only that device, no others. But that creates a logistical conundrum: when you connect to the serverA computer with a dedicated purpose. Older familiar examples are print servers (a computer that controls local printing) and file servers (a computer used for storing files centrally). More modern examples are web servers (the computers that handle your web requests when you use your browser) or application servers (computers dedicated to handling the computing needs of a specific application). Servers are often powerful, expensive machines since they have to handle a heavy load., how does it know what your device’s key is, since they’re unique to each individual device?

The easy answer is that, when building the systemsThis is a very generic term for any collection of components that, all together, can do something. Systems can be built from subsystems. Examples are your cell phone; your computer; the radio in your car; anything that seems like a "whole." and provisioningThis is a manufacturing step where your IoT device gets its own private key. The key and your device's ID are likely stored in a database so that your device can be recognized when you connect for the first time. the keys, you store the device’s ID and its key in some well-protected databaseA structured way of storing data and relating different pieces of data to each other. (Like, which address belongs to which person.) There are “query” languages, the best-known of which is SQL, that let you enter data into the database, change data that’s already in the database, and retrieve data from the database.. The server you connect to then goes to that database and, with your device ID, finds the key.

Sounds good, but there’s a danger there: that’s one purty-lookin’ database just waiting for a hackerA misused, but common term for an unauthorized person trying to break into a device or network. Originally, in this context, "hackers" referred to the good guys (or "white hats"), while "crackers" were the bad guys (black hats). who’s looking for the treasure trove of keys it contains. Hopefully that’s really hard to do, but there could be a way around that. As an alternative, some systems have a way of deriving keys from a master key and the device ID. That process will involve some fancy algorithmA way of calculating something, typically as a step-by-step recipe. A familiar one to all of us is how we do long division on paper: that's an algorithm. Algorithms abound in the IoT. that’s not obvious.

Master Keys and Root Keys and Session Keys – Oh My!

That algorithm would then be used when provisioning the IoT device, and the web serverA server whose purpose is to receive requests for web pages and then send those pages out to the requestor. you connect to would also know that algorithm and the master key. So when you send your device ID to the server, rather than it using the ID to look up a stored key, it can use the algorithm with the master key to re-create the device’s unique key. No more tasty-looking keys in that database.

Of course, that works only if the algorithm and the master key remain secret. Again, it’s hard to guarantee that (what if a disgruntled employee somehow smuggles the formula out of the company and makes it public?). But it may well be better than the database approach.

OK, so let’s circle back. We have IoT devices with private keys pre-stored inside. These are often called root keysA key that is typically unique to each IoT device (but might not be) and which is used to create session keys for communication between IoT devices and IoT servers in the cloud.. If you literally used that key for all encryption, then if anyone figures the key out, they can simply impersonate you, and you’re stuck.

So, instead, you can use it to generate what are called session keysA one-time-use security key used for encryption during a single communication session between an IoT device and an IoT server. – temporary keys used only for one session. When you go back in for a new session, you generate a new session key. That protects the stored root key. If anyone hacks the session key, it won’t work for a new session.

Session Keys in the Server

But how do both sides know the session key, since it wasn’t put in there during manufacturing? The device creates the session key from its root key and the nonce, but what about the server? It can’t send the session key to the server.

Here again, there’s likely to be an algorithm. Only, instead of using the device ID with the master key, it uses a random number with the root key. (Stay with me here!) Both the device and the server know the algorithm, and the device sends the random number – often referred to as a nonce since it’s used only once – to the server. The server then:

• calculates the root key from the device ID and the master key (which it knows), and then
• calculates the session key from the nonce and the root key.

And now both sides have the same session key.

So that’s one way of handling things using only private keys. And some IoT devices will use only private keys, since it takes less computing to do that than to do the public/private thing. But what if you do have the public/private thing – only you don’t want to use those keys for encrypting all of the data?

Session Keys for PKI Public/Private-Key Systems

Well, you may remember that the authentication process we talked about last week uses a random number challenge so that each side can prove that they’re them. Well, this one-use random number is also a nonce, and you can use it directly as a private session key. Or to derive a session key. Either way, the authentication process itself automatically ends up exchanging the keys, since both sides have the random number (encrypted when sent). (Of course, throughout this piece, when I say, “You can use…,” I don’t mean literally that you have to involve yourself; your computer or IoT device is doing this for you.)

So we used the public/private keys to encrypt the authentication messages, including the private session key. We then switch from PKIA system of mathematical algorithms for public and private keys as well as certificates of authority that are used when authenticating a web session. encryption (not great for data) to something like AES, which is better for data, and now we use it with the new private session key to encrypt data during the session.

Deep Breath!

If your head isn’t swimming yet, then you’re better than I am. I’ll summarize key points here (no pun intended – wait, no, pun totally intended) and attempt to illustrate the simplified concepts with a couple of mini-videos. Hopefully that will clarify anything that’s not yet clear.

To summarize, we have seen the following keys:

• Master keysA security key used in some systems to create individual root keys for IoT devices.: used for provisioning private root keys during manufacturing.
• Root keys: used for generating private session keys during authentication.
• Session keys: used for encrypting messages during one session between a device and a server, and never ever reused.
• Public/private (asymmetric) keys: used with one way of authenticating where the public key is used for encryption and the private key is used for decryption. But not good for encrypting big blocks of data.
• Symmetric keysA way of encrypting data that uses the same key both for encrypting and decrypting.: private keys used for encryption schemes like AES that work well on data. They may be shared during manufacturing or during authentication with public/private keys. Master keys, root keys, and session keys all are usually symmetric.

Illustration of simplified PKI authentication

 

Illustration of simplified private-key authentication