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: ekms, quantumlayer, akms-simulator

ekms

A prototypical Key Management System (KMS) for QKDN.

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 ekms 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 ekms 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 ekms

A ekms can be configured through a configuration file, as seen below:

Id: "0ff33c82-7fe1-482b-a0ca-67565806ee4b" # ID of the ekms
Name: ekms01 # name of the ekms
InterComAddr: 172.100.20.10:50910 # Address of the endpoint for inter communication
GRPCAddr: 172.100.20.10:50900 # deprecated
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
Peers: # Peers to other ekms
    # peer to ekms02
    - 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 ekms03
    - PeerId: "f80db2c0-2480-46b9-b7d1-b63f954e8227"
      PeerInterComAddr: 172.100.20.12:50910
      Sync: false
      QuantumModule:
          Type: emulated
          Address: 172.100.20.18

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 ekms 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 ekms 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.

quantumlayer

A prototypical implementation of an emulated quantum module.

The generation of random numbers is done via the golang's crypto/rand pseudo random number generator (PRNG). The sending quantumlayer takes the generated random numbers and sends them by means of an UDP datagram to the receiving quantumlayer.

If the exchange was successful the corresponding quantumlayers forward the random numbers to the connected ekms for further processing. For this a quantumlayer uses the gRPC interface defined in: danet/quipsec.

Configuration of a quantumlayer

A quantumlayer can be configured through a configuration file, as seen below:

KMSAddr: "172.100.20.10:50910" # The address of the connected ekms.
UDPAddr: "172.100.20.14:50901" # The UDP address of the quantumlayer itself (used for the exchange of random numbers).
PeerUDPAddr: "172.100.20.15:50901" # The UDP address of the peer quantumlayer.
GenerateKeys: true # Sets the quantumlayer to generate keys and send them to the peer quantumlayer (only one of both should have this setting set to true).

Generation of Random Numbers

As mentioned above, golang's crypto/rand pseudo random number generator (PRNG).

First, rand is used to generate the amount of random numbers numRands and then uses this to generate the actual random numbers (stored in b). This is done in func (qlemuprng *QuantumlayerEmuPRNG) GenerateRandomNumbers() (randNums []byte)

• numRands, randError := rand.Int(rand.Reader, big.NewInt(1000)
• b := make([]byte, numRands.Uint64())
• _, randError = rand.Read(b)

Beyond Pseudo Random Number Generator (PRNG) based Emulation

Future versions of the quantum layer may include implementations of emulations of real quantum links.

akms-simulator

A simple simulation of an AKMS endpoint. This provides a REST endpoint to receive KSA keys from a ekms. 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. It's 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 ekms, with ekms01 and ekms04 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/ekms 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 ekms through gNMI. This also applies for setting entries within the ekms 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/ekms02-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 ekms. 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:

1. Fork the repository.
2. Create a new branch.
3. Make your changes.
4. 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).