How do the processes for digital certificates, signatures and ssl work?

Question

I have been trying to understand how ssl works. Instead of Alice and Bob, lets consider client and server communication. Server has a digital certificate acquired from a CA. It also has public and private keys. Server wants to send a message to Client. Server's public key is already available to client.

Assuming that ssl handshake is completed.

Server to Client:

Server attaches its public key to the message.
Runs hash function on (message+public key). Results is known as HMAC.
Encrypt HMAC using it's private key. Result is called digital signature.
Send it to Client along with the digital certificate.
Client checks the certificate and finds that it's from the expected Server.
Decrypts HMAC using Server's public key.
Runs the hash funciton on (message+public key) to obtain the original message.

Client to Server

Client runs hash funciton on (message+public key) and then encrypts using the same public key.
Server decrypts using private key, runs the hash funciton on the resultant data to obtain the message.

Please let me know if my understanding is correct.

Please re-post the above steps with corrections or additions. Then, It will be easy to understand. – John Sep 22 '11 at 16:07 — John, Sep 22 '11 at 16:07

Tom Leek · Accepted Answer · 2011-11-01 15:08:49Z

There are a few confusions in your post. First of all, HMAC is not a hash function. More about HMAC later on.

Hash Functions

A hash function is a completely public algorithm (no key in that) which mashes bit together in a way which is truly infeasible to untangle: anybody can run the hash function on any data, but finding the data back from the hash output appears to be much beyond our wit. The hash output has a fixed size, typically 256 bits (with SHA-256) or 512 bits (with SHA-512). The SHA-* function which outputs 160 bits is called SHA-1, not SHA-160, because cryptographers left to their own devices can remain reasonable for only that long, and certainly not beyond the fifth pint.

Signature Algorithms

A signature algorithm uses a pair of keys, which are mathematically linked together, the private key and the public key (recomputing the private key from the public key is theoretically feasible but too hard to do in practice, even with Really Big Computers, which is why the public key and be made public while the private key remains private). Using the mathematical structure of the keys, the signature algorithm allows:

to generate a signature on some input data, using the private key (the signature is a mathematical object which is reasonably compact, e.g. a few hundred bytes for a typical RSA signature);
to verify a signature on some input data, using the public key. Verification takes as parameters the signature, the input data, and the public key, and returns either "perfect, man !" or "dude, these don't match".

For a secure signature algorithm, it is supposedly unfeasible to produce a signature value and input data such that the verification algorithm with a given public key says "good", unless you know the corresponding private key, in which case it is easy and efficient. Note the fine print: without the private key, you cannot conjure some data and a signature value which work with the public key, even if you can choose the data and the signature as you wish.

"Supposedly unfeasible" means that all the smart cryptographers in the world worked on it for several years and yet did not find a way to do it, even after the fifth pint.

Most (actually, all) signature algorithms begin by processing the input data with a hash function, and then work on the hash value alone. This is because the signature algorithm needs mathematical objects in some given sets which are limited in size, so they need to work on values which are "not too big", such as the output of a hash function. Due to the nature of the hash function, things work out just well (signing the hash output is as good as signing the hash input).

Key Exchange and Asymmetric Encryption

A key exchange protocol is a protocol in which both parties throw mathematical objects at each other, each object being possibly linked with some secret values that they keep for them, in a way much similar to public/private key pairs. At the end of the key exchange, both parties can compute a common "value" (yet another mathematical object) which totally evades the grasp of whoever observed the bits which were exchanged on the wire. One common type of key exchange algorithm is asymmetric encryption. Asymmetric encryption uses a public/private key pair (not necessarily the same kind than for a signature algorithm):

With the public key you can encrypt a piece of data. That data is usually constrained in size (e.g. no more than 117 bytes for RSA with a 1024-bit public key). Encryption result is, guess what, a mathematical object which can be encoded into a sequence of bytes.
With the private key, you can decrypt, i.e. do the reverse operation and recover the initial input data. It is assumed that without the private key, tough luck.

