Périmètre du document
Ce livre blanc décrit l'architecture technique de Φ Probatoire dans sa version 2.2. Il s'adresse à un public technique et juridique averti.
Il s'adresse aux responsables de la sécurité des systèmes d'information (RSSI), aux directions des systèmes d'information (DSI), aux instructeurs ANSSI dans le cadre de l'évaluation CSPN en cours, aux experts judiciaires appelés à statuer sur l'opposabilité d'actes signés via Φ, et aux auditeurs sécurité indépendants.
Doctrine et stabilité
L'architecture documentée ici repose sur une doctrine technique consolidée à travers quatre itérations successives entre mai et juin 2026. La version courante 2.2 est le point de référence : trois composants d'identification fermés à l'enrôlement, paraphe manuscrit vivant à chaque signature, ancrage cryptographique du dossier identité dans l'AAD signée ML-DSA-65 de chaque acte.
Ce que ce document ne contient pas
- Les vecteurs de test KAT (Known Answer Tests) cryptographiques internes — réservés à l'instruction ANSSI CSPN sur demande formelle
- Le code source intégral du crate Rust de scellement — repository privé, accès sur convention
- Les éléments biométriques de tests opérationnels — exclus par construction (doctrine, RGPD art. 9)
L'enveloppe .phi v3
Chaque acte signé est sérialisé dans un conteneur portable .phi, conçu pour transiter via tout canal de transport — messagerie grand public, partage de fichier, support physique.
L'intégrité de bout en bout est garantie par une AAD signée ML-DSA-65 (Additional Authenticated Data) sur neuf lignes canoniques. L'AAD est une chaîne canonique signée intégralement avec la clé privée du signataire, conservée dans l'enclave matérielle. Toute permutation, ajout ou retrait casse la signature.
# Structure de l'AAD signée (9 lignes canoniques) PHI/V3/ENVELOPE / version=3 / type / ref recipient_pk_hash / kem_bundle / sender_pk document_hash / created_at / device_id identity_bundle_hash
Description champ par champ
| Champ | Définition |
|---|---|
| PHI/V3/ENVELOPE | Préfixe immuable, garantit l'identification du format et bloque toute confusion avec une version antérieure (hard switch v2 → v3 depuis 2026-05-30) |
| version=3 | Numéro de version explicite, doublon défensif du préfixe |
| type | Type d'acte (contrat, mandat, attestation, etc.) |
| ref | Référence professionnelle libre de l'expéditeur (numéro de dossier interne) |
| recipient_pk_hash | SHA3-256 de la clé publique ML-DSA-65 du destinataire — verrouille l'acte à un destinataire unique |
| kem_bundle | Ciphertext ML-KEM-768 contenant la clé symétrique AES-256-GCM de déchiffrement du payload |
| sender_pk | Clé publique ML-DSA-65 du signataire, fournie en clair pour permettre la vérification immédiate |
| document_hash | SHA3-256 du document signé (PDF, DOCX, etc.) — intégrité du contenu garantie |
| created_at | Horodatage de scellement, double : horloge murale + compteur monotone τ |
| device_id | Identifiant matériel stable du dispositif signataire (lié à l'attestation Android Keystore) |
| identity_bundle_hash | SHA3-256 du dossier identité du signataire — neuvième ligne, nouvelle en v3 (cf. §4) |
Payload chiffré
Le document signé et les trois composants du dossier identité voyagent dans un payload chiffré AES-256-GCM, dont la clé est encapsulée par ML-KEM-768 pour le destinataire. Le payload est lisible uniquement après déchiffrement local dans l'enclave du destinataire.
Depuis le 30 mai 2026, le module de signature n'émet plus aucune enveloppe v2. Le module de réception rejette toute enveloppe non préfixée PHI/V3/ENVELOPE. Pas de code de compatibilité descendante. Aucune enveloppe v2 n'a jamais été émise en production — la migration est sans régression.
La preuve G
G est la signature mathématique centrale de Φ Probatoire : une valeur scalaire de 32 octets qui fusionne irréversiblement quatre dimensions — qui signe, quoi est signé, quel matériel a signé, à quel instant.
# Formule canonique G = Φ ( QUI | DOCUMENT | SILICIUM | INSTANT ) compute_g(tag, tau, device_id, ctx, beta) → [u8; 32] SHA3-256("PHI/G/V1" || CBOR_canonique)
Les quatre dimensions fusionnées
| Dimension | Composants |
|---|---|
| QUI | Tag identité du signataire (sender_pk_hash), betaBio (token biométrique éphémère dérivé de l'empreinte digitale), betaManuscrit (SHA3 des strokes capacitifs du paraphe vivant à l'instant τ) |
| DOCUMENT | document_hash (SHA3-256), contexte d'acte (ctx), type, référence |
| SILICIUM | device_id, attestation matérielle Android Keystore, identifiant StrongBox si présent |
| INSTANT | τ monotone (compteur matériel) et horodatage absolu (horloge murale) |
Propriétés fondamentales
betaBio et betaManuscrit ne quittent jamais l'appareil.Φ est la seule source de G dans tout le crate. Aucune autre fonction ne produit, ne dérive ou ne reconstruit G. Cette invariance est garantie par l'isolement de la fonction compute_g dans le module crypto Rust, audité ligne à ligne dans le cadre de la procédure CSPN.
Le dossier identité — trois composants
La chaîne d'identification fermée repose sur trois éléments capturés une seule fois à l'enrôlement, scellés cryptographiquement, et transportés chiffrés dans chaque .phi émis par le signataire.
| Composant | Source | Rôle probatoire |
|---|---|---|
| A · Scan A4 | Sélecteur de fichiers local, PDF ou JPG ≤ 8 Mo, page photo de la pièce | Référence visuelle haute qualité — photo officielle, numéro, signature officielle imprimée |
| B · Selfie côté signature | Caméra frontale, capture unique à l'enrôlement | Identification visuelle de la personne + lien personne-pièce + lecture de la signature manuscrite officielle imprimée |
| Paraphe baseline | Capture capacitive des strokes, sérialisation CBOR | Référence graphologique pour comparaison expertale des paraphes ultérieurs |
Cadrage du selfie B selon le type de pièce
| Pièce | Cadrage |
|---|---|
| Passeport | Tenu ouvert à plat à côté du visage, pages photo et signature simultanément visibles. Une seule capture, dense en preuve. |
| Carte nationale d'identité | Verso à côté du visage (face signature manuscrite officielle). |
| Titre de séjour | Verso à côté du visage (face signature manuscrite officielle). |
# Calcul de identity_bundle_hash
identity_bundle_hash = SHA3-256(
sha3(scan_a4_bytes) ||
sha3(selfie_bytes) ||
sha3(paraphe_baseline_strokes)
)Stockage et transport
- Stockés localement dans le téléphone, chiffrés AES-256-GCM via une clé hardware-backed de l'Android Keystore, sérialisés en TLV
- Embarqués chiffrés dans le payload ML-KEM-768 de chaque
.phiémis — visibles en clair par le destinataire après déchiffrement local - Ancrés cryptographiquement dans l'AAD signée ML-DSA-65 via
identity_bundle_hash— toute substitution post-enrôlement d'un composant fait échouer la vérification de signature à la réception
Trois pièces : passeport, carte nationale d'identité, titre de séjour. Le permis de conduire est explicitement exclu, conformément à la jurisprudence Cass. civ. 1re, 25 juin 2009, n° 08-15.971 : il n'est pas une pièce d'identité au sens du Code civil.
Acte vivant à chaque signature
Le paraphe manuscrit posé par le signataire à chaque acte est différent à chaque exécution (geste répété, jamais identique au stroke près). Il est haché dans G via betaManuscrit, daté par τ monotone, et expertisable graphologiquement par comparaison au paraphe baseline conservé dans le dossier identité.
Algorithmes cryptographiques
Φ Probatoire repose exclusivement sur des algorithmes standardisés par le NIST, au niveau de sécurité 3 (équivalent ≈ 192 bits classiques). Aucune primitive ad hoc, aucun rolling de crypto maison.
Signature numérique — ML-DSA-65
Module-Lattice-based Digital Signature Algorithm, niveau NIST 3, standardisé en août 2024 (FIPS 204). Fondé sur la difficulté des problèmes Module-LWE et Module-SIS sur les réseaux euclidiens structurés.
- Taille de clé publique : 1952 octets
- Taille de clé privée : 4032 octets
- Taille de signature : 3309 octets
- Sécurité quantique : niveau 3 NIST (≈ 192 bits classiques)
- Algorithme prédécesseur : CRYSTALS-Dilithium
Publication du 13 août 2024. Φ Probatoire utilise exclusivement ML-DSA-65.
Encapsulation de clé — ML-KEM-768
Module-Lattice-based Key Encapsulation Mechanism, niveau NIST 3, standardisé en août 2024 (FIPS 203). Fondé sur Module-LWE.
- Taille de clé publique : 1184 octets
- Taille de ciphertext : 1088 octets
- Taille de clé encapsulée : 32 octets (AES-256)
- Sécurité quantique : niveau 3 NIST
- Algorithme prédécesseur : CRYSTALS-Kyber
Publication du 13 août 2024. Φ Probatoire utilise exclusivement ML-KEM-768.
Fonction de hachage — SHA3-256
Permutation Keccak-f[1600], capacité 512 bits, standardisée par la FIPS 202 (août 2015).
- Taille de sortie : 256 bits (32 octets)
- Résistance à la collision : 128 bits classique, 85 bits quantique (Grover)
- Usage : hash de document, hash de composants identité, hash de chaîne de journal, dérivation
betaBio/betaManuscrit
Chiffrement symétrique — AES-256-GCM
Authenticated Encryption with Associated Data (AEAD) standardisé NIST. Clés de 256 bits, tag 128 bits. Utilisé pour le chiffrement du payload avec la clé encapsulée par ML-KEM-768, et pour le chiffrement du dossier identité dans l'Android Keystore.
Justification du choix exclusivement post-quantique
Φ Probatoire est conçu pour une opposabilité juridique de très long terme (50 ans et plus). L'industrie estime que des ordinateurs quantiques cryptographiquement pertinents pourraient apparaître à horizon 10 à 25 ans, capables de casser RSA, ECDSA et ECDH en temps polynomial via l'algorithme de Shor. Une signature RSA apposée aujourd'hui ne sera plus opposable à terme. ML-DSA-65 et ML-KEM-768, fondés sur des problèmes de réseaux euclidiens résistants à Shor, garantissent la robustesse de la preuve sur la durée d'archivage.
L'enclave matérielle sécurisée
Les clés privées ML-DSA-65 et ML-KEM-768 de chaque utilisateur résident exclusivement dans un sous-système matériel isolé du processeur principal, conçu pour rendre l'extraction de clé matériellement et logiciellement impossible.
| Implémentation | Caractéristiques |
|---|---|
| TEE TrustZone (ARM) | Mode d'exécution sécurisé du SoC ARM, séparé du monde normal par hyperviseur matériel. Niveau de garantie Common Criteria EAL2+ typique. |
| StrongBox Keymaster | Sous-système matériel dédié (Secure Element ou chip discret) physiquement séparé du SoC. Common Criteria EAL5+ typique. Disponible sur Samsung, Pixel et certains Motorola récents. |
Garanties fondamentales
- Isolation matérielle — mémoire de l'enclave physiquement séparée de la RAM principale. Ni l'OS, ni aucune application même root ne peut lire le contenu de l'enclave.
- Opérations cryptographiques internes — la clé privée n'en sort jamais. L'API expose uniquement des opérations sur entrée externe (« signe ce hash », « déchiffre ce blob », « génère une clé »).
- Verrouillage biométrique — l'exécution d'une opération sensible exige une authentification biométrique matériellement vérifiée.
- Résistance physique — extraction d'une clé requiert décapsulation du silicium en laboratoire (FIB, side-channel, glitching) : coût estimé plusieurs dizaines de milliers d'euros par tentative, taux d'échec élevé, traces irréversibles.
- Attestation matérielle — chaque clé générée est accompagnée d'un certificat d'attestation signé par la racine de confiance du constructeur du chip.
# Les seules opérations exposées par le silicium sign(hash, key_handle) → signature decrypt(ciphertext, key_handle) → plaintext generate(spec) → key_handle attest(key_handle) → certificate_chain # L'API d'extraction de clé privée n'existe pas.
PHI SAS ne dispose d'aucun moyen technique d'extraire une clé ou de signer en votre nom.
Une réquisition judiciaire reçue par PHI SAS visant à produire des clés ou des actes signés est techniquement impossible à exécuter chez PHI SAS — la chose demandée n'existe pas dans nos systèmes. Aucune extraction, aucune reconstitution, aucune signature par procuration n'est réalisable, parce que la matière même requise (la clé privée) ne quitte jamais le silicium du dispositif de l'utilisateur et n'est dupliquée nulle part.
Double verrouillage biométrique du dispositif
Pour s'aligner sur les exigences ANSSI CSPN appliquées aux applications traitant des données sensibles et sur les pratiques bancaires établies, Φ Probatoire impose une chaîne de défense biométrique en deux étages successifs et indépendants.
Géré par l'OS Android. L'empreinte digitale du propriétaire est vérifiée par l'enclave matérielle du SoC (TEE TrustZone ou StrongBox). Sans déverrouillage, le téléphone reste inaccessible.
À chaque ouverture de Φ, l'application exige une vérification biométrique matérielle indépendante. Tant que l'empreinte n'est pas vérifiée : l'écran reste sur un fond minimal avec le logo Φ uniquement, aucune donnée n'est affichée, aucune navigation arrière ne permet de contourner le verrouillage.
Φ refuse explicitement le bypass par code PIN du téléphone : la biométrie matérielle est exigée. Trois échecs consécutifs déclenchent un blocage de 60 secondes (anti-brute-force).
Même un téléphone saisi et déverrouillé au niveau de l'OS ne permet pas l'accès à Φ. La clé privée ML-DSA-65 reste verrouillée dans l'enclave, conditionnée à la biométrie du propriétaire — matériellement impossible à reproduire sans sa présence physique au moment de l'opération.
Le journal cryptographique chaîné
Chaque téléphone Φ tient un journal d'événements horodatés et cryptographiquement chaînés, conservé en local, chiffré AES-256-GCM, et exportable pour production judiciaire.
# Structure d'une entrée de journal { "seq" : N, // numéro de séquence monotone "timestamp" : horloge_murale, // horodatage absolu "tau" : compteur_monotone, // horodatage matériel "event_type" : "RECEIVED" | "SIGNED" | …, "payload_hash" : SHA3-256(payload), // hash du contenu "prev_hash" : SHA3-256(entry N-1), // chaînage "bio_required" : true }
Événements enregistrés
Le journal n'enregistre que des événements positifs et caractérisés — pas l'intention, pas le brouillon. Liste exhaustive : CGU_ACCEPTED/CGU_REFUSED, SETUP_IDENTITY, IDENTITY_DOCUMENT_UPDATED, IDENTITY_BUNDLE_EXPORTED, RECIPIENT_IDENTITY_ACCEPTED, RECEIVED, SIGNED, RESET.
Chaînage et vérification d'intégrité
Chaque entrée intègre le hash de l'entrée précédente (prev_hash), formant une chaîne immuable. Toute modification a posteriori invalide toutes les entrées suivantes. Le vérificateur de cohérence recompute la chaîne entière et retourne : Valid(entryCount), Invalid, Empty ou InternalError(cause).
Pourquoi pas d'événement « envoyé »
Le journal n'enregistre pas les événements sortants. Ce choix est doctrinal : l'application étant strictement locale, sans réseau, elle ne dispose d'aucun moyen de confirmer qu'un envoi a atteint son destinataire. L'intention d'envoyer n'est pas une preuve de la volonté de signer — seule la réception caractérisée par le destinataire fait preuve. La preuve d'envoi appartient au canal de transport, non au journal Φ.
Export pour production judiciaire
Trois éléments exportables en PDF authentifié, sous protection biométrique : le journal complet sous forme tabulaire chaînée ; l'attestation visible en clair de chaque acte ; le certificat d'intégrité, émis si et seulement si la chaîne est intacte. Un expert ou un magistrat peut rejouer la vérification d'intégrité à partir du PDF exporté, en utilisant les hashs publics et la clé publique du signataire.
Vérification destinataire — trois niveaux
G n'est jamais transmis ni recalculable depuis l'extérieur du téléphone signataire — deux de ses ingrédients sont des secrets biométriques qui ne quittent jamais l'appareil. La vérification s'opère donc sur trois niveaux distincts, selon le contexte juridique.
Tout destinataire muni de la clé publique du signataire (fournie en clair dans l'enveloppe v3) effectue, sans aucun accès au téléphone signataire : vérification de la signature ML-DSA-65 sur l'AAD complète, recalcul du document_hash, recalcul de identity_bundle_hash, vérification de la cohérence du journal local.
Garantie : une signature post-quantique valide existe sur un G calculé à τ ; le document n'a pas été modifié ; le dossier identité n'a pas été substitué. G lui-même n'est pas révélé.
En cas de contentieux, un expert judiciaire peut, en présence du signataire et de son appareil : demander au signataire de poser son empreinte (reproduction de betaBio), reproduire betaManuscrit si les strokes de l'acte sont conservés, recalculer G en local, et le comparer binairement au G signé à τ.
Garantie : preuve mathématique complète et opposable. C'est uniquement à ce niveau que G est recalculé au sens strict. Mode forensique opt-in, journalisé, jamais automatisable à distance.
Méthode procédurale civile classique : un expert en écriture compare les strokes du paraphe vivant (capturés à l'acte) au paraphe baseline, et le cas échéant à d'autres écrits authentifiés. Admissible en justice indépendamment de la couche cryptographique.
« Le destinataire vérifie cryptographiquement la signature post-quantique sur la preuve G et l'intégrité du dossier identité. En cas de litige, un expert judiciaire peut, en présence du signataire, reproduire intégralement le calcul mathématique. »
Cette architecture préserve la vie privée biométrique du signataire (RGPD art. 9) tout en garantissant une preuve mathématique post-quantique opposable.
Le canal Inline-Offline™
Φ Probatoire n'opère aucune infrastructure réseau. Le transport de l'enveloppe .phi est délégué aux messageries grand public, sans que celles-ci aient jamais accès au contenu en clair.
Principe
L'enveloppe .phi est un conteneur binaire chiffré, indépendant de tout protocole de transport : chiffrée AES-256-GCM avec une clé encapsulée par ML-KEM-768 pour le destinataire uniquement, signée ML-DSA-65, sérialisée en CBOR canonique, sauvegardée comme fichier attachable à tout transport.
Acheminement
Le signataire envoie le fichier .phi par le canal de son choix : pièce jointe d'email, message WhatsApp/Signal/Telegram, AirDrop, clé USB, ou impression QR code multi-pages. L'opérateur du canal voit transiter un blob binaire opaque.
Garanties contre les opérateurs de transport
- L'opérateur n'a aucun moyen de lire le contenu — chiffré ML-KEM-768 + AES-256-GCM
- L'opérateur ne peut pas modifier le contenu sans casser la signature ML-DSA-65
- L'opérateur ne peut pas déchiffrer le contenu, même contraint par une autorité étatique (Cloud Act ou équivalent) : la clé privée du destinataire est dans son enclave matérielle
- Le contenu chiffré n'est pas exploitable pour entraîner des modèles d'apprentissage automatique, contrairement aux documents en clair des messageries grand public
L'absence d'infrastructure centralisée chez PHI SAS place l'architecture hors du champ d'application des lois étrangères d'extraterritorialité sur les données stockées en cloud (Cloud Act américain et équivalents). Aucune ordonnance ne peut contraindre PHI SAS à produire le contenu d'un acte ou un élément d'identification — ces données n'existent pas dans nos systèmes.
Trinité de vérification logicielle
Côté destinataire, la vérification d'un .phi reçu repose sur trois composants logiciels indépendants. L'invocation est séquentielle — toute défaillance d'une couche entraîne le rejet de l'acte.
Seul point d'appel autorisé du crate Rust depuis Kotlin. Vérifie la signature ML-DSA-65 sur l'AAD v3, l'attestation matérielle de la clé publique signataire, et le déchiffrement ML-KEM-768 du payload (échec implicite si la clé destinataire ne correspond pas).
Vérifie l'intégrité de la chaîne du journal local. Retourne un résultat scellé : Valid(entryCount) / Invalid / Empty / InternalError.
Présente au destinataire les éléments visuels du dossier reçu pour reconnaissance manuelle. Quatre comparaisons : photo officielle ↔ visage du selfie ; pièce du scan ↔ pièce du selfie ; signature officielle imprimée ↔ paraphe baseline ; paraphe baseline ↔ paraphe vivant posé à τ.
Validation explicite par bouton « Je reconnais l'identité » / « Je ne reconnais pas ». Le destinataire engage sa responsabilité professionnelle, comme dans un face-à-face physique notarial.
Hypothèses de sécurité explicites
La robustesse de Φ Probatoire repose sur deux hypothèses, énoncées ici sans détour. Elles ne sont pas des faiblesses : elles sont le socle vérifiable sur lequel toute la chaîne probatoire se construit.
On suppose que la clé privée générée dans l'enclave matérielle (TEE TrustZone, EAL2+ ; ou StrongBox, EAL5+) ne peut être extraite ni par voie logicielle, ni par attaque physique à coût raisonnable. Cette hypothèse est adossée aux certifications Common Criteria des constructeurs de silicium et à l'attestation matérielle vérifiable à chaque clé.
Si cette hypothèse tombe pour un modèle de matériel donné, c'est ce matériel — non l'architecture Φ — qui est en cause.
On suppose que les problèmes Module-LWE et Module-SIS, sur lesquels reposent ML-DSA-65 et ML-KEM-768, demeurent intractables, y compris pour un ordinateur quantique cryptographiquement pertinent. Cette hypothèse est celle retenue par le NIST au terme de huit ans d'analyse publique (FIPS 203 / 204).
Le choix exclusivement post-quantique vise précisément à maximiser la durée de validité de cette hypothèse sur l'horizon d'archivage (50 ans et plus).
Énoncer ces hypothèses n'affaiblit pas la preuve : cela en délimite le périmètre de validité avec la rigueur attendue par un instructeur ANSSI ou un expert. Toute la chaîne probatoire — preuve G, journal chaîné, symétrie bilatérale — est conditionnellement sûre, sous H1 et H2. C'est le standard de tout système cryptographique sérieux.
Conformité normative
Φ Probatoire s'aligne sur les standards cryptographiques internationaux les plus récents et respecte les exigences du droit français et européen.
ML-DSA-65 (signature), ML-KEM-768 (encapsulation), SHA3-256 (hachage). Niveau de sécurité 3, ≈ 192 bits classiques.
Aucune donnée personnelle ni biométrique du signataire n'est transmise à PHI SAS ni à un tiers. L'empreinte digitale et les strokes graphologiques sont traités exclusivement dans l'enclave matérielle de l'appareil. PHI SAS n'est ni responsable ni sous-traitant de traitement. Les données biométriques (art. 9) ne quittent jamais l'appareil.
Exclusion du permis de conduire comme pièce d'identité au sens du Code civil. Pièces acceptées : passeport, carte nationale d'identité, titre de séjour.
Suppression de l'exigence d'une formule manuscrite sacramentelle (« lu et approuvé »). Le paraphe manuscrit posé à chaque acte, scellé cryptographiquement à l'instant exact et comparable graphologiquement au paraphe baseline, y est juridiquement équivalent et probatoirement plus robuste.
Procédure en cours d'instruction. La cible de sécurité couvre l'architecture probatoire (preuve G, dossier identité 3 composants, journal chaîné), le canal Inline-Offline™, et l'application mobile Android.
L'architecture s'inscrit dans le cadre de l'écrit électronique et de la fiabilité présumée de la signature.
Glossaire technique
| Terme | Définition |
|---|---|
| AAD | Additional Authenticated Data — bytes signés par ML-DSA-65 mais non chiffrés. En v3, contient 9 lignes canoniques (cf. §2). |
| betaBio | Token biométrique éphémère dérivé de l'empreinte digitale au moment de la signature. Ne quitte jamais l'enclave. Ingrédient de G. |
| betaManuscrit | SHA3-256 des strokes capacitifs du paraphe manuscrit posé à chaque signature, à l'instant τ. Différent à chaque acte. |
| CSPN | Certification de Sécurité de Premier Niveau, administrée par l'ANSSI. Φ est en cours d'instruction. |
| G | Preuve mathématique centrale. Valeur scalaire de 32 octets produite par Φ, fusionnant QUI, DOCUMENT, SILICIUM, INSTANT. Calculée exclusivement dans le téléphone du signataire. |
| identity_bundle_hash | SHA3-256 de la concaténation des hashs des trois composants du dossier identité. Neuvième ligne de l'AAD v3. Statique par signataire, immuable après enrôlement. |
| Inline-Offline™ | Marque désignant le canal de transmission : payload chiffré transitant via messageries grand public, lisible offline par le destinataire après déchiffrement local. |
| ML-DSA-65 | Module-Lattice-based Digital Signature Algorithm, niveau 3 NIST (FIPS 204). Signature post-quantique de Φ. |
| ML-KEM-768 | Module-Lattice-based Key Encapsulation Mechanism, niveau 3 NIST (FIPS 203). Encapsulation de clé post-quantique de Φ. |
| paraphe_baseline | SHA3 des strokes du paraphe de référence, capturé une seule fois à l'enrôlement. Référence graphologique. |
| SHA3-256 | Fonction de hachage standardisée FIPS 202 (2015). 256 bits de sortie. Tous les hachages internes de Φ. |
| StrongBox | Implémentation hardware-backed de l'Android Keystore sur sous-système matériel dédié (Common Criteria EAL5+ typique). |
| τ (tau) | Compteur monotone matériel — prouve l'ordre des faits, pas l'heure murale. Élément temporel de G garantissant la non-réplication. |
| TEE | Trusted Execution Environment — sous-système matériel sécurisé isolé de l'OS. ARM TrustZone ou StrongBox sur Android. |
Références normatives
- NIST FIPS 204 — Module-Lattice-Based Digital Signature Standard, août 2024
- NIST FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard, août 2024
- NIST FIPS 202 — SHA-3 Standard, août 2015
- Règlement (UE) 2016/679 — RGPD
- Ordonnance n° 2016-131 du 10 février 2016 — réforme du droit des contrats
- Cour de cassation, 1re civ., 25 juin 2009, pourvoi n° 08-15.971
- Règlement (UE) 2024/1183 — eIDAS 2
- ANSSI — Méthodologie CSPN
Pour toute demande d'accès au code source, aux KAT cryptographiques internes, à la documentation de cible de sécurité ou aux tests d'intrusion : phi-signature@proton.me, ligne dédiée à l'instruction ANSSI et aux auditeurs indépendants sous convention de confidentialité.