2. Installation

2.1. Installing QKDLite solution

In this section, we will guide you on how to set up a pair of virtual QKDLite nodes that can replicate keys from the main node to the remote node. You will need to get the installer package from pQCee to install QKDLite solution in your Virtual Machine (VM) or bare metal machine.

We will use the following example settings on two VMs to guide you through the installation process.

  1. QKDLite Main Node

    • Operating System: x64 Ubuntu Server 22.04 LTS (Jammy Jellyfish)

    • Node Name: QKDLITE_SAE_A

    • Username: pqcee

    • SAE Name: SAE_A

    • Intranet IP: 192.168.1.10

    • Public Internet IP: 1.2.3.4

  2. QKDLite Remote Node

    • Operating System: x64 Ubuntu Server 22.04 LTS (Jammy Jellyfish)

    • Node Name: QKDLITE_SAE_B

    • Username: pqcee

    • SAE Name: SAE_B

    • Intranet IP: 192.168.1.20

    • Public Internet IP: 4.3.2.1

2.1.1. Set Up the Virtual Machines

  1. Create two VM instances in your cloud infrastructure.

    1. Setup one VM for QKDLite Main Node.

    2. Setup a second VM for QKDLite Remote Node.

  2. Ensure that you can SSH into pqcee user account in each VM via its respective public internet IP address from your Internet administration machine.

    Listing 2.1  console: Secure Shell login to QKDLITE_SAE_A
    ssh -i ~/.ssh/<private_key.pem> pqcee@1.2.3.4
    Listing 2.2  console: Secure Shell login to QKDLITE_SAE_B
    ssh -i ~/.ssh/<private_key.pem> pqcee@4.3.2.1

  3. Update each VM to the latest patches and set the appropriate clock time zone.

    Listing 2.3  console: Update Ubuntu OS
    sudo apt update
sudo apt upgrade -y
sudo timedatectl set-timezone Asia/Singapore

    Note

    You may need to reboot the operating system at the end of this step.

  4. Copy the QKDLite installer package to the home root directory each VM. Please replace <private_key.pem> below with your SSH private key filename.

    Listing 2.4  console: Secure Copy QKDLite installer to VMs
    scp -i ~/.ssh/<private_key.pem> pQCee_QKDLite_3.2.0_installer_Ubuntu_2204_LTS_x64.tar.gz pqcee@1.2.3.4:~
scp -i ~/.ssh/<private_key.pem> pQCee_QKDLite_3.2.0_installer_Ubuntu_2204_LTS_x64.tar.gz pqcee@4.3.2.1:~

  5. Extract the QKDLite installer package into a directory. The created directory will have the same name as the .tar.gz filename.

    Listing 2.5  console: Extract QKDLite installer package
    tar -xzvf pQCee_QKDLite_3.2.0_installer_Ubuntu_2204_LTS_x64.tar.gz

2.1.2. Install QKDLite in the VMs

  1. Install QKDLite solution by executing the installer package.

    1. In each VM, execute the installer package and follow the instructions provided by the installer.

      Listing 2.6  console
      cd ~/pQCee_QKDLite_3.2.0_installer_Ubuntu_2204_LTS_x64
./install.sh

    2. The installer will request for the following information.

      1. External public IP address. If you assigned an external public IP address to the VM and the IP address is not detected by the installer, please type in the public IP address. Otherwise, press Enter to skip.

        Listing 2.7  console: QKDLite installer
        The following IP address(es) have been detected on this machine and they
will be included in the ETSI server certificate generation:
127.0.0.1 192.168.1.10

If you require additional external public IP address for inclusion in the
ETSI server certificate generation, please enter the IP address (or press
Enter for none): 1.2.3.4

      2. Organisation name. The organisation name is required to generate CA and server certificates for the ETSI server in the QKDLite node. Enter a string without spaces representative of your organisation.

        Listing 2.8  console: QKDLite installer
        Please enter organisation name: pQCee

      3. Certificate expiry (in years). Specify the number of years before the generated CA and server certificates expires. Press Enter to use the default setting of 10 years.

        Listing 2.9  console: QKDLite installer
        Please enter certificate expiry timeline in year(s): [10]

      4. SAE Name of main node and remote node. The Security Application Entity (SAE) name is required for the proper labelling of quantum keys to be provided via the ETSI server. We can use “SAE_A” for QKDLITE_SAE_A and “SAE_B” for QKDLITE_SAE_B. If you are on QKDLITE_SAE_A, press Enter to use the defaults for “SAE_A” for main node and “SAE_B” for remote node.

        Listing 2.10  console: QKDLite installer
        Please enter SAE name for this node: [SAE_A]

Please enter SAE name for remote node: [SAE_B]

      5. SSH details of remote node. The username and IP address of the remote node is required for the localhost node to connect to the remote node for key replication. Press Enter to use the same username as your localhost node, and enter the IP address of the remote node.

        Listing 2.11  console: QKDLite installer
        Please enter SSH username for remote node: [pqcee]

Please enter IP address for remote node (e.g., 192.168.1.10): 192.168.1.20

      6. HSM SO Pin. The Security Officer (SO) Pin is used to perform administration actions on the HSM. The installer installs SoftHSMv2 out of the box and the SO Pin allows you to create and delete HSM slots. Enter your SO Pin twice to confirm.

        Listing 2.12  console: QKDLite installer
        Please enter an SO Pin for the HSM:
Please enter the SO Pin again:

        Note

        Due to the sensitive nature of the secrets, characters typed for SO Pin, User Pin, and Transport Key Data will not be shown on screen.

      7. HSM User Pin. The HSM User Pin is used to add, delete and view keys stored inside the HSM slot. Enter your User Pin twice to confirm.

        Listing 2.13  console: QKDLite installer
        Please enter a User Pin for the HSM:
