Livres blancs techniques

Ce livre blanc décrit l'architecture du système de Transfert sécurisé de PDF Pro, un mécanisme de transfert de fichiers chiffré de bout en bout dans lequel les fichiers sont chiffrés côté client avec AES-256-GCM avant le téléversement. Le serveur ne stocke qu'un texte chiffré opaque et n'a jamais la possibilité de déchiffrer, d'inspecter ou de lire le contenu des fichiers. Le système prend en charge deux modes de clé : une clé aléatoire générée automatiquement (transportée via le fragment d'URL, qui n'est jamais envoyé au serveur) ou une clé dérivée d'une phrase secrète via PBKDF2. Dans les deux modes, la clé de chiffrement n'existe que dans les navigateurs de l'expéditeur et du destinataire. Ce document détaille les primitives cryptographiques, le flux de données, le modèle de menace et les limites honnêtes du système. Note terminologique : ce système n'utilise pas de preuves à divulgation nulle de connaissance (ZKP). Lorsque nous disons que le serveur a une « connaissance nulle » de vos fichiers, nous voulons dire que — par conséquence du chiffrement côté client — le serveur ne détient que du texte chiffré qu'il ne peut pas déchiffrer.

Le système de Transfert sécurisé suit une séparation client-serveur stricte où toutes les opérations cryptographiques se déroulent exclusivement dans le navigateur :

• Client (navigateur) : dérivation de clé, chiffrement, déchiffrement, lecture de fichiers, reconstruction de fichiers.
• Serveur (Supabase Storage + fonctions serverless) : stocke les blobs chiffrés, gère les métadonnées (expiration, nombre de téléchargements), applique les politiques d'accès.

Le serveur est intentionnellement conçu pour être un « tuyau muet » pour les données chiffrées. Il n'a connaissance ni de la clé de chiffrement, ni de la phrase secrète, ni du contenu des fichiers. Cela est imposé architecturalement, et non par simple politique.

Tout le chiffrement de fichiers utilise l'algorithme de chiffrement authentifié AES-256-GCM, accessible via la Web Crypto API native du navigateur. Cela fournit à la fois la confidentialité (les données ne peuvent pas être lues) et l'intégrité (les données ne peuvent pas être modifiées sans détection).

1.3.1 Paramètres de l'algorithme

1.3.2 Implémentation du chiffrement

// Flux de chiffrement simplifié (Web Crypto API)

const iv = crypto.getRandomValues(new Uint8Array(12));
const salt = crypto.getRandomValues(new Uint8Array(16));

// Dérive la clé depuis la phrase secrète (voir Section 1.4)
const key = await deriveKey(passphrase, salt);

// Chiffre le fichier
const ciphertext = await crypto.subtle.encrypt(
  { name: "AES-GCM", iv: iv },
  key,
  fileArrayBuffer
);

// Paquet : [salt (16o)] + [iv (12o)] + [texte chiffré + tag]
const blob = concatenate(salt, iv, ciphertext);

Le blob chiffré final est une concaténation de trois composants : le sel de 16 octets (utilisé pour la dérivation de clé), l'IV de 12 octets (utilisé pour AES-GCM) et le texte chiffré avec le tag d'authentification GCM ajouté de 16 octets. Ce blob est ce que le serveur reçoit et stocke.

Le Transfert sécurisé prend en charge deux modes de clé mutuellement exclusifs. Le mode est sélectionné par l'expéditeur lors de la création du transfert.

1.4.1 Mode A — Clé générée automatiquement (par défaut)

Dans le mode par défaut, aucune phrase secrète n'est impliquée. Le navigateur génère directement une clé AES de 256 bits cryptographiquement aléatoire :

