Aspects of computer security: Privacy and Integrity

This is the fourth post in the series about computer security. Today, the topics are

4. Privacy — Are communications and data safe from unauthorized viewing?

5. Integrity — Are communications and data safe from unauthorized modification?

Again, I’m grouping two together because they’re closely related. In this case, they both deal with situations where an attacker gets into the middle of the data stream. In the first case, the attacker is just snooping; in the second, the attacker is trying to modify or replace the data. The attacks are similar, but have different characteristics and different consequences.

When you send a password, a credit-card number, or other personal information over a computer network — and especially over an open network like the Internet — there’s a possibility that someone might be “listening in”. We think of information being sent from one computer to another, but it’s not actually quite that way. There’s a significant degree to which networks actually are segmented, but at some level your data goes out to a set of computers, with the address of a specific one attached to it, and the other computers all ignore those data packets that aren’t addressed to them. Imagine that your postal mail were delivered by having the whole pile for your street left at the door of the first house, and the occupant of each house looked through the envelopes and kept those meant for him, giving the rest of the pile to the next house. It’s somewhat like that.

And in that situation, someone could choose to keep a piece of mail meant for someone else, or could open one and read it before passing it on. The same is true with the network: a computer could be programmed to look at and record data intended for other systems.

The most common way to avoid that is to use data encryption, which can be done at the network layer, using IPsec, on top of the transport layer, using TLS or SSL, or at the application layer, using standards such as S/MIME (for email).

When you visit a web site whose URL begins with https://, your communication with that web site is encrypted using TLS or SSL. The web browser ensures that the computer you’re talking to has a security certificate that matches the address in the URL, and then negotiates encrypted communication. The data packets can still be peeked at and recorded by a computer that’s programmed to do that... but the data will not be decipherable by the snooper, and will be useless.

Similarly, if a snooper should try to replace or modify the data you’re sending — say, to change a $20 payment to $2000 — that would not work if you’re using encrypted communication, because the attacker wouldn’t be able to modify the encrypted information in a valid way.

Encrypting the entire communication, though, is fairly expensive, and slows down the communication. That’s why we don’t encrypt everything on the Internet: there’s little need to encrypt the information you get from Wikipedia, from the New York Times, or from this blog. And so most information flowing on the Internet is not encrypted.

There are times, though, when it’s not important to protect information from prying eyes, and the likelihood of its being altered by an attacker is small... but it’s important enough that we want to know if it has been altered. In that case, we don’t need to prevent the alteration, but we do need to detect it. For that, we can use digital signatures.

I did a whole series on digital signatures over a year ago, starting with this post, so you can review that if you’re interested. The short version is that digital signatures provide a mechanism for ensuring that the information was actually sent by who we think sent it, and that it wasn’t altered along the way. Otherwise, we know something is wrong... we don’t know how to correct it, but we know to ignore the faulty data.