The Strong Case for Interoperability, Part II: Transition
Back in June, Kevin Mooney wrote an excellent piece on The Strong Case for Interoperability. Getting back to that subject matter, in perhaps not the most ideal of circumstances, we are going to talk about standards, interoperability, and transition as it pertains to resolving systemic issues. This is being driven by faults in 802.11 as described in Mathy Vanhoef’s and Frank Piessens’ paper on key reinstallation attacks released today.
Piessens’ and Vanhoef’s paper demonstrates that WPA2 is a compromised protocol and that it is possible to break the four-way handshake1 of the WPA2 by a man-in-the-middle attack that withholds the fourth message of the handshake during authentication and association from the thing requesting authentication (your laptop, phone, etc.) to the thing executing authentication (a wireless router or access point). The requesting devices load their keys and start sending encrypted traffic. The attacker in the man-in-the-middle position repeats the third message of the four-way handshake to the requesting device causing session keys to be reloaded by the requesting devices with a nonce of 1. Effectively, this is taking advantage of a race condition where requestor session keys are loaded before receiving acknowledgement that the authenticator acknowledges the pairwise and group session keys. This allows the keys to be reinstalled on the requesting device which compromised the nonce used for data encryption. With the nonce and data encryption compromised, message confidentiality becomes compromised as well. Variations of this theme apply for the peer key handshake, group key handshake, and the fast basic service set handshake.
Depending on what ciphers are being used, the impact ranges from replay and decrypt for the counter-based, cipher block chaining encryption defined by the IEEE 802.11i standard in 2004 to full on decryption, replay, and message injection in the Galois/Counter Mode Protocol (GCMP) introduced in the 802.11ac amendment of 2016. This is not to say that AES-GCMP is an inferior protocol for 802.11. Its abilities for performance, authentication, confidentiality, and integrity should be a great story in incremental improvement. It is how AES-GCMP can be exposed due to weaknesses in the 802.11 four-way handshake that rains on the 802.11ac parade.
This may not seem like a very good starting point on why standards and interoperability matter. It’s a bit of a write up on encryption ciphers and a reference to a well-written and very technical paper. Much like checking for a repeated message or disallowing reuse of nonces, it is worth looking for another word in the title: “transition.” In this case, transition refers to the orderly change from one thing to another.
As outlined in Piessens’ and Vanhoef’s paper, the fact that 802.11 has issues is bad, but it is a bad thing in a standard that is interoperable amongst vendors. This gives organizations an opportunity to see which vendors resolve the problem with their products and which vendors lose business with minimal impact to the organization. In other words, an orderly transition of technology. I make the argument that resolving the 802.11 scenario is a middle of the road transition use case as it can be accomplished by software or firmware patches or replacing affected systems with equipment that does not have encryption reinstallation and nonce reuse problems.
If you consider AES-CCMP and AES-GCMP (the AES symmetric cryptography authentication, integrity, and confidentiality protocols discussed), standards allow for a natural progression to AES-GCMP over time without loss of services. This is only possible because IEEE 802.11 allows for vendor neutral application of the standard and changes can happen over time. Sticking to 802.11 as an example, this is good demonstration of a small incremental change. So that begs the question — what about a large transition scenario?
Depending what you have heard about the term Crypto Agility, that is about as good of an example as you can consider for massive scale transition. If this is the first time you’ve read about the subject, Crypto Agility defines the ability for an IT system to change the type of encryption used with minimal impact to the system as a whole. Given how encryption is fundamental in providing controls for confidentiality and integrity of information, the impact of change is not a small thing. A good example is moving away from RSA asymmetric keys to a lattice-based asymmetric crypto scheme with minimal impact to your network. Crypto Agility impacts both how encryption keys are used and how encryption keys are created and managed.
When dealing with transition on a larger scale, resolution is rooted in adoption of standards for management and distribution of encryption key material with Key Management Interoperability Protocol (KMIP) being an excellent example2. The use of KMIP corresponds to the rollout of technology that uses the encryption. The consistency in encryption key management allows for variety in encryption key utilization. This gives organizations an orderly path to fundamental changes in encryption.
At the end of the day, it is worth noting that standards and interoperability give us a path to transition — whether it is small changes or massive ones. For better or for worse, change happens — but with good standards that promote interoperability, change doesn’t have to hurt.
Ready to learn more about how our KMIP empowered Key Orchestration can work with your existing technology to improve your security strategy, request a custom demo today.
Additional Notes
1Four-Way Handshake Overview:
1) Authenticator Device sends a message, one of the fields is a replay counter that increments with every message between the Authenticator and the Device Requesting Authentication, another field is a random number called a Nonce used by the encryption cipher – this nonce is generator by the Authenticator. This message is not encrypted
2) The Device Requesting the Authentication (Supplicant) Responses with a message with an incremented Replay Counter and a nonce created by the supplicant. This message is not encrypted
3) The Authenticator acknowledges that it knows the Pairwise Master Key and it informs the Supplicant that it is ready to install Pairwise Temporal Key, and Group Temporal Key. This is the last unencrypted message from the authenticator to the supplicant.
4) Message 4 has the supplicant acknowledging to the Authenticator that the Pairwise and Group Temporal keys are about to be installed and that encrypted communications can begin. This is the last unencrypted message between the Supplicant and Authenticator.
2Members of the Fornetix team are active participants in the KMIP technical committee. Despite the fact that KMIP is a great example of protocol development, we might be a little biased.
