Quant
The quant
repository contains a prototypical software stack that allows to emulate a key exchange within a Quantum Key Distribution Network (QKDN).
Currently quant
contains the following three main parts: goKMS
, quantumlayer
, akms-simulator
goKMS
A Key Management System (KMS) for QKDN written in go.
The KMS receives an amount or random numbers (called bulk keys) from the
quantumlayers, whereas the actual amount will vary over time. Processes them
and provides a key store for each registered peer. So called forwarding routes
can be set through gnmi, either via assign-forwarding
or
key-routing-sessions
(see temp.yang).
If a route is configured the goKMS
that has no prev-hop
provided within its
route configuration, will initiate the process to exchange a so-called
platform-key
. After this both, start and end goKMS
should have a
platform-key for a KSA key exchange available.
Note well: This is currently not intended to be used in production environments, neither in networks that can be reached by everybody, nor in other uncontrolled settings.
Configuration of a goKMS
A goKMS can be configured through a configuration file, as seen below:
Id: "0ff33c82-7fe1-482b-a0ca-67565806ee4b" # ID of the kms
Name: kms01 # name of the kms
InterComAddr: 172.100.20.10:50910 # Address of the endpoint for inter communication
AkmsURL: "http://172.100.20.22:4444/api/v1/keys/push_ksa_key" # address of the rest endpoint of a connected AKMS (used for sending KSA key to the AKMS).
AkmsCkmsServerPort: "9696" # Port of connected AKMS
GnmiTLS: # Settings for TLS for gNMI endpoint. Can be overwritten with cli parameters.
TLS: true # Whether TLS is enabled
CAFile: "ssl/ca.crt" # Path to ca
CertFile: "ssl/kms/kms1-selfsigned.crt" # Path to cert
KeyFile: "ssl/kms/kms1-selfsigned.key" # Path to key
KmsTLS: # Settings for TLS for inter KMS communication
TLS: true # Whether TLS is enabled
CAFile: "ssl/ca.crt" # Path to ca
CertFile: "ssl/kms/kms1-selfsigned.crt" # Path to cert
KeyFile: "ssl/kms/kms1-selfsigned.key" # Path to key
QuantumModuleTLS: # Settings for TLS for quantum module communication
TLS: true # Whether TLS is enabled
CAFile: "ssl/ca.crt" # Path to ca
CertFile: "ssl/kms/kms1-selfsigned.crt" # Path to cert
KeyFile: "ssl/kms/kms1-selfsigned.key" # Path to key
AkmsCkmsTLS: # Settings for TLS for akms ckms interface
TLS: true # Whether TLS is enabled
CAFile: "ssl/ca.crt" # Path to ca
CertFile: "ssl/kms/kms1-selfsigned.crt" # Path to cert
KeyFile: "ssl/kms/kms1-selfsigned.key" # Path to key
Peers: # Peers to other goKMS
# peer to goKMS02
- PeerId: "5e41c291-6121-4335-84f6-41e04b8bdaa2" # id of the peer
PeerInterComAddr: 172.100.20.11:50910 # inter com endpoint of the peer
Sync: true # determines which peer partner is responsible for syncing
QuantumModule: # Quantum module used for this peer
Type: emulated # Type of the quantum module e.g. emulated or etsi
Address: 172.100.20.14 # Address of the quantum module
# peer to goKMS03
- PeerId: "f80db2c0-2480-46b9-b7d1-b63f954e8227"
PeerInterComAddr: 172.100.20.12:50910
Sync: false
QuantumModule:
Type: emulated
Address: 172.100.20.18
You can also provide some configuration via command line arguments. Only settings relevant for running goKMS with remote configuration via gNMI are available here. This includes gNMI TLS settings and log level. Furthermore a path to a configuration file can be provided. Keep in mind that cli arguments will be prioritized, so you can overwrite your gNMI settings in the config file with your cli arguments.
Available are the following flags:
Usage of goKMS:
-caFile string
location of the gNMI ca file (overwrites settings in config file)
-certFile string
location of the gNMI cert file (overwrites settings in config file)
-gnmiBindAddress string
address to bind gNMI to (overwrites settings in config file) (default ":7030")
-gnmiTLS
If true do use TLS for gNMI, paths to ca, cert and key must be set aswell (overwrites settings in config file)
-noGRPCPassthrough
set the default resolve scheme for grpc to not use passthrough, default is false
-keyFile string
location of the gNMI key file (overwrites settings in config file)
-kms_config string
path to the config file
-log string
logrus lof level (debug, info, warn, error, fatal, panic) (default "info")
Interfaces
Inter-KMS Communication
This interface is required for the communication between the peering KMS in order to coordinate their actions for key selection and key forwardwing path configuration. The definition can be found in: api/kmsintercom/kmsintercom/kmsintercom.proto
Interface to quantum modules
This interface is solely a go API within the proto-kms and is accessible here quantumlayer/quantumlayer.go as the interface definitions.
The goKMS
currently has two interfaces to communicate with a quantum module.
-
First there is our own interface implementation which can be found under: danet/quipsec This is the interface that is used within our implementation of an emulated quantum module (see
quantumlayer
). -
Second there is the REST-based implementation of ETSI014 which allows us to handle quantum modules that implemented the ETSI014 API (polling is currently hardcoded to 2 seconds).
gNMI
To manage the goKMS we provide an gNMI endpoint.
By using the gnmi-target package it is possible to manage (GET/SET/subscribe) configuration data of the KMS. Currently we use the temp.yang file for this and only a part of it is implemented yet.
Debug setup
For goKMS there is a debug setup available for VS Code.
- Set your breakpoints
- To use it run
make debug-kms-up
and wait for the build to complete. - If you see the first log outputs from the running docker setup start the debugger in VS Code named
kms-debug
.
If you are finished stop the debugger and run make debug-kms-down
to stop the environment.
Quantumlayer
An implementation of an emulated quantum module. It has two possible operation modes:
(Pseudo) Random Numbers
The generation of random numbers is done via the golang's math/rand pseudo random number generator(PRNG). The synchronization is done in an "offline" way, as both quantum modules simply wait to the next full 20 seconds on their clock before sending data. As both modules use the same seed for it's number generation, they will send the same data. After sending, it will sleep a given amount of time.
For this a quantumlayer uses the gRPC interface defined in: danet/quipsec.
Replay Numbers
The generation of random numbers is done with the help of a CSV file. This file should include a timestamp in ms and the number of bits that should be sent at that time. The quantum module always waits the given duration and then sends the given amount of data. For the random numbers, the same method as in the random operation mode is used.
Configuration of a quantumlayer
A quantumlayer can be configured through a configuration file, as seen below:
KMSAddr: "kms_1:50911" # The address of the connected goKMS.
OperationMode: "normal" # The operations mode. Can be either "normal" or "replay"
SleepTimerForGenerationInMs: 5000 # How long the module should sleep between each send process. Only relevant if mode is "normal"
Seed: 1337 # The seed for the random number generation. Must be the same on both matching quantum modules. If empty, the current day is used.
replayFilePath: './data.csv' # The path to the replay data. Only relevant if mode is "replay"
Also available are the following arguments:
Usage of quantumlayer:
-config string
path to the config file
-noGRPCPassthrough
set the default resolve scheme for grpc to not use passthrough, default is false (default false)
-log string
logrus lof level (debug, info, warn, error, fatal, panic), default: info (default "info")
akms-simulator
A simple simulation of an AKMS endpoint. This provides a REST endpoint to receive KSA keys from a goKMS
. The following functionalities are not implemented, the explanation is just there as a means of describing the KMS type. The 'A' stands for access and one of the main purposes of this type of KMS is providing a security barrier protecting the core network of a provider from malicious activity of an end user. Its further purpose is to interact with AAA instances of providers for contractual matters.
Usage
See the makefile for options.
To use private repos rename build_env.env.example
to build_env.env
and add valid credentials. If you have access, simply use your username and a GitLab access token.
Minimal Test Setup
A docker-compose file provides a minimal test setup to play around with quant
.

