MIKEY-SAKKE frequently asked questions

Benefits of MIKEY-SAKKE

MIKEY-SAKKE offers significant scalability as it eliminates the need for pre-configuration between users or the distribution of user certificates. It demonstrates remarkable flexibility, supporting various forms of communication, including real-time conversations (like voice calls), conference calls, and deferred messaging (such as text and voicemail). Furthermore, it is designed for central management, allowing complete oversight of security by a domain manager, while also ensuring high availability, as communication does not necessitate interaction with centralized systems.

Intended Use of MIKEY-SAKKE

MIKEY-SAKKE is primarily intended for deployment in enterprise settings, especially within government organizations. Similar to other enterprise solutions, such as Blackberry’s Enterprise Server and Microsoft’s Active Directory, it requires central oversight through a Key Management Server (KMS), enabling government departments or enterprises to securely communicate by controlling key material. The security framework of MIKEY-SAKKE remains tightly governed by the enterprise via the KMS.

Purpose Behind MIKEY-SAKKE’s Development

The National Cyber Security Centre (NCSC) acknowledged a pressing need within the UK government for secure communication methods. To address this need while fostering competition, an open protocol was necessary, enabling companies to innovate with interoperable solutions for government use, making functionality a competitive advantage.

NCSC’s Definition of MIKEY-SAKKE

MIKEY-SAKKE was defined by NCSC utilizing an identity-based cryptographic protocol created by researchers Sakai and Kasahara in 2003. This Sakai-Kasahara scheme (SK) is a widely recognized identity-based public key cryptography system. For authentication, NCSC implemented the Elliptic Curve Digital Signature Algorithm (ECDSA), making necessary adjustments to ensure compatibility with the Sakai-Kasahara protocol. These components were combined within the MIKEY framework to allow secure Voice over IP (VoIP) communications.

NCSC’s Role in MIKEY-SAKKE Development

NCSC does not develop MIKEY-SAKKE-based security solutions. The solutions are independently developed by industry stakeholders utilizing this open standard.

Target Users of MIKEY-SAKKE

MIKEY-SAKKE was primarily designed for secure governmental communications. It is essential for civil servants involved in sensitive governmental discussions. This encompasses a wide array of applications, including public safety discussions, where employers require an auditable framework for secure communications through a managed process. This assurance of accountability is crucial in governmental operations, such that if an officer’s actions need investigation, only their police department should have the capacity to decrypt those communications.

Other Potential Users of MIKEY-SAKKE

Since the protocol’s inception, it has garnered interest from security-oriented enterprises within sectors such as finance, legal, and healthcare, which share similar security needs.

Security Assessment of MIKEY-SAKKE

MIKEY-SAKKE maintains a high level of security when implemented correctly. NCSC certifies that a properly configured system can prevent communication access from even highly skilled adversaries. This assurance is one of the reasons it is recommended for broader use within the UK government. However, if the KMS is compromised, all associated users will also be at risk. This characteristic is a common vulnerability in all centralized systems, including Microsoft’s Active Directory and Blackberry’s Enterprise Server. Therefore, it is paramount that the KMS is controlled and operated by the communications system owner, with the system designed to avert KMS breaches.

Best Practices for MIKEY-SAKKE Deployment in Standard Scenarios

Guidelines for MIKEY-SAKKE in Larger Deployments

In larger setups, the KMS may be situated within a Hardware Security Module (HSM) behind an assured diode, restricting data flow out while preventing any incoming communications. This configuration secures the KMS by denying attackers access. Additionally, the key material can be partitioned across different servers, adding another layer of security as disruptions would require the compromise of multiple servers. It is essential to note that the KMS is the only part of the solution that the system owner manages directly, allowing client communications that are encrypted to be routed through external VoIP platforms operated by ISPs or mobile network providers.

Audit and Lawful Intercept Capabilities of MIKEY-SAKKE

MIKEY-SAKKE includes provisions for audits or lawful intercept, as permitted by the deploying department or organization. This feature is critical for government use and was intentionally integrated into the protocol’s design. To audit encrypted communications, the organization should obtain a specific, time-limited key from the KMS, which allows for the decryption of communications within that defined timeframe (for instance, for a month). The KMS is also capable of logging these actions to maintain accountability.

Audit Mechanism and Mass Surveillance

MIKEY-SAKKE’s design does not support mass surveillance, as commercial KMSs typically issue only single-user keys that are time-bounded. The system owner retains control over their own KMS, which governs the audit function. Audit mechanisms are not feasible without the cooperation of the system owner. Furthermore, if a lawful interception request is made with a proper warrant, the organization can choose whether to provide the necessary user-specific keys for assistance in legal investigations.

Audit Mechanism Explained

It is important to clarify that the audit mechanism does not function as a backdoor. Asking for a password to access an account is not considered a backdoor, and similarly, the audit process is merely a feature available to the system owner and can be disabled if not required. Thus, if the organization opts not to utilize this feature, no party can decrypt its communications. Consequently, there is no inherent ‘backdoor’ present.

Escrowing Keys to GCHQ

There is no such practice of escrowing keys to GCHQ.

Trust in KMS Management

If there is a lack of trust in the individual or entity managing your KMS, it is advisable not to use MIKEY-SAKKE. Since the KMS is responsible for handle your encryption keys, its management should be entrusted to a reliable authority.