My previous post outlines several core concepts around cryptography, such as asymmetric key encryption, digital certificate, the encoding formats and relevant file extensions. In this article, we continue to explore cryptography use cases, where these concepts are connected and put into application.
The most important use case is TLS handshake. I cannot stress enough how paramount this scenario is. This use case and its variation can be found in almost every situation where connection needs to be secured.
TLS handshake: the process in which client and server establish secure connection. During the handshake, two parties agree on TLS version, decide on cipher suite, authenticate the identity of each other (although client identity authentication is less common), and generate session key for symmetric encryption after the handshake. Details steps are very important. Here is a fairly thorough reference, and here is a great diagram:
Secure browser connection: The most widespread use of TLS handshake is to secure browser connection with HTTPS:
- Browser initiates connection to the server;
- Server sends browser its certificate (public key + digital signature signed by CA);
- Browser has preloaded public key of CA and uses it to decrypt digital signature and get the digest of public key;
- Browser calculate digest of received public key and compares it against the digest from the previous step;
- If the result is the same, public key is trusted, a green lock is displayed; otherwise, a warning is displayed;
- proceed to the rest of the steps in TLS handshake.
Secure connection in Java: Java applications manages keys and certificates through two classes: java.security.KeyStore and java.security.TrustStore. Suppose a Java application client initiates TLS connection to server. The server application will present its certificates from server’s Key Store. The client will use certificates stored in client’s Trust Store to verify the identity of the server. Once validated, the client then presents certificates stored in client’s Key Store back to the server for validation.
- A KeyStore keeps keys and certificates for your own application. Typically, you store a KeyPair in a KeyStore file.
- A TrustStore keeps the certificates of external systems that your application trusts.
Below is a great diagram:
JKS file is Java’s version of PKCS#12 (private key + certificate, password protected). Entries in a JKS file must have an “alias” that is unique. The JKS file type can be used for both Key Store and Trust Store. When it’s used in Key Store, it contains a certificate and private key for the Java application. When it’s used in Trust Store, it only contains certificate from external trusted applications. Note that JKS is the default keystore format until Java 8. Since Java 9 the default keystore format is PKCS12.
Finally, we can introduce some tools:
Command line Tools
openssl is a versatile tool for cryptography and keytool is a similar tool for Java applications.
keytool is for store keys/certificates in Java Key Store or Trust Store.
Conclusion
I do not include any openssl or keytool command in this article in order to remain theoretical. However, once through the conceptual hurdles, one should become fairly comfortable picking up the tools and understand why each command is needed to achieve its purpose.