CQP Tool kit

Le système fournit divers composants pour intégrer QKD dans un système de sécurité. Il est écrit en C++11 mais utilise des interfaces GRPC ce qui permet de l'intégrer avec de nombreux langages différents.

Démarrage rapide

Pour exécuter le logiciel nativement, soit :

téléchargez et installez les paquets deb Ubuntu ou
clonez la source, en vous assurant que les sous-modules sont mis à jour, et compilez localement

Pour cloner la source avec les sous-modules :```bash git clone --recurse-submodules [email protected]:QComms/cqptoolkit.git

> Si vous avez cloné sans utiliser `--recurse-submodules`, les sous-modules peuvent être mis à jour en exécutant `git submodule update --init` depuis le dossier source.

Voici une liste des dépendances nécessaires pour compiler le projet (veuillez lire plus bas pour plus de détails sur l'installation) :```bash
sudo apt install pkg-config ca-certificates file build-essential cmake ninja-build libusb-1.0-0-dev libcurl4-openssl-dev \
	libcrypto++-dev libcap-dev uuid-dev libssl-dev libsqlite3-dev libprotobuf-dev libgrpc++-dev \
	libssl-dev protobuf-compiler protobuf-compiler-grpc checkinstall
mkdir build-cqptoolkit
cd build-cqptoolkit
cmake -G Ninja ../cqptoolkit && ninja

Test rapide

Depuis le dossier de build, pour exécuter deux sites (sur le même ordinateur local) chacun avec un dispositif QKD , commencez par démarrer le site « A » en lançant un agent de site et en y connectant un « pilote factice » d'Alice : (Si les binaires ont été installés, omettez les chemins vers les commandes des instructions.)```bash ./src/Tools/SiteAgentRunner/SiteAgentRunner -p 8000 & ./src/Drivers/DummyQKDDriver/DummyQKDDriver -r localhost:8000 -a

ENTRÉE :```bash
./src/Tools/SiteAgentRunner/SiteAgentRunner -p 8001 &
./src/Drivers/DummyQKDDriver/DummyQKDDriver -r localhost:8001 -b

Cela ne commencera pas à produire une clé immédiatement, car ce système est conçu pour être contrôlé par un système de gestion, la connexion doit être établie avec la commande SiteAgentCtl.

Tout d'abord, vous pouvez vérifier la liste des périphériques disponibles avec :```bash ./src/Tools/SiteAgentCtl/SiteAgentCtl -d -c localhost:8000

ce qui devrait produire quelque chose de similaire par défaut, si *SiteAgentRunner* et *DummyQKDDriver* étaient lancés sans spécifier un argument de fichier de chaîne de configuration JSON :```json
{
 "url": "<hostname>:8000",
 "devices": [
  {
   "config": {
    "id": "dummyqkd__0__16_alice",
    "kind": "dummyqkd"
   },
   "controlAddress": "<hostname>:34219"
  }
 ]
}

et port 8001 devrait produire quelque chose de similaire à```json { "url": ":8001", "devices": [ { "config": { "id": "dummyqkd__0__16_bob", "side": "Bob", "kind": "dummyqkd" }, "controlAddress": ":38367" } ] }

- Maintenant, la connexion peut être établie en appelant :```bash
./src/Tools/SiteAgentCtl/SiteAgentCtl -c localhost:8000 -j localhost:8001

Cela créera un seul saut d'un site à l'autre, là encore, des itinéraires plus complexes peuvent être définis en utilisant l'option -a avec une chaîne JSON spécifiant le chemin.

Après quelques secondes, une clé devrait être disponible, qui peut être testée en demandant une clé.

NOTE : Le paramètre -k doit être l'URL affichée dans les détails du second site, pas "localhost:8001"```bash ./src/Tools/SiteAgentCtl/SiteAgentCtl -c localhost:8000 -k hostname:8001

