6

I am trying to understand the difference between digital signature and digital certification and how they work as a whole together on a high level perspective. I hope gurus here can point to me if my understanding is wrong.

  1. When a user access a website, in order to encrypt communication between the the user and the website, a symmetric key is to be used.

  2. *In order for the symmetric key to be used by both the client and server, information about the creation of the symmetric key must be encrypted using the asymmetric key.

  3. But first, the authenticity of the webserver must be confirmed. Hence, the webserver sends the user/client its digital certification. Inside the digital certification, it contains the public key use by the webserver to be use for asymmetric encryption at 2).

  4. This digital certification is being issued by the Certificate Authority which checks and verifies to prove that the webserver/domain does really belong to whom it is suppose to belong to.

  5. *However again, how do we prove the authenticity and integrity of the digital certification? For integrity, the digital certificate is hashed and sent together with the original certificate. For authenticity, the hashed digital certificate is signed with the CA's private key.

  6. *So if the digital certificate is signed by the CA's private key, how do we get CA's public key? The overall idea I have is that public keys from CA are preinstalled in many browsers.

  7. With the public key of the CA, the digitally signed hash/certificate is decrypted and to produce the original hash. The client then hash the received certificate and compare it with the original hash. If the 2 hash results matched, the certificate is not tampered.

  8. With the digital certificate, the public key used by the webserver is retrieved by the webclient/user. The webclient/user then use this public key to encrypt the information of building the symmetric key over to the webserver.

  9. With the symmetric key being known and created on both sides, encrypted communication can begin.


Questions:

  • Is my understanding correct?

  • For 2*, is the session key created by the web client and sent to the webserver for use directly (encrypted) or is it setup by exchanging information that end up having both sides with the same session key (Diffie Hellman algorithm?)?

  • For 5,* I have never applied for a digital certificate before. When the CA issue a digital certificate, does it really issue the digital certificate? Or does it just issue a digitally signed hash of the certificate.

  • Else, how do we send the digital certificate (original) and its digitally signed hashed version without the CA private key?

  • For 6*, is my understand correct that CA's public key come preinstalled with the browsers?

  • Does the client need to authenticate with the webserver? (I read about having the client sending cert to the webserver as well).

  • What will be put in the truststore on the webclient, and what will be put in the keystore on the webserver?

5

First, I think that you're confusing some terms. The term is "digital certificate", "certificate", or simply "cert". Not "digital certification". If you really mean "digital certification" then this answer is likely wrong.

  1. Yes. Symmetric keys are used for bulk encryption because symmetric encryption algorithms are much faster than asymmetric ones.
  2. No. This is not a guarantee. All that is required is that the server and client agree upon a shared secret. By using a Diffie-Hellman key exchange, they can agree on the shared secret without needing any encryption. You can read the details about the algorithm or you can just trust that DH key exchange allows for a shared secret to be agreed upon without any crypto being needed. DH is frequently (maybe mostly but I don't have stats) used to agree upon the shared secret.
  3. Yes
  4. Yes
  5. Yes. A certificate chain is used to prove that all certs are untampered.
  6. Trusted CA certs come installed in Windows. IE uses the Windows ones while Chrome and Mozilla install their own set of trusted CA certs.
  7. OK. You're mostly correct here. Some digital signature algorithms work by encrypting the hash of the message with a private key. Other algorithms do other tricks (I'm unfamiliar with the details) but it isn't quite the same thing. So number 7 is best said as "The signature is then validated by the client." Generally this will mean hash and asymmetric encryption, but not always.
  8. Again, no. Diffie-Hellman key exchange is generally used (as discussed in 2 above).
  9. Yes!

Regarding your bulleted questions.

Is my understanding correct ?

Mostly - I made corrections above.

for 2* is the session key created by the web client and send to the webserver for use directly (encrypted) or it is setup by exchanging information that end up having both side with the same session key (Diff hellman algorithm ?)

Diffie Hellman as stated above.

For 5* I have never applied for a digital certificate before. When the CA issue a digital certificate, does it really issue the digital certificate ? or it just issue a digitally signed hash of the certificate.

CAs don't issue certificates as much as sign requests. This is typically done by sending the CA a certificate signing request or CSR. Most tools that generate certs or keys have options for generating a CSR.

Else,how do we send the digital certificate (original) and its digitally signed hashed version without the CA private key ?

I'm not sure what you mean here. Perhaps I answered it above?

For 6* is my understand correct that CA's public key come preinstalled with the browsers ?

Answered above, they come with the browsers or the OS. I think that Java has maintains its own list as well. Probably a few other common apps do the same.

Does the client need to authenticate with the webserver ? (i read about having the client sending cert to the webserver as well).

