The development of MIKEY-SAKKE

Created:  26 Jan 2016
Updated:  31 Mar 2016
Dr Ian Levy explains how the protocol underpins both public safety and enterprise secure communications.

Ian Levy

Dr Ian Levy, Director Cyber Security and Resilience, GCHQ

CESG welcomes challenge in cyber security - that's how good systems are created. Sometimes these systems bring really significant design challenges. Large scale public safety and enterprise systems are two classes of use that CESG have to provide solutions for. That's why MIKEY-SAKKE was created, and I want to go into a little of the design ethos.


Use Case 1: Public Safety

MIKEY-SAKKE was designed by CESG 5 years ago to ensure that organisations such as the police, fire and ambulance services were ready to meet a worldwide move from the legacy TETRA radio system to a Public Safety System based on the public 4G system known as Public Safety LTE (PS-LTE). 

As these services move off TETRA to PS-LTE, the congestion and loading characteristics of the systems could change significantly. In the worst case communications could become patchy, with traditional security systems unable to perform well in this very congested environment. If this were to happen during a major incident, with multiple agencies needing to communicate quickly and effectively, the result could be catastrophic.

MIKEY-SAKKE based systems have been designed to perform better in such scenarios. The half-round-trip characteristics of the protocol, coupled with the secure deferred delivery and retargeting abilities, allow you to build systems that degrade gracefully in these extreme circumstances, rather than failing or forcing users back to clear mode.


Use Case 2: Enterprise Communication Security

Organisations must be able to protect their communications from competitors or criminals that may be trying to intercept.

Because the cost of equipment to intercept mobile telephony traffic off-air has fallen dramatically, it was necessary to create an overlaid security solution for sensitive communications.

However, staff still need to be able to communicate easily. They will want secure voicemail that is not stored in the clear, and to bring in third parties to those communications quickly and easily but in a controlled way. The MIKEY-SAKKE protocol does all this with end-to-end encryption.

For investigative or regulatory reasons, most Organisations will want the ability to monitor their employees. MIKEY-SAKKE makes this possible; the organisation can record the encrypted traffic and decrypt it if and when they need to. They don't need to actively ‘man-in-the-middle’ communications, which they'd have to do with other systems. And ONLY the enterprise can do this, because only the enterprise has the key management server.

In this scenario, MIKEY-SAKKE gives organisations control over their destiny. They have end-to-end security on their communications, but can still manage their good business governance, regulatory and legal requirements in a secure way. Many other enterprise class protocols also have a centralised point of control and monitoring, for example Kerberos.


Only the owners of individual systems can decrypt their conversations

The MIKEY-SAKKE protocol is openly published by CESG in the Internet Engineering Task Force (IETF) RFCs 6507,6508 and 6509. Section 6 'Security Considerations' of RFC6509 which defines MIKEY-SAKKE states: "Traffic keys cannot be derived by any infrastructure component other than the KMS."

Any real world security system has something that could compromise security. Whether it's a Certificate Authority, a code signing key, the integrity of the source code to a product, the Key Distribution Centre in Kerberos or the Key Management Server in the MIKEY-SAKKE system. There's always something that can break a security system.

Perfect security just isn't possible. You have to know what's important so you can protect it appropriately. In the MIKEY-SAKKE case, unlike most other security designs, the Key Management Server doesn't ever need to be accessible to the clients. It can be completely offline and therefore better protected from attack. The online key distribution server handles only encrypted user keys (which only the individual users can decrypt) so the security impact of it being compromised is small.

The Key Management Server isn't a backdoor - and it's certainly not there to enable 'mass undetectable surveillance'.  Only the owners of individual systems can decrypt their conversations.

The products that industry have created under the Secure Chorus Industry Interoperability Group provide government with enterprise grade end-to-end security that also meets governance, regulatory and legal requirements. By publishing the protocol as RFCs and the Secure Voice specification, we avoided being locked into vendor specific implementations and satisfied the need to ensure interoperability between products.

CESG also needed to get the specification into the 3GPP Public Safety Specification, and work with manufacturers to ensure that the protocol can be supported on the sort of devices that will be used. Having the protocol in the public domain helps, but having it published in RFC's is the best way of ensuring that people who want to build solutions using this protocol have the information that they need.


Apples and aardvarks

In both the use cases described above, the system operator owns all of the data going over it. This is different to commodity products such as FaceTime, Skype or Google Talk where the system operator does not own the users' data, and the users don't necessarily trust the system operators. The Electronic Frontier Foundation EFF (EFF) Secure Messaging Scorecard is a tool that is used to score such commodity secure communication tools. Using the Scorecard in this scenario is fine, but to apply the same principles to a protocol designed to satisfy a completely different use case (as in the examples given above), with a completely different set of constraints, does not make sense. It is like comparing apples to aardvarks.


MIKEY-SAKKE: the best solution for the myriad of requirements

At the end of the day, it's about balance and compromise, getting the best balance between security and satisfying use cases. Are there other ways of achieving the requirements? Almost certainly. But I think that MIKEY-SAKKE is the best solution for the myriad of requirements and constraints that CESG had to design for. It's important to understand what it was designed for and judge it against those criteria, rather than other related use cases.

MIKEY-SAKKE does what it's designed to do, and it does it well.

Was this information helpful?

We need your feedback to improve this content.

Yes No