Cryptify’s implementation of MIKEY-SAKKE

Dr Steven Murdoch yesterday published an article about MIKEY-SAKKE on the blog Bentham’s Gaze.

The article elaborates on security risks with MIKEY-SAKKE key establishment when using an online/always available Key Management System (KMS) controlled by a third party e.g. a network provider. I have received questions regarding this from some of our customers and therefore I would like to explain our implementation of MIKEY-SAKKE in Cryptify Call.

According to the MIKEY-SAKKE standard a KMS generates a master secret. From this master secret all users key material is derived. The users keys are to be updated every month with new keys generated by the KMS.

If one would put a KMS online, it would of course be exposed to threats, and if successfully attacked, the master secret would be compromised. The Cryptify Call KMS is designed to always be offline and most of the time it is powered off and kept in a safe. The KMS only needs to be active when adding users and when generating the monthly key update for the users. These operations are, by design, performed with the KMS still being offline.

The second assumption in the article is that the KMS would be owned and operated by a third party. The MIKEY-SAKKE KMS can always generate the user keys from the master secret, a feature referred to, in the article, as “key escrow” within the KMS. The Cryptify Call KMS is designed to be owned and operated by the user organisation, e.g a government agency, a company or a department within an organisation. In all cases, the owner of the KMS is the only one with access to the key material.

With the implementation choices above, Cryptify has avoided the security risks related to MIKEY-SAKKE KMS implementations described in the article.

Kungsbacka the 20th of January 2016

Johan Wagné
Cryptify AB