I have heard that with forward secrecy that the ECDSA ciphers generate different keys for "each session" because they are not dependent on the private key of the server. My question is how is "each session" defined? Does this different key approach mean it happens with each consecutive/different SSL connection to say the same server or does it happen within the existing SSL connection as server side SSL re-negotiation request happen?
4
-
did you mean ECDHE?– Steffen UllrichAug 20, 2014 at 12:52
-
Forward Secrecy or Perfect Forwards Secrecy, there's a subtle difference.– RoraΖAug 20, 2014 at 12:59
-
Yes ECDHE-ECDSA* or ECDHE-RSA*..sorry– user53029Aug 20, 2014 at 13:00
-
Forward Secrecy– user53029Aug 20, 2014 at 13:01
Add a comment
|
2 Answers
Forward Secrecy
The key used to protect transmission of data must not be used to derive any additional keys, and if the key used to protect transmission of data is derived from some other keying material, then that material must not be used to derive any more keys. In this way, compromise of a single key permits access only to data protected by that single key.
Perfect Forward Secrecy (PFS)
PFS holds true above, but satisfies the two properties below:
- Generates random public keys per session for the purposes of key agreement
- Does not use any sort of deterministic algorithm in doing so
Addressing your questions in SSL/TLS
How is "each session" defined?
Ephemeral Diffie Hellman is used for PFS. Using Ephemeral Diffie Hellman (DHE/ECDHE) forces each session to renegotiate its DH parameter every time a single SSL session closes. So "each session" quite literally means as soon as the session ends the keys are destroyed. No session IDs are stored by the server, so new keys are forced each time.
Does this different key approach mean it happens with each consecutive/different SSL connection to say the same server or does it happen within the existing SSL connection as server side SSL re-negotiation request happen?
Doesn't matter if its the same server, or a server side re-negotiation the server shouldn't have cached session keys. So new DH parameters are needed with *DHE cipher suites. Now this is how the theory works. Configuration is kind of a different story. Some servers might have to disable session resumption to ensure this occurs.
Implementations SHOULD generate a new X for each handshake when using DHE cipher suites.
-
Am I correct that RSA can create only the same symmetrical key each session because of the static public and private keys? Feb 20, 2017 at 23:07
-
@ipeacocks RSA doesn't generate symmetric keys. Symmetric keys are generated separately and then encrypted with RSA. Since the keys are unique the RSA encryptions are as well.– RoraΖFeb 21, 2017 at 0:48
-
@RoraZ but technically (by design) RSA can generate symmetric keys and sign them? Thanks to Diffie-Hellman exchange keys are counted on hosts. Per my understanding DH process is enough for symmetric key generation and RSA only signs each stage (for understanding who is who) of its generation. Am I correct? Feb 21, 2017 at 6:45
-
1@ipeacocks RSA does not generate symmetric keys. It generates asymmetric keys where the encryption key is public and the decryption key is private. It is not symmetric encryption/decryption. DH negotiates asymmetric keys that are unique to each session, and is used as the pre-master secret in TLS. This along with several other pieces of information is used to generate the master secret which then produces symmetric keys. All of this is authenticated with RSA. This answer might help clarify things.– RoraΖFeb 21, 2017 at 13:21
Each session means each SSL session. An SSL session can be reused over multiple TCP connections (that is SSL connections) if both client and server implement session reuse and each of the SSL connections gets closed in a clean way.
A SSL connection might also consist of multiple SSL sessions if you do multiple full SSL handshakes within the same connection.
answered Aug 20, 2014 at 13:04
-
What about an existing SSL connection where the server request renegotiation where each party stops exchanging data in order to renegotiate how the communication is secured? Aug 20, 2014 at 13:08
-
Renegotiations are secured by the already established session. Aug 20, 2014 at 13:41
-
@SteffenUllrich For PFS new DH parameters should be generated for each handshake using DHE cipher suites. Unless I'm missing understanding how PFS is supposed to work.– RoraΖAug 20, 2014 at 14:34
-
Yes, with each full handshake a new session with a new session key is created. But a full handshake is not done when you resume a session. Aug 20, 2014 at 16:51
-
@SteffenUllrich true, but if the server is not keeping session IDs (as should be done with PFS) then it will force a full handshake.– RoraΖAug 25, 2014 at 12:49