The underpinning technologies behind Secure Chorus are at the cutting-edge of modern cryptographic standards. These standards are used in Secure Chorus for two primary purposes: ensuring that two parties exchanging data, whether persons or machines, are doing so with the individual or the machine they believe they are exchanging data with (authentication of identity) and ensuring no unauthorized person or machine can access the content of any data exchange (end-to-end encryption).
Origins of MIKEY-SAKKE
In 2012, the UK government’s National Technical Authority for Information and Assurance (CESG) – now the National Cyber Security Centre (NCSC) – defined MIKEY-SAKKE as a standard to answer the security requirements from government to have a cryptographic method for validating an identity for government communications.
This standard was based upon an existing standard for elliptic curve signatures, the Elliptic Curve Digital Signature Algorithm (ECDSA) and an identity-based cryptographic protocol developed by two Japanese researchers, SAKAI and KASAHARA. Using these protocols for secure communications gave rise to MIKEY-SAKKE, defined by the IETF as RFC 6507  and RFC 6509 .
MIKEY-SAKKE builds upon a range of existing security technologies. It specifies the use of the widespread Secure Real-time Protocol (SRTP)  to securely transmit multimedia data. This is specifically used with the widespread Advanced Encryption Standard – 128 bit (AES-128) as defined by NIST FIPS 197  in the Galois Counter Mode (AES/GCM) cipher mode of operation, as defined by NIST SP 800-38D .
MIKEY-SAKKE has been approved by 3GPP for use in Mission-Critical applications, such as emergency services communications . 3GPP is the collaboration project which provides system specifications for cellular telecommunications network technologies.
More information on how MIKEY-SAKKE was developed by NCSC and the use-cases for the cryptographic technology can be found on the NCSC’s website .
Key Management Servers
The system used in MIKEY-SAKKE means that each user is attached to a Key Management Server (KMS). This server distributes key information to the users it manages on a regular (typically monthly) basis. Unlike other closed secure communication systems, the approach in Secure Chorus is specifically adapted for enterprise.
The existence of the KMS means that an organisation has control over its own security system, without having to give access to their data to unauthorised third parties. As an organisation’s data becomes increasingly valuable and sensitive in today’s world, an organisation’s control over its own security system is critically important. With this control, different activites can be performed by the organisation such as data analytics, monitoring of cyber incidents and auditing activities. All while ensuring compliance with the relevant regulatory frameworks applicable to the organisaton’s sector.
The Key Management Server can be managed entirely by an organisation’s own IT team. And it may be kept offline for maximal security. Ultimately, thanks to the properties of MIKEY-SAKKE, the organisation retains full control over their security system, and only those explicitly authorised by an organisation can access that organisation’s data.
With a KMS approach, there is no need for complex key-exchange or handshaking between the originator and consumers of data. Instead a short packet of data (“I_MESSAGE”) is sent from the originator to the consumers, which encapsulates all the information required to decrypt a data stream or message, and a signature from the originator. Both parties can then be mutually authenticated following the processing of this single I_MESSAGE, without the need for a return path from the consumer back to the originator. The overhead on the data channel is minimal to none, depending on the protocol used at the application layer. This high data-efficiency also makes the standard very attractive for IoT purposes.
A walkthrough on how the MIKEY-SAKKE and the KMS works, how keys are managed, and how the technology can be used to build secure multimedia services for data processing can be found on the NCSC’s website .
Secure Chorus develops standards which enable interoperable secure digital data processing between Secure Chorus Compliant Products.
Secure Chorus’ interoperability standards build upon a foundation of a number of existing and industry-wide adopted standards not only in the field of cryptography – but also leveraging other existing telecommunication standards. Secure Chorus contains MIKEY-SAKKE as the encryption algorithm at its core, but defines other protocols and codecs which Secure Chorus products must support.
As a first step to make their secure communication products interoperable with one-another, Secure Chorus’ members need to adopt these specific standards into their products.
Although Secure Chorus’ approach can extend to all types of digital data. The foundation of Secure Chorus’ interoperability standards specifically addresses and resolves the problem of achieving interoperability of two secure voice products, with the aim of achieving a seamless secure phone call.The NCSC’s website  highlights how solutions with MIKEY-SAKKE at their core can address the evolving risks of communications, and further address the benefit of interoperability for products using Secure Chorus’ standards.
The Secure Chorus standards specify a profile of the Session Initialisation Protocol (SIP) for supporting the communication between systems. SIP is a common Voice over IP (VoIP) protocol standardised by the IETF .
Secure Chorus’ technology roadmap is developed by consensus amongst its members, generating a multi-layered time-based chart that enables the technology development to be aligned with market trends and drivers.
Current areas of collaboration include extending the VoIP standards beyond one-to-one communication to group calls, instant messaging, video calls, voicemail, document sharing and machine-to-machine communications. We are also studying other areas of innovation – we intend to develop post-quantum capability into Secure Chorus with a Post Quantum Identity Based Crypto Scheme. We will be seeking input from industry, academia and government to identify the right solution to address this critical challenge.
|||IETF, “RFC 6507 – Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI),” February 2012. [Online]. Available: https://tools.ietf.org/html/rfc6507.|
|||IETF, “RFC 6509 – MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY),” February 2012. [Online]. Available: https://tools.ietf.org/html/rfc6509.|
|||IETF, “RFC 3711 – The Secure Real-time Transport Protocol (SRTP),” Mar 2004. [Online]. Available: https://tools.ietf.org/html/rfc3711.|
|||NIST, “Information Technology Library,” [Online]. Available: https://www.nist.gov/itl.|
|||3GPP, “Specification #: 22.179,” 22 Sep 2017. [Online]. Available: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=623.|
|||NCSC, “The development of MIKEY-SAKKE,” 26 Jan 2016. [Online]. Available: https://www.ncsc.gov.uk/articles/development-mikey-sakke.|
|||NCSC, “Using MIKEY-SAKKE: Building secure multimedia services,” 28 Sep 2016. [Online]. Available: https://www.ncsc.gov.uk/articles/using-mikey-sakke-building-secure-multimedia-services.|
|||NCSC, “Secure Voice at OFFICIAL,” 8 Aug 2016. [Online]. Available: https://www.ncsc.gov.uk/guidance/secure-voice-official.|
|||IETF, “RFC 3261 – SIP: Session Initiation Protocol,” Jun 2002. [Online]. Available: https://tools.ietf.org/html/rfc3261.|