[From the last episode: We looked at different kinds of 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. used for 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..]

Let’s say you want to connect to a website. Yeah, I know, we’re supposed to be talking about the IoTThe Internet of Things. A broad term covering many different applications where "things"  are interconnected through the internet., but using a web browser is more familiar and it uses the same concepts. So we’ll assume you want to connect to your bank. Something where securityRefers to whether or not IoT devices or data are protected from unauthorized viewers. matters – you don’t want just anyone being able to connect to your bank as if they were you.

The security thing that you see is the part where they ask for your username and password. And that’s important. But stuff happens even before that, when you connect to the page that asks for your password. In fact, these days, pretty much every website has to use security or else Google demotes it in its rankings.

So what we’re going to talk about happens even if you don’t formally log in – even if you’re shopping “anonymously” (yeah, I know… no such thing these days…). IoT devices should do something like this every time they connect to a 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. across the internet.

Here’s the thing: you say you’re you, but… what if you’re not? What if someone is pretending to be you? What if… someone intercepts your request to connect and messes with it so that they can get in instead of you? And how can you do this communication as secretly as possible?

What we’re talking about here is called 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., and the idea is that you’re proving to the website (or whatever you’re connecting to) that you’re authentically you. And the website is doing the same back to you. And you have tools to help with that – even though you probably don’t notice them (unless you look carefully on a slower computer). Those tools are your public and 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. and a certificateA digital document that certifies, more or less, that someone is who they say it is. It’s issued by a certificate authority..

Certifiably You

A certificate brings trust to this transaction. It comes from some trusted entity (a company in that business), called a certificate authorityA trusted organization that issues security certificates., or CA. There are other ways to get certified, but it’s the most common, straightforward way. Just like you don’t see your keys, you also don’t see your certificates (you may have more than one for different purposes). It’s generally part of your browser (but that’s not how it has to be – that wouldn’t work for an IoT device).

The certificate has a variety of pieces of information – including 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., and, critically, its structure means that someone can tell if someone else has monkeyed with it in order to fake an identity. (We’ll look more at how to do that in an upcoming discussion of attestation.)

What we’re going to look at now is a simplified version of what’s called a TLSTransport Layer Security. A very common internet security protocol. You can think of it as an updated version of SSL, although both are still used. Used with TCP on Layer 4 of the stack. handshake. If you look carefully at the messages going by near the bottom of your browser as it connects, you might see, “Performing TLS handshake” (or something similar). Cuz that’s what’s happening. TLS is a common security protocol (whose ancestor was SSLSecure Sockets Layer. A common internet security protocol. TLS is a more recent version of this, but SSL is still used. Works with TCP on Layer 4 of the stack., which you might have heard of). There are other protocolsAn agreed way of doing something. Like a convention, except that protocols tend to be related to processes.; our point here isn’t to learn TLS specifically, but to see how this stuff tends to work – even with variations.

Making Introductions

So when you first connect to the web, your browser sends a message to the web serverA server whose purpose is to receive requests for web pages and then send those pages out to the requestor. with the certificate, which has the public key. That message goes “in the clear” or in “plain text” – that is, it’s not encrypted. But there’s nothing in the message that’s confidential, so it’s fine. You’re saying, “Hey, this is me, here’s my public key. Please encrypt everything from now on with this key.”

The website responds by sending its certificate and public key, and your browser will encrypt all the next messages with that key. Now that you’ve both got keys for encrypting, you want to make sure that no one else is interfering in this whole thing, pretending to be one of you. Presumably, only you have your private key and only the website has its private key.

What Could Go Wrong??

So you send each other a challenge: a random number that’s encrypted with the public key. Let’s say the website sends you a random number encrypted with your public key. Only you can decrypt it with your private key, which no one else has. If someone decrypts it with a different key, they’ll get a number, but it won’t be the right one.

So the next part is where you re-encrypt that number with the website’s public key and send it back. The website will decrypt the number with its private key. If all the keys are legitimate, then the website will get back the original number it sent. If the first version of the random number is decrypted with the wrong key, you’ll have the wrong number, and, even if you encrypt it with the website’s public key, you’ll be encrypting the wrong number, and the website will see that.

On the other hand, if the number gets re-encrypted with the wrong public key – say, by someone other than you – then the website’s private key won’t work properly. It will get a result, but not the right one. This is how you prove that you’re each who you say you are.

That’s So Random – Hopefully

The random number thing is important. It has to be a large number – hard to guess – and there’s one more important trick: each random number can be used only once. Why? This gets into all the million scenarios that security experts have to think through. What if someone sits there watching this successful exchange between you and the web server? They could record all the back-and-forths and then replay that whole thing to try to get in themselves. By allowing the random number to be used only once, then that replay will fail – because it’s using the recorded random number, which has already been used once.

The following diagram illustrates this handshake. This is typical of the kinds of drawings used to illustrate such interactions. On one side is you and your browser (or it could be an IoT device); on the other is the website’s server (or an IoT server). Each arrow is a message of some sort, and it progresses in time from top to bottom.

When an IoT device connects to the cloudA generic phrase referring to large numbers of computers located somewhere far away and accessed over the internet. For the IoT, computing may be local, done in the same system or building, or in the cloud, with data shipped up to the cloud and then the result shipped back down., it’s going to do some version of this. The details may vary, but you get the gist. Hopefully.

This completes this simple version of authentication. But it may not be the last we see of that random number. We look at that next.