Le lien peut être arrêté avec la commande unjoin:```bash
./src/Tools/SiteAgentCtl/SiteAgentCtl -c localhost:8000 -u localhost:8001

Notez que la clé est toujours disponible même si la génération a été arrêtée, tant que les agents du site sont en cours d'exécution. Elle peut être demandée avec la même commande de demande de clé ci-dessus.

Exemple de chiffrement

Avec les agents et pilotes de site lancés sur le même ordinateur local comme décrit ci-dessus et après avoir démarré le lien pour l'échange de clés, on peut également tester les fonctionnalités de chiffrement.

Tout d'abord, démarrez un côté du « VPN » sur bob qui écoutera sur le port 9010 et se connectera au magasin de clés de Bob :``` ./src/Tools/QTunnelServer/QTunnelServer -p 9010 --keystore-url=hostname:8001

Maintenant, démarrez le côté Alice du VPN, en définissant le tunnel à créer. Deux ports seront ouverts, un pour chaque côté sur 9000 et 9001, tout ce qui entre dans ces ports sera chiffré, transféré de l'autre côté, déchiffré et produit sur l'autre port.```
./src/Tools/QTunnelServer/QTunnelServer --keystore-url=`hostname`:8000 --remote=localhost:9010 --start-node=tcpsrv://0.0.0.0:9000 --end-node=tcpsrv://0.0.0.0:9001

Tout ce qui utilise des communications TCP peut alors utiliser ce port, netcat est un programme simple qui enverra des données sur les ports, démarrez-en un d'un côté :``` nc localhost 9000

et un sur l'autre:```
nc localhost 9001

Tout ce qui est tapé d’un côté apparaîtra de l’autre lorsque la touche Entrée est enfoncée. L’inspection des paquets transitant par les ports 9000 et 9001 avec un outil tel que Wireshark montrera les données chiffrées et l’ID de clé utilisé.

D’autres formes de connexion peuvent être créées, au lieu de tcpserv :

Progression

Fonctionnalités prévues et terminées

On espère que ce projet pourra s’avérer utile à la fois pour les travaux de recherche scientifique et pour les grands projets. Vous trouverez plus de détails sur le projet dans cet article.

Pour contribuer à ce projet, veuillez consulter le fichier Contribution.

Installation

Le système fonctionne actuellement sous Linux – Windows est prévu pour le futur. Pour l’instant, le plus simple est de compiler à partir des sources.

Image Docker