Then the key exchange protocol runs thus: one party chooses a random value (a sequence of random bytes), encrypts that with the peer's public key, and sends him that. The peer uses his private key to decrypt, and recovers the random value, which is the shared secret.

An historical explanation of signatures is: "encryption with the private key, decryption with the public key". Forget that explanation. It is wrong. It may be true only for a specific algorithm (RSA), and, then again, only for a bastardized-down version of RSA which actually fails to have any decent security. So no, digital signatures are not asymmetric encryption "in reverse".

Symmetric Cryptography

Once two parties have a shared secret value, they can use symmetric cryptography to exchange further data in a confidential way. It is called symmetric because both parties have the same key, i.e. the same knowledge, i.e. the same power. No more private/public dichotomy. Two primitives are used:

Symmetric encryption: how to mangle data and unmangle it later on.
Message Authentication Codes: a "keyed checksum": only people knowing the secret key can compute the MAC on some data (it is like a signature algorithm in which the private and the public key are identical -- so the "public" key had better be not public !).

HMAC is a kind of MAC which is built over hash functions in a smart way, because there are many non-smart ways to do it, and which fail due to subtle details on what a hash function provides and does NOT provide.

Certificates

A certificate is a container for a public key. With the tools explained above, one can begin to envision that the server will have a public key, which the client will use to make a key exchange with the server. But how does the client make sure that he is using the right server's public key, and not that of a devious attacker, a villain who cunningly impersonates the server ? That's where certificates come into play. A certificate is signed by someone who is specialized in verifying physical identities; it is called a Certificate Authority. The CA meets the server "in real life" (e.g. in a bar), verifies the server identity, gets the server public key from the server himself, and signs the whole lot (server identity and public key). This results in a nifty bundle which is called a certificate. The certificate represents the guarantee by the CA that the name and public key match each other (hopefully, the CA is not too gullible, so the guarantee is reliable -- preferably, the CA does not sign certificates after its fifth pint).

The client, upon seeing the certificate, can verify the signature on the certificate relatively to the CA public key, and thus gain confidence in that the server public key really belongs to the intended server.

But, you would tell me, what have we gained ? We must still know a public key, namely the CA public key. How do we verify that one ? Well, we can use another CA. This just moves the issue around, but it can end up with the problem of knowing a priori a unique or a handful of public keys from über-CAs which are not signed by anybody else. Thoughtfully, Microsoft embedded about a hundred of such "root public keys" (also called "trust anchors") deep within Internet Explorer itself. This is where trust originates (precisely, you forfeited the basis of your trust to the Redmond firm -- now you understand how Bill Gates became the richest guy in the world ?).

SSL

Now let's put it all together, in the SSL protocol, which is now known as TLS ("SSL" was the protocol name when it was a property of Netscape Corporation).

The client wishes to talk to the server. It sends a message ("ClientHello") which contains a bunch of administrative data, such as the list of encryption algorithms that the client supports.

The server responds ("ServerHello") by telling which algorithms will be used; then the server sends his certificate ("Certificate"), possibly with a few CA certificates in case the client may need them (not root certificates, but intermediate, underling-CA certificates).

The client verifies the server certificate and extracts the server public key from it. The client generates a random value ("pre-master secret"), encrypts it with the server public key, and sends that to the server ("ClientKeyExchange").

The server decrypts the message, obtains the pre-master, and derive from it secret keys for symmetric encryption and MAC. The client performs the same computation.

Client sends a verification message ("Finished") which is encrypted and MACed with the derived keys. The server verifies that the Finished message is proper, and sends its own "Finished" message in response. At that point, both client and server have all the symmetric keys they need, and know that the "handshake" has succeeded. Application data (e.g. an HTTP request) is then exchanged, using the symmetric encryption and MAC.