That's an optional step. For most applications (eg: Amazon and your bank), you, the client, authenticate to the site by making a secure HTTPS connection and then giving it your name and password. Some sites allow two-factor authentication as well. SSL's mutual authentication (AKA: 2-way authentication) is part of SSL that allows the client to authenticate to the server during the SSL handshake. For this to occur, the client must have a cert and private key and that cert must be pre-registered with the server. (Note that there are no CAs for these certs, the browser trusts a cert because they got a copy of it and were told to trust it.) The convenient part of 2way auth is that it happens by magic. No nasty passwords to remember or type. The (really) inconvenient part is that having to manage a collection of certificates and private keys across all your browsers (think mobile) is a pain. Sometimes client certs (ie: 2way auth) are also used as a second factor in a 2-factor auth process. My experience is that 2way auth is most used in high-security environments where users (almost) always use the same computer.

What will be put in the truststore on the webclient, and what will be put in the keystore on the webserver ?

Do you mean what will be put in the truststore/keystore when using 2way auth? Nothing is put in the client's truststore for 2way auth. The cert and its key are usually kept in a keystore or other secure, typically encrypted, data store. And nothing goes into the server's keystore for 2way auth. All the server needs to do is keep a copy of the cert and associate it with the appropriate user. This is generally done in a database.

Maybe you are asking what will go in the truststore/keystore for standard SSL connections? The root CA certs go into the client's truststore. This is typically done by the browser/OS provider and users never need to change this. If you are deploying self-signed certs (ie: no CA) or running a web proxy, you may need to add new certs to the client's truststore. The server's private key is stored in its keystore. For convenience, frequently the cert is stored in there as well.

1

When a user access a website, in order to encrypt communication between the the user and the website, a symmetric key is to be use.

Yes.

*In order for the symmetric key to be used by both the client and server, information about the creation of the symmetric key must be encrypted using the asymmetric key

Yes, unless it is diffie-hellman.

But 1st, the authenticity of the webserver must be confirmed. Hence, the webserver send the user/client its digital certification. Inside the digital certification, it contains the public key use by the webserver to be use for asymmetric encryption at 2).

Yes.

This digital certification is being issued by the Certificate Authority which will does checks and verification to prove that the webserver/domain does really belongs to whom it is suppose to be long to.

Yes - this depends on the level of the certificate. Whether the requested certificate is Domain Validated (DV), Organisation Validated (OV) or an Extended Validation (EV) certificate determines which checks are carried out.

*However again, how do we prove the authenticity and integrity of the digital certification ? For integrity, the digital certificate is hashed and send together with the original certificate. For authenticity, the hashed digital certificate is signed with the CA private key.

Yes, the certificate includes a signature downloaded by the browser.

*So if the digital certificate is signed by the CA private key, how do we get CA's public key ? The overall idea i have is that public keys from CA are preinstalled in many browsers.

For the browser to trust the certificate, the CA's public key must be in the operating system or browser's certificate root store. Internet Explorer and Chrome use the OS's store, while Firefox has its own store.

With the public key of the CA, the digitally signed hash/certificate is decrypted and to produce the original hash. The client then hash the received certificate and compare it with the original hash. If the 2 hash results matched, the certificate is not tampered.

Not quite. Don't confuse hashing, encryption and signing. The public certificate of the website is signed by the private key of the CA (or by an intermediary CA). As long as the chain results in a trusted root certificate, everything is good. e.g.

Site CA --signed-by-> Intermediary CA --signed-by-> Root CA

Anyone can verify that the signature matches the hashed certificate using the CA's public key. Public key cryptography takes advantage of "trapdoor functions" in mathematical equations. It is easy to verify that a signature is generated by a private key using the public key, however it is computationally infeasible to generate the signature without having the private key of the CA.

With the digital certificate, the public key used by the webserver is retrieved by the webclient/user. The webclient/user then use this public key to encrypt the information of building the symmetric key over to the webserver.

Yes, the pre-master secret is encrypted with the public key. In the case of Diffie-Hellman the public key is instead used to sign the shared secrets.

For 5* I have never applied for a digital certificate before. When the CA issue a digital certificate, does it really issue the digital certificate ? or it just issue a digitally signed hash of the certificate.

Yes, you will receive the certificate and the signature which is calculated over the hash of the certificate.

Else,how do we send the digital certificate (original) and its digitally signed hashed version without the CA private key ?

You can keep the private key. To get your certificate signed, you generate a Certificate Signing Request (CSR) to send to the CA. Once they sign your certificate, you can install the signed version on your server to pair up with the previously generated private key.

Some CAs will generate the private key for you - however, for security I recommend you generate your own and simply send the CSR.

Does the client need to authenticate with the webserver ? (i read about having the client sending cert to the webserver as well).

Yes, you can authenticate the client with the web server using client certificates. This is just for authentication though, rather than encryption.

What will be put in the truststore on the webclient, and what will be put in the keystore on the webserver ?

The web client would send its certificate and the web server can verify its public key and check that its signed by a trusted CA. As proof of possession of the private key, the client also signs the handshake messages which can be verified by the public key by the server.

  • 2. No. The session key is not generated by the client; is not encrypted; is not transmitted; and is not decrypted. It is calculated independently by both peers via a key agreement protocol. – user207421 Mar 21 '17 at 4:36
  • I didn't say that, I said that information used in the creation of the symmetric keys is encrypted using the asymmetric key. Ie, the premaster secret when it is not DH. – SilverlightFox Mar 21 '17 at 7:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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