Public Key encryption

Question

This is the way I understand how the public key work...Let's say you are on a website and you access the credit card for page. You then encrypt the packet with the public key of that site and the send it over to them. The site then decodes the packet using the corresponding private key. So that part I understood.

Now, how about when I'm accessing an authenticated page. Let's say I'm accessing my bank account page. How do the website encrypt the packet that is destined for me. How do I open it and how do I know that someone along the way has not read it.

Answer 1

That's quite a big question =) The below is a high-level overview of HTTPS; shout up if anything isn't clear and I'll fill in more details.

When you use an HTTPS connection, public key crypto is only used during session initialisation. Part of that initialisation is the secure swapping of a private, shared key that is then used for symmetric encryption. The reason for this is that asymmetric (public key) encryption is significantly slower than symmetric key encryption, due to the maths involved.

SSL handshake

At a very high level, the protocol goes something like this:

1. Client sends initial "HELLO" message, that contains the ssl version it would like to use, a pseudo-random string of bits (let's call that B1) and a list of the various ciphers it supports.

2. The server responds with with its own "HELLO" message, another pseudo-random string of bits (let's call that B2), the cipher it has selected (normally the strongest cipher from the list the client sent that the server supports), and its certificate which contains its public key (let's call that k).

3. The client then uses the certificate to authenticate the server (see below) and creates a "premaster secret" - another string of pseduo-random bits that we'll call S.

4. If the client is happy with the results of server authentication, it encrypts the premaster secret S with the server's public key k, and sends it to the server (S itself is encrypted, but the connection is still not).

5. At this point, the server and client share three strings of bits - B1, B2 and S. B1 and B2 were sent in the clear - S was encrypted, and so, assuming the server's private key really is private, is known only to the client and server.

6. Both client and server then use these three bit strings to construct the session key - a string that is known only to them, and can be used as a key in the previously selected symmetric cipher.

7. Client and server then exchange messages that indicate they are changing protocol, and all subsequent messages are encrypted (symmetrically, with the key computed above).

Server authentication

When the client receives the server HELLO message, it needs to be sure that it is talking to the server it thinks it is. The server cert and key are used to establish this trust.

All a digital certificate is is a third party asserting "this entity holds the private key that corresponds to this public key, which is embedded in this certificate". Organisations like Verisign will make this assertion - for a price. The reason people pay Verisign and others for certs is that Verisign have gone to the trouble of getting their intermediary certs embedded in most of the common browsers.

So, when the client receives the server HELLO, it will perform the following checks:

• Does today's date fall within the certificate's validity period?
• Does the subject name of the certificate match that of the server I am trying to connect to?
• Does the Issuer name on the certificate match any of the CAs whose public keys I know about?
  • If so does the public key I have for this CA validate this certificate?

If all those checks pass, the client assumes it can believe that the server is who it was expecting. It then takes the public key (still k) out of the cert, and uses it to securely transmit S to the server. At this point, the idea is that you have some third party's (Verisign's) assertion that the public key belongs to the server; so only the server will be able to decrypt the result of E(S,k), and hence only the server can produce the matching key that you'll use for the symmetric cipher.

After the handshake, your confidence that the packets cannot be read by a third party should be equal to your confidence in the symmetric algorithm that's being used.

(There are other nice twists - eg the reason three bit strings are used is to prevent replay attacks. If only S was used, an attacker could record the entire session and replay it at leisure - for example, repeating a money transfer instruction over and over. By having both client and server generate additional pseduo-random strings, you greatly reduce the likelihood of two independent SSL handshakes producing the same S.)

Answer 2

It's simpler than that, actually.

Public keys are public. Anyone can see them, anyone can use them...But they're only one way. Something encrypted with your public key can only be DEcrypted with YOUR private key.

So, in your example, what happens is that you send packets to the bank that are encrypted with the public key that belongs to the bank, and the bank sends back packets that are encrypted with YOUR public key. Only you can read what the bank sends you, and only the bank can read what you send the bank. Even if you encrypt it using their public key, you can't read it. You can only read the packets if you have the corresponding private key.

