AIT QKD R10 Documentation

(This documentation covers the AIT QKD R10 v9.9999.8.)

This page starts the documentation of the AIT QKD R10 software. The whole software bundle is shipped with one single package.

Useful guides covering installation-related topics:

After installation of the AIT QKD R10 you will find:

The following documentation helps you using the AIT QKD R10 framework:

  • The current API (Application Programming Interface) of the QKD can be found online at API-HTML or after installation on your local disk at /usr/share/doc/qkd.

Here are examples you can use for setting up a working installation:

AIT QKD R10 Concept

The design of the AIT QKD R10 is focused on the idea that the work is divided across several stages of QKD; these are: sifting, error estimation, error correction and privacy amplification. These steps are encapsulated within small processes, or programs, which are dedicated for their designated task only. These programs are labeled "QKD modules". There is no single big process which does all key reconciliation, but a series of programs working together to produce shared secret keys.

As such, the AIT QKD R10 bears an agent driven approach:

AIT QKD R10 Agents

Raw keys material is collected from the QKD hardware and then passed on from one module to the next until the final integration into the operating system occurs. It is the final step at which the keys are used and thus consumed. QKD modules arranged in such serial lines are called "QKD pipelines".

When two concurrent QKD pipelines work across a network connected via

  1. quantum channel for Qubit acquisition, or
  2. classical channel for key reconciliation

This forms the basic scenario the AIT QKD model.

AIT QKD scenario

The data shipped between these QKD modules on one side is the "keystream". The keystream consists of serial key data along with key metadata like id, QBER, etc.

Note on the communication on one side (top to bottom): this keystream is the only interface between the modules on one side. Next, there is no back-chatter between the modules, i.e. there is no communication inbetween, be it handshakes or anything else. These modules are loosely coupled. All a single module knows is where to pull the next key to process on and where to push the key once it's produced.

Data between modules on the same layer, e.g. BB84 Alice to BB84 Bob, have no format or syntax. Alice and Bob may interact freely across the network.

Addresses from which these modules get their keys, where to put the keys and where to connect or listen to their remote counterpart can have various formats though. One simple–and obvious–way is to connect the modules via standard UNIX stdin/stdout for the key pull/push line. However, there are more sophisticated ways like ipc:// (inter process communication) and even tcp://.