secure-protocol

v1.0.1

Published

6 hours ago

Standard d'interopérabilité et de vérification cryptographique pour attestations numériques

0High
0Medium
0Low

adama_traore

secure protocol crypto signature bf

SecureProtocol 🛡️

Standard d'interopérabilité et de vérification cryptographique pour attestations numériques.

📌 Présentation

SecureProtocol est une bibliothèque Node.js robuste conçue pour garantir l'intégrité et l'authenticité technique des documents numériques (diplômes, attestations, certificats). Elle repose sur une architecture décentralisée et asymétrique permettant des vérifications immédiates en ligne ou hors-ligne.

🚀 Fonctionnalités

Scellage Hybride & Flexible :
- Mode Embarqué (Par défaut) : La preuve cryptographique est insérée directement à la fin du fichier cible, délimitée par un marqueur standard.
  [!IMPORTANT] Restriction stricte de format : Le mode embarqué est exclusivement et uniquement réservé aux fichiers au format PDF (.pdf). Tout autre format de fichier (texte, ZIP, images, etc.) soumis en mode embarqué sera rejeté avec une exception UNSUPPORTED_EMBEDDING_FORMAT pour éviter la corruption de fichier.
  Toute tentative de scellage successif sur un document déjà signé est bloquée (la co-signature/co-existence des clés n'étant pas encore supportée).
- Mode Détaché : La preuve est stockée séparément dans un fichier compagnon portant l'extension .secure. Obligatoire pour tous les autres formats : .txt, images, documents Office (.docx, .xlsx, .pptx), fichiers structurés (JSON, XML, HTML) et archives ZIP.
Scellage d'Archives ZIP Intelligent :
- Mode Archive : Calcule le hash global et signe l'archive ZIP entière comme un fichier monolithique binaire unique.
- Mode Extracted : Décompresse le ZIP, extrait et scelle individuellement chaque fichier à l'intérieur en y injectant sa propre preuve embarquée, puis renvoie le tableau complet des documents d'origine et leurs preuves associées.
Détection Automatique à la Vérification : Détection transparente du mode de scellage (embarqué ou détaché) lors des appels de vérification de l'authenticité et de l'annulation.
Métadonnées et Auto-suffisance : Présence obligatoire de l'identifiant émetteur (issuer au format DID) et de sa clé publique (publicKey) au sein de la preuve (norme 1.0.0), facilitant les audits décentralisés.
Multi-Algorithmes : Support natif d'ECDSA (paires de clés au format JWK standard), Ed25519, et RSA.
Séparation des Responsabilités (Sémantique vs Cryptographie) : Le protocole garantit l'intégrité et l'authenticité technique d'une suite d'octets brute, sans présumer de sa validité sémantique. La validation de format (ex: s'assurer qu'un document à sceller n'est pas corrompu ou qu'un PDF respecte bien la structure binaire PDF via ses en-têtes) relève exclusivement de la couche applicative (l'application cliente) avant la soumission au scellage. Le noyau du protocole reste ainsi agnostique, exempt de dépendances lourdes, et hautement performant.
Architecture de Production : Conformité aux principes SOLID, pattern Façade, tolérance aux pannes réseau et BDD lors des vérifications de révocation, immunité contre les attaques TOCTOU, protection contre la pollution de prototype, et validation stricte de schéma de preuve à l'exécution.

🛠️ Installation

# Installation locale
npm install ../secure-protocol

📖 Utilisation Rapide

1. Initialiser l'identité de l'Université (Génération ECDSA JWK)

const SecureProtocol = require('secure-protocol');

async function genererIdentite() {
    // Génère une paire de clés ECDSA P-256 exportée au format standard JWK (JSON Web Key)
    const { privateKey, publicKey } = await SecureProtocol.initializeUniversityIdentity();
    
    console.log("Clé Privée Université (JWK) :", privateKey);
    console.log("Clé Publique Université (JWK) :", publicKey);
}

2. Sceller un document (Côté Université / Émetteur)

Le scellage d'un fichier accepte des options pour configurer l'intégration de la preuve et ses métadonnées.

const SecureProtocol = require('secure-protocol');

async function emettreDiplome(privateKeyJWK, publicKeyJWK) {
    // Utilise automatiquement ECDSASigner par défaut (Performance & Sécurité maximales)
    const protocol = new SecureProtocol();
    
    // Exemple 1 : Scellage en Mode Embarqué (par défaut) avec métadonnées d'émetteur
    const optionsEmbarque = {
        embed: true, // optionnel car activé par défaut
        issuer: "Université Virtuelle du Burkina Faso",
        publicKey: publicKeyJWK
    };
    const proof1 = await protocol.sealFile('./diplome.pdf', privateKeyJWK, optionsEmbarque);
    console.log("✅ Diplôme scellé en mode embarqué. Preuve intégrée directement dans 'diplome.pdf'.");

    // Exemple 2 : Scellage en Mode Détaché (génère un fichier compagnon 'diplome2.pdf.secure')
    const optionsDetache = {
        embed: false,
        issuer: "Université Virtuelle du Burkina Faso",
        publicKey: publicKeyJWK
    };
    const proof2 = await protocol.sealFile('./diplome2.pdf', privateKeyJWK, optionsDetache);
    console.log("✅ Diplôme scellé en mode détaché. Fichier de preuve 'diplome2.pdf.secure' généré.");
}

3. Vérification Modulaire et Explicite (Côté Vérificateur / Plateforme)

La vérification de l'authenticité et de l'annulation détecte automatiquement et de façon transparente si la preuve est intégrée (mode embarqué) ou séparée (mode détaché).

Conformément à la philosophie de souveraineté Zero-Trust, le protocole privilégie l'injection explicite de la clé publique officielle de confiance de l'émetteur (publicKey) lors de la vérification locale ou en ligne. Si aucune clé publique explicite n'est fournie, le protocole résout par défaut la clé stockée dans la preuve scellée pour l'audit décentralisé.

const SecureProtocol = require('secure-protocol');

async function verifierDiplome(publicKeyJWK) {
    // Utilise l'algorithme par défaut ECDSA
    const protocol = new SecureProtocol();
    
    // Étape A : Vérification d'Authenticité (Détection automatique du mode + injection explicite de la clé publique de l'université émettrice !)
    const isAuthentic = await protocol.verifyFileAuthenticity('./diplome.pdf', publicKeyJWK);
    if (!isAuthentic) {
        console.error("❌ Document FALSIFIÉ, signature invalide ou clé publique incorrecte.");
        return;
    }
    console.log("✅ Document cryptographiquement AUTHENTIQUE et intègre.");

    // Étape B : Vérification d'Annulation (En ligne, exécutée UNIQUEMENT si le document est authentique)
    try {
        const isNotCancelled = await protocol.checkFileRevocation('./diplome.pdf', 'https://api.universite.edu/revocation');
        if (isNotCancelled) {
            console.log("✅ Le diplôme est ACTIF et valide.");
        } else {
            console.log("❌ Le diplôme a été ANNULÉ (RÉVOQUÉ) par l'université.");
        }
    } catch (error) {
        if (error.code === 'REVOCATION_ACCESS_DENIED') {
            console.warn("⚠️ Contrôle d'annulation impossible : accès BDD refusé par l'université.");
        } else if (error.code === 'REVOCATION_DATABASE_UNAVAILABLE') {
            console.warn("⚠️ Contrôle d'annulation impossible : base de révocation indisponible.");
        } else {
            console.warn("⚠️ Erreur réseau lors de la vérification.");
        }
        console.log("ℹ️ Le diplôme reste cryptographiquement authentique (Étape A validée).");
    }
}

4. Démonstration en Ligne de Commande (CLI)

Un outil CLI de production (bin/secure.js) est intégré à la bibliothèque. Il utilise de manière native la stratégie ECDSA (P-256) par défaut, mais vous permet de spécifier un algorithme de signature alternatif en fin de commande :

# Sceller un document (ECDSA P-256 par défaut)
node bin/secure.js sign diplome.pdf private_key.pem

# Sceller un document en spécifiant explicitement RSA ou Ed25519
node bin/secure.js sign diplome.pdf private_key.pem RSA
node bin/secure.js sign diplome.pdf private_key.pem Ed25519

# Vérifier l'intégrité et l'authenticité (l'algorithme est auto-détecté dynamiquement depuis la preuve !)
node bin/secure.js verify diplome.pdf public_key.pem

🔑 Formats de Preuve et de Clés

Afin de garantir une interopérabilité maximale, le protocole standardise la structure de ses preuves et accepte les formats de clés industriels suivants.

1. Structure de la Preuve Cryptographique (`proof`)

Une preuve de confiance générée par le protocole (norme 1.0.0) est un objet JSON structuré de la manière suivante :

{
  "version": "1.0.0",
  "algorithm": "ECDSA",
  "hash": "a591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b57b277d9ad9f12fc",
  "signature": "3045022100e1a47fb2cfb7b190d62c65bf0bcda32b57b277d9ad9f12fca591a6d40bf420404a",
  "timestamp": 1779541724400,
  "issuer": "Université Virtuelle du Burkina Faso",
  "publicKey": {
    "kty": "EC",
    "crv": "P-256",
    "x": "MKBCTNIcKUSDii11ySs3526iYIGtb7wHbgOkUM16wUM",
    "y": "8cT2EFMcIYJk4T97cO15GPT73FG9Hn3HbgOkUM16wUM"
  },
  "revocationUrl": "https://api.uvbf.edu.bf/v1/revocation"
}

Spécification des Champs de la Preuve

2. Format d'Embarquement de la Preuve (Mode Embarqué)

Dans le mode embarqué (exclusivement réservé aux fichiers .pdf), la preuve de confiance est intégrée directement à la fin du fichier physique. Cette architecture évite l'utilisation de fichiers compagnons externes tout en préservant l'intégrité du document original.

[!WARNING] L'injection de données textuelles brutes après le flux binaire d'origine d'un fichier non supporté (comme un ZIP ou une image) altère sa structure interne (ex: signature EOCD corrompue dans un ZIP). Le mode embarqué ne doit jamais être forcé pour des fichiers autres que PDF. Pour tout autre format, utilisez obligatoirement le mode détaché.

Pour y parvenir, le protocole insère un délimiteur/marqueur standard unique pour marquer la transition entre le flux binaire d'origine et la structure JSON de la preuve :

Le Délimiteur Standard : \n--SECURE-PROTOCOL-PROOF--\n (représenté par la constante PROOF_MARKER dans le code source).

Structure Physique du Fichier PDF Scellé

Le fichier scellé résultant se présente sous la forme de blocs de données contigus :

[=== Données Binaires du Document PDF Original ===]
--SECURE-PROTOCOL-PROOF--
{
  "version": "1.0.0",
  "algorithm": "ECDSA",
  "hash": "...",
  "signature": "...",
  "timestamp": ...,
  "issuer": "...",
  "publicKey": { ... }
}

Mécanisme d'Extraction et d'Isolation (Zero-Trust)

Lors de l'audit ou de la vérification de l'authenticité :

Le lecteur binaire cherche la position du délimiteur --SECURE-PROTOCOL-PROOF-- à partir de la fin du fichier (ou via flux de lecture continu).
Le fichier est virtuellement segmenté en deux :
- Partie Supérieure (Avant le délimiteur) : Représente le document original intègre. Son empreinte SHA-256 est recalculée dynamiquement.
- Partie Inférieure (Après le délimiteur) : Représente la preuve JSON.
Le validateur compare le hash recalculé de la partie originale avec la valeur du champ hash stockée dans la preuve, garantissant que le document n'a subi aucune modification postérieure au scellage.

3. Formats de Clés Supportés

A. ECDSA (Format JWK - Standard Web JSON)

Les clés elliptiques sont stockées sous forme d'objets JSON standards (RFC 7517).

Clé Publique :

{
  "kty": "EC",
  "crv": "P-256",
  "x": "MKBCTNIcKUSDii11ySs3526iYIGtb7wHbgOkUM16wUM",
  "y": "8cT2EFMcIYJk4T97cO15GPT73FG9Hn3HbgOkUM16wUM"
}

Clé Privée (contient le paramètre secret "d") :

{
  "kty": "EC",
  "crv": "P-256",
  "x": "MKBCTNIcKUSDii11ySs3526iYIGtb7wHbgOkUM16wUM",
  "y": "8cT2EFMcIYJk4T97cO15GPT73FG9Hn3HbgOkUM16wUM",
  "d": "nsrtd15G9Hn3HbgOkUM16wUMfT2EFMcIYJk4T97cO15G"
}

B. Formats PEM (Blocs de texte classique en Base64 - SPKI / PKCS#8)

Le protocole supporte de façon transparente les clés PEM pour l'ensemble de ses stratégies de signature (y compris ECDSA). Des clés ECDSA P-256 par défaut (private_key.pem et public_key.pem) sont fournies à la racine du projet pour vos démonstrations.

Exemple de Clé Publique ECDSA (PEM - Standard SPKI) :

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWUW5f9hJoi+4fg7AT+mLna8Sn+ld
ctm0Ysy3kCBfjwCiKS97e+ihmTrOa10QzUX1yE0ry1nNIhYz5MntkpZPtA==
-----END PUBLIC KEY-----

Exemple de Clé Publique RSA (PEM) :

-----BEGIN PUBLIC KEY-----
MIIB## 📖 Référence de l'API Développeur (v1.0.0)

Cette section fournit les spécifications détaillées et des exemples d'intégration pour toutes les méthodes publiques exposées par la classe façade SecureProtocol.

1. Administration d'Identité et Cryptographie

🔹 `SecureProtocol.initializeUniversityIdentity()`

Description : Méthode statique générant une paire de clés asymétriques sur la courbe elliptique ECDSA (P-256) au format standardisé JWK (JSON Web Key) (conforme à la RFC 7517).
Retour : Promise<Object> sous la forme { privateKey: Object, publicKey: Object }.
Exemple :

const SecureProtocol = require('secure-protocol');

async function genererCles() {
    const { privateKey, publicKey } = await SecureProtocol.initializeUniversityIdentity();
    console.log("Clé Privée (Émetteur) :", JSON.stringify(privateKey));
    console.log("Clé Publique (Vérificateur) :", JSON.stringify(publicKey));
}

2. Services de Scellage (Émission de Preuves)

🔹 `async seal(data, privateKey, options)`

Description : Scelle une suite d'octets ou une chaîne de caractères en calculant son empreinte SHA-256 et en la signant cryptographiquement.
Paramètres :
- data : String | Uint8Array | Buffer — [OBLIGATOIRE] Le contenu brut à signer.
- privateKey : Object | String — [OBLIGATOIRE] Clé privée JWK ou PEM.
- options : Object — [OBLIGATOIRE] Configurations de métadonnées :
  - issuer : String [OBLIGATOIRE] Identifiant DID ou nom officiel de l'université.
  - publicKey : Object | String [OBLIGATOIRE] Clé publique associée (embarquée dans la preuve).
  - asText : Boolean (Optionnel, défaut false) Si true, le contenu est traité comme du texte clair.
  - embed : Boolean (Optionnel, défaut true) Injecte la preuve directement dans le texte si asText est actif.
  - revocationUrl : String (Optionnel) URL du registre de révocation.
Retour : Promise<Object | String> — L'objet proof JSON (mode détaché) ou le texte signé avec preuve concaténée (mode embarqué).

🔹 `async sealFile(filePath, privateKey, options)`

Description : Version physique de la méthode seal, appliquant le scellage sur un fichier du disque via flux asynchrones.
Contraintes :
[!WARNING] L'option options.embed = true (activée par défaut) est strictement interdite pour tous les formats autres que le PDF (.pdf). Si vous tentez de sceller un fichier non-PDF en mode embarqué, le protocole jettera immédiatement une exception UNSUPPORTED_EMBEDDING_FORMAT pour empêcher la corruption du fichier binaire cible. Pour tous les autres formats (images, ZIP, Office, XML/JSON), vous devez spécifier options.embed = false.
Exemple :

const protocol = new SecureProtocol();

// Mode Embarqué (PDF uniquement)
const proofPDF = await protocol.sealFile('./diplome.pdf', privateKey, {
    issuer: "UVBF",
    publicKey: publicKeyJWK,
    embed: true // Intègre la preuve en queue de fichier
});

// Mode Détaché (Obligatoire pour les autres formats)
const proofZIP = await protocol.sealFile('./certificats.zip', privateKey, {
    issuer: "UVBF",
    publicKey: publicKeyJWK,
    embed: false // Génère la preuve détachée à sauvegarder sous format .secure
});

🔹 `async sealZip(zipBuffer, privateKey, options)`

Description : Service dédié aux archives ZIP. Propose deux modes de fonctionnement selon les besoins de certification.
Paramètres :
- zipBuffer : Uint8Array | Buffer | ArrayBuffer — [OBLIGATOIRE] Contenu binaire du fichier ZIP.
- privateKey : Object | String — [OBLIGATOIRE] Clé privée.
- options : Object — [OBLIGATOIRE] Métadonnées (issuer, publicKey obligatoires) avec :
  - mode : 'archive' | 'extracted' (Optionnel, par défaut 'archive').
Comportement des modes :
1. Mode 'archive' (Monolithique) : Signe le fichier ZIP global en tant que fichier unique. Retourne un objet de preuve unique (proof).
2. Mode 'extracted' (Granulaire) : Décompresse le ZIP en mémoire, ignore les fichiers système cachés, scelle individuellement chaque document extrait et renvoie un tableau de résultats.
Retour (Mode 'extracted') : Promise<Array<Object>> où chaque élément a la structure :
- fileName : String (chemin d'accès relatif dans l'archive).
- originalBytes : Uint8Array (les octets du fichier original non altérés).
- proof : Object (la preuve cryptographique individuelle associée).
- success : Boolean (indique si le scellage individuel a réussi).
Exemple :

const protocol = new SecureProtocol();

// 1. Mode Archive
const globalProof = await protocol.sealZip(zipBuffer, privateKey, {
    mode: 'archive',
    issuer: "UVBF",
    publicKey: publicKey
});

// 2. Mode Extracted (Individuel)
const itemsSealed = await protocol.sealZip(zipBuffer, privateKey, {
    mode: 'extracted',
    issuer: "UVBF",
    publicKey: publicKey,
    embed: true // Tente d'embarquer la preuve (bloqué pour les non-PDF à l'intérieur du ZIP)
});

🔹 `async sealBatch(filePaths, privateKey, options)`

Description : Traite un tableau de chemins de fichiers en parallèle.
Comportement : Utilise le processeur de lot interne avec un contrôle de concurrence maximal (10 workers simultanés par défaut) et un rate limit de 50 opérations/sec pour éviter d'épuiser l'E/S disque et le CPU.

3. Services de Vérification et d'Audit (Zéro-Trust)

Le protocole propose des méthodes modulaires de vérification (séparant l'authenticité locale du contrôle d'annulation en ligne) ainsi qu'une API d'audit globale idéale pour les applications Web.

🔹 `async verifyFileAuthenticity(filePath, publicKey = null, options = {})`

Description : Vérifie localement (hors-ligne) que le fichier n'a pas été altéré (intégrité) et qu'il provient bien du détenteur de la clé publique (authenticité). Détecte automatiquement si la preuve est embarquée ou détachée.
Paramètres :
- filePath : String — [OBLIGATOIRE] Chemin du fichier.
- publicKey : Object | String | null (Optionnel) La clé publique officielle de confiance. Si passée à null, le validateur extrait et utilise la clé publique incluse au sein de la preuve pour effectuer un audit autonome.
Retour : Promise<Boolean> — true si le document est authentique et valide localement.

🔹 `async checkFileRevocation(filePath, registryUrl, options = {})`

Description : Interroge en ligne le registre d'annulation (registre de révocation) spécifié pour vérifier si l'empreinte (hash) du document y est déclarée révoquée.
Comportement (Fail-Closed) : En cas d'indisponibilité du registre (erreur HTTP, BDD injoignable, timeout), la méthode lève une exception et bloque la validation pour empêcher l'utilisation d'un document potentiellement annulé.
Retour : Promise<Boolean> — true si le document est ACTIF (non révoqué).

🔹 `async verifyFile(filePath, publicKey, registryUrl = null, options = {})`

Description : Méthode d'audit unitaire combinée. Vérifie l'authenticité locale puis, si une URL de registre est disponible (fournie en paramètre ou extraite de la preuve), effectue la vérification de révocation en ligne.
Retour : Promise<Boolean> — true si le document est authentique localement ET actif en ligne.

🔹 `async verifyDocuments(files, registryUrl = null, options = {})`

Description : API d'audit haut niveau conçue pour le traitement en mémoire (idéale pour les navigateurs web recevant des fichiers via glisser-déposer).
Paramètres :
- files : Array<Object> — [OBLIGATOIRE] Liste d'objets { name: String, data: Uint8Array }. Les fichiers .secure représentent des preuves détachées, les autres représentent des documents de données.
- registryUrl : String | null (Optionnel) URL pour forcer la vérification de révocation globale.
Logique d'Association Automatique :
1. Calcule le hash de chaque document de données.
2. Associe chaque document à sa preuve détachée correspondante (si un fichier .secure porte sur le même hash d'origine), activant le mode détaché.
3. Si aucune preuve détachée n'est associée, le protocole recherche et extrait une preuve en queue de fichier, activant le mode embarqué.
4. Si un fichier .secure n'est associé à aucun document, il est validé de façon isolée en tant que preuve seule (renvoyant un avertissement demandant le document original).
Retour : Promise<Array<Object>> — Rapports détaillés avec historique d'audit (auditLog) utile pour l'affichage de consoles de débogage cryptographique.
Exemple :

const protocol = new SecureProtocol();

// Fichiers récupérés du navigateur (PDF original + preuve détachée .secure)
const filesToAudit = [
  { name: "diplome.pdf", data: new Uint8Array(...) },
  { name: "diplome.pdf.secure", data: new Uint8Array(...) }
];

const reports = await protocol.verifyDocuments(filesToAudit, "https://api.uvbf.edu/revocation");
reports.forEach(report => {
    console.log(`Fichier: ${report.fileName} | Validé: ${report.success}`);
    console.log("Trace de l'audit :");
    report.auditLog.forEach(step => console.log(`  [${step.status.toUpperCase()}] ${step.msg}`));
});

4. Utilitaires d'Injection et d'Extraction Bas Niveau

Si votre application gère les flux mémoires directement, vous pouvez utiliser les méthodes de sérialisation et d'extraction de bas niveau sans passer par le système de fichiers.

🔹 `embedProof(bufferOrString, proof)`

Description : Concatène la preuve cryptographique à la fin du contenu original en insérant le marqueur --SECURE-PROTOCOL-PROOF--.
Paramètres :
- bufferOrString : String | Uint8Array | Buffer | ArrayBuffer — Contenu d'origine.
- proof : Object — Preuve JSON conforme à la structure v1.0.0.
Retour : Uint8Array | String (conserve le type de l'entrée d'origine).

🔹 `extractEmbeddedProof(bufferOrString)`

Description : Recherche le délimiteur standard à partir de la fin du flux, fragmente le contenu et extrait la preuve.
Retour : Object sous la forme { originalBuffer: Uint8Array, proof: Object | null }.

🏗️ Architecture Technique et Modularité (SRP)

Le package secure-protocol est conçu selon des normes architecturales rigoureuses (principes SOLID, pattern Façade et Strategy) pour garantir extensibilité et immunité en production :

src/index.js (Façade unifiée) : Point d'entrée de la bibliothèque exposant l'API publique (SecureProtocol). Elle orchestre les appels en déléguant les traitements métiers aux services dédiés et résout la stratégie de signature appropriée selon le document.
src/services/FileSealService.js : Responsable de l'orchestration du processus de signature (scellage) et de vérification d'authenticité technique/d'intégrité.
src/services/IdentityService.js : Responsable unique de la génération des identités cryptographiques universitaires (paires de clés au format standard JWK).
src/services/RevocationService.js : Responsable de l'interrogation en ligne des registres de révocation pour vérifier le statut d'annulation d'un document.
src/utils/FileHandler.js : Responsable des opérations physiques d'entrées/sorties (lecture, écriture, tronquage de fichiers, insertion ou extraction de preuves en queue de fichier en mode classique ou streaming).
src/utils/StreamHandler.js : Prépare et sécurise l'ouverture de flux de lecture pour le streaming.
src/utils/BatchProcessor.js : Gère le traitement par lots en parallèle avec rate limiting et contrôle de concurrence.
src/core/Hasher.js : Calcule l'empreinte (hash SHA-256) d'un contenu ou d'un flux de données.
src/core/signers/ (Stratégies de signature) : Contient l'abstraction commune (SignerStrategy) et ses implémentations concrètes (RSA, ECDSA P-256, Ed25519) pour la signature et la vérification cryptographique.
src/errors/SecureError.js : Gestion polymorphique centralisée des erreurs de l'application via une classe d'exception typée.

🛡️ Robustesse de Production

Inviolabilité et Validation du Timestamp : Hachage combiné du hash du document et du timestamp lors de la signature et de la vérification, empêchant toute modification ou manipulation de la date de scellage après émission. De plus, une validation stricte du chronométrage local rejette immédiatement les preuves dont le timestamp est situé dans le futur au-delà d'une dérive tolérée de 5 minutes (marge d'erreur d'horloge système standard).
Sécurité des flux mémoire : Utilisation de streams asynchrones pour le hachage des fichiers volumineux afin de maintenir une empreinte mémoire constante (< 50 Mo) et empêcher les plantages par dépassement de mémoire (DoS).
Isolation et immutabilité : Protection contre la pollution de prototypes (Object.freeze) et comparaisons de signatures en temps constant (_timingSafeEqual) pour contrecarrer les attaques temporelles.
Validation stricte à l'exécution : Validation de schéma de preuve (_validateProofSchema) à l'entrée de chaque opération sensible pour rejeter immédiatement les preuves malformées avant tout traitement cryptographique.

Développé par Adama Traoré

Published

Vulnerabilities

Links

Maintainers

Keywords

Readme