People buy things online all the time. They trust the Internet security mechanisms that have been put in place and believe a little gold icon in the corner of the web browser equals security. What most people don't do is stop and think "gee, how does a little gold icon equate to security?"
So this wonderous blog entry shall take you through the world of "modern" security, how it works, and then how easily it can be broken. I'll also share some interesting tidbits of information and form an interesting connection that no one else has made that is worth thinking about. Just so you know in advance, I still trust the technology and make purchases online, but it is something that has nagged me for some time now.
People have been making stuff "secure" for a really long time. Other people have been trying to break security for just about as long - mostly so they could steal whatever was being made secure. Only in recent years has a third group formed. This third group of people try to break security only to make things more secure. The third group is considered to be a "gray" area and is loaded down with controversy. I'd like to think this blog entry classifies as none of the above groups and is merely a different perspective.
Anywho, security has been around a really long time. The earliest documented case to date of information being encoded/encrypted is Julius Caesar's Caesar cipher:
http://en.wikipedia.org/wiki/Information_security
http://en.wikipedia.org/wiki/Caesar_cipher
The Caesar cipher was a relatively simple encoding that involved shifting the letters of the alphabet 'x' positions. We laugh at the simplicity of this today given the sheer amount of technology at our disposal but, back then, it had to be an arduous process to encode and decode messages and the secrecy of how the encoding worked made messages appear to be gibberish.
Even as recent as World War II, cryptographic algorithms had to be kept secret. For if the knowledge of how the algorithm worked became public knowledge, the algorithm would be broken and all messages would be able to be read. An example of this was:
http://en.wikipedia.org/wiki/Enigma_machine
Jumping to today: All cryptographic algorithms in use today are known and published works that have been analyzed by both the second and third groups I talked about. Yet we remain secure and purchase things online using these algorithms. How is this possible? Introducing:
http://en.wikipedia.org/wiki/Public_key_cryptography
Public key cryptography. I'm not going into the math behind the concept but if you read the above page, you'll see mentions of "Alice" and "Bob". Think of "Alice" as your web browser and "Bob" as the website (web server) you are talking with. If you are the sort of person who needs a specific example, let's pick Amazon.com's purchasing system to be Bob. Most people are familiar with that site.
How public key cryptography works has been repetitively dumbed down so people like me can understand it. Simply put: Alice and Bob each have public and private keys. Their private keys are in their separate rooms. They both exchange their public keys in sight of everyone. Alice then goes to her room and encrypts a message using Bob's public key and then encrypts the result with her private key. She then leaves her room and publicly hands the encrypted message to Bob. He goes to his room and decrypts the message using Alice's public key and then his private key.
The most complex part of this is understanding that public and private key pairs have to be generated in such a way that you can't decipher what the private key is based on the public key. From here on is where most people launch into a tirade of how the math works. But since most people don't like math, I won't bother with the details. Just suffice it to say that it works as long as both private keys are kept secret.
When it comes to web browsers (i.e. Alice), though, you probably aren't aware of any private keys you have. That would be because you don't have any. At least not at first. You probably have noticed that it takes a while to connect to a secure website but after the initial delay, navigation goes relatively quickly. Well, part of that delay is your computer generating a private and public key pair to use to contact the website (i.e. Bob). Generating these keys can take up to 15 seconds plus a lot of CPU and they are usually generated every time you visit the site.
But here is where things get tricky. A lot of thought has gone into how the fictional Alice and Bob communicate with each other. The problem is this: Most discussions about Alice and Bob are how they know each other personally and trust each other implicitly. But if Alice is a web browser and Bob claims to be Amazon.com, how does Alice know that she can trust that Bob is actually Bob on the big bad Internet and not someone who has surreptitiously made himself to merely look like Bob?
http://en.wikipedia.org/wiki/Public_key_infrastructure
Public Key Infrastructure, or more commonly, PKI, is a fancy phrase for saying, "Use a third-party to validate the public and private keys". That is, someone other than Alice or Bob validates that the message came from Bob because both Alice and Bob trust the person/organization who signed Bob's certificate:
http://en.wikipedia.org/wiki/Public_key_certificate
That is about the most concise definition of a certificate I've seen to date. Since I can't say it better than that, visit Wikipedia.
So what's wrong with all this? It sounds all wonderful and like it actually works. The problem begins with deciding who to trust as the Certificate Authority (CA). Over 50% of the certificates issued each year come from Verisign and Thawte (also owned by Verisign). That means a LOT of trust is riding on Verisign - a commercial company. But they are fairly responsible with the trust given to them despite their commercial interests.
In general, the entire system is quite secure. So where's the problem?
The problem lies with Verisign's private key. Whoever has that key can generate certificates that are automatically trusted by any web browser. From what I understand, most trusted CAs use a non-networked computer with a single serial line that is dedicated solely to generating signed certificates. I have one question: What happens if the Verisign private key falls into the "wrong hands"? It isn't inconceivable to then create, say, a man-in-the-middle attack for Amazon.com (Bob) or your online bank and capture all the information in plain-text without you knowing about it. Digital security is one thing, but Verisign doesn't tell us how secure the physical security is. But if Verisign is secure physically (i.e. you couldn't get the private key guns a-blazin'), that doesn't mean other trusted CAs won't have weaker security.
Every web browser has a list of trusted root certificates. After this blog entry, I wouldn't want to work for any of those companies.
The physical route might be too obvious. ("Hmm...I wonder why they were only after the only computer that had just happened to have our most critical private keys on it that we use to just sign digital certificates with and nothing else?") Trusted keys in browsers would get changed and everything would be secure again. Even then, it may be possible to not actually have to do that. What if someone figures out a way to reverse-engineer a private key? Most certificates expire and have to be renewed annually, which makes reverse-engineering the private key of individual websites infeasible. However, trusted CA root certificates expire anywhere from 2020 to 2037. It may be possible to reverse-engineer a CA private key from a set of signed certificates and using a guesstimate of the rough date and time of when the CA generated their private key and what software package they might have used to generate the key. That is, re-create the private key they use. Given that there is a LOT of time between now and when the first major (most widely used) CA certificates expire, this may be a feasible route - and a lot harder to figure out "whodunnit".
It is interesting to note that the export laws concerning cryptography and cryptographic algorithms are now fairly relaxed. This is the interesting connection I wanted to make:
http://www.financialcryptography.com/mt/archives/000206.html
Verisign can issue certificates to the government that can be used for "wiretapping" purposes. That is, the government can spoof Amazon.com without prior permission should they choose to do so. Granted, a subpoena is required, but aren't that difficult to get if you have the right credentials. If the government can wiretap with Verisign signed certificates, then that means anybody could do that for any website if they had Verisign's private key.
If my second conjecture is correct - that is, the possibility of reverse-engineering the private key given the ability to roughly guess certain parameters and letting the computer brute-force the rest - that may be another explanation for the relaxing of export law in cryptography. That is, if the government already has the ability to do so and someone has figured out how to see 90% or so of transmitted data that has been encrypted as plain-text. Some people should find it odd that an increasingly controlling government would relax something like cryptography export law unless they already knew something the rest of us don't (i.e. the law didn't matter anymore).
At any rate, I'm not too concerned, but I do keep the stuff I do on the Internet that requires security (e.g. purchases) to a minimum.
By the way, the idea of physically obtaining Verisign's private key could make for one-third of a cool action movie - probably along the lines of National Treasure - assuming they made it as accurate as possible (National Treasure did actual research on how someone would go about stealing the Declaration of Independence). The other two-thirds of the movie would involve simultaneously breaking into major Internet eXchange Points (IXPs) worldwide (fairly secure facilities - from what I understand, a few are really deep underground) to utilize the newly acquired private key (probably would configure their setup to route specific traffic - e.g. Amazon.com secure web traffic - through an attached proxy for the ultimate man-in-the-middle attack). What happens after that is probably bad - ranging from identity theft to economic collapse. But since no one reads this blog (i.e. no more than five people), it is highly unlikely to come to the attention of Hollywood's script writers and therefore we won't have a cool movie made that has the nifty geek-factor in it. Then again, there aren't many of those movies made anymore. Either because Hollywood doesn't cater to geeks or the script writers hate having the details poked at by the geeks. I'd watch the movie though - it would likely be fun and entertaining.
So this wonderous blog entry shall take you through the world of "modern" security, how it works, and then how easily it can be broken. I'll also share some interesting tidbits of information and form an interesting connection that no one else has made that is worth thinking about. Just so you know in advance, I still trust the technology and make purchases online, but it is something that has nagged me for some time now.
People have been making stuff "secure" for a really long time. Other people have been trying to break security for just about as long - mostly so they could steal whatever was being made secure. Only in recent years has a third group formed. This third group of people try to break security only to make things more secure. The third group is considered to be a "gray" area and is loaded down with controversy. I'd like to think this blog entry classifies as none of the above groups and is merely a different perspective.
Anywho, security has been around a really long time. The earliest documented case to date of information being encoded/encrypted is Julius Caesar's Caesar cipher:
http://en.wikipedia.org/wiki/Information_security
http://en.wikipedia.org/wiki/Caesar_cipher
The Caesar cipher was a relatively simple encoding that involved shifting the letters of the alphabet 'x' positions. We laugh at the simplicity of this today given the sheer amount of technology at our disposal but, back then, it had to be an arduous process to encode and decode messages and the secrecy of how the encoding worked made messages appear to be gibberish.
Even as recent as World War II, cryptographic algorithms had to be kept secret. For if the knowledge of how the algorithm worked became public knowledge, the algorithm would be broken and all messages would be able to be read. An example of this was:
http://en.wikipedia.org/wiki/Enigma_machine
Jumping to today: All cryptographic algorithms in use today are known and published works that have been analyzed by both the second and third groups I talked about. Yet we remain secure and purchase things online using these algorithms. How is this possible? Introducing:
http://en.wikipedia.org/wiki/Public_key_cryptography
Public key cryptography. I'm not going into the math behind the concept but if you read the above page, you'll see mentions of "Alice" and "Bob". Think of "Alice" as your web browser and "Bob" as the website (web server) you are talking with. If you are the sort of person who needs a specific example, let's pick Amazon.com's purchasing system to be Bob. Most people are familiar with that site.
How public key cryptography works has been repetitively dumbed down so people like me can understand it. Simply put: Alice and Bob each have public and private keys. Their private keys are in their separate rooms. They both exchange their public keys in sight of everyone. Alice then goes to her room and encrypts a message using Bob's public key and then encrypts the result with her private key. She then leaves her room and publicly hands the encrypted message to Bob. He goes to his room and decrypts the message using Alice's public key and then his private key.
The most complex part of this is understanding that public and private key pairs have to be generated in such a way that you can't decipher what the private key is based on the public key. From here on is where most people launch into a tirade of how the math works. But since most people don't like math, I won't bother with the details. Just suffice it to say that it works as long as both private keys are kept secret.
When it comes to web browsers (i.e. Alice), though, you probably aren't aware of any private keys you have. That would be because you don't have any. At least not at first. You probably have noticed that it takes a while to connect to a secure website but after the initial delay, navigation goes relatively quickly. Well, part of that delay is your computer generating a private and public key pair to use to contact the website (i.e. Bob). Generating these keys can take up to 15 seconds plus a lot of CPU and they are usually generated every time you visit the site.
But here is where things get tricky. A lot of thought has gone into how the fictional Alice and Bob communicate with each other. The problem is this: Most discussions about Alice and Bob are how they know each other personally and trust each other implicitly. But if Alice is a web browser and Bob claims to be Amazon.com, how does Alice know that she can trust that Bob is actually Bob on the big bad Internet and not someone who has surreptitiously made himself to merely look like Bob?
http://en.wikipedia.org/wiki/Public_key_infrastructure
Public Key Infrastructure, or more commonly, PKI, is a fancy phrase for saying, "Use a third-party to validate the public and private keys". That is, someone other than Alice or Bob validates that the message came from Bob because both Alice and Bob trust the person/organization who signed Bob's certificate:
http://en.wikipedia.org/wiki/Public_key_certificate
That is about the most concise definition of a certificate I've seen to date. Since I can't say it better than that, visit Wikipedia.
So what's wrong with all this? It sounds all wonderful and like it actually works. The problem begins with deciding who to trust as the Certificate Authority (CA). Over 50% of the certificates issued each year come from Verisign and Thawte (also owned by Verisign). That means a LOT of trust is riding on Verisign - a commercial company. But they are fairly responsible with the trust given to them despite their commercial interests.
In general, the entire system is quite secure. So where's the problem?
The problem lies with Verisign's private key. Whoever has that key can generate certificates that are automatically trusted by any web browser. From what I understand, most trusted CAs use a non-networked computer with a single serial line that is dedicated solely to generating signed certificates. I have one question: What happens if the Verisign private key falls into the "wrong hands"? It isn't inconceivable to then create, say, a man-in-the-middle attack for Amazon.com (Bob) or your online bank and capture all the information in plain-text without you knowing about it. Digital security is one thing, but Verisign doesn't tell us how secure the physical security is. But if Verisign is secure physically (i.e. you couldn't get the private key guns a-blazin'), that doesn't mean other trusted CAs won't have weaker security.
Every web browser has a list of trusted root certificates. After this blog entry, I wouldn't want to work for any of those companies.
The physical route might be too obvious. ("Hmm...I wonder why they were only after the only computer that had just happened to have our most critical private keys on it that we use to just sign digital certificates with and nothing else?") Trusted keys in browsers would get changed and everything would be secure again. Even then, it may be possible to not actually have to do that. What if someone figures out a way to reverse-engineer a private key? Most certificates expire and have to be renewed annually, which makes reverse-engineering the private key of individual websites infeasible. However, trusted CA root certificates expire anywhere from 2020 to 2037. It may be possible to reverse-engineer a CA private key from a set of signed certificates and using a guesstimate of the rough date and time of when the CA generated their private key and what software package they might have used to generate the key. That is, re-create the private key they use. Given that there is a LOT of time between now and when the first major (most widely used) CA certificates expire, this may be a feasible route - and a lot harder to figure out "whodunnit".
It is interesting to note that the export laws concerning cryptography and cryptographic algorithms are now fairly relaxed. This is the interesting connection I wanted to make:
http://www.financialcryptography.com/mt/archives/000206.html
Verisign can issue certificates to the government that can be used for "wiretapping" purposes. That is, the government can spoof Amazon.com without prior permission should they choose to do so. Granted, a subpoena is required, but aren't that difficult to get if you have the right credentials. If the government can wiretap with Verisign signed certificates, then that means anybody could do that for any website if they had Verisign's private key.
If my second conjecture is correct - that is, the possibility of reverse-engineering the private key given the ability to roughly guess certain parameters and letting the computer brute-force the rest - that may be another explanation for the relaxing of export law in cryptography. That is, if the government already has the ability to do so and someone has figured out how to see 90% or so of transmitted data that has been encrypted as plain-text. Some people should find it odd that an increasingly controlling government would relax something like cryptography export law unless they already knew something the rest of us don't (i.e. the law didn't matter anymore).
At any rate, I'm not too concerned, but I do keep the stuff I do on the Internet that requires security (e.g. purchases) to a minimum.
By the way, the idea of physically obtaining Verisign's private key could make for one-third of a cool action movie - probably along the lines of National Treasure - assuming they made it as accurate as possible (National Treasure did actual research on how someone would go about stealing the Declaration of Independence). The other two-thirds of the movie would involve simultaneously breaking into major Internet eXchange Points (IXPs) worldwide (fairly secure facilities - from what I understand, a few are really deep underground) to utilize the newly acquired private key (probably would configure their setup to route specific traffic - e.g. Amazon.com secure web traffic - through an attached proxy for the ultimate man-in-the-middle attack). What happens after that is probably bad - ranging from identity theft to economic collapse. But since no one reads this blog (i.e. no more than five people), it is highly unlikely to come to the attention of Hollywood's script writers and therefore we won't have a cool movie made that has the nifty geek-factor in it. Then again, there aren't many of those movies made anymore. Either because Hollywood doesn't cater to geeks or the script writers hate having the details poked at by the geeks. I'd watch the movie though - it would likely be fun and entertaining.
Comments
Post a Comment