Please enter the User Pin again:

      8. Transport Key Data. The Transport Key Data is your secret used to create a Transport Key in the HSM slot. The Transport Key Data must be the same for both the main node and the remote node, otherwise key replication from main node to remote node will fail.

        Listing 2.14  console: QKDLite installer
        Please enter Transport Key data:
Please enter the Transport Key data again:

      9. Once you have entered the above information, the installer will proceed to install QKDLite.

2.1.3. Connect QKDLite Main Node to Remote Node

Once QKDLite has been installed on both main node and remote node, we will need to grant the right permissions for the main node to connect to the remote node to perform key replication.

  1. In QKDLite main node, copy the text contents of the qkdlite-mldsa-key.pub ssh client public key displayed on the console.

    Listing 2.15  console on QKDLite main node
    cd ~/.ssh
cat qkdlite-mldsa-key.pub
# copy contents of file printed on console output

  2. In QKDLite remote node, append the copied ssh client public key to the end of the authorized_keys file.

    Listing 2.16  console on QKDLite remote node
    cd ~/.ssh
vim authorized_keys
# append copied contents to this file

    Caution

    Ensure that you append the copied contents to a new line in the file. Otherwise, sshd is unable to authenticate against your newly-added public key in authorized_keys file.

    Tip

    You can use nano to edit files if you are not familiar with vim.

  3. Back to QKDLite main node, test that QKDLite main node can connect to the remote node.

    Listing 2.17  console on QKDLite main node
    cd ~/QKDLite
./replicate_create_keys_qrng.py QKDLITE_SAE_B TestKey 1
./replicate_delete_keys.py QKDLITE_SAE_B TestKey

    A successful connection will show a console output as follows:

    Listing 2.18  console output
    pqcee@QKDLITE_SAE_A:~/QKDLite$ ./replicate_create_keys_qrng.py QKDLITE_SAE_B TestKey 1
Creating QRNG key(s) locally on QKDLITE_SAE_A...
TestKey,4545aca956bb1f9c808338d5fb4b7f56
Exporting QRNG key(s) locally on QKDLITE_SAE_A...
TestKey, 4545aca956bb1f9c808338d5fb4b7f56, 60CA71133D81E38DBA5872105422EB247B6EF4F9CB3F31153BA151188130C10BD9062C44122BB789
Importing key(s) on remote QKDLite node QKDLITE_SAE_B...
TestKey,4545aca956bb1f9c808338d5fb4b7f56

pqcee@QKDLITE_SAE_A:~/QKDLite$ ./replicate_delete_keys.py QKDLITE_SAE_B TestKey
Deleting keys on remote QKDLite node QKDLITE_SAE_B...
TestKey,4545aca956bb1f9c808338d5fb4b7f56
Deleting keys locally on QKDLITE_SAE_A...
TestKey,4545aca956bb1f9c808338d5fb4b7f56

    Note

    The above instructions establish a one-way connection from QKDLITE_SAE_A to QKDLITE_SAE_B. If you require another one-way connection in the reverse direction from QKDLITE_SAE_B to QKDLITE_SAE_A, you will need to repeat the above instructions with QKDLITE_SAE_B as the main node.

2.2. Configure pQCee Quantum-safe TLS Proxy

If you require a quantum-safe connection between the QKDLite node to a classical TLS KME in your infrastructure, you can follow the instructions below to configure and deploy our quantum-safe TLS proxy.

The instructions assume deploying the quantum-safe TLS proxy as a VM on a cloud infrastructure.

  1. Setup a VM to be used as a TLS proxy.

    1. Create an Ubuntu 22.04 LTS VM on your cloud infrastructure with SSH access from the internet.

    2. SSH into the VM and patch to the latest apt updates.

      sudo apt update
sudo apt upgrade

    3. Install Docker Engine on Ubuntu.

  2. Install pQCee quantum-safe TLS proxy.

    1. Download our quantum-safe TLS proxy Dockerfile and nginx-conf/nginx.conf files into a directory in the VM.

    2. In the Dockerfile, set ARG KME_IP to the IP address of the KME. During the Docker image build process, the placeholder KME_IP in nginx-conf/nginx.conf will be replaced with the KME’s IP address.

    3. In the root of the directory containing our quantum-safe TLS proxy source files, build the docker image.

      sudo docker build -t oqs-nginx .

    4. Once the docker image is built, execute the container to listen at port 443.

      sudo docker run --detach --name oqs-nginx -p 443:443 oqs-nginx

  3. Verify that pQCee quantum-safe TLS proxy accepts quantum-safe TLS connections at port 443.

    1. On you local development system, use the command below to connect to the quantum-safe TLS proxy using the official FIPS ML-KEM-768 post-quantum cipher.

      docker run \
   -it openquantumsafe/curl \
   curl -k https://<public ip address> --curves mlkem768

      Note

      <public ip address> refers to the internet-facing IP address assigned to your VM on your cloud infrastructure.

    2. A successful quantum-safe TLS connection returns a “Welcome to nginx” homepage on your console.

  4. Configure QKDLite node to send network connections via pQCee quantum-safe TLS proxy to the QKD KME.

    1. In the qkdlite_init.sh file, set KME_IP to the IP address of the quantum-safe TLS proxy.

    2. Perform a QKD key creation operation using create_key_keyid.sh. A successful key creation means that the QKDLite node is now connecting to the quantum-safe TLS proxy using a quantum-safe TLS connection. Thus, the QKDLite node now connects to the QKD KME via the pQCee quantum-safe TLS proxy.