3

This question already has an answer here:

I am trying to understand how SSL uses PKI and Digital Signature authentication to ensure secure and verified communications. I've read various sources online and from what I can tell the basic process is:

  1. A Server is given a Certificate from a Certificate Authority (CA). This Certificate includes (at minimum) the Public Key of the Server and a Digital Signature. The Digital Signature is some 'token' data encrypted with the CA's Private Key.
  2. The Server sends data to a Client. It also sends the Digital Signature with it.
  3. The Client checks that this CA is trusted by looking for it in a hard-coded list of CAs on the local system.
  4. The Client can verify this Digital Signature by decrypting it using the CA's Public Key and checking for the original 'token' data. The Client now knows that the Server is trustworthy, according to the CA.
  5. The Client sends data to the Server, encrypted by the Server's Public Key and an algorithm e.g. RSA.
  6. The Server decrypts the data using it's Private Key.

I would like to know if this understanding is correct from a high-level, and if not, what have I got wrong/missed? Or any sources I should read elsewhere that will help.

marked as duplicate by Mike Ounsworth, forest, Rory Alsop Oct 19 '18 at 11:50

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    Mostly correct. Minor points: 1) the 'token' data is actually the hash of the data being signed (the rest of the cert in your case) so that the verifier can be sure the data hasn't been tampered with. 2) Your understanding of signatures as "encrypting with the private key" is true for RSA and is probably a good mental picture in general, but know that it's an over-simplification for any signature scheme other than RSA, for example DSA or ECDSA. – Mike Ounsworth Oct 17 '18 at 13:10
  • 2
    You might be interested in this complete yet easily understandable explanation of TLS 1.2 : tls.ulfheim.net "The Illustrated TLS Connection: Every byte of a TLS connection explained and reproduced". – A. Hersean Oct 17 '18 at 13:46
  • @MikeOunsworth Thank you for the corrections, very helpful. I’ve read many sources online and my understanding seems to vary for each one! Nice to have some clarification – petehallw Oct 17 '18 at 21:46
  • @MikeOunsworth I do have a question if you don’t mind - With RSA at least, the sever encrypts the message via the private key and this can only be decrypted with the public key... but as the public key is available to everyone how do we know that someone else hasn’t intercepted it? Also I think I’m confused about the token data as I said the client compares it but now I’m not sure what it compares it to! – petehallw Oct 18 '18 at 16:34
0

We have a canonical question which gives a very detailed explanation of TLS: How does SSL/TLS work?

I'll answer your specific question:

With RSA at least, the sever encrypts the message via the private key and this can only be decrypted with the public key... but as the public key is available to everyone how do we know that someone else hasn’t intercepted it?

Say I have a message:

I, Mike Ounsworth will give $10 from account XXXX-YYYY-ZZZZ to petehallw account XXXX-YYYY-ZZZZ.

I want to sign this message so that:

  1. Everyone knows that it came from me
  2. Nobody can tamper with it and change it from $10 to $1000, or change the account number.

If you look inside an RSA-sign operation, it would look sorta like **WARNING: OVER-SIMPLIFICATION ALERT**. First I hash the massage:

SHA2("I, Mike Ounsworth will give $10 from account XXXX-YYYY-ZZZZ to petehallw account XXXX-YYYY-ZZZZ.")
= 521C5EC6F1FEE551A2A5A8967EE183369424DBD26C4F25337EF72C42D01DB7E1

Next we compute a signature on the hash value (you have the mental model of encrypting that SHA256 hash with the private key, which is ok, but we aware that it's an over-simplification).

RSA-sign("521C5EC6F1FEE551A2A5A8967EE183369424DBD26C4F25337EF72C42D01DB7E1", privateKey)
= <binary_signature_blob>

Then anyone with the public key can verify by:

  1. Computer their own SHA256 hash of the massage they received.
  2. Use the public key to "extract" the SHA256 from the binary signature blob.
  3. Make sure the two SHA256 hashes match.

As stated above, this is already an over-simplification, even for RSA which is the simplest cipher to understand. You said that the different articles you read seem to disagree on how RSA signatures work, that's probably because crypto is complicated and each article is probably simplifying down to layman's terms in a different way.

  • Thanks again for explaining. So with this method (noted it’s over simplified) we can pretty much guarantee that the message was not tampered with, but it seems we can’t guarantee that nobody else looked at the information being sent by intercepting it somehow, as they could also decrypt it using the public key. – petehallw Oct 18 '18 at 18:33
  • Correct. "Security" is often thought of as "CIA: Confidentiality, Integrity, Availability". Digital signatures only provide Integrity (ie tamper-proof). If you want Confidentiality then you need to to use encryption + signature. That said, certificates and public keys are usually considered to be public information anyway, so don't need any Confidentiality. – Mike Ounsworth Oct 18 '18 at 18:37

Not the answer you're looking for? Browse other questions tagged or ask your own question.