Architecture de signature électronique en production

Le problème : chaque pièce fonctionne, et la plateforme échoue quand même

Les articles 1 à 7 ont donné une norme à chaque pièce : empreinte, certificat, HSM, révocation, autorisation, PAdES, horodatage.

Une plateforme en production peut les utiliser toutes correctement et signer quand même un document que personne n’a approuvé. Le HSM signe n’importe quelle empreinte qu’on lui présente. L’archive ne reste sûre que tant que l’algorithme de son dernier horodatage n’a pas vieilli. Les défaillances se logent dans les jointures entre composants.

Cet article assemble les pièces en une seule architecture de référence, tirée des textes de l’ETSI et du Cloud Signature Consortium sur la signature à distance, et non d’un produit. Il confronte ensuite cette conception à un modèle de menaces sourcé et à une liste de contrôle.

Les normes ETSI et l’API CSC n’existent qu’en anglais : leurs citations sont traduites par nos soins.

La carte des normes de la signature serveur

Trois documents se partagent le travail, une couche chacun.

L’ETSI TS 119 431-1 fixe les exigences de politique et de sécurité d’un prestataire de services de confiance (TSP, l’organisation qui fait fonctionner le service) « qui exploite un dispositif de création de signature (SCDev) à distance », avec des exigences supplémentaires lorsque ce dispositif est un QSCD à distance, le dispositif qualifié de création de signature du règlement européen eIDAS (l’article 3 cite sa définition du dispositif qualifié à distance). Le service qu’elle décrit, une application de signature serveur plus le dispositif, est un service d’application de signature serveur (Server Signing Application Service) (SSAS) (TS 119 431-1, §1). Sa compagne, la TS 119 431-2, couvre l’autre moitié : le composant qui construit la signature AdES autour de la valeur de signature (TS 119 431-2, §1).

La TS 119 431-1 « ne spécifie pas les protocoles utilisés pour accéder au SSAS » et renvoie pour cela à l’ETSI TS 119 432 (§1, note 5). La TS 119 432 est « limitée à la signature serveur à distance, c’est-à-dire que la clé de signature est détenue dans un service partagé distant ». Elle n’impose aucune liaison protocolaire, et reprend quand elle le peut des constructions JSON de l’API CSC et XML de l’OASIS DSS-X (TS 119 432, §1). Sa version 1.3.1 cite l’API CSC v2.2.0.0 comme référence normative (§2.1).

L’API CSC est l’interface interopérable. Elle laisse de côté la politique des prestataires (le domaine de l’ETSI), les formats de signature, la validation des signatures et l’évaluation de sécurité des HSM, qui, dit-elle, est « en cours de normalisation par le CEN en Europe et par FIPS aux États-Unis » (CSC, §1).

Pour la durée, la TS 119 312 liste les algorithmes adaptés aux nouvelles signatures (TS 119 312, §1), et la TS 119 511 couvre la conservation à long terme : garder une signature vérifiable « même si, plus tard, la clé de signature est compromise, le certificat expire ou des attaques cryptographiques deviennent réalisables » (TS 119 511, §1).

L’architecture de référence

La TS 119 432 répartit la signature entre deux services (§4.2) :

• Le composant de service d’application de création de signature (Signature Creation Application Service Component) (SCASC) reçoit le document, ou son empreinte, et renvoie le document signé.
• Le composant de service d’application de signature serveur (Server Signing Application Service Component) (SSASC) reçoit une représentation des données à signer (Data To Be Signed Representation) (DTBS/R) et renvoie une valeur de signature. C’est lui qui détient les clés.

L’API CSC nomme autrement des rôles voisins : une application pilote qui dialogue avec le signataire, une application de création de signature qui construit la structure CMS ou PAdES, un dispositif de création de signature qui produit la valeur, un serveur d’autorisation OAuth 2.0, et le prestataire de service de signature à distance (RSSP) qui exploite le dispositif (CSC, §6.1). Un RSSP « exploite généralement un HSM (ou un dispositif sécurisé multi-utilisateur fonctionnellement équivalent) et un service d’authentification » (§4.1, note 9).

L’identité et l’enrôlement inscrivent le signataire et lui rattachent une clé de signature. La TS 119 431-1 découpe le service en services composants, de la génération de clé et du rattachement à l’identité jusqu’à l’activation et la suppression, et « n’impose aucune restriction sur un éventuel découpage d’une implémentation » (§4.4).

