MIKEY-SAKKE frequently asked questions

Advantages of MIKEY-SAKKE

MIKEY-SAKKE offers significant scalability, eliminating the need for pre-configuration between users or the distribution of user certificates. It also features flexibility, accommodating real-time communications like voice calls, conference calls, and deferred messages such as voicemails. The protocol is centrally managed, granting domain managers complete oversight of the system’s security while ensuring high availability, as calls can occur without centralized interaction.

Purpose of MIKEY-SAKKE

MIKEY-SAKKE is specifically tailored for use in enterprise contexts, particularly within government settings. Similar to enterprise services like Blackberry’s Enterprise Server and Microsoft’s Active Directory, it necessitates centralized management via a ‘Key Management Server’ (KMS). Once implemented, it enables secure communication for members of government departments or enterprises by providing necessary key material. The overall security of the system rests solely in the hands of the enterprise through its KMS.

The Necessity of MIKEY-SAKKE

The NCSC acknowledged the need for secure communications within the UK government. To achieve scalability while fostering competition, an open protocol was proposed to allow companies to create interoperable solutions for government with competitive functionality.

NCSC’s Definition of MIKEY-SAKKE

The NCSC established MIKEY-SAKKE based on an identity-based cryptographic protocol created by two Japanese researchers, Sakai and Kasahara, in 2003. Utilizing the well-established Sakai-Kasahara (SK) IDPKC scheme for authentication, NCSC adopted the elliptic curve digital signature algorithm (ECDSA) with slight adjustments for optimization with the Sakai-Kasahara protocol. These protocols were integrated within the MIKEY framework to enhance secure voice-over-IP (VoIP) support.

NCSC’s Role in MIKEY-SAKKE Solutions

NCSC does not develop MIKEY-SAKKE security solutions. Instead, these solutions are independently developed by industry actors based on this open standard.

Target Users of MIKEY-SAKKE

MIKEY-SAKKE was originally conceived to meet the secure communication needs of government. It is particularly suited for situations where civil servants engage in sensitive governmental discussions, encompassing diverse applications, including public safety. Additionally, employers may require a mechanism to audit secure communications through a managed and logged process, safeguarding accountability in government. For example, if a police officer’s actions are under scrutiny, the police department must possess the ability to decrypt that officer’s communications.

Other Potential MIKEY-SAKKE Users

Since its inception, there has been notable interest from security-conscious enterprises across sectors such as finance, law, and healthcare, seeking similar secure communication solutions.

Security of MIKEY-SAKKE

MIKEY-SAKKE is considered secure if deployed correctly. The NCSC assures that a properly configured system denies access to communications, even to the most adept adversaries. This is why it is employed and recommended for broader use across the UK government. However, the security of all users managed by a compromised KMS would be at risk, a concern shared across centralized architectures, including Microsoft’s Active Directory and any traditional Public Key Infrastructure managed by Certificate Authorities. Therefore, it is crucial that the KMS is securely owned and managed by the system owner responsible for the protected communications, ensuring the system is deployed to avert KMS compromise.

Deployment of MIKEY-SAKKE in Standard Scenarios

Deployment of MIKEY-SAKKE in Large Settings

In larger deployments, the KMS may be set up within a Hardware Security Module (HSM) secured by a diode, which restricts data flow outward from the KMS, allowing no data to be sent back. The KMS’s security is enhanced by denying attackers access to the system. Moreover, the key material can be divided across multiple servers, requiring an attacker to undermine several servers for success. It is essential to note that the KMS is the only part of the solution managed directly by the system owner. Since all client communications are encrypted, they can utilize external VoIP services, such as those provided by ISPs or mobile network operators.

Support for Audit or Lawful Intercept with MIKEY-SAKKE

Yes, this is permissible based on the deploying department or organization’s policies. This capability is crucial for government use and was intentionally incorporated into the protocol’s design. To audit encrypted communications, the organization may extract a user-specific and time-bounded key from the KMS, which allows decryption of communications for that designated period (e.g., a month). The KMS can log this action for accountability purposes.

Does the Audit Mechanism Enable Mass Surveillance?

No, established commercial KMSs can only provide time-limited, single-user keys. The system owner maintains control over their KMS, thus regulating the audit function. Audit cannot occur without the mutual consent of the system owner. Similarly, should an organization receive a lawful interception warrant (such as within an insider trading probe), that organization can decide whether or not to provide the specific user and time-bound key required for that investigation.

Is the Audit Mechanism a Form of Backdoor?

No. Requesting your password is not considered a ‘backdoor’ to your laptop, and similarly, the audit mechanism is a feature at the discretion of the system owner that may or may not be activated. If the organization does not deem it necessary, they can opt not to disclose user key material. In this scenario, no one can decrypt the communications of the organization. At no point is there an actual ‘backdoor’.

Are Keys Escrowed to GCHQ?

No.

Should My Organization Use MIKEY-SAKKE Without Trusting the KMS Manager?

No. Since the KMS manages your encryption keys, it must be administered by someone you can trust.