There is no public key or certificate involved in the process beyond the handshake. Just symmetric encryption (e.g. 3DES, AES or RC4) and MAC (normally HMAC with SHA-1 or SHA-256).

thanks. Could you check my answer to the question? I guess it is correct. – John Nov 3 '11 at 14:30 — John, Nov 3 '11 at 14:30
@John: well, your description of asymmetric encryption and signatures is a bit confusing, since use the infamous "encrypt with private key" metaphor. Also, you seem to encrypt a signature, which is kind of weird. For the SSL part, you got it mostly right, except for the "CertificateVerify" message, which occurs after the "ClientKeyExchange", and only if the client sent a certificate (as a "Certificate" message before the ClientKeyExchange). See section 7.3 of RFC 5246, there is an explanatory diagram. – Tom Leek Nov 3 '11 at 16:24 — Tom Leek, Nov 3 '11 at 16:24
Thanks a ton... Tom. Could u edit my description of asymmetric encryption and signatures and make corrections. It would be very helpful. – John Nov 3 '11 at 16:40 — John, Nov 3 '11 at 16:40
+1 tom Can you please have alook at my question ? stackoverflow.com/questions/12645128/certificate-hash-checking – Royi Namir Sep 28 '12 at 18:15 — Royi Namir, Sep 28 '12 at 18:15

John · Answer 2 · 2011-09-23 17:49:14Z

After much struggle. I have the below understand of the differences between SSL, Asymmetric key encryption, Digital Certificate (DC) and Digital Signature (DS).

What is Digital Certificate, also known as public key certificate?

DC is an electronic document which uses a digital signature to bind a public key with an identity information such as name, address, etc

Contents of certificate: Public key certificate

Most important being, Signature-Algorithm, Issuer and the Public Key.

What is a asymmetric key encryption and digital signature?

Explained by means of an example.

Both machines have a pair of cryptographic keys — a public encryption key and a private decryption key.

Machine-A has access to Machine-B's public key and certificate.
Machine-B has access to Machine-A's public key and certificate.

Machine-A to Machine-B

At Machine-A:

Hash_function(Data) = Hash
Encrypt(Hash) using Machine-A's private key = DS
Attach Data to DS and DC = Data+DS+DC
Encrypt(Data+DS+DC) using Machine-B's public key.
Send it to Machine-B.

At Machine-B:

Decrypt (Data+DS+DC) using Machine-B's private key.
Verify DC to authenticate the Machine-A.
Decrypt(DS) using Machine-A's public key = Hash#1
Hash_function(Data) = Hash#2
if(Hash#1 == Hash#2) Data and signature are valid.

Machine-B to Machine-A

The process is now exactly the reverse of the above.

What is SSL/TLS?

The TLS protocol allows client/server applications to communicate across a network in a way designed to prevent eavesdropping and tampering. In most of the Client-Server communication, only the Server needs to be authenticated. TLS streamlines Asymmetric key encryption to make effective use of this phenomenon. Secure Sockets Layer

Client and Server example.

Server has a digital certificate acquired from a CA. It also has public and private keys.

User clicks on a URL starting with

https://

A secure connection is needed for this session. The browser establishes a TCP connection on the HTTPS TCP Port 443.

Client > Server : SYN
Client < Server : SYN+ACK
Client > Server : ACK

SSL Handshake on new TCP connection:
Client > Server : CLIENT_HELLO

The client sends a CLIENT_HELLO command to the server, which includes:
- The highest SSL and TLS version supported by the client.
- Ciphers supported bythe client. The ciphers are listed in order of preference.
- Data compression methods that are supported by the client.
- The session ID. If the client is starting a new SSL session, the session ID is 0.
- Random data that is generated by the client for use in the key generation process.
Client < Server : SERVER_HELLO

The server sends a SERVER_HELLO command to the client, which includes:
- The SSL or TLS version that will be used for the SSL session.
- The cipher that will be used for the SSL session.
- Data compression method that will be used for the SSL session.
- The session ID for the SSL session.
- Random data that is generated by the server for use in the key generation process.
Client < Server : CERTIFICATE (PUBLIC KEY)

The server sends the CERTIFICATE command. It includes the servers certificate.
Client < Server : SERVER_DONE

The server sends the SERVER_DONE command. This command indicates that the server has completed this phase of the SSL handshake.
Client > Server : CERTIFICATE_VERIFY

Client informs the server that it has verified the server's certificate
Client > Server :

Using all data generated in the handshake thus far, the client (with the cooperation of the server, depending on the cipher being used) creates the pre-master secret for the session, encrypts it with the server's public key (obtained from the server's certificate), and then sends the encrypted pre-master secret to the server.