• Le navigateur génère une clé AES-GCM aléatoire de 256 bits via crypto.getRandomValues() et crypto.subtle.generateKey().
• La clé est exportée sous forme d'octets bruts et placée dans le fragment d'URL (#).
• Conformément à la spécification HTTP, le fragment d'URL n'est jamais envoyé au serveur — il est traité exclusivement par le navigateur.
• L'expéditeur partage l'URL complète (y compris le fragment) avec le destinataire via son canal préféré (par ex., application de messagerie, e-mail).
• Le navigateur du destinataire extrait la clé du fragment d'URL et l'utilise pour déchiffrer le fichier.

1.4.2 Mode B — Transfert protégé par phrase secrète

Lorsque l'expéditeur choisit de définir une phrase secrète, la clé est dérivée de cette phrase secrète via PBKDF2 :

• L'utilisateur fournit une phrase secrète.
• La phrase secrète est utilisée pour dériver une clé AES-256 via PBKDF2-SHA256.
• Paramètres : 600 000 itérations, sel aléatoire de 16 octets.
• La clé dérivée chiffre le fichier.
• Le sel est stocké à côté du texte chiffré (préfixé au blob chiffré).
• La phrase secrète est partagée hors bande (séparément du lien).
• Aucune récupération de phrase secrète n'est possible — ni le serveur ni PDF Pro ne peuvent récupérer une phrase secrète oubliée.

1.4.3 Paramètres PBKDF2 (Mode B)

1.4.4 Implémentation de la dérivation de clé (Mode B)

async function deriveKey(passphrase, salt) {
  // Importe la phrase secrète comme matériel de clé brute
  const keyMaterial = await crypto.subtle.importKey(
    "raw",
    new TextEncoder().encode(passphrase),
    { name: "PBKDF2" },
    false,
    ["deriveKey"]
  );

  // Dérive la clé AES-256-GCM
  return crypto.subtle.deriveKey(
    {
      name: "PBKDF2",
      salt: salt,
      iterations: 600000,
      hash: "SHA-256"
    },
    keyMaterial,
    { name: "AES-GCM", length: 256 },
    false,
    ["encrypt", "decrypt"]
  );
}

Le cycle de vie complet d'un transfert sécurisé suit ce parcours :

1.5.1 Envoi (téléversement) — Mode A (clé générée automatiquement)

1. L'expéditeur sélectionne un fichier dans le navigateur.
2. Le navigateur génère une clé AES-GCM aléatoire de 256 bits et un IV aléatoire de 12 octets via crypto.getRandomValues().
3. Le navigateur chiffre le fichier avec AES-256-GCM, produisant texte chiffré + tag d'authentification.
4. Le navigateur concatène [IV | texte chiffré+tag] en un seul blob.
5. Le navigateur téléverse le blob chiffré sur le serveur via HTTPS.
6. Le serveur stocke le blob dans Supabase Storage et crée un enregistrement de métadonnées (ID de transfert, expiration, limite de téléchargement, nom de fichier, taille de fichier).
7. Le serveur retourne une URL de transfert. Le navigateur ajoute la clé exportée au fragment d'URL (#).
8. L'expéditeur partage l'URL complète (avec fragment) avec le destinataire.

1.5.2 Envoi (téléversement) — Mode B (phrase secrète)

1. L'expéditeur sélectionne un fichier et saisit une phrase secrète dans le navigateur.
2. Le navigateur génère un sel aléatoire de 16 octets et un IV de 12 octets via crypto.getRandomValues().
3. Le navigateur dérive une clé AES-256 à partir de la phrase secrète via PBKDF2 (600K itérations).
4. Le navigateur chiffre le fichier avec AES-256-GCM, produisant texte chiffré + tag d'authentification.
5. Le navigateur concatène [sel | IV | texte chiffré+tag] en un seul blob.
6. Le navigateur téléverse le blob chiffré sur le serveur via HTTPS.
7. Le serveur stocke le blob dans Supabase Storage et crée un enregistrement de métadonnées (ID de transfert, expiration, limite de téléchargement, nom de fichier, taille de fichier).
8. Le serveur retourne une URL de transfert contenant l'ID de transfert.
9. L'expéditeur partage l'URL de transfert et la phrase secrète avec le destinataire via des canaux distincts.

1.5.3 Réception (téléchargement) — Mode A

1. Le destinataire ouvre l'URL complète du transfert (avec la clé dans le fragment).
2. Le navigateur extrait la clé AES du fragment d'URL (jamais envoyée au serveur).
3. Le navigateur télécharge le blob chiffré depuis le serveur via HTTPS.
4. Le navigateur extrait l'IV (12 premiers octets) du blob.
5. Le navigateur déchiffre le texte chiffré avec AES-256-GCM en utilisant la clé et l'IV extraits.
6. Si le déchiffrement réussit (le tag GCM est validé), le fichier en clair est présenté à l'utilisateur.
7. Le serveur met à jour le compteur de téléchargements et, si le mode « brûler à la lecture » est activé, supprime le blob.

1.5.4 Réception (téléchargement) — Mode B

1. Le destinataire ouvre l'URL de transfert et saisit la phrase secrète dans le navigateur.
2. Le navigateur télécharge le blob chiffré depuis le serveur via HTTPS.
3. Le navigateur extrait le sel (16 premiers octets) et l'IV (12 octets suivants) du blob.
4. Le navigateur dérive la clé AES-256 à partir de la phrase secrète + sel via PBKDF2 (600K itérations).
5. Le navigateur déchiffre le texte chiffré avec AES-256-GCM en utilisant la clé dérivée et l'IV.
6. Si le déchiffrement réussit (le tag GCM est validé), le fichier en clair est présenté à l'utilisateur.
7. Si le déchiffrement échoue (mauvaise phrase secrète = mauvaise clé = tag GCM invalide), une erreur est affichée.
8. Le serveur met à jour le compteur de téléchargements et, si le mode « brûler à la lecture » est activé, supprime le blob.

Tous les transferts sécurisés sont éphémères par conception. Aucune option de stockage permanent n'est proposée.

1.7.1 Options d'expiration

1.7.2 Garantie de suppression

Lorsqu'un transfert expire ou est brûlé à la lecture, le blob chiffré est définitivement supprimé de Supabase Storage. L'enregistrement de métadonnées est conservé pendant 30 jours dans un état « supprimé en douceur » (à des fins d'enquête sur les abus) avant d'être définitivement purgé. L'enregistrement de métadonnées ne contient ni la clé de chiffrement, ni la phrase secrète, ni aucune information susceptible de servir à reconstituer le fichier.

1.8.1 Hypothèses

• Environnement d'exécution navigateur de confiance (sans extensions malveillantes)
• Canal sécurisé pour le partage du lien/de la phrase secrète
• La terminaison HTTPS est de confiance
• L'appareil du destinataire n'est pas compromis
• Pas de prévention de capture d'écran

1.8.2 Hors périmètre

• Logiciels malveillants sur les terminaux
• Ingénierie sociale / attaques par hameçonnage
• Capture d'écran par les destinataires
• Extensions de navigateur compromises
• Attaques par informatique quantique (considération future)

• La robustesse de la phrase secrète est contrôlée par l'utilisateur. Nous pouvons imposer une longueur minimale dans l'interface, mais nous ne pouvons pas empêcher les utilisateurs de choisir des phrases secrètes faibles. La sécurité du chiffrement est directement proportionnelle à l'entropie de la phrase secrète.
• La transmission de la phrase secrète est hors bande. Nous ne fournissons pas de canal sécurisé pour partager la phrase secrète. Si elle est partagée via un canal non sécurisé (par ex., un e-mail non chiffré accompagnant l'URL de transfert), le modèle de sécurité s'en trouve affaibli.
• Les métadonnées de fichier ne sont pas chiffrées. Le nom et la taille du fichier d'origine sont stockés en clair sur le serveur. Cela révèle le type et la nature approximative du fichier transféré, même si son contenu reste chiffré.
• Confiance dans le code côté client. Les utilisateurs doivent faire confiance au fait que le JavaScript servi par notre CDN est le bon code, non modifié. Un CDN compromis ou un détournement DNS pourrait servir du JavaScript malveillant. C'est une limite fondamentale de toute cryptographie web.
• Pas de confidentialité persistante (forward secrecy). Si la phrase secrète est compromise à un moment donné avant la suppression du blob chiffré, une copie stockée du blob peut être déchiffrée. Le mode « brûler à la lecture » et les courtes durées d'expiration atténuent ce risque.
• Dépendance au modèle de sécurité du navigateur. La sécurité du système dépend de l'implémentation par le navigateur de la Web Crypto API et de son isolation mémoire. Un navigateur compromis ou une extension malveillante pourrait saper toutes les protections côté client.
• Informatique quantique. AES-256 est considéré comme résistant au quantique (l'algorithme de Grover réduit la sécurité effective à 128 bits, ce qui reste infaisable). Cependant, PBKDF2 avec SHA-256 n'est pas spécifiquement conçu pour la résistance post-quantique. Ce n'est pas une préoccupation à court terme mais est mentionné par souci d'exhaustivité.

Ce livre blanc décrit l'architecture du système de Signature confidentielle de PDF Pro, un mécanisme de signature cryptographique de documents où le PDF ne quitte jamais le navigateur du signataire. Le système utilise ECDSA avec la courbe P-256 et un hachage SHA-256 pour produire des signatures numériques détachées. Seuls le hachage du document, la signature cryptographique et la clé publique sont transmis au serveur. Les clés privées sont générées, chiffrées et stockées exclusivement dans le navigateur de l'utilisateur via IndexedDB, protégées par une dérivation de clé PBKDF2 (600 000 itérations) et un chiffrement AES-256-GCM. Ce document détaille l'architecture complète de signature et de vérification, le modèle de gestion des clés, le schéma de la charge utile signée, la conception de la piste d'audit, le modèle de menace et les limites honnêtes.

Le système de Signature confidentielle est conçu autour d'une contrainte fondamentale : le document PDF ne doit jamais être transmis au serveur. Cette contrainte est appliquée architecturalement via un modèle de signature détachée.

• Client (navigateur) : génération de clé, stockage de clé (chiffrée dans IndexedDB), hachage du document (SHA-256), génération de signature (ECDSA P-256), vérification de signature.
• Serveur (Supabase) : stocke les clés publiques, les enregistrements de signature (hachage + signature + métadonnées), les événements de la piste d'audit. Ne reçoit jamais le document PDF, les clés privées ou les phrases secrètes des clés.

2.3.1 Paramètres de l'algorithme

2.3.2 Flux de signature

// 1. Hacher le document PDF (côté client)
const fileBuffer = await file.arrayBuffer();
const hashBuffer = await crypto.subtle.digest("SHA-256", fileBuffer);
const hashHex = Array.from(new Uint8Array(hashBuffer))
  .map(b => b.toString(16).padStart(2, '0')).join('');

// 2. Signer le hachage avec la clé privée (côté client)
const signature = await crypto.subtle.sign(
  { name: "ECDSA", hash: "SHA-256" },
  privateKey,   // CryptoKey provenant d'IndexedDB (déchiffrée)
  hashBuffer
);

// 3. Envoyer au serveur : hachage + signature + clé publique (PAS le PDF)
await submitSignature({
  documentHash: hashHex,
  signature: base64Encode(signature),
  publicKey: exportedPublicKeyJWK
});

2.4.1 Génération de clé

// Génère une paire de clés ECDSA P-256 (Web Crypto API)
const keyPair = await crypto.subtle.generateKey(
  {
    name: "ECDSA",
    namedCurve: "P-256"
  },
  true,   // extractible (nécessaire pour le chiffrement + le stockage)
  ["sign", "verify"]
);

// Exporte la clé publique au format JWK pour l'enregistrement serveur
const publicKeyJWK = await crypto.subtle.exportKey("jwk", keyPair.publicKey);

// Exporte la clé privée au format JWK pour le stockage chiffré
const privateKeyJWK = await crypto.subtle.exportKey("jwk", keyPair.privateKey);

Les clés privées persistantes ne sont jamais stockées en clair. Avant d'être écrites dans IndexedDB, la clé privée (exportée en JWK JSON) est chiffrée selon le même schéma que le Transfert sécurisé :

2.5.1 Paramètres de protection

2.5.2 Schéma de stockage

// Structure d'enregistrement IndexedDB pour une clé de signature chiffrée
{
  "keyId":       "identifiant-unique-uuid-v4",
  "publicKey":   { /* format JWK, non chiffré */ },
  "encryptedPrivateKey": {
    "salt":       "16-octets-encodes-en-base64",
    "iv":         "12-octets-encodes-en-base64",
    "ciphertext": "texte-chiffre-aes-gcm-encode-en-base64"
  },
  "algorithm":   "ECDSA",
  "curve":       "P-256",
  "createdAt":   "2026-04-16T00:00:00.000Z",
  "userId":      "id-utilisateur-supabase-auth"
}

PDF Pro utilise un modèle de signature détachée, ce qui signifie que la signature est stockée séparément du document. C'est le mécanisme essentiel de confidentialité : le document ne quitte jamais l'appareil du signataire.

2.6.1 Ce qui est envoyé au serveur

• Hachage SHA-256 du PDF (32 octets, encodé hex sur 64 caractères).
• Signature ECDSA sur le hachage (64 octets, encodée en base64).
• Clé publique du signataire (format JWK).
• Métadonnées : nom d'affichage du signataire, e-mail (si authentifié), horodatage, ID de signature.

2.6.2 Ce qui N'est PAS envoyé au serveur

• Le document PDF lui-même — jamais transmis.
• La clé privée — ne quitte jamais le navigateur.
• La phrase secrète de signature — ne quitte jamais le navigateur.
• Tout contenu de page, texte ou image du PDF.

Le schéma JSON suivant définit l'enregistrement complet de signature stocké sur le serveur :

{
  "schemaVersion":  "1.0",
  "signatureId":    "uuid-v4",
  "documentHash":   "sha256-hex-64-caracteres",
  "hashAlgorithm":  "SHA-256",
  "signature":      "signature-ecdsa-encodee-base64",
  "signatureAlgorithm": "ECDSA",
  "curve":          "P-256",
  "publicKey": {
    "kty": "EC",
    "crv": "P-256",
    "x":   "coordonnee-x-encodee-base64url",
    "y":   "coordonnee-y-encodee-base64url"
  },
  "signer": {
    "identityLevel": "authenticated | self-asserted",
    "displayName":   "chaîne ou null",
    "email":         "chaîne ou null",
    "userId":        "supabase-uid ou null"
  },
  "timestamp":      "ISO-8601-UTC",
  "metadata": {
    "fileName":     "nom-de-fichier-original.pdf",
    "fileSize":     123456,
    "pageCount":    12,
    "clientVersion": "2.0.0",
    "userAgent":    "chaine-user-agent-navigateur"
  },
  "auditChain": {
    "previousEventHash": "sha256-de-l-evenement-precedent ou null",
    "eventHash":         "sha256-de-cet-enregistrement"
  }
}

La vérification de signature est un processus en deux phases : une vérification cryptographique côté client suivie d'une contre-vérification côté serveur.

2.8.1 Phase 1 : Vérification cryptographique côté client

1. L'utilisateur charge un PDF dans le navigateur.
2. Le navigateur calcule le hachage SHA-256 du PDF chargé.
3. Le navigateur interroge le serveur sur les enregistrements de signature correspondant à ce hachage.
4. Pour chaque enregistrement de signature retourné, le navigateur effectue une vérification ECDSA :

   const isValid = await crypto.subtle.verify(
     { name: "ECDSA", hash: "SHA-256" },
     importedPublicKey,
     signatureBuffer,
     hashBuffer
   );

5. Si isValid === true, la signature est cryptographiquement valide : le document n'a pas été modifié depuis sa signature et la signature a été produite par le détenteur de la clé privée correspondante.

2.8.2 Phase 2 : Contre-vérification côté serveur

1. Le serveur confirme que la clé publique de l'enregistrement de signature est enregistrée pour un utilisateur connu (pour les signatures authentifiées).
2. Le serveur confirme que l'enregistrement de signature n'a pas été révoqué.
3. Le serveur confirme l'intégrité de la piste d'audit (validation de la chaîne de hachages).
4. Le serveur retourne le niveau d'identité du signataire et son statut d'enregistrement.

2.8.3 Résultats de vérification

Chaque événement de signature et de vérification est enregistré dans une piste d'audit infalsifiable. Les événements sont chaînés par hachage : chaque événement inclut le hachage SHA-256 de l'événement précédent, formant une chaîne en ajout uniquement, à la manière d'une blockchain.

2.9.1 Types d'événements d'audit

2.9.2 Structure de la chaîne de hachages

// Chaque événement d'audit inclut :
{
  "eventId":            "uuid-v4",
  "eventType":          "DOCUMENT_SIGNED",
  "timestamp":          "ISO-8601-UTC",
  "data":               { /* charge utile spécifique à l'événement */ },
  "previousEventHash": "sha256-du-json-de-l-evenement-precedent",
  "eventHash":          "sha256-du-json-de-cet-evenement-sans-eventHash"
}

// Détection de falsification : pour vérifier la chaîne, calculez :
// SHA-256(JSON.stringify(événement sans le champ eventHash))
// et confirmez que le résultat correspond à eventHash.
// Confirmez ensuite que previousEventHash correspond à eventHash de l'événement précédent.

Si un événement de la chaîne est modifié, tous les liens de hachage suivants seront brisés, rendant la falsification immédiatement détectable. Cela garantit fortement l'intégrité de la piste d'audit.

Note : Dans l'interface du produit, « self_asserted » peut être affiché comme « Identité auto-déclarée » ou « Signature invité ». « authenticated » peut être affiché comme « Compte authentifié ». Ce sont des libellés d'affichage pour les mêmes niveaux d'identité sous-jacents.

2.11.1 Hypothèses

• Environnement d'exécution navigateur de confiance
• L'implémentation de la Web Crypto API est correcte
• IndexedDB n'est pas accessible aux autres origines
• L'utilisateur protège sa phrase secrète
• Le code serveur correspond au comportement publié

2.11.2 Hors périmètre

• Logiciels malveillants sur les terminaux
• Ingénierie sociale / attaques par hameçonnage
• Capture d'écran par les destinataires
• Extensions de navigateur compromises
• Attaques par informatique quantique (considération future)

• Pas une signature électronique qualifiée (SEQ). Les signatures PDF Pro ne répondent pas aux exigences du règlement européen 910/2014 (eIDAS) pour les signatures électroniques qualifiées. Nous ne sommes pas un prestataire de services de confiance qualifié (PSCo) et nos clés de signature ne sont pas générées sur un dispositif de création de signature qualifié (DCSQ).
• Pas qualifiées eIDAS. Sous eIDAS, seules les signatures électroniques qualifiées ont l'équivalence légale d'une signature manuscrite dans tous les États membres de l'UE. Les signatures PDF Pro sont au mieux des signatures électroniques avancées, et leur valeur juridique dépend de la juridiction et du cas d'usage spécifiques.
• Pas approuvées par Adobe. Les signatures PDF Pro n'apparaissent pas sur la Adobe Approved Trust List (AATL). Lors de l'ouverture d'un document signé par PDF Pro dans Adobe Acrobat, la signature ne sera pas affichée comme « approuvée » dans l'interface Adobe. La vérification doit être effectuée via le système de vérification de PDF Pro.
• Pas une autorité de certification. Nous n'émettons pas de certificats X.509. Notre infrastructure de clés publiques est propriétaire à PDF Pro et n'est pas interopérable avec les systèmes PKI tels que ceux utilisés par les agences gouvernementales ou les autorités de certification.
• Pas une notarisation. Les signatures PDF Pro ne constituent pas une notarisation, une apostille ou toute forme d'authentification de document certifiée par un gouvernement.
• Aucune vérification d'identité réelle. Nous vérifions les adresses e-mail via Supabase Auth, mais nous n'effectuons pas de vérification de pièce d'identité officielle, ni de vérification biométrique, ni de validation d'identité en personne.

2.12.1 Pour quoi les signatures PDF Pro SONT adaptées

• Flux de travail métier — Approbations internes de documents, validations d'équipe, autorisations d'achat où les parties font confiance au modèle d'identité PDF Pro.
• Vérification d'intégrité — Prouver qu'un document n'a pas été modifié depuis un moment précis.
• Non-répudiation (limitée) — Démontrer que le détenteur d'une clé privée spécifique a signé un document spécifique à un moment précis. La force de la non-répudiation dépend de la qualité de la protection de la clé privée et de la liaison de la clé publique à une identité.
• Conformité d'audit — Fournir une piste d'audit infalsifiable des événements de signature de documents pour les exigences de conformité interne.
• Signature de contrats — Dans de nombreuses juridictions, les signatures électroniques (y compris non qualifiées) sont juridiquement valides pour la plupart des contrats commerciaux en vertu de lois telles que ESIGN (États-Unis), UETA (États-Unis) et eIDAS Article 25(1) (UE).