SSL:
----
Elliptic curve Diffie-Hellman (ECDH) is an anonymous key agreement protocol that allows two parties, each having an elliptic curve public-private key pair, to establish a shared secret over an insecure channel. This shared secret may be directly used as a key, or better yet, to derive another key which can then be used to encrypt subsequent communications using a symmetric key cipher. It is a variant of the Diffie-Hellman protocol using elliptic curve cryptography.
Alternative protocols include the Fully Hashed MQV (FHMQV), an authenticated protocol for key agreement based on the Diffie-Hellman scheme. SSL supports forward secrecy using two algorithms, the standard Diffie-Hellman (DHE) and the adapted version for use with Elliptic Curve cryptography. ECDHE and DHE are the cornerstones of conventional SSL secure web connection protocols. DHE is significantly slower. ECDHE is supported by all major modern browsers.
The security of communications transmitted across the Internet can be improved by using public key cryptography. However if the public and private keys used in those communications are compromised it can reveal the data exchanged in that session as well as the data exchanged in previous sessions.
The concept of Perfect Forward Secrecy (PFS) is the property that ensures that a session key derived from a set of long-term public and private keys will not be compromised if one of the (long-term) private keys is compromised in the future. Online systems such as IPSEC can negotiate new keys for every communication and if a key is compromised only the specific session it protected will be revealed.
Forward Secrecy
---------------
Forward Secrecy has been used as a synonym for Perfect Forward Secrecy but there is a subtle difference between the two. Perfect Forward Secrecy has the additional property that an agreed key will not be compromised even if agreed keys derived from the same long-term keying material in a subsequent run are compromised.
For Perfect Forward Secrecy to exist 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 was derived from some other keying material, that material must not be used to derive any more keys.
Perfect Forward Secrecy (PFS) refers to the notion that compromise of a single key will permit access to only data protected by a single key. To protect storage of data (especially passwords) it is recommended that you use a derived key to encrypt the data. Using PBKDF2 (Password-Based Key Derivation Function 2) can mitigate against brute-force cracking attempts.
Google uses forward secrecy, and has confirmed that forward secret HTTPS is used for Gmail and many other Google HTTPS services such as SSL Search, Docs and Google+. Users of the Chrome web browser can check whether they have forward secret connections by clicking on the green padlock in the address bar of HTTPS sites. Google’s forward secret connections have a key exchange mechanism of ECDHE_RSA which is based on Elliptic Curve Diffie-Hellman Exchange (ECDHE). In November 2013 Twitter confirmed that it had implemented Forward Secrecy on all of its web sites and API feeds.
Enabling forward secrecy on a web server can be achieved by configuring your server with ECDHE and DHE suites at the top of your list. You can check your server using the Qualys SSL Server Test.
This article is licensed under the GNU Free Documentation License. It uses material from the Wikipedia article "Perfect forward secrecy".
Diffie-Hellman
--------------
ECDH is a variant of the Diffie-Hellman protocol using elliptic curve cryptography. Elliptic curve Diffie-Hellman (ECDH) is an anonymous key agreement protocol that allows two parties, each having an elliptic curve public-private key pair, to establish a shared secret over an insecure channel. This shared secret may be used as a key, or better yet, to derive another key which is then used to encrypt subsequent communications with a symmetric key cipher.
Alternative protocols include the Fully Hashed MQV (FHMQV), an authenticated protocol for key agreement based on the Diffie-Hellman scheme. SSL supports forward secrecy using two algorithms, the standard Diffie-Hellman (DHE) and the adapted version for use with Elliptic Curve cryptography.
ECDHE and DHE are the cornerstones of conventional SSL secure web connection protocols. DHE is significantly slower. ECDHE is supported by all major modern browsers. The Curve25519 function was carefully designed to allow all 32-byte strings as Diffie-Hellman public keys. ECDHE can also be used to protect sensitive data such as Pseudonymized Data which is being used as part of a Data Fading policy.
This article is licensed under the GNU Free Documentation License. It uses material from the Wikipedia article "Elliptic curve Diffie-Hellman".
Perfect Forward Secrecy
-----------------------
The security of communications transmitted across the Internet can be improved by using public key cryptography. However if the public and private keys used in those communications are compromised it can reveal the data exchanged in that session as well as the data exchanged in previous sessions.
The concept of Perfect Forward Secrecy (PFS) is the property that ensures that a session key derived from a set of long-term public and private keys will not be compromised if one of the (long-term) private keys is compromised in the future. Online systems such as IPSEC can negotiate new keys for every communication and if a key is compromised only the specific session it protected will be revealed.
For Perfect Forward Secrecy to exist 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 was derived from some other keying material, that material must not be used to derive any more keys.
Cisco offers Perfect Foward Secrecy as a parameter for VPN and LAN-to-LAN tunnel sessions. The Internet Key Exchange (IKE) Policy settings can use Diffie-Hellman Group algorithms. Virtru uses the AES-256 algorithm to encrypt messages with perfect forward secrecy before it leaves a device.
Perfect Forward Secrecy (PFS) refers to the notion that compromise of a single key will permit access to only data protected by a single key.
Forward Secrecy has been used as a synonym for Perfect Forward Secrecy but there is a subtle difference between the two. Perfect Forward Secrecy has the additional property that an agreed key will not be compromised even if agreed keys derived from the same long-term keying material in a subsequent run are compromised.
In April 2014, a news article by the Electronic Frontier Foundation (EFF) was posted in reponse to the OpenSSL Heartbleed bug. Why the Web Needs Perfect Forward Secrecy More Than Ever… “At this moment, forward secrecy is more crucial than ever before.”
The FHMQV-C protocol (Fully Hashed MQV plus C for ‘key confirmation’) uses perfect forward secrecy. The compromise of a static private key does not compromise any of the session keys, and this can be demonstrated through analysis of FHMQV with session key expiration.
This article is licensed under the GNU Free Documentation License. It uses material from the Wikipedia article "Perfect forward secrecy".
Keystore:
---------
Ultimately, .keystore and .jks are just file extensions: it's up to you to name your files sensibly. Some application use a keystore file stored in $HOME/.keystore: it's usually implied that it's a JKS file, since JKS is the default keystore type in the Sun/Oracle Java security provider. Not everyone uses the .jks extension for JKS files, because it's implied as the default. I'd recommend using the extension, just to remember which type to specify (if you need).
In Java, the word keystore can have either of the following meanings, depending on the context:
the API: http://docs.oracle.com/javase/6/docs/api/java/security/KeyStore.html
a file (or other mechanism) that can be used to back this API
a keystore as opposed to a truststore, as described here: http://stackoverflow.com/a/6341566/372643
When talking about the file and storage, this is not really a storage facility for key/value pairs (there are plenty or other formats for this). Rather, it's a container to store cryptographic keys and certificates (I believe some of them can also store passwords). Generally, these files are encrypted and password-protected so as not to let this data available to unauthorized parties.
Java uses its KeyStore class and related API to make use of a keystore (whether it's file based or not). JKS is a Java-specific file format, but the API can also be used with other file types, typically PKCS#12. When you want to load a keystore, you must specify its keystore type. The conventional extensions would be:
.jks for type "JKS",
.p12 or .pfx for type "PKCS12" (the specification name is PKCS#12, but the # is not used in the Java keystore type name).
In addition, BouncyCastle also provides its implementations, in particular BKS (typically using the .bks extension), which is frequently used for Android applications.
TrustSTore vs Key Store
------------------------
The terminology is a bit confusing indeed, but both javax.net.ssl.keyStore and javax.net.ssl.trustStore are used to specify which keystores to use, for two different purposes. Keystores come in various formats and are not even necessarily files (see this question), and keytool is just a tool to perform various operations on them (import/export/list/...).
The javax.net.ssl.keyStore and javax.net.ssl.trustStore parameters are the default parameters used to build KeyManagers and TrustManagers (respectively), then used to build an SSLContext which essentially contains the SSL/TLS settings to use when making an SSL/TLS connection via an SSLSocketFactory or an SSLEngine. These system properties are just where the default values come from, which is then used by SSLContext.getDefault(), itself used by SSLSocketFactory.getDefault() for example. (All of this can be customized via the API in a number of places, if you don't want to use the default values and that specific SSLContexts for a given purpose.)
The difference between the KeyManager and TrustManager (and thus between javax.net.ssl.keyStore and javax.net.ssl.trustStore) is as follows (quoted from the JSSE ref guide):
TrustManager: Determines whether the remote authentication credentials (and thus the connection) should be trusted.
KeyManager: Determines which authentication credentials to send to the remote host.
(Other parameters are available and their default values are described in the JSSE ref guide. Note that while there is a default value for the trust store, there isn't one for the key store.)
Essentially, the keystore in javax.net.ssl.keyStore is meant to contain your private keys and certificates, whereas the javax.net.ssl.trustStore is meant to contain the CA certificates you're willing to trust when a remote party presents its certificate. In some cases, they can be one and the same store, although it's often better practice to use distinct stores (especially when they're file-based).
shareimprove this answer
edited May 21 '14 at 16:51
Bhesh Gurung
33.6k1864103
answered Jun 14 '11 at 9:26
Bruno
74.9k7152230
thanks for the reply, it clears things up a little. I'm still confused though when it comes to usage, I can use a pk12 pri/pub key (xxx.p12) as a keystore (via -D) and create a SSL connection (trusted) without any mention of a truststore via -D... oh well. – Toby Jun 15 '11 at 8:03
28
You don't need to specify a truststore, because there's a default value for it (it's bundled with the JRE), usually in $JAVA_HOME/lib/security/cacerts (see 2nd JSSE ref guide link I sent). Like browsers, it contains a default set of trusted CA certificates. In general, a client will always use a truststore to check the server cert but the keystore will only be used if the server requests a client cert, and the server will always use a keystore for its own key+cert but the truststore will only be used if the client sends a client certificate. –
There is no difference between keystore and truststore files. Both are files in the proprietary JKS file format. The distinction is in the use: To the best of my knowledge, Java will only use the store that is referenced by javax.net.ssl.trustStore to look for certificates to trust when creating SSL connections. Same for keys and javax.net.ssl.keyStore. But in theory it's fine to use one and the same file for trust- and keystores.
PKCS#11 vs PKCS#12
-------------------
PKCS#12 is a file format (often called .p12 or .pfx) where you can store a private key and certificates. It's used for converting/transporting keys and certificates, mainly. If you export a private key + certificate from your browser, it's likely going to be in that format.
PKCS#11 is an interface, usually used to talk to hardware cryptographic tokens (often smart-cards or USB-tokens, which effectively are smart-cards embedded in a reader). This interface has a number of operations to make use of the keys and certificates. Some tokens are able to sign using the private key they contain, without the key being able to leave the device. The point of this interface is to treat what handles the keys and certificates as a separate entity, without having to do the cryptographic operations that PKCS#11 offer (more specifically, the ones related to the private key).
When you use PKCS#11 with NSS, you're effectively using NSS as a black-box wrapped behind the PKCS#11 layer (it's effectively a software provider for what a PKCS#11 hardware token would be). There is a slight difference in the way Java uses NSS via PKCS#11 in that it doesn't require a PKCS#11 shared library (compared to other PKCS#11 libraries), so as such, it's not PKCS#11 strictly speaking, although it's very similar.
In Java, you may be able to get an RSAPrivateKey instance from a PKCS#11 store, use it to sign and decipher, without ever being able to get anything from its modulus. The security provider handling it will do the signing/deciphering via the library (and thus via the token, if that library is supported by a hardware token).
Coming back to the KeyStore in Java, it's an API that can allow you to load and use keys and certificates from files (you get various files formats such as JKS, PKCS#12, PEM, depending on your security provider) or from other underlying APIs (such as PKCS#11, more or less merged with NSS in the Sun provider, or the KeychainStore if you're on OSX and want to use the KeyChain as a KeyStore).