This minimal setup contains four goKMS
, with goKMS01
and goKMS04
as endpoints.
Both of those are then connected to a akms-simulator
. Quantumlayers
are
used as quantum modules.
Start and Stop
By running make compose-up
and make compose-down
the setup can be started
or stopped with its default config.
The default config is based on the configuration files provided in the config/goKMS and config/quantumlayer folder.
Setting routes
We provide some example .json
files to configure forwarding routes. They can
be found under config.
It is possible to configure the goKMS
through
gNMI. This also applies for setting
entries within the goKMS internal routing table. Therefore the paths
assign-forwarding
as well as key-routing-sessions
are both suitable.
The following is an example of a gNMI set request sent through gnmic:
gnmic -a "172.100.20.12:7030" -u admin -p admin --insecure -e JSON_IETF set --update-path 'key-routing-sessions/routing-sessions[path-id=38e0588b-6a2d-42c9-85a0-887cc877c299]' --update-file ./config/goKMS02-a.json
The .json
provided in this case contains information about previous
and next hops, as well as a path id.
{
"path-id": "38e0588b-6a2d-42c9-85a0-887cc877c299",
"prev-hop": {
"node-id": "0ff33c82-7fe1-482b-a0ca-67565806ee4b",
"ip-address": "172.100.20.10",
"port": 50910
},
"next-hop": {
"node-id": "968fd594-b0e7-41f0-ba4b-de259047a933",
"ip-address": "172.100.20.13",
"port": 50910
}
}
Instant playground
For an instant playground the bash script configure-and-run-docker-playground.sh
can be used (see
config/configure-and-run-docker-playground.sh). This adds two
key-routing-sessions which results in the exchange of two platform keys.
-
kms01
->kms02
->kms04
-
kms01
->kms03
->kms04
After that two requests from an AKMS are simulated through two curl requests.
Demo with goSDN-Controller
There is an additional playground where the goSDN-Controller can be used to configure goKMS. Therefore a small lab is provided.
Requirements:
- docker
- containerlab
Below is a short demo video of this setup in combination with the goSDN-Controller.
Contributing
Contributions are welcome! Please follow these guidelines:
- Fork the repository.
- Create a new branch.
- Make your changes.
- Submit a pull request.
Acknowledgements
Developed in the DemoQuanDT project ("Quantenschlüsselaustausch im deutschen Telekommunikationsnetz für höhere IT-Sicherheit", engl. quantum key exchange in the german telecommunications network for higher IT security).
The DemoQuanDT project is funded by the german ministry of education and research (BMBF).