La création de signature construit l’objet signé. Elle assemble l’empreinte du document et celles des attributs signés en DTBS, hache le tout pour obtenir la DTBS/R, n’envoie que la DTBS/R côté signature, puis compose le fichier PAdES final à partir de la valeur qui revient (TS 119 432, §4.3.2–4.3.4). N’envoyer que l’empreinte « limite les menaces pour la confidentialité », au prix de fonctions comme l’apparence visible de la signature (§4.3.1).

Le module d’activation et le magasin de clés forment le cœur. Le magasin de clés est un HSM (PKCS#11) ou un KMS. Devant lui se tient un module d’activation de signature (signature activation module) (SAM) : « un composant logiciel qui utilise les données d’activation de signature (SAD) pour garantir le contrôle exclusif » (§4.4.1.2). Dans le projet de profil de protection certifié, les SAD « lient entre eux trois éléments » : l’authentification du signataire, la clé de signature et la DTBS/R. Le SAM vérifie ce lien avant d’activer la clé, et tous deux se trouvent dans un environnement protégé contre les manipulations (prEN 419 241-2 v0.16, §3.3). C’est le « un HSM n’est pas une autorisation » de l’article 3, à l’échelle de l’architecture.

Le magasin de preuves conserve le journal d’audit. La conservation garde les anciennes signatures vérifiables. L’AC, la TSA et OCSP/CRL sont des services externes, et le vérificateur n’a besoin que du fichier signé et de ses propres ancres de confiance, plus les données de révocation si le fichier ne les contient pas.

L’enrôlement : une clé, un certificat, une personne

Dans la politique normalisée de la TS 119 431-1, la clé du signataire « doit être générée et utilisée dans un SCDev certifié conforme à l’EN 419221-5 » (GEN-6.2.1-02A). La clé est liée à un moyen d’identification électronique, lui-même lié à l’identité ; seules les clés à usage unique peuvent être liées directement à l’identité. Le prestataire « doit protéger l’intégrité des liens entre la clé de signature du signataire et la référence de son moyen d’identification électronique » (§6.2.2, note 1 ; LNK-6.2.2-10A), et l’identité derrière ce moyen doit être « la même que celle liée au sujet du certificat associé » (LNK-6.2.2-05). La vérification d’identité elle-même suit l’annexe A de l’EN 419 241-1 « pour un niveau de garantie substantiel ou supérieur » (LNK-6.2.2-02A) ; « substantiel » désigne un niveau de garantie d’identité. Cette annexe n’a pas été lue, et cet article ne dit donc pas ce que ce niveau exige ; l’article 2 a introduit la vérification d’identité.

L’enrôlement fixe aussi le modèle de mutualisation : la TS 119 431-1 prévoit une clé par signataire. La clé unique de l’organisation, dans l’article 1, ne prouve qu’une chose : l’organisation a signé. Sur le « dispositif sécurisé multi-utilisateur » de la CSC, les liens entre clés et signataires deviennent des données critiques pour la sécurité.

Une clé à usage unique « doit être liée à exactement une session de signature » et supprimée « immédiatement après la fin de la session de signature » (GEN-6.2.1-09 ; DEL-6.3.2-05). Si un certificat est révoqué, sa clé « doit être détruite », et elle l’est aussi à la demande du signataire (DEL-6.3.2-01, -02).

La signature, et ce que veut dire « contrôle exclusif »

La TS 119 432 envisage deux niveaux de garantie du contrôle exclusif « tels que définis dans l’EN 419 241-1 » (§4.4.1.2) :

• Au niveau SCAL1, les clés sont utilisées « avec un faible niveau de confiance » sous le contrôle exclusif du signataire. Le côté signature authentifie le signataire, et l’activation « peut durer une période donnée et/ou pour un nombre donné de signatures ». Une note ajoute qu’on n’attend pas des implémentations SCAL1 qu’elles « satisfassent aux exigences de contrôle exclusif telles qu’on les attendrait d’un QSCD autonome ».
• Au niveau SCAL2, les clés sont utilisées « avec un haut niveau de confiance ». Le SAM encadre leur usage au moyen de SAD que le signataire fournit « pour signer des documents précis ».

Le §5.3.1 rend la différence concrète. SCAL1 « repose généralement sur des mécanismes d’authentification simples (par exemple nom d’utilisateur et mot de passe, ou PIN) », « sans lien cryptographique entre les données d’activation de signature (SAD) et les données à signer ». SCAL2 exige « une authentification plus forte (par exemple multifacteur, ou défi-réponse cryptographique) » et un lien cryptographique entre les SAD et les données à signer. L’API CSC dit la même chose (CSC, §8.1.4).

L’API CSC propose deux styles d’autorisation. credentials/authorize est explicite : l’application recueille le PIN ou l’OTP. oauth2/authorize renvoie un jeton OAuth 2.0 de portée credential (§8.1.4). La voie OAuth peut confier l’authentification à FIDO/WebAuthn, à un fournisseur OpenID Connect ou à un fournisseur fondé sur le portefeuille EUDI (§6.1). La TS 119 432 indique que des facteurs recueillis dans l’application pilote « ne devraient pas pouvoir satisfaire aux exigences SCAL2 » (§5.3.2, note).

Dans les deux styles, le lien passe par un paramètre de la requête. credentials/authorize prend hashes, qui « permet au serveur de lier les SAD à la ou aux empreintes, empêchant ainsi qu’une autorisation serve à signer un contenu différent » (§11.8). Avec OAuth, oauth2/authorize prend hashes ou authorization_details, et pour la valeur SCAL « 2 », l’un des deux « DOIT être spécifié » (§8.2.2). Les SAD ou le jeton reviennent à l’application, qui les envoie avec les empreintes à signatures/signHash (§11.13). Le service « DOIT empêcher les applications de signature de créer plus de signatures qu’autorisé » (§9). L’article 5 a construit le même lien à la main (en citant la CSC v2.0).

La TS 119 431-1 ajoute deux règles côté service. « Les clés de signature ne doivent pouvoir être utilisées que dans les cas pour lesquels le consentement du signataire a été obtenu », et le prestataire « devrait s’assurer que le certificat de clé publique est valide » avant d’utiliser la clé (SIG-6.3.1-09, -08). Dans la politique normalisée, pour une personne physique dont l’authentification est directement liée à l’identité, l’approbation exige « une action explicite (pas une simple case à cocher) », comme faire défiler le document jusqu’au bout ou taper « J’accepte de signer ce contrat » (SIG-6.3.1-15, exemple 2).

La vérification : la plateforme n’est pas dans la boucle

La vérification ne demande aucune nouvelle norme : les contrôles du ByteRange et du CMS de l’article 6, ceux de la chaîne et de la révocation des articles 2 et 4, ceux des horodatages de l’article 7. L’API CSC exclut la validation de son périmètre (§1).

Le vérificateur se fie à ses propres ancres, pas au verdict de la plateforme. La page de vérification d’une plateforme est une commodité ; la preuve est dans le fichier.

Le renouvellement d’archivage : B-LTA est un calendrier, pas un tampon

B-LTA « vise à assurer la disponibilité et l’intégrité à long terme du matériel de validation » et peut aider à valider une signature au-delà d’événements comme « l’affaiblissement des algorithmes cryptographiques utilisés, ou l’expiration des données de validation » (EN 319 142-1, §6.1). La protection est prolongée « au-delà de la durée de vie du dernier horodatage de document » en ajoutant les données DSS qui valident cet horodatage, puis un nouvel horodatage de document. Chaque mise à jour du DSS « devrait contenir les valeurs du dictionnaire DSS précédent » (§5.4.1). Lorsque les données de validation ou la cryptographie du dernier horodatage deviennent « menacées », la mise à jour est répétée « selon la même méthode LTV » (§5.4.3).

L’annexe B, informative, de la TS 119 312 le dit simplement : « Plus le processus est appliqué tôt, mieux c’est. » Pour la transition post-quantique, elle recommande des horodatages d’archivage émis par des TSA qui utilisent des signatures fondées sur le hachage ou hybrides, et des empreintes plus longues comme SHA-384 (annexe B). Un service de conservation relevant de la TS 119 511 « doit surveiller la robustesse de chaque algorithme cryptographique » et compléter les preuves avant qu’elles cessent d’être efficaces (§7.14). Un piège de conception : si le service n’a reçu qu’une empreinte, il « ne peut pas recalculer de lui-même une nouvelle empreinte » (annexe D.1, note 2). Conservez les documents, ou acceptez que le renouvellement dépende de la robustesse durable de l’ancienne empreinte.

Choisir les algorithmes des nouvelles signatures

La TS 119 312 V2.1.1 indique que seuls les mécanismes recommandés par l’ECCG « devraient être utilisés pour générer de nouvelles signatures et de nouveaux cachets » ; les mécanismes hérités (legacy) restent utilisables pour l’interopérabilité « tant qu’ils restent admis » (§4). Pour une plateforme conçue aujourd’hui :

• Empreintes : SHA-256, -384 et -512 et leurs équivalents SHA3 sont recommandés ; SHA-224 est hérité jusqu’en 2028 (§5.1). L’empreinte soumise à une TSA « ne devrait jamais relever d’un mécanisme hérité » (§9.2).
• RSA : RSASSA-PSS « doit être utilisé » ; PKCS#1 v1.5 est hérité (§6.2.2.1). Les clés RSA de 1 900 à moins de 3 000 bits, RSA-2048 compris, « ne doivent plus servir à émettre de nouveaux certificats après le 31/12/2026 », et ces certificats doivent expirer au plus tard le 31/12/2028 (§8.4).
• ECDSA sur P-256, P-384, P-521 et les courbes Brainpool, ainsi qu’EdDSA, sont recommandés (§6.2.2.3–4). ML-DSA et SLH-DSA sont recommandés, avec un usage hybride conseillé pour ML-DSA (§6.2.2.5). Pour SLH-DSA dans les formats fondés sur CMS comme PAdES, « seul SLH-DSA pur doit être utilisé », et non la variante avec pré-hachage (§6.2.2.6).
• Lorsqu’une protection quantique est nécessaire, par exemple pour des signatures qui doivent rester valides « au-delà de 2030 », RSA, ECDSA et EdDSA doivent être employés dans un schéma hybride ou remplacés. La TS 119 312 ne fixe aucune échéance de migration ; un document distinct « en cours d’élaboration » le fera (§1, note 1 ; §8.5).

PAdES s’en remet à la TS 119 312, qui « peut être supplantée par des recommandations nationales » (EN 319 142-1, §6.2.1).

L’exploitation : privilèges, journaux, reprise

L’EN 319 401 couvre la couche d’exploitation autour de la cryptographie (EN 319 401) :

• Séparation des privilèges. Les accès suivent le « besoin d’en connaître, le moindre privilège et la séparation des tâches », et les systèmes doivent séparer « les fonctions d’administration de la sécurité et d’exploitation ». Les comptes à privilèges exigent une authentification forte « telle que l’authentification multifacteur », et leurs droits sont revus à intervalles planifiés (§7.4).
• Maîtrise des clés. Les clés, les algorithmes et les dispositifs sont maîtrisés « tout au long de leur cycle de vie », et la politique cryptographique est revue « en tenant compte de l’état de l’art » (§7.5).
• Surveillance et journaux. La TS 119 431-1 veut que soient journalisés « tous les événements de sécurité », des changements de politique aux pannes en passant par les tentatives d’accès au SSAS (OVR-6.4.5-02). L’EN 319 401 veut une heure des journaux « synchronisée avec l’UTC au moins une fois par jour », et des journaux qui ne puissent pas être « facilement supprimés ou détruits » (§7.10). Une chaîne de hachage scellée dans le document, comme dans l’article 5, rend toute altération détectable.
• Conservation des traces. La TS 119 431-1 conserve les enregistrements d’audit « pendant au moins sept ans après que tout certificat fondé sur ces enregistrements a cessé d’être valide » (OVR-6.4.6-01). La loi guinéenne sur les transactions électroniques fixe 10 ans (L/2016/035/AN, art. 37). Le droit local prime ; ceci n’est pas un avis juridique. Pour les textes guinéens, voir ce que dit vraiment le droit guinéen sur la signature électronique.
• Compromission et reprise. Après un sinistre, « y compris la compromission d’une clé privée de signature », l’activité est rétablie dans le délai du plan de continuité, « après avoir traité toute cause du sinistre susceptible de se reproduire » (§7.11). Les horodatages ajoutés auparavant gardent les signatures antérieures vérifiables après une compromission de clé (TS 119 312, annexe B). Les sauvegardes de clés « ne doivent pas dépasser le minimum nécessaire pour assurer la continuité » (GEN-6.3.3-04).

Les tests découlent des mêmes textes. L’EN 319 401 veut des sauvegardes contrôlées en intégrité et une reprise testée à intervalles planifiés, avec des résultats documentés (§7.11). Notre conseil : testez aussi les chemins négatifs, comme l’ont fait les articles 5 à 7. Rejouez une autorisation, remplacez l’empreinte, révoquez un certificat, laissez vieillir un horodatage, et vérifiez que chacun échoue.

Modèle de menaces

Une sélection de départ, pas un modèle de menaces complet. Les onze premières lignes reprennent les menaces visant le SAM du projet de profil de protection certifié, certaines fusionnées (prEN 419 241-2 v0.16, §5.3) ; la liste complète figure dans le profil. Les deux dernières viennent des textes ETSI.

Liste de contrôle avant la production

Ce qu’une plateforme en production devrait pouvoir montrer, chaque ligne étant sourcée. La passer avec succès relève d’une revue de conception, pas d’une certification.

Mariama signe, Ibrahima vérifie

Retour au contrat de prêt, sur une plateforme construite selon cette architecture de référence.

1. Mariama s’enrôle une fois. Le service de signature génère sa clé dans son magasin de clés, une AC la certifie, et le service enregistre le lien entre la clé et elle.
2. L’entreprise d’Ibrahima envoie le contrat de 5 000 000 GNF. L’application de signature calcule la DTBS/R et lui montre le document.
3. Mariama s’authentifie côté SAM et approuve. Ses SAD désignent cette empreinte et aucune autre.
4. Le SAM vérifie les SAD et active sa clé. L’application assemble une signature PAdES avec un horodatage, et chaque étape entre dans le journal d’audit.
5. Ibrahima valide le PDF avec ses propres ancres de confiance.
6. Des années plus tard, le service de conservation ajoute des données de validation fraîches et un nouvel horodatage de document avant que l’ancien ne vieillisse.

Un contrat remplacé par une version à 9 000 000 GNF ne correspond plus aux SAD : le SAM le refuse.

La place de SEDEYA

Quatre boîtes correspondent à une affirmation vraie sur SEDEYA ; cette correspondance ne dit rien des autres, qui sont des rôles que l’architecture nomme. Le magasin de clés : les clés de signature de SEDEYA sont conservées dans un HSM (PKCS#11) ou un KMS. La création de signature : SEDEYA signe les PDF en PAdES, jusqu’au niveau B-LTA, avec des horodatages RFC 3161 et les données de validation intégrées au fichier, pour des enveloppes signées en séquence ou en parallèle. Le magasin de preuves : chaque transaction de signature entre dans un journal d’audit chaîné par hachage, scellé dans le PDF signé. La vérification : Ibrahima peut valider le fichier avec ses propres outils, et SEDEYA propose aussi une page de vérification publique, par dépôt du fichier ou par QR code, une commodité dont la preuve ne dépend pas. Pour le point de vue de l’acheteur sur cette même revue, lisez ce qu’il faut demander à un prestataire de signature électronique avant de vous engager.

Risques et idées reçues

En résumé

• La TS 119 431-1 fixe la politique du service, la TS 119 432 les protocoles, et l’API CSC l’interface.
• L’architecture sépare la création de signature (qui construit le PDF) du côté signature (qui détient les clés), avec un SAM entre le signataire et la clé.
• SCAL2, tel que le décrit la TS 119 432, exige une authentification forte et des SAD liées aux données à signer. Un HSM seul n’apporte ni l’une ni les autres.
• Dans le modèle de la TS 119 431-1, l’enrôlement lie une clé à un signataire ; la révocation détruit la clé.
• B-LTA ne reste utile que si quelqu’un continue de le renouveler, avec des algorithmes que la TS 119 312 recommande encore.

Vérifiez votre compréhension

Vérifiez votre compréhension

Un fournisseur affirme que ses clés sont dans un HSM, et que seul le signataire peut donc signer. Quelle question lui posez-vous ?

Afficher la réponse

Ce qui active la clé. Un HSM signe n’importe quelle empreinte qu’on lui présente. Demandez si un SAM vérifie des données d’activation de signature qui lient l’authentification du signataire à la DTBS/R exacte, et où sont recueillis les facteurs du signataire.

Vérifiez votre compréhension

Votre plateforme émet des certificats de signataire RSA-2048. Qu'est-ce qui change le 1er janvier 2027 selon la TS 119 312 V2.1.1 ?

Afficher la réponse

Aucun nouveau certificat portant une clé RSA de 1 900 à moins de 3 000 bits ne peut être émis après le 31/12/2026, et les certificats existants doivent expirer au plus tard le 31/12/2028. Passez à RSA-PSS avec au moins 3 000 bits, ou à un schéma recommandé comme ECDSA P-256.

Vérifiez votre compréhension

Le service de conservation ne stocke que les empreintes des documents, pas les documents. Quel risque cela comporte-t-il ?

Afficher la réponse

Si l’algorithme de hachage s’affaiblit, le service « ne peut pas recalculer de lui-même une nouvelle empreinte » (TS 119 511, annexe D.1), et la preuve que les données existaient alors sort de ce que le service peut garantir.

Prochaine étape

Cet article est le dernier de la série. Parlez-nous : nous vous présenterons un PDF signé avec SEDEYA, sa structure PAdES, ses horodatages et ses données de validation intégrées, et comment n’importe qui peut le vérifier.