Hashing and Digital Signatures

[From the last episode: We looked at authorizationThe process of deciding what privileges – if any – someone gets on a network, server, or other asset. – the permissions that different people or things have to see things on the networkA collection of items like computers, printers, phones, and other electronic items that are connected together by switches and routers. A network allows the connected devices to talk to each other electronically. The internet is an example of an extremely large network. Your home network, if you have one, is an example of a small local network..]

Let’s say that your IoTThe Internet of Things. A broad term covering many different applications where "things"  are interconnected through the internet. device sends a message 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.. Let’s say it’s a refrigerator, and it’s sending the message that you’re out of milk. Perhaps this message would trigger messages from the server to milk providers so that they can send you ads or deals on milk. But one of those suppliers wants all the business, so they found a way to intercept that message and change “milk” to “broccoli.”

Now they’re the only ones who know that you need milk. Everyone else thinks you need broccoli. So you get tons of broccoli ads, but only ads from one milk company. And, frankly, since they’re not competing, they’re not really offering you deals. As far as you can tell, they’re the only game in town, and, if you don’t want to get up and go to an actual store, then you’ll order only from them at the price they set.

Has the Message Been Altered?

In this case, someone has intercepted and changed the message between your fridge and the server. How can the server know for sure that the message they received is exactly the same one you sent? If your first answer is, “Because it’s encrypted and no one should have the password,” that’s not a bad answer. And it’s probably mostly true. But what if it’s not?

This is where digital signaturesAn encrypted digest that can be appended to a message or sent separately from the message. come in, and they involve the notion of a hash. In everyday use, to hash something means to chop it up and mix it – like corned beef hash. And that’s kind of what an electronic hash is like: you take a message and chop it and mix it. Let’s take a simplified example: we’ll create a simplistic hash of the phrase, “Four score and seven years ago”. I’m going to make up a hashingA way to combine the contents of a message to generate a value that is almost unique to that message. algorithm here that will be easy to understand – but there’s a catch, as we’ll see.

• Let’s take that phrase – 30 characters (including spaces) – and break it into 10-character chunks. That gives us three chunks: “Four score”, “ and seven”, and “ years ago”.
• Now we’ll take all of the ASCIIAn older way of representing characters (letters, numbers, and punctation) in computers. It could handle only characters relevant to English and languages using those characters. It has mostly been replaced by Unicode, which can represent all the world's characters. values for those letters and spaces and add them together. That sum is: 2823.
• Now we’ll divide by the number of chunks, which is 3. In this case, the answer is: 941. So we’re hashing that text into the value 941.

The result of our hashing operation – in this case, 941 – is called a digestThe result of a hashing operation..

We can then attach this number to our message and send “Four score and seven years ago 941”. OK, that would be confusing since the receiver couldn’t be sure where the message ended and the hash began, so let’s say we use a special character “|” to separate one from the other. So we send “Four score and seven years ago|941”.

Checking the Hash

If someone intercepted that message and changed “Four” to “Five,” the receiver would know. How? Because it would do the math and come up with an answer different from 941. That’s the basic idea of a hash.

But this hash is horrible. It simply adds values of characters. So “Four score”, “score Four”, and “coreThis can have more than one meaning. When discussing networks, the core is the heart of the network where much of the traffic (or at least that part that has to go a long ways to its destination) moves. This is in contrast to the edge -- the outer part of the network where devices like computers and printers get connected. When discussing computers, you can think of it as the same as a CPU. sFour” would all add to the same number because they all use the same characters. In other words, there are tons of ways to keep the hash value the same. So you could catch some changes, but there are many you’d never catch. Which makes this a really bad hash algorithm.

True hash algorithmsA 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. are much more complicated. Yes, it is possible for two different messages to end up with the same hash value, but it’s much, much more unlikely. Accepted algorithms are carefully vetted by experts to guard against this kind of thing.

OK, so we have a way to show that the message has been changed. But, in our example, we just sent the hash value in the clear. So an interloper could change the message – and then change the hash value to reflect the new message. That’s no good!

One way of handling this would be to separate the message from the hash value, sending the value in a separate message or even by another mode, like by email or text. That would make it harder for the interloper, but not impossible.

Encryption – with a Catch

So what if we encrypt the hash value? Then it would be hard to monkey with. But there’s a problem: let’s say we’re using PKIA system of mathematical algorithms for public and private keys as well as certificates of authority that are used when authenticating a web session., and you encrypt with the server’s 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., just like with any message? Well, anyone knows the public keyA 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. – it’s public, after all. So if someone wanted to change the hash value, they could make the message changes, create a new digest, and encrypt the new digest with the public key – and the server would never know.

Yeah, you’re right: they weren’t able to decrypt the old digest. But who cares what the old digest was? They’re just going to throw that away and replace it with the modified – and newly encrypted – digest.

So we’re going to turn things around from what we said about 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. before. In this case, we’re concerned less about protecting the number itself from being read; we’re concerned about making sure that only the original sender can encrypt it properly. And that means encrypting it with the sender’s private keyA 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. – not the receiver’s public key. Yeah, that’s backwards. But no one else has the private key (hopefully), so no one else can encrypt the value properly.

At the receiving end, the way the key math works, the receiver can decrypt the value using the sender’s public key. Again, backwards. This means that anyone could decrypt the value and read it using the public key, which anyone can see. But, as we saw above, who cares if someone sees the hash value? That’s not revealing a secret. The point is that, if someone tries to change the hash value, they don’t have the private key they need to re-encrypt an altered value.

This encrypted hash becomes the digital signature.

Yes, these scenarios all assume that something somewhere along the way is broken, that someone got into the message, or something. It’s yet another backstop.