Il existe une image Docker prête à l’emploi dans le [registre gitlab][]. Vous pouvez l’exécuter avec sudo docker run -it --rm registry.gitlab.com/qcomms/cqptoolkit/runtime. Ajoutez une commande à la fin pour exécuter quelque chose directement, par exemple pour exécuter une simulation de la génération de clé QKD avec QKDSim :```bash sudo docker run -it --rm registry.gitlab.com/qcomms/cqptoolkit/runtime AlignmentTests

### Ubuntu 18.04+

Vous pouvez installer les paquets binaires depuis [Gitlab](https://gitlab.com/QComms/cqptoolkit/-/jobs/artifacts/master/download?job=package%3Adeb). Extrayez le fichier zip et installez les outils avec `dpkg`, cela signalera des dépendances manquantes mais ne vous inquiétez pas, la deuxième ligne les corrigera.```bash
sudo dpkg -i setup/*.deb build/gcc/CQP-*-Linux-{Algorithms,Networking,CQPToolkit,KeyManagement,QKDInterfaces,CQPUI,Simulate,Tools,UI,Drivers,IDQDevices}.deb
sudo apt install -fy

Pour installer les fichiers de développement (en-têtes et bibliothèques statiques), exécutez sudo dpkg -i build/gcc/CQP-*-Linux-*-dev.deb ; sudo apt install -fy à la place.

Depuis les sources

Bien sûr, si vous ne souhaitez pas modifier les versions de vos bibliothèques système et de vos dépendances, vous pouvez construire à l'intérieur d'un conteneur Docker qui a déjà toutes les dépendances installées avec :```bash sudo docker run -it registry.gitlab.com/qcomms/cqptoolkit/buildenv

Sinon, la construction à partir des sources nécessite d'installer les dépendances listées dans `setup/setupbuild.sh`, actuellement cela fonctionne pour Ubuntu et Arch Linux.

Clonez la source depuis [gitlab](https://gitlab.com/QComms/cqptoolkit.git) avec [git][] et compilez avec [CMake][] et [gnu make](https://www.gnu.org/software/make/) :
L'option `--recurse-submodules` ajoute les extras optionnels - l'accès à certains d'entre eux est restreint à UoB et ses partenaires, la construction fonctionnera sans eux.```bash
git clone --recurse-submodules https://gitlab.com/QComms/cqptoolkit.git

Si vous voulez obtenir tous les sous-modules, et disposez des identifiants appropriés, exécutez :```bash git submodule update --checkout

Maintenant, vous pouvez aller dans votre dépôt local et installer les dépendances avec le script (peut-être devez-vous modifier les permissions du fichier) :```bash
cd cqptoolkit/setup
./setupbuild.sh

Ensuite, vous pouvez construire le projet dans un nouveau dossier :```bash mkdir build-cqptoolkit cd build-cqptoolkit cmake ../cqptoolkit && nice make -s -j

this can be installed with

sudo make install

La build utilise [CMake][] pour produire des makefiles/solutions/etc pour de nombreuses plateformes différentes et est invoquée depuis un dossier de build vide qui contiendra tous les fichiers de sortie. Les builds de débogage produisent des packages suffixés par un « D ».
La build peut être contrôlée en passant des options à cmake, par exemple `-DBUILD_TESTING=OFF`. Exécutez cmake avec les options `-LH` pour lister les commutateurs disponibles.

Pour effectuer des modifications et développer la bibliothèque, il est recommandé d'installer [QT Creator](http://doc.qt.io/qtcreator/) et d'ouvrir le projet en [sélectionnant le fichier CMakeLists.txt](https://codeyarns.com/2016/01/26/how-to-import-cmake-project-in-qt-creator/). Il est conseillé d'utiliser des builds parallèles en allant dans Projects -> Build Steps -> Details et en ajoutant `-j<number>` aux paramètres de l'outil, voir [so](https://stackoverflow.com/questions/8860712/setting-default-make-options-for-qt-creator).
Une fois construits, les fichiers se trouvent par défaut au même niveau que le dossier du projet, nommé `build-<project name>-<platform>-<target>`.

> **Note à propos de protobuf + QT sur Ubuntu**
> La bibliothèque `qt5-gtk-platformtheme` est liée à une ancienne version de protobuf, ce qui empêchera nos programmes QT de s'exécuter.
> Cette dépendance optionnelle peut être supprimée avec `apt-get remove qt5-gtk-platformtheme`

## Exploration de la bibliothèque

    @startuml
        title Applicaiton Overview

        component "QKD Device Drivers" as drv
        interface IDevice as idev
        drv - idev

        component "Device contol and\n Key storage" as sa
        interface IKey as ikey
        sa - ikey
        sa ..> idev

    package "Key consumers" as kc {
        component "Custom VPN" as tun
        component "Custom\nWeb Server" as nginx
        component "HSM bridge" as hsm
    }
    tun ..> ikey
    nginx ..> ikey
    hsm ..> ikey

    package Utilities {
        component "Config/Control GUI" as gui
        component "Simulators/Testing" as sim
        component "Data extraction" as stats

        gui -[hidden]down- sim
        sim -[hidden]down- stats
    }
    @enduml

Voici un organigramme pour vous aider à trouver le domaine qui vous concerne, car le projet couvre de nombreux aspects différents de la QKD et de la gestion des clés - les contributeurs sont les bienvenus pour faire évoluer ce projet vers plus de spécialisation.
La QKD nécessite une forme de communication [non-clonable](https://en.wikipedia.org/wiki/No-cloning_theorem), généralement en utilisant des photons uniques sur un câble à fibre optique. Ils peuvent fonctionner en point à point ou en un-à-plusieurs, mais ils ont intrinsèquement un emplacement physique (là où la fibre se termine) - ils ne peuvent pas être virtualisés ! Le point auquel le photon est transmis ou détecté est la frontière du système sécurisé - presque comme le [pare-feu](https://en.wikipedia.org/wiki/Firewall_(computing)) d'un réseau. Une fois que les photons indivisibles ont été transformés en une chaîne de bits pour former une [clé symétrique](https://en.wikipedia.org/wiki/Key_(cryptography)), les règles standard de la sécurité informatique telles que l'authentification, le contrôle d'accès, etc., s'appliquent. La différence est qu'une fois ces clés produites, chacun des dispositifs QKD possède un nombre que [personne d'autre ne connaît](https://en.wikipedia.org/wiki/Shared_secret) [prouvé par la science](https://arxiv.org/pdf/quant-ph/0003004.pdf).

La nature de cet effet de « pare-feu » est que les systèmes contrôlant les dispositifs QKD doivent être sécurisés et considérés comme dignes de confiance - également appelés « nœud de confiance » - où et comment vous tracez la ligne peut aller de gardes armés à simplement [verrouiller la porte de la salle des serveurs](https://www.youtube.com/watch?v=rnmcRTnTNC8).

Si vous ne pouvez pas voir le diagramme ci-dessous, veuillez consulter la [documentation en ligne](https://qcomms.gitlab.io/cqptoolkit/), il peut également être construit par la cible `doc`.

    @startuml
    title Where to start \n

    skinparam activity {
      StartColor #EF476F
      BarColor #FFD166
      EndColor #EF476F
      BackgroundColor #06D6A0
      BorderColor #118AB2
    }

    start
    if (Do you have a QKD Device?) then (Yes)
        if (Does your QKD device have a driver?) then (No)
            :You will need to [[./index.html#CreatingDrivers create a driver]] which implements the
            <b>IDriver</b> and <b>IReporting</b> interfaces.;
            if (Use the library?) then (Yes)
                :See the [[./index.html#RunningDummyQKDDriver DummyQKDDriver]] for an example.;
            else (No)
            endif
        else (Yes)
        endif
    else (No)
        :Check out how to run the
        [[./index.html#RunningDummyQKDDriver DummyQKDDriver]];
    endif

    if (Do you want keys for multiple
    locations in a network?) then (Yes: Sites)
        :[[./index.html#Registering Register your driver]] with the site agent
        using the <b>ISiteAgent</b> Interface
        Keys can be obtained by using the [[./index.html#IKeyInterface IKey]] interface;

        if(Do you want keys to be stored/persist between restarts?) then (Yes)
            if (Do the keys need to be secured?) then (Yes)
                :Use the [[./index.html#HSMs HSM storage]] options;
                if (Is your HSM supported?) then (No)
                    :Create a driver that implements
                    the <b>IBackingStore</b> interface.
                    Add the driver creation to the
                    <b>BackingStoreFactory</b>;
                else (Yes)
                endif
            else (No)
                : When running SiteAgentRunner,
                use the option ""-b file"" or
                set ""backingStoreUrl"" to
                ""file:///filename.db"";
            endif
        else (No)
        endif
    else (No: Point-to-Point)
        :Use the [[./index.html#IDeviceInterface IDevice interface]] to
        control the driver for your system.
        As keys become available they will
        be sent via the call to <b>WaitForSession</b>.;
    endif

    if (Do you want to use the key for anything?) then (Yes)
        :See the [[./index.html#Encryption encryption section]]
        for an example of using the [[./index.html#IKeyInterface IKey interface]];
    else (No)
    endif
    stop

    @enduml


### Exécution de DummyQKDDriver <a name="RunningDummyQKDDriver" />

Cette section n'est qu'un commentaire sur la fonctionnalité utile de DummyQKDDriver pour simuler la sortie d'un dispositif QKD. Veuillez vous référer à la section suivante pour un exemple guidé pour configurer un lien simple avec eux.
Comme pour la plupart des programmes, lui passer `-h` affichera les options disponibles. Le DummyQKDDriver exécute un ensemble standard d'étapes de post-traitement sur des détections de photons simulées en utilisant la classe cqp::DummyQKD. Deux instances du programme doivent être exécutées, une pour Alice et une pour Bob.

Exécutez Bob en premier sur le port 8000 en appelant :```bash
DummyQKDDriver -b -k 0.0.0.0:8000

Maintenant, lancez Alice, en lui demandant de se connecter à Bob et de commencer l'échange de clé (en mode manuel) :```bash DummyQKDDriver -a -m localhost:8000

Si cela a fonctionné, vous obtiendrez un flot de messages d'erreur comme celui-ci : `ERROR: OnKeyGeneration No listener for generated key`. Cela est dû au fait que, même si exécuter le système de cette manière est agréable pour le voir faire quelque chose, ce n'est pas très utile : il n'y a nulle part où placer la clé générée. Les pilotes sont conçus pour être utilisés par quelque chose.

Le projet dispose d'un système de gestion des clés appelé [Site Agents](#SiteAgents) ou vous pouvez communiquer directement avec les pilotes via l'[interface IDevice](#IDeviceInterface)

### Configurer les Site Agents <a name="SiteAgents" />

Les site agents, les pilotes et les tunnels VPN doivent être paramétrés pour chaque nœud du réseau avec des fichiers de chaînes JSON, car la commande par défaut sans arguments ne spécifie pas tous les champs nécessaires par défaut et ne fonctionne que pour un test sur la même machine locale.

Les site agents peuvent être exécutés avec SiteAgentRunner ; nous pouvons exécuter deux sites avec :```bash
SiteAgentRunner -c site-a.json

et:```bash SiteAgentRunner -c site-b.json

avec chaque fichier JSON indiquant de manière appropriée un port différent pour Alice et Bob (par exemple 9000/9001). La chaîne JSON ressemble à ceci :```json
		{
		    "name":"",
		    "id":"",
		    "netManUri":"",
		    "bindAddress":"0.0.0.0",
		    "listenPort":9000,
		    "connectionAddress":"",
		    "credentials": {},
		    "useAutoDiscover":false,
		    "backingStoreUrl":"",
		    "fallbackKey":""
		}

Maintenant, nous pouvons attacher nos DummyQKDDriver's, un à chaque site :```bash DummyQKDDriver -c driver_config-a.json # run as Alice, register with site agent

et:```bash
DummyQKDDriver -c driver_config-b.json # run as Bob, register with site agent

avec chaque fichier JSON indiquant de manière appropriée un port différent pour Alice et Bob (par exemple 9000/9001). La chaîne JSON ressemble à ceci :```json {
"controlParams": { "config": { "id": "dummyqkd__0__16_alice", "side": "Alice", "switchName": "", "switchPort": "", "kind": "dummyqkd", "bytesPerKey": 0 }, "controlAddress": "'hostnameIP':4423", "siteAgentAddress": "127.0.0.1:9000" }, }

> Le champ d'adresse de contrôle peut être 0.0.0.0:0 s'il n'y a pas de pare-feu à gérer. Si c'est le cas, il faut indiquer l'adresse IP réelle de l'hôte et choisir un port approprié que le pare-feu ne bloquera pas.

Rien ne se passera encore car les agents du site ne savent pas quoi faire avec ces appareils. Nous pouvons leur ordonner de commencer à générer la clé (-b as begin) en envoyant la commande cqp::ISiteAgent::StartNode :```bash
SiteAgentCtl -c localhost:9000 -b '{"hops":[{"first":{"site":"'hostname':9000","deviceId":"dummyqkd__0__16_alice"},"second":{"site":"'hostname':9001","deviceId":"dummyqkd__0__16_bob"}}]}'

Les ordinateurs doivent pouvoir résoudre les noms d'hôte et ceux-ci devraient être utilisés ici à la place des adresses IP fixes. Il faut donc modifier les fichiers /etc/hostnames sur les deux machines si ce n'est pas le cas.

C'est une façon alambiquée de dire connecter A à B mais c'est très puissant, permettant de spécifier plusieurs sauts pour produire une clé sécurisée de bout en bout à partir d'une chaîne d'appareils. Cette chaîne JSON peut être spécifiée dans le champ de configuration "staticHops" des agents du site pour que cela se produise automatiquement une fois que tous les appareils sont disponibles. Le lien peut ensuite être arrêté avec :```bash SiteAgentCtl -c localhost:9000 -e '{"hops":[{"first":{"site":"'hostname':9000","deviceId":"dummyqkd__0__16_alice"},"second":{"site":"'hostname':9001","deviceId":"dummyqkd__0__16_bob"}}]}'

> Notez l'utilisation de `-e` au lieu de `-b` pour *terminer* le lien au lieu de le *commencer*.

Des configurations plus complexes peuvent être réalisées en implémentant vous-même l'interface cqp::remote::INetworkManager pour émettre les commandes. Les retours des appareils arrivent via l'interface cqp::remote::IReporting sur le même socket afin que vous puissiez réagir aux changements du système. [Ici](#Reporting) vous pouvez voir comment extraire des informations de l'interface de rapport avec l'outil StatsDump.

### Création de pilotes <a name="CreatingDrivers" />

L'application pilote est un pont entre les interfaces internes de l'appareil (cqp::IQKDDevice) et l'interface externe cqp::remote::IDevice. La classe cqp::RemoteQKDDevice gère la plupart du travail pour vous, l'application doit gérer la configuration et la création de l'appareil.

Le véritable travail consiste à créer un pilote pour configurer l'appareil et lire la clé. Si votre appareil produit uniquement des détections brutes, vous devrez configurer un [pipeline de traitement](#ProcessingPipelines) comme cqp::DummyQKD ou cqp::PhotonDetectorMk1 et cqp::LEDAliceMk1. Si votre appareil génère une clé prête à l'emploi comme cqp::Clavis3Device, vous devez la lire et la publier via l'interface cqp::IKeyCallback (utilisez cqp::KeyPublisher).

Ces deux approches nécessitent une forme de gestion de session, fournie par cqp::session::SessionController et cqp::session::AliceSessionController, qui implémentent les interfaces cqp::ISessionController et cqp::remote::ISession et sont utilisées par cqp::RemoteQKDDevice pour démarrer et arrêter l'appareil et son pair. Ce sont généralement les seuls nécessaires, mais dans certaines situations, ils doivent être spécialisés pour répondre aux exigences de l'appareil.

    @startuml Readme_Drivers
    title Anatomy of a driver
        package Application {
            namespace cqp #DDDDDD {
                class RemoteQKD
                interface IQKDDevice {
                    GetSessionController()
                }
                class "SessionController" as session
                interface "IDetector::Service" as detServ {
                    StartDetecting()
                    StopDetecting()
                }
                class "Provider<IDetectionEventCallback>" as provider {
                    Attach()
                    Dettach()
                    Emit()
                }

                RemoteQKD .r.> IQKDDevice : uses
                IQKDDevice -r[hidden]-> session
            }
            class Main {
                main()
            }
            class MyDriver
            class Detector

            MyDriver .u.|> cqp.IQKDDevice
            MyDriver o-u-> cqp.session
            Detector .u.|> cqp.detServ
            Detector -u-|> cqp.provider

            Main o-> MyDriver
            MyDriver o-> Detector
            Main o-u-> cqp.RemoteQKD

            note bottom of MyDriver
                In this case the driver is a simple detector
                which produces detection. Post processing detail not shown.
                MyDriver pull together all the parts to run the driver.
            end note

            note bottom of Detector
                The detector controls the device
                and outputs the data using the Provider
            end note
        }
    @enduml

### Enregistrement d'un pilote <a name="Registering" />

Au moment de la rédaction, tous les pilotes peuvent être enregistrés auprès d'un agent de site en utilisant le commutateur `-r`. Cela amène cqp::RemoteQKDDevice à appeler cqp::remote::ISiteAgent::RegisterDevice sur cqp::SiteAgent, qui utilisera ensuite l'interface cqp::remote::ISession pour démarrer/arrêter l'appareil.

### Interface IDevice <a name="IDeviceInterface" />

Cette interface permet un accès plus direct à l'appareil que via les agents de site. Les clés générées par l'appareil sont immédiatement renvoyées à l'appelant. Appelez d'abord cqp::remote::IDevice::WaitForSession, puis cqp::remote::IDevice::RunSession. Appelez cqp::remote::IDevice::EndSession pour arrêter la génération de clé.

### HSMs <a name="HSMs" />

Les [HSM](https://en.wikipedia.org/wiki/Hardware_security_module) sont des dispositifs de stockage qui sont des coffres-forts numériques physiquement sécurisés. Il existe une interface standard pour eux appelée [PKCS#11](https://en.wikipedia.org/wiki/PKCS_11). Chaque fabricant a ses propres interfaces et le support de PKCS#11 est approximatif, mais il existe une implémentation logicielle que nous utilisons comme référence appelée [SoftHSM2](https://www.opendnssec.org/softhsm/). La classe cqp::keygen::HSMStore fournit une implémentation qui relie cqp::SiteAgent à l'interface cqp::IBackingStore.

### Interface IKey <a name="IKeyInterface" />

Les sites fournissent des clés pour de nombreux points de terminaison (les magasins de clés disponibles peuvent être récupérés en appelant cqp::remote::IKey::GetKeyStores), elles peuvent être demandées en utilisant l'interface cqp::remote::IKey. Une fois qu'une nouvelle clé a été demandée, l'autre côté ne peut la récupérer que comme une clé existante - cela évite les conflits et les mauvaises utilisations des clés.

### Chiffrement <a name="Encryption" />

Plus de détails sur les implémentations spécifiques peuvent être trouvés dans :
* [Tunnels](https://gitlab.com/qcomms/cqptoolkit/-/blob/master/Tunnels.md)

### Rapports <a name="Reporting" />

Les modifications des valeurs dans le système sont publiées en externe via l'interface cqp::remote::IReporting et en interne avec la classe cqp::stats::Stat. Vous pouvez vous inscrire à toutes les statistiques en appelant cqp::remote::IReporting::GetStatistics avec le champ cqp::remote::ReportingFilter::listIsExclude défini sur `true` ou des filtres spécifiques peuvent être spécifiés.

### Pipelines de traitement <a name="ProcessingPipelines" />

Le protocole standard [BB84 QKD](https://en.wikipedia.org/wiki/BB84) nécessite des étapes de post-traitement pour transformer les détections brutes en clés utilisables.

- **Alignement** Trouver le début et la fin de la transmission réelle.
    + Ajustement des différences/dérives temporelles, etc.
    + Compensation des différences de phase ou autres entre l'émetteur et le récepteur, etc.
- **Tamisage** Rejeter les détections invalides
- **Correction d'erreurs** Corriger les détections incorrectes - sans divulguer les valeurs
- **Amplification de confidentialité** Hachage de la clé pour rendre inutiles les bits divulgués

Un exemple de pipeline de traitement peut être vu dans cqp::DummyQKD::ProcessingChain.

## Construction

Les builds sont gérés par le [système d'intégration continue](https://about.gitlab.com/product/continuous-integration/) de gitlab défini dans le fichier `.gitlab-ci.yml`.

Les images docker peuvent être construites manuellement en exécutant `setup/makeDocker.sh`.

### Windows

Ceci est un travail en cours.
Cette configuration a été testée sur Windows 10 et Windows Server 2016 avec Visual Studio 15 (2016).
Les configurations suivantes sont prises en charge.

| Système d'exploitation | VS 2017   | QT Creator    | Codeblocks    |
|:----------|-----------|---------------|---------------|
| Linux     |           | gcc           | gcc           |
| Windows   | MSVC      | MSVC / MSYS2  | MSYS2-Mingw   |

#### IDE

- [Visual Studio 2016][]
    + Exécutez le script [InstallVcPkg.bat](https://gitlab.com/qcomms/cqptoolkit/-/blob/master/build/vs2017_x64/InstallVcPkg.bat) une fois pour installer vcpkg dans C:\vcpkg
    + Exécutez le script [SetupMSBuild.bat](https://gitlab.com/qcomms/cqptoolkit/-/blob/master/build/vs2017_x64/SetupMSBuild.bat)
    + Ouvrez la solution [cqp.sln](https://gitlab.com/qcomms/cqptoolkit/-/blob/master/build/vs2017_x64/cqp.sln)
    + Sélectionnez Build->Solution
- [QT Creator pour Windows][]
    + QT Creator peut utiliser soit le compilateur natif Microsoft, soit MSYS2. Installez MSYS2 séparément, vous n'avez pas besoin d'installer le compilateur minGW qui vient avec l'installateur QTCreator. Ou installez le [Windows 10 SDK][]
    + Sous le menu des composants, sélectionnez les composants pour le compilateur que vous utilisez. Par exemple msvc2017
    + En utilisant "Open Project", sélectionnez le fichier `CMakeLists.txt` à la base de l'arborescence source.
- [MSYS2][] et [Codeblocks][]
    + Installez le paquet [MSYS2][].
    + Exécutez le script [installMSYS2Dependencies.bat](https://gitlab.com/qcomms/cqptoolkit/-/blob/master/build/installMSYS2Dependencies.bat)
    + Sous Settings->Debugger -> "Create config" appelé "MSYS2 GDB"
        - Changez le débogueur pour pointer vers gdb.exe (ex. C:\\msys64\\mingw64\\bin\\gdb.exe)
    + Sous Settings->Compiler
        + Copiez les paramètres du compilateur GCC, appelez-le "GCC - Old"
        + Changez le répertoire d'installation de la chaîne d'outils vers l'emplacement d'installation mingw64 de MSYS2 (ex. C:\\msys64\\mingw64)
        + Dans chacun des champs sous "Program Files" sauf le programme "make", supprimez le préfixe `mingw32-`.
        + Dans le champ make, ajoutez l'option -j pour permettre la construction multi-cœur : `mingw32-make.exe -j`
        + Sélectionnez le débogueur "MSYS2 GDB" précédemment créé
        + Si vous préférez une sortie lisible du compilateur, "Other Settings"->"Compiler Logging" à "Task description"
    + Dans le répertoire de construction CodeBlock (\\build\\CodeBlocks)
    + Exécutez le fichier `SetupCodeBlocks-MSYS2.bat`
    + Ouvrez le fichier de projet "CQP.cbp" de CodeBlocks.

Si votre fichier de projet a une structure de dossiers profonde (c'est un bug), elle peut être améliorée en faisant un clic droit sur l'espace de travail et :

- Décocher "Display folders as on disk"
- Cocher "Hide Folder Name"

## Citation de ce logiciel```
@Manual{,
title = {CQPToolkit: A QKD toolkit library},
author = {{Richard Collins, University of Bristol, UK}},
organization = {University of Bristol},
address = {Bristol, UK},
year = 2018,
url = {https://gitlab.com/QComms}
}

Lectures complémentaires

Pour plus de détails sur l'écriture de code pour la boîte à outils, consultez le Guide de codage Pour les questions et les problèmes, consultez la FAQ

CQPToolkit

Populaires