Problems with ETSI GS QKD 014 v1.1.1

The post in TODO state. I will expand on the following ETSI 014 issues in the future.

• SAE identity extraction from certificate is unspecified
• Key ID model does not support reconstruction well
• No delegated authorization / JWT-style retrieval
• Too much metadata visibility about who talks to whom
• Arbitrary bit-length requests are poorly defined
• No practical mandatory key-size profiles
• No standard bulk-transfer model for very large requests
• Certificate / PKI profiling is too vague
• Weak guidance for PQC / hybrid classical-channel protection
• No timeout / retry semantics for asynchronous key arrival

Quantum key distribution (QKD) is a complementing approach to classical cryptography. It is a method by which eavesdropping can be detected on a communication channel. Albeit useful properties, it has not seen wide adoption due to hardware requirements. The benefit of QKD over securely shipping large HDD with pre-shared keys is uncertain. As summarized in a technical position paper by ANSSI ¹, “QKD may find some use in a few niche applications, for instance as a defense-in-depth measure on point-to-point links.” In academia, these devices are also seen as steps towards a greater goal - the quantum internet ².

Commercial QKD products have been avaiable since the early 2000s: MagiQ publicly unveiled Navajo in 2003 ³. Since then roughly 16 other vendors offer their devices ⁴. Typical secret key rate (SKR) are in the magnitude of a few kbits/s. For seamless integration into classical telecommunication use-cases, SKR of a few kbits/s is unsuitable for OTP-encryption. As of now, QKD is therefore usually used for continous AES rekeying.

EuroQCI⁵ aims to build a secure quantum communication infrastructure spanning the whole EU, with terrestrial fibre links between strategic national and cross-border sites plus a satellite segment, and it involves all 27 EU Member States and ESA. At that scale, bespoke APIs are not serious. Large networks need common interfaces for key request, status, authorization, monitoring, and interoperation across administrative and vendor boundaries. Otherwise every deployment becomes a custom adapter project, and cross-border federation becomes fragile and expensive.

ETSI understood that early: its QKD application-interface work started in 2008, GS QKD 004 was published in December 2010, and the HTTPS REST-based GS QKD 014 followed in February 2019 ETSI GS QKD 014 V1.1.1 defines a simple JSON key-delivery API intended for multi-vendor interoperability. A consuming application, encryptor, VPN gateway should not need to know implementation details. In practice, the document leaves multiple under-specified that predictably fragment implementations.

Funding note. Some of the work behind these observations was carried out within the EU-funded project No. 101091559, Development of Experimental Quantum Communication Infrastructure in Latvia (LatQN). The comments and reflections in this post are my own and may not reflect technical position of the IMCS, UL or EU.