alan-mushi / ksi

'Keyless Signatures with Identity' implementation (Master 2 project)

Keyless Signatures with Identity - Master 2 project

Do not use in production (it's a PoC... and it uses pickle because time was lacking).

ksi's Issues

Merkle Trees

Implémentation du serveur

Pour la signature portant sur St il faudrait faire une structure permettant de changer d'algo de signature asymétrique facilement.

Sur le serveur il serait préférable d'utiliser le logger python en lieu et place de print() "sauvages".

Il serait de bon ton de commencer par concevoir un serveur émettant St par appel de fonction, puis d'ajouter la sérialisation des objets pythons échangés, enfin de rendre le serveur accessible sur un port TCP (issue #7). Pour réellement bien finir les choses une "message queue" (tel que RabbitMQ) des requêtes serait intéressant à ajouter et permettrait de scaler très facilement.

Benchmarks

Réaliser des benchmarks en faisant varier les algorithmes de hachage utilisés.

Toutes les autres issues doivent naturellement être finalisées avant celle ci!

Vérification de la signature

La vérification de la signature KSI est jugée fausse à l'étape de la vérification de la signature apposée par le serveur uniquement dans les fichiers api_server.py et api_client.py mais fonctionne parfaitement dans les tests unitaires... mystère.

API pour le serveur accessible par le réseau

À réaliser après la tâche #4

Créer une API JSON/XML/... pour accéder au service de création de timestamp (St) depuis le réseau. Il faudra bien entendu modifier le client pour qu'il utilise le service. Pour inspiration: https://tools.ietf.org/html/rfc3161

Utilisation d'une BDD

Pour le stockage des données:

1. Des certificats clients utilisés par le serveur (lecture seule pour le serveur, insertion pour les clients)
2. Des timestamps émis par le serveur (lecture-écriture pour le serveur, lecture seule pour les clients)
3. Des clés (publiques) utilisées pour signer les requêtes de timestamps par le serveur (insertion pour le serveur, lecture seule pour les clients)
4. Des signatures publiées par les clients (insertion pour les clients, pas d'accès pour le serveur)

Les points 1 et 3 correspondent à l'utilisation possible d'un serveur LDAP. Les points 2 et 4 correspondraient plus à des bases de type clé-valeur ou bien NoSQL avec un stockage en colonnes. Bien entendu il est possible d'utiliser un seul type de base SQL (MariaDB/PostgreSQL...) pour tous les usages.

Rappelons nous que dans les "publications KSI" il est explicité que le client puisse publier ses certificats et signatures d'une manière à ce que le serveur n'y ait pas accès en modification. Il est possible de traiter cette contrainte en fixant des politiques d'accès ou en employant des serveurs/BDD différents.

Pour ce point je pense que l'utilisation de systèmes de container est tout à fait justifiée.

Classe pour gérer les hash

J'ai fait une première version mais il est possible de simplifier le code

Génération des signatures KSI

Voir #5 pour quels éléments sont à coordonner.

À des fins de débug je pense qu'ajouter des couleurs sur les noeuds du hash tree présents dans ci (la hash chain) serait pratique (à ajouter dans Node.to_graphviz()).

Génération des certificats KSI

Vérification de la signature KSI

Il faudra coordonner avec le serveur l'algo/sérialisation utilisé(e) pour St.
Il faudra coordonner avec le client la sérialisation utilisée pour ci (la chaîne de hash).