certificate usage for signing and encryption

Question

I have a question for basic operating with certificates in emails and pdfs. Im familiar with public key cryptography.

The scenario:

In my scenario I want to send a confidential email to a person A from a server B.

My understanding (no certificates):

Keypair 1: private key AA, public key AB

Keypair 2: private key BA, public key BB

Keypair 1 is generated on the server. Private key AA stays on the server, Public key AB is transfered to Person A. Keypair 2 is generated on the client. Private key BA stays, public key BB is tranfered to the server.

Now I sign the message with private key AA and encrypt it with public key BB on the server B. Person A verifies the signature with public key AB, and decrypts it with private key BA.

Question:

I want to translate this scenario of using certificates. What confuses me is who holds which certificate what inside these certificates and types. Any help is appreciated!

Thanks in advance. If something is unclear please let me know.

EDIT:

Thanks to all for the nice answers. Cant decide which I should give the "thumb up". Love the star wars example :).

Answer 1

A certificate is simply a public key that has been signed by a third party and is part of a key pair as you described. (or in the case of self signed certificates it is signed by the first party). It is also worth noting that the sender only needs a keypair if you need authentication (ie, the receiver knows that the message came from the sender) in addition to confidentiality.

The sender would encrypt the message with a secret key and then encrypt that secret key with the public key of the recipient. The encrypted secret key and encrypted message can then be sent and only the recipient can decrypt the message by decrypting the secret key for the message. If verification is needed, the HMAC of the message can be encrypted with the public key of the sender and the certificate included with the message. If the certificate is signed by a trusted third party, then the recipient knows that the public key is valid and can use it to verify the HMAC, thus verifying that the sender holds the private key which corresponds to the certificate.

Answer 2

The recipient of the encrypted message has to be able to verify the message signature applied by the sender of the message. The signature of the message is computed as a hash of the content of the message, encrypted with the PRIVATE key of the sender. What the recipient needs to do to verify the signature is to decrypt the message (using the recipient's private key), compute the hash of the message contents, and then decrypt the provided signature value with the sender's PUBLIC key. If the decrypted version of the signature matches the locally computed hash of the message, then the signature is "valid" and the recipient can be sure that the message hasn't been altered since it was encrypted.

Here's where certificates enter this scenario: the recipient needed to use the sender's PUBLIC key to verify the signature. To do this, the recipient needs to have the certificate of the sender, signed by a trusted Certificate Authority (eg Verisign, GoDaddy etc).

So the only absolute in this scenario is that the recipient of the message needs to have the certificate of the sender, and trust the signer of that certificate.

Answer 3

Certificates are useful because even if you have a key pair, that doesn't mean you can just send someone your public key and the receiver will know that you control the corresponding private key. There must be some way for the receiver to associate that key with your identity (your "self"). Otherwise, an attacker could just send the server his public key, claiming that it's yours, and the message would be sent to him (or, conversely, you could receive a public key from a fake server, and receive a message that is properly encrypted, signed, but didn't come from who you think it came).

One way to exchange keys securely would be in-person, but that's cumbersome and not always feasible. Another option is to use a trusted third-party in the process - Person A signed the public keys of both Person B and Person C and associated each key with the holder's ID, so as long as B has a copy of A's public key he can verify that C's key matches C's ID (even if that key/certificate was sent through an insecure channel). Thus, B can send confidential messages to C (and, as pointed out in AJ Henderson's answer, the converse is also necessary if B wants to sign the message - C must have A's public key in order to verify B's identity).

So, answering your question, the certificates play a role in your process in the public key exchanging phase, everything else goes like you described. The contents of a certificate are one public key associated to one identifier (be it a domain name, or something else that uniquely identifies you, and that an honest third-party would not sign if they didn't know/trust you). And for who owns what, typically both own a list of trusted third-parties, used for verification, but nothing stops you from having also a list of known certificates from trusted individuals (in which case it doen't matter whether or not a third party signed them).

---

Update: a complete example, tailored to fit your scenario:

Alice (Server A) wants to send a message to Bob (Person B), with the help of their common acquaintance Charles Augustus. They have each a key pair, comprised of a private key (AA, BA and CA) and a public key (AB, BB and CB), and a certificate that associates their public key to their names (AC, BC and CC). Charlie signed his own certificate (CC$C) using his private key.

When Alice and Charlie met in-person, Charlie signed Alice's certificate using his private key (AC$C), after confirming that Alice controlled the corresponding private key (AA), that the certificate contained Alice's name (the server's domain name) plus public key (AB) and that she wasn't an impostor. Alice also got a copy of Charlie's certificate. Some time later, Bob did the same (getting BC$C, using his ID or some other proof-of-identity, since people don't have domain names).

When Alice wants to send a message to Bob, this is what happens:

1. Bob sends his certificate (BC$C) to Alice;
2. Alice confirms that the certificate has Bob's name, and that it was signed by Charlie;
3. Since Alice has Charlie's certificate (CC$C), she uses the public key (CB) contained in it to verify the signature (made with the private key CA);
   • now she trusts that Bob controls the private key (BA) that pairs the public key (BB) contained it Bob's certificate.
4. "Now I sign the message with private key AA and encrypt it with public key BB on the server A. Person B verifies the signature with public key AB, and decrypts it with private key BA."
5. Now Bob has the message, but he needs to be sure it really came from Alice. BTW Alice also sent her certificate (AC$C) together with the message (that's how Bob got the public key AB);
6. Bob confirms that the certificate has Alice's name, and that it was signed by Charlie;
7. Since Bob has Charlie's certificate (CC$C), he uses the public key (CB) contained in it to verify the signature (made with the private key CA);
   • now he trusts that Alice controls the private key (AA) that pairs the public key (AB) contained it Alice's certificate.

Answer 4

Certificates has been made to serve as a transport for the public keys. Besides, they can be used to add trust.

TL;DR: your scenario does not change a bit with certificate if you don't need authentification.

For now, let's just assume that a certificates holds a public key. You are then able to share it publicly to the galaxy claiming that this is the public key belonging to Obi-Wan Kenobi. Since, you hold the corresponding private key on your computer, you will be able to decrypt any message encrypted with the public key from the certificate and to sign message with your private key.

However, nobody can confirm you are who you claim to be i.e. Obi-Wan ("that's not true, that's impossible"). For this to happen, it is necessary that the world can authenticate that your certificate belongs to Obi-Wan Kenobi. Now let's assume the galaxy can trust the Republic and the Republic's administration publish a public key and holds their private key. They are a root Certificate Authority. This public certificate will be self-signed and for trust to happen, the whole galaxy HAS to trust this certificate.

Since the whole galaxy trust a single root certificate, one is now able to go to the Republic's office with their ID and their own generated public key. After verifying the person identity, let's say you are the real Obi-Wan Kenobi (wow!), the office will then create your certificate. This certificate will state your identity and embed your public key. Finally, using the private keys of the Republic, they will sign your certificate therefore binding your identity to your public key. Anyone holding your certificate and the Republic's public key will be able to verify the Republic's signature. Assuming it's valid and they trust the Repuplic's root certificate, they can now be sure the certificate they get belongs to Obi-Wan Kenobi and nobody else.

Finally, your certificate holds your public key AND can be proved belonging to Obi-Wan. Therefore, anyone encrypting things with that particular public key is guaranteed it can only be read by said Obi-Wan Kenobi, the unique owner of the private key.

Nota: eventually, for you case with two actors, you will need to repeat the registration process twice.