If a server proves its bona fides by presenting its public key, and its public key is public, what prevents a bad actor from getting the public key and pretending to be the original? Is the server’s public key tied to a particular IP address or domain so that the client should check that? Or is a third-party certificate required to prove the server’s bona fides? How about the client’s public key? What prevents a bad actor from pretending to be the owner of that public key?
In: Technology
Encryption is based on one way processes. A simple example – say your public key is 299. I use the number 299 to encrypt something in a way that can only be unencrypted with your private key – which I don’t know, but it is related to 299 (it is the factors – 23 and 13). To find the factors and break the code is hard – I need to divide 299 by every number less than its square root. But, having the private key, You can calculate the public key very quickly – it is a single multiplication. Now in reality the private key is a much larger product of two prime numbers – a number so big it would take years to find the factors.
So – I encrypt with the public key a code phrase “where does it rain in Spain”. you get the message and decrypt with the private key. You then use your private key to answer “mainly on the plain”. I get your answer and decrypt it with the public key – which anyone could do – but the fact your public key works proves that You and only You could have answered me, and answering my specific code phrase proves you are who i intended to be talking to – the package was not intercepted and fake answer entered into the stream. Then, we repeat the process in reverse to prove I am to you – and then we can start talking.
The shared key exchange is only used to establish encryption. The server doesn’t really care who you are, only that the communications are encrypted. It does not prevent the man in the middle (MITM) attack, where someone sits in the middle passing keys back and forth between the two and reading all of the information passed.
However, public key infrastructure allows us to have TLS (transport layer security), which is the security layer of https (web sites). You have root certificates on your computer, and the server has a certificate derived from one of those roots. Thus, you know the server is what it says it is. Usually that’s all that’s needed, they don’t care who is connecting, you care who you are connecting to.
Going more secure, you could set it up so you both have certificates so you both have a verified identity.
This of course requires you both have the same root certificates on your machines. For example, if you go to some secure Army web sites you might get a certificate error because the military certificate (DOD Root) isn’t installed on your computer.
First, a bad actor can’t do anything with someone else’s public key. That public key encrypts things in a manner that only the server’s *private* key can decrypt. This means that when you encrypt something with somebody’s public key, you know that the holder of their private key, which is very protected, is the only one who can read it.
Second, in many implementations of public key cryptography, part of the data in the key is locked to a particular domain. The application knows that if you go to www.reddit.com, but they offer a public key for example.com to not trust it, since the domains do not match.
This is indeed a security issue, which is why we don’t just take “official” public keys at face value. SSL certificates are our solution. You go to a trusted third party and say “Hello. I am the owner of Reddit.com. I intend to host my website at these IP ranges. This is the public key I intend to use. Can I have a certificate for this please?”.
The SSL authority verifies your claim and approves the certificate.
When a client goes to you in the future and you let them have your public key you also go “BTW, this is my SSL certificate proving this public key belongs to me. It has been signed by that person over there”. Either you trust that person and go “Oh, all right! 😀 ” or you don’t, in which case you go to that person and say “I don’t know you. Who are you?”, and the SSL goes “I am Bob inc. Big Company LLC can vouch for me!”. Either you trust Big Company LLC or not, and the cycle repeats. Eventually you will reach someone you trust because your browser / device came with a predefined list of the biggest SSL providers that it will trust by default.
The client’s public key is less important because it will be included in the first request to the server which is encrypted and a shared secret encryption key is the first thing a TSL handshake does.
The whole point of public/private key pairs is that either one can encrypt messages that then require the other to decrypt.
This means you can prove you know the private key by either reading and responding correctly to challenges encrypted with the public key, or by sending challenge responses encrypted with the private key that decrypt correctly when the challenger uses the public key to decrypt them.
Using this kind of challenge, the parties can make sure they are talking to someone who knows the private key corresponding to the public key they have on file. Certificates are useful for making sure that the people you think you’re talking to actually published that public key.
The verification process does not consist of a simple comparison of the public key. There is a mathematical algorithm which allows someone with a private key to create a signature for some data and then someone with the public key can verify this signature. If you only have the public key you can not create the signature. During the connection handshake the client and server both sign some of the important parameters in the connection such as the encryption key they have decided to use. The other part is then able to verify that whomever they talk with is the one in possession of the private key that they have the public key for.
Latest Answers