Encryption is relatively straight forward and easy once an encryption schema has been selected and encryption keys are possessed. However, exchanging of keys between two or more entities can be a significant challenge, especially over an untrusted open network. There are key exchange protocols that help address this problem. The two most notable are Diffie-Hellman (DH) and RSA. The challenge that these two protocols help to address is the ability to create a shared secret key (for encrypting messages) over an open network – we assume that everyone is watching.  We these utilize key exchange protocols in various points within our infrastructure to help protect sensitive information.  A common use cases for such a key exchange is when our clients interact with our web applications using SSL/TLS. 

The DH protocol does not actually “exchange” the secret key, however it enables both entities to compute the secret key on their own. It relies on the complexity of solving a discrete logarithm, were each entity uses its own prime number (secret) and uses modulo exponents to derive a shared number, the key.  While this is efficient and secure, it is not immune to attacks. A man-in-the-middle (MITM) attack can intercept the messages during the key exchange protocol and spoof the sender or the receiver. This attack is enabled because the DH protocol does not have a built-in method to authenticate the entities in the communications.

The RSA protocol helps us to solve the DH MITM problem by providing the capability to both encrypt and authenticate (via digital signatures). In short, using a set of corresponding keys (public and private) the RSA protocol enables the entities to send an encrypted message along with a “signature” to verify that the entity is indeed who she says she is. This is performed with a function of the private the sender’s private key, enabling verification using the public key. While this solves our MITM problem, we still have a concern about using RSA. This concern is that if the private key is ever leaked, all historical encrypted data could be at risk.

For several of our encryption implementations we will be using a combination of both protocols. We will use RSA to perform authentication and DH to exchange keys once an authenticated session has been established. When using ephemeral keys unique to specific sessions, the risk of leaked private key is minimized to a specific session. This capability, known as Perfect Forward Secrecy (PFS) is also built into the TLS protocol and is supported by most modern browsers. This makes it a good choice to protect PHI in all of our web-based applications (e.g. our web portals) as it does not require additional components, other than a browser, to implement for our clients and partners/providers.