Assuming that the private keys are indeed private, no one can read your packets without cracking the private key.

Now, the caveat is the "Man in the Middle" attack. This is where a proxy or relay site sets up in between you and the person you think you're talking to, and tricks you into accepting their public key in lieu of the key of the site you think you're visiting. So you send packets to them, encrypted with their public key, which they then read, reencrypt using their public key, and forward on to the site, who then sends them packets that they read, and then forward to you.

Answer 3

Simple answer: The exact same way.

Suppose A can send data securely to B but B can only send data insecurely to A. All you have to do is have A make up a random key and send it securely to B. Now B can encrypt data with that random key, send it to A, and it is secure.

So if you have a bidirectional link that is only secure in one direction, it is trivial to make it secure in both directions.

Answer 4

You know who the bank is because your browser recognizes their certificate as valid. But how does the bank know it's you? The answer is that it does not, at least not from SSL. Your browser MAKES a private key PER SESSION. This private key means nothing to the bank, because you could still be anybody. However, that private key does give you a secure connection. Since you trust the bank's website, you log in using the secure connection, and at that point it knows that you are you, and that the session is secure for data about you.

The bank encrypts data for your browser using the public key the browser gave it when the session started, and you encrypt stuff for the bank using their public key. The process is the same in both directions, essentially, once you establish identity.

Answer 5

In both cases, you use the web site's (shopping site or bank) public key to negotiate an encryption key for the current session. This encryption key is used to encrypt all communication after that. It is not an asymmetric key (not a public-key-private-key-pair), it is a "regular" secret key that is shared between your browser and the site (and will be destroyed when you close the window).

The reason to use public key encryption only to transmit the secret key is that it is much faster to do symmetric encryption. It is also equally secure. And, as you have pointed out, only one side needs to have a public key.

In fact, the only reason that the web-site needs to have a public key at all, is so that you can be sure who you are talking to. It prevents man-in-the-middle attacks. For the purposes of keeping the connection secure from eavesdroppers, that is not strictly necessary. In fact, many web sites use public keys that are self-signed (as opposed to certified by a registration authority) for SSL. In this case, you cannot really be sure that the other party really is who they claim to be, but you can be sure that no third party can listen in.

Answer 6

Your question is a bit generic. What exactly are you looking for?

• protocol implementations (how do I open an encrypted packet)
• mathematical details (how do the website encrypt the packet that is destined for me)
• secrurity issues (the 'man in the middle' attack)

Have you read the related wikipedia entry?

Answer 7

There's two types of ciphers being used here. There's the public key (asymmetric) type, and the more common shared-key (symmetric) type. The symmetric ciphers are much more efficient, since there aren't many ways to set up a public key cipher.

Therefore, you use the public key to make contact. Your browser can then encrypt a shared key with the site's public key, and only that site can receive the shared key. Then your browser and the website communicate with a standard cipher. The key is normally discarded at the end of the session. Therefore, as long as everything goes correctly, your communication is secure.

There's also the question of making sure who you're talking to. For this purpose, the website has a certificate, which is an attestation from a certificate authority that you're talking to whoever asked for the certificate. The certificate authorities are loaded into your browser when you get it, and any certificate signed by one of those will be accepted by your browser. Some authorities offer higher-priced certificates that will show up in your browser as green, and those have been more carefully verified by the certificate authority in question.

I'm not saying this is the best way to do this. For example, I'd like to see a warning when you get a different certificate for the same website, a warning that's often used in other applications of public key crypto. I don't think the Firefox warning for a self-signed certificate is appropriate (which indicates a site that used public key crypto without buying a certificate), since it makes those sites look less trustworthy than an unencrypted connection.

(I'm not going into the technical details here, but it's a reasonably straightforward application of public key ciphers and cryptographic hashes. A hash is a method of reducing a file or something to a fixed-lengh identifier, so that two files are unlikely to have the same value. A cryptographic hash is one where it's really difficult to make two files with the same hash value.)