The server uses its private key to decrypt the pre-master secret, and then performs a series of steps to generate the master secret.

Client also performs the same series of steps on the pre-master secret to generate the same master secret.

Note: In situations where client needs to be authenticated, the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case, the client sends both the signed data and the client's own certificate to the server along with the encrypted pre-master secret.
Client <> Server :

Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity.

Note: From now on it's symmetric key encryption.
Client > Server :

The client sends a message to the server informing it that future messages from the client will be encrypted with the session key.
Client > Server : FINISHED

Client then sends a separate (encrypted) message indicating that it's portion of the handshake is finished.
Client < Server :

The server sends a message to the client informing it that future messages from the server will be encrypted with the session key.
Client < Server : FINISHED

Server sends a separate (encrypted) message indicating that it's portion of the handshake is finished.

The SSL handshake is now complete and the session begins. The client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity.

The above explanation is taken from various sources. It would be great if this is turned to a wiki. – John Sep 23 '11 at 17:50 — John, Sep 23 '11 at 17:50

Georgios · Answer 3 · 2011-12-28 08:41:08Z

up vote 2 down vote

For a more detailed explanation "under the hood", I can also suggest the following article: The First Few Milliseconds of an HTTPS Connection by Jeff Moser. The article uses packet captures of an HTTPS communication session to illustrate how the protocol works. It's interesting to see the things we are talking about in action and it clears out many "dark" spots.

edited Dec 28 '11 at 8:41

answered Nov 1 '11 at 11:16

Georgios
1,3911628

Simply throwing out a link is generally considered bad form. Would you care to summarize the relevant portions of the article as well? – Scott Pack Dec 27 '11 at 16:11

Apologies, I updated my answer above. – Georgios Dec 28 '11 at 8:35

add comment

缩略语	英文全名	中文解释
AES	Advanced Encryption Standard	高级加密标准
CA	Certificate Authority	证书机构
DES	Data Encryption Standard	数据加密标准
HTTPS	Hypertext Transfer Protocol Secure	安全超文本传输协议
MAC	Message Authentication Code	消息验证码
MD5	Message Digest 5	消息摘要算法5
PKI	Public Key Infrastructure	公钥基础设施
RSA	Rivest Shamir and Adleman	非对称密钥算法的一种
SHA	Secure Hash Algorithm	安全散列算法
SSL	Secure Sockets Layer	安全套接层
VPN	Virtual Private Network	虚拟专有网络

alxe_yu

SSL工作原理

1 概述

1.1 产生背景

1.2 技术优点

2 协议安全机制

2.1 数据传输的机密性

2.2 身份验证机制

2.3 消息完整性验证

2.4 利用非对称密钥算法保证密钥本身的安全

2.5 利用PKI保证公钥的真实性

3 协议工作过程

3.1 SSL的分层结构

3.2 SSL握手过程

3.2.1 只验证服务器的SSL握手过程

3.2.2 验证服务器和客户端的SSL握手过程

3.2.3 恢复原有会话的SSL握手过程

4 典型组网应用

4.1 HTTPS

4.2 SSL VPN

SSL工作原理

How do the processes for digital certificates, signatures and ssl work?

migrated from stackoverflow.com Sep 22 '11 at 14:20

4 Answers

公告