Brevet FR2884089A1 — publié le 20061006

SIGNATURE ÉLECTRONIQUE RENFORCÉE La présente invention se rapporte au domaine de la signature électronique de fichiers numériques. La présente invention se rapporte plus particulièrement à une amélioration des procédés de signature électronique tels que définis par exemple dans le standard PKCS-7, et les documents ETSI de type RFC. En particulier, l'art antérieur connaît déjà le document de l'organisme de standardisation ETSI RFC 3852 version de Juillet 2004, équivalent au document ETSI TS 101 733 V 1.2.2.2. Dans ce document, sont définis l'ensemble des fonctions et spécifications standards en matière de signature électronique. On notera d'abord que la présente invention est compatible avec ce standard, et que les nouvelles fonctionnalités apportées n'entrent pas en conflit avec les spécifications ETSI. La présente invention entend améliorer la sécurisation des signatures électroniques qui, lorsqu'il s'agit d'attributs non signés, risquent une substitution frauduleuse. Plus précisément, il faut noter que la RFC 3852 prévoit qu'une signature (signaturel) peut être complétée par un attribut non signé de type jeton connu de l'homme du métier, à savoir une capsule CMS signée par un tiers (signature2) qui fera référence à ladite signature en rajoutant des informations complémentaires qui lui sont propres (par exemple la date et l'heure dans le cas d'un jeton d'horodatage de type connu en soi). On rappelle que le terme CMS utilisé dans ce document signifie "Cryptographic Message Syntax", terme anglais signifiant "syntaxe pour message cryptographique". Ce terme définit une structure de fichier permettant en particulier, de signer électroniquement, de condenser, d'authentifier ou de chiffrer un message quel que soit son contenu. Cette structure de signature selon l'art antérieur est illustré figure 1 sur laquelle les attributs signés de la signature principale comprennent une empreinte de l'objet à signer 1 et un identifiant du signataire 2. Les attributs non signés comprennent une empreinte de la signature 3, et, dans le cas d'un jeton, un identifiant du signataire par le jeton 4, et la signature par le jeton 5. Compte tenu de la structure actuelle de CMS, il est impossible de lier les deux signatures 4 et 2 entre elles, c'est-à-dire que le jeton signé par la seconde signature dépend de signaturel, mais non l'inverse. On comprend donc qu'il est possible de substituer un jeton par un autre. La présente invention entend donc résoudre le problème de la sécurisation des signatures électroniques en garantissant aux signataires la présence d'un témoin de la signature pour assurer une signature renforcée. Pour ce faire, la présente invention est du type décrit ci-dessus et elle est remarquable, dans son acception la plus large, en ce qu'elle concerne un fichier électronique pour la signature électronique d'un contenu originel comprenant au moins une première zone de contenu, - une seconde zone contenant un champ de première signature, - une troisième zone comprenant une description d'un premier signataire associé à ladite première signature, ledit champ de signature comprenant au moins - un ensemble d'attributs signés, - une première signature, - et un ensemble d'attributs non signés, caractérisé en ce que - ledit ensemble d'attributs non signés comprend un jeton associé de manière unique à un second signataire et en ce que - ledit ensemble d'attributs signés comprend au moins une empreinte associée audit contenu et une empreinte de la 15 description du second signataire qui signe ledit jeton. Avantageusement, ledit jeton comprend, une empreinte de ladite première signature, ladite empreinte étant signée par ledit jeton. Selon une variante, ledit jeton comprend en outre une empreinte de chacun des attributs non signés qui le précèdent, ces empreintes étant signées par ledit jeton. Selon un aspect, l'invention concerne également, en combinaison avec le fichier précédemment défini, mais également en lui-même, un fichier électronique pour la signature électronique d'un contenu originel comprenant au moins une première zone de contenu, une seconde zone contenant un champ de première signature, une troisième zone comprenant une description d'un premier signataire associé à ladite première signature, ledit champ de signature comprenant au moins - un ensemble d'attributs signés, - une première signature, - et un ensemble d'attributs non signés, ledit ensemble d'attributs signés comprenant une empreinte dudit contenu, caractérisé en ce que - ledit ensemble d'attributs non signés comprend au moins une contresignature qui contient dans ses attributs signés ladite empreinte du contenu ainsi qu'une empreinte de ladite première signature. Il est entendu que cette variante de l'invention est nouvelle en tant que telle et pourra être revendiquée soit seule, soit en combinaison avec d'autres caractéristiques de l'invention. L'invention concerne également un procédé pour la génération d'un tel fichier à partir d'un contenu originel, et un programme d'ordinateur pour la mise en uvre du procédé selon l'invention. On comprendra mieux l'invention à l'aide de la description, faite ciaprès à titre purement explicatif, d'un mode de réalisation de l'invention, en référence aux figures annexées où : la figure 1 représente de façon schématique les fichiers numériques signés selon l'art antérieur, - la figure 2 représente de façon schématique les fichiers numériques signés de façon renforcée selon la présente invention, la figure 3 représente de façon schématique les fichiers numériques contresignés selon l'art antérieur, la figure 4 représente de façon schématique les fichiers numériques contresignés selon la présente invention. Nous décrivons ici le format du document signé selon l'invention. On définit d'abord les notations utilisées dans le cadre de cette description. Les structures de données sont décrites au format ASN.1 (Abstract Syntax Notation 1, terme anglais qui signifie Notation de Syntaxe Abstraite), mais il est entendu que tout format actuel ou futur peut être utilisé sans limiter la portée de la présente invention. Afin de clarifier la lecture de la présente demande, les structures (noms de variables, de types, etc.) sont indiquées en gras. Selon l'invention, on définit d'abord un jeton dit jeton transactionnel qui sert à contresigner l'ajout d'une signature et de tous ses attributs non signés sur un document sécurisé selon l'invention. Cette signature renforcée engage par conséquent le propriétaire du certificat associé au jeton, baptisé alors certificat transactionnel. Techniquement, un jeton transactionnel est une capsule CMS autonome de type id-signedData qui contient l'empreinte de hashage de la signature et de ses attributs non signés qui viennent d'être ajoutés sur le document selon l'invention, signée par la clé privée du certificat transactionnel. Ce certificat transactionnel est un certificat qui sert à signer le jeton transactionnel. Un certificat transactionnel certifie en quelque sorte l'opération de signature dans le sens où il est un témoin de l'opération. Le certificat transactionnel peut par exemple identifier l'unité de traitement qui effectue l'opération (la "transaction", d'où son nom), ou bien un ordinateur, un logiciel, une personne présente, etc., selon la manière dont le mot de passe de la clé privée du certificat transactionnel est fourni et la signature calculée (mot de passe codé "en dur" dans le logiciel, saisi par un tiers avec une carte à puce à crypto- processeur, etc.) Selon un mode de réalisation, un même certificat transactionnel peut être utilisé pour signer plusieurs transactions (signatures) relatives à un même document. Illustré figure 2, suite à l'apposition de la 20 signature selon l'invention, le document signé comprend, de manière connue en soi: Le contenu La signature selon l'invention Une description du signataire La signature comprend alors un ensemble d'attributs signés (c'est à dire avant la signature) de type SignedAttr, la signature elle-même correspondant à un chiffrement, par une clé privée du signataire, de l'empreinte des attributs contenus dans son champ signedAttrs de type SignedAttrs, et un ensemble d'attributs non signés de type UnsignedAttrs. De préférence, les attributs de type SignedAttrs sont les suivants: É ContentType É MessageDigest É SigningTime É otherSigningCertificate É SignaturePolicyId É CommitmentTypeIndication É SignerLocation Ces attributs sont de type connu par l'homme du métier et sont par exemple définis dans la CMS précédemment mentionnée. On utilise en outre de façon nouvelle un attribut signé spécifique SigningTranCertificate 6 du type OtherSigningCertificate qui définit le second signataire qui signe le jeton. Cet attribut signé correspond à l'empreinte du certificat transactionnel utilisé pour signer le jeton transactionnel correspondant à la signature considérée. Lors de la vérification du document, il doit donc y avoir correspondance pour que le document soit déclaré valable. Ce principe garantit la cohérence de la signature et du jeton associé, et évite ainsi la substitution du jeton transactionnel. Associé à l'attribut signé SigningTranCertificate, on définit alors un attribut non signé de type TransactionToken correspondant audit jeton signé par le second signataire, comme illustré figure 2. On note donc que selon l'invention, toute signature comprend au moins un attribut non signé. De préférence, la signature d'un jeton transactionnel présente les spécificités suivantes: - Un attribut signé Commitment Type Indication Attribute (RFC3126 partie 3.12.1) avec pour valeur Proof of approval , qui signifie que le signataire du jeton approuve le contenu qu'il a signé, c'est-à-dire la signature 1. - La clé privée utilisée pour signer l'empreinte de hashage de la signature qui vient d'être ajoutée sur le document selon l'invention peut être accédée localement ou à distance (dans ce cas, comme pour un jeton d'horodatage, un protocole applicatif spécifique devra être utilisé pour effectuer une requête de jeton transactionnel et fournir une réponse contenant le jeton). Afin de préciser la structure dudit jeton transactionnel, on donne sa structure ASN.1 définie de la manière suivante: TransactionToken Contentlnfo - - contentType vaut id-signedData ([CMS]) - - content contient une structure de données de type SignedData ([CMS]) Le champ de type EncapsulatedContentlnfo de la structure SignedData est construit ainsi: - eContentType est un OID qui identifie de manière unique le type de contenu. Cet OID est défini par: id-ct-TransactionTokenlnfo OBJECT IDENTIFIER::= { un identifiant référencé} - eContent est le contenu luimême (OCTET STRING) représentant la structure de données TransactionTokenlnfo. TransactionTokenlnfo::= SEQUENCE { version INTEGER, policy TAPolicyId, signaturelmprint Messagelmprint, unsignedAttrslmprints Uns ignedAttrslmprints, serialNumber INTEGER, nonce INTEGER OPTIONAL, ta [0] GeneralName OPTIONAL, extensions [1] IMPLICIT Extensions OPTIONAL 10} TAPolicyId::= OBJECT IDENTIFIER UnsignedAttrslmprints SET SIZE (0..MAX) OF 15 UnsignedAttrimprint UnsignedAttrlmprint SEQUENCE { type OBJECT IDENTIFIER messageimprint Messagelmprint 20} Messagelmprint::= SEQUENCE { hashAlgorithm Algorithmldentifier, hashedMessage OCTET STRING 25} Il est par ailleurs entendu que, comme illustré figure 2, le jeton transactionnel selon l'invention peut venir renforcer une empreinte du contenu du document à signer, mais également toute structure de type CMS, et en particulier, l'objet de la signature peut être soit un contenu, soit une signature elle-même, soit les deux. Les empreintes renforcées par le jeton peuvent alors être soit des empreintes du contenu, soit des empreintes d'une signature, soit une combinaison d'une empreinte de contenu et d'une empreinte de signature. Par ailleurs, de façon tout à fait nouvelle pour ce type de jeton, et comme illustré figure 2, le jeton transactionnel vient signer non seulement la signature principale (signaturel), mais également l'ensemble des attributs non signés associés à cette signature 7. Le contenu signé du jeton transactionnel est donc l'empreinte de la signature principale (signaturel), mais également l'empreinte de chacun des attributs non signés qui le précèdent. Par ailleurs, l'invention peut concerner également un nouveau type de signature dit signature d'original qui permet d'obtenir une contresignature, qui est par définition un attribut non signé, non seulement d'une signature principale 8 (signaturel sur la figure 4), mais également du contenu lui-même 9. En effet, selon l'art antérieur illustré figure 3, une contresignature vient contresigner l'empreinte d'une signature principale 8 (signaturel) et comprend un identifiant du contresignataire et la contresignature ellemême. Au contraire, comme illustré figure 4, la contresignature selon l'invention signe à la fois une 30 empreinte du contenu 9 et une empreinte de la signature principale 8. Pour ce faire, on définit un nouvel attribut non signé de type Countersignature qui prend comme attribut signé une empreinte du contenu. Cet attribut est donné par MessageDigestContent qui correspond à une empreinte du contenu qui, de façon nouvelle, se situe au niveau des attributs signés de la signature. De cette façon, la signature est appliquée sur un contenu originel dont l'intégrité est garantie par l'empreinte de la signature 8. On comprend donc que le niveau d'intégrité est augmenté par rapport aux signatures de l'art antérieur. L'invention est décrite dans ce qui précède à titre d'exemple. Il est entendu que l'homme du métier est à même de réaliser différentes variantes de l'invention sans pour autant sortir du cadre du brevet. REVENDICATIONS 1. Fichier électronique pour la signature électronique d'un contenu originel comprenant au moins une première zone de contenu, une seconde zone contenant un champ de première signature, une troisième zone comprenant une description d'un premier signataire associé à ladite première signature. 10 ledit champ de signature comprenant au moins - un ensemble d'attributs signés, -une première signature, - et un ensemble d'attributs non signés, caractérisé en ce que - ledit ensemble d'attributs non signés comprend un jeton associé de manière unique à un second signataire et en ce que -ledit ensemble d'attributs signés comprend au moins une caractéristique associée audit contenu et une empreinte 20 de la description du second signataire qui signe ledit jeton. 2. Fichier électronique selon la revendication 1, caractérisé en ce que ladite caractéristique associée audit 25 contenu correspond à une empreinte du contenu. 3. Fichier électronique selon la revendication 1, caractérisé en ce que ladite caractéristique associée audit contenu correspond à une empreinte de ladite première 30 signature dudit contenu. 4. Fichier électronique selon la revendication 1, caractérisé en ce que ladite caractéristique associée audit contenu correspond à une empreinte de la première signature dudit contenu et à une empreinte dudit contenu. 5. Fichier électronique selon la revendication 1, caractérisé en ce qu'un attribut non signé comprend une empreinte de ladite première signature, ladite empreinte étant signée par ledit jeton. 6. Fichier électronique selon la revendication 5, caractérisé en ce qu'un attribut non signé comprend en outre une empreinte de chacun des attributs non signés qui précèdent ledit jeton, ces empreintes étant signés par ledit jeton.