WO2005124503A1 - Procede d'authentification universelle de documents - Google Patents

Procede d'authentification universelle de documents Download PDF

Info

Publication number
WO2005124503A1
WO2005124503A1 PCT/FR2005/050416 FR2005050416W WO2005124503A1 WO 2005124503 A1 WO2005124503 A1 WO 2005124503A1 FR 2005050416 W FR2005050416 W FR 2005050416W WO 2005124503 A1 WO2005124503 A1 WO 2005124503A1
Authority
WO
WIPO (PCT)
Prior art keywords
computer application
file
generating
document
block
Prior art date
Application number
PCT/FR2005/050416
Other languages
English (en)
Inventor
Henri Hovette
Original Assignee
Henri Hovette
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Henri Hovette filed Critical Henri Hovette
Publication of WO2005124503A1 publication Critical patent/WO2005124503A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures

Definitions

  • the present invention relates to the field of integrity, confidentiality and security of electronic documents.
  • the present invention relates more particularly to a method of securing by specific formatting of electronic documents, whatever the initial format of the document. This process also allows effective access control to the document.
  • the major technical problem which arises in the field of securing electronic documents is the maintenance of the integrity of the content of an initial file.
  • a secure file is composed of two parts: a header (or header) and an encrypted document.
  • the header includes security information which includes the rules for accessing the document and a key attached to the file.
  • the rules for accessing the secure document facilitate restricted access and essentially determine how / where / when / by whom the document is accessible.
  • the key associated with the file is used to encrypt and decrypt the portion of the document corresponding to the encrypted data. Only users with document access privileges can recover the key to read the encrypted document.
  • the present invention intends to remedy the drawbacks of the prior art by allowing the security of a document by specific formatting while maintaining the absolute integrity of the initial document.
  • the format defined by the invention the text of the electronic writing is not dissociated from the various certificates of authenticity. Thus, any modification, substitution or deletion of the document and of the certificates is immediately detectable.
  • the present invention is of the type described above and it is remarkable in its broadest sense, in that it relates to a method of generating a file authenticated by a computer application from a written document.
  • electronic for controlling access to said authenticated file characterized in that it comprises at least the steps consisting in: generating a first set of data in the form of a header; - generate a second set of data representing at least part of said electronic writing in one of the following two formats: • ASCII format • binary format - generate a third set of data comprising at least one piece of information corresponding to at least one identifier of said computer application .
  • said third set of data comprises information corresponding to a time stamp (internal or external) of the implementation of said method.
  • said identifier of said computer application comprises at least one fingerprint of a digital certificate of said computer application.
  • said third set of data comprises a hash of said identifier of said computer application.
  • said third set of data comprises a hash of the set of data constituted by said identifier and said second set of data.
  • said third set of data comprises a hashing of the set of data constituted by said identifier, said second set of data and said first set of data.
  • said identifier of said computer application comprises at least one identifier of the user of said computer application.
  • said identifier of said computer application comprises at least one digital signature of the user of said computer application.
  • said first set of data includes the version number of said computer application.
  • said first set of data comprises the type of extension of said electronic writing.
  • said first set of data includes the type of confidentiality required for said identified document.
  • said method further comprises a step of recording said authenticated file with an extension corresponding to said computer application.
  • said identifier of said computer application comprises at least one identifier of the computer equipment on which said computer application is installed.
  • FIG. 3 illustrates the procedure for signing multiple blocks of the writing to be signed;
  • - Figure 4 illustrates a representation of a signed document -c.aud;
  • - Figure 5 illustrates a representation of a signed document -c.aud after the insertion of a stamp;
  • - Figure 6 illustrates a mode of creation of a file. aud®;
  • - Figure 7 illustrates an example of processing the last block in the creation of an .aud® file;
  • - Figure 8 illustrates the final processing of the last block in the case where the final block has a size greater than 65536 bytes;
  • L ⁇ initial step of the process is installation on the position of a user of a specific computer application A.
  • the latter previously seized an information sheet corresponding to his professional or private identity. Note that such a file can correspond to an individual, a private company or a liberal profession, etc. It is an identification sheet of the user of the software license.
  • the registration of the user and software license corresponds to a list of information (AuDIds) comprising for example the following fields in the case of a particular "file”: License number and source of the computer application used Last name of the user First name of the user - Address of the user Email address of the user Various data calculated such as the serial number of the disc, the Mac number of the card Ethernet ... This form can also be completed using an electronic identity card, an electronic passport or any other mechanism allowing user identification. From these different fields and data, a calculation is carried out to obtain a certificate of the application associated with the specific user who carried out the identification and on the computer on which the application is located.
  • the hash is of type SHA 256 of known type, for an encryption algorithm AES (Advanced Encryption Standard) and the mathematical base comes from elliptic curves (EC).
  • This certificate is the “signature” of the user's computer application (Audlds).
  • the “Audlds” certificate (or signature of the application) is then stored in the “local database”, encrypted on the user's computer.
  • This signature is a combination of a password of at least 8 characters and the identity of the user. She can be stored, for example, externally: as an encrypted .sign file, on a USB key or memory card or directly in the "local base" of the user station. It can also be associated with biometric data from the user (fingerprint or iris recognition), its use must be confirmed by the validation of the biometric data.
  • the installation phase ends with the creation of an “AUD” electronic license contract that the user has read before making “accept”, which is signed by the Audlds certificate and the AudSig certificate. This electronically signed contract is sent automatically by e-mail to the distributor via the Internet.
  • the AUD contract and the attributes of the certificates are stored in a database. This storage makes it possible to verify the license certificates thanks to the unique license number, part of which is calculated during the installation of the software and to the certificate ID (fingerprint) of the product with a view to document traceability. An activation key is returned upon registration.
  • the computer application A is capable of transforming the format of the document to make it an authenticated document of “.aud®” type.
  • the Dl document can be in any ASCII or binary digital format (text, image, video, music).
  • the format of the original .aud® documents is as follows: a header, a body corresponding to the original electronic writing, a foot. Note that the two header and body parts cannot be modified once the ".AUD®” document has been created.
  • the base of the file which will contain the different signatures and stamps, is variable and evolves as the document is distributed.
  • the different parts of the certified document are in the form of tags and content. From an original document, it is therefore modified according to the invention in the following form:
  • the content of the header contains several important fields, at least of which: the version number: it is the version number of the application which allowed the creation of the document. aud®; document type: this field identifies the type of document among the unsigned, signed or acknowledgment documents; the name of the original file; - extension: this is the type of extension of the original file (.doc, .pdf, .xls for the most conventional); the type of distribution desired: this field defines the procedures for controlling access to the document; the original number (unique number per AUD® original created).
  • This number of fields is of course not limited, but once created, this header cannot be modified once the .aud ® secure file has been created.
  • the content of the original document is not modified by the computer application implementing the method according to the invention. It is in a binary or ASCII format thus keeping perfect integrity (block 2).
  • the essential part of authentication is the signature of the computer application present at the bottom of the document.
  • This foot contains on the one hand a first AUDInfo subset limited by two start-type AUDInfo and end AUDInfo sub-tags (block 3).
  • This subset includes a timestamp of the creation of the original .AUD® file allowing the traceability of the creation of the document.
  • the certificate of the computer application used to create the document is then inserted after the sub- AUDInfo set after an AUDIds Start type sub-tag (block 4).
  • This certificate inserted at the foot of the .AUD® document contains several online fields, at least of which:
  • Audld clear information corresponding to the software license, hardware and user; 2. The imprint of the certificate (ID) of the computer application; 3. A hash of the document to be signed corresponding to the entire document from the start of the Header to the end of the AUDInfo subset (therefore up to the End AUDInfo tag); 4. A hash from the previous lines 2 and 3.
  • the hashes of lines 3 and 4 is still achieved by an elliptic curve algorithm and SHA-256. Note that the hashing of line 4 makes it possible to mathematically link the document to be signed and the imprint of the certificate of the computer application (ID).
  • this type of file corresponds to a paper document put in a signature book and ready for signature.
  • the “.AUD®” document described above can then receive the different signatures or stamps corresponding to the distribution of the document. Illustrated in Figure 4, the signature is added at the bottom of the document. It is always preceded by an AUDInfo subset (block 5) comprising the timestamp of the signature insertion as before between two Start AUDInfo and End AUDInfo sub-tags. If the user is connected to the Internet, this timestamp is obtained by the NTP protocol.
  • the signature of the document by the user then includes, as before, the 4 fields corresponding to the AUDIDs information, to the signature of the computer application, to the hashing of the document to be signed corresponding to the entire document from the start of the Header until the end of the previous AUDInfo subset (so up to the End AUDInfo tag which has just been created) and hashing of the two previous lines.
  • the hashes included in previous certificates are deleted, on the one hand because they have become obsolete due to the insertion of a new subset of the foot, and on the other hand so that it is absolutely not possible to delete signatures, even by retrieving information from hashing.
  • Block 6 also corresponds to block 6 from which the last elliptical impression was removed. It is also possible to insert a co-signature. This co-signature makes it possible to add an unactivated signature to the computer application on which the document to be signed is read. The user of the computer application then "opens" access to external signatures, for example by external key or smart card.
  • this co-signature is, for example, that of a meeting where each approves by affixing his signature on the "open" document on the post of the secretary general.
  • the stamp will be preceded by an AUDInfo subset corresponding to the application of the one that authorizes the co-signature, and the 4 fields specific to the co-signer. It is thus possible to see for example that "Martinez signed the document on Dupont's software".
  • Type. aud including: the attributes of the“ Audlds ”certificate of the software that opens the AUD file, the attributes of the“ Audids ”certificate of the AUD file, the“ AudSig ”certificate attributes and the signature of the user who opens the AUD file.
  • the file “-ar.aud” is then signed and sent to the requester of the acknowledgment of receipt.
  • a second special certificate makes it possible to restrict the distribution of an AUD® document. This is achievable by storing, for example, an encryption key at a local server. The various computer applications having access to this local network can then decrypt the document, but not those outside the local network. (Restricted distribution mode) Similarly, for confidential communication between two people, a specific key is generated and exchanged only between the two users wishing to exchange documents confidentially.
  • the user must first select the original file (electronic writing to secure) from which he wants to create the original Aud.
  • the system only stores the path of the file chosen by the user and blocks this original file in read / write mode (so that no other application can use it during processing). This action is instantaneous because no processing is carried out on the original file.
  • the system will map the original file in memory in blocks of 64Kb (by the "granularity" function of Windows) and carry out a processing on each block to create the original Aud file (.aud file).
  • the creation of the file. aud is then carried out according to the following process.
  • the process initially includes an initialization phase comprising the following steps: 1- Verification of the existence of the original file 2- Creation of the header of the Aud document (HEADER) 3- Addition of the en -head to a variable “buffer_block” 4- Creation of the foot of the Aud document (PIED) - complete end of processing with the two hashes 5- Adding of the foot to a variable “buffer_pied” 6- Creation of the Aud file (empty) 7- Creation of the temporary file (empty) 8- Initialization of the hash variable SHA256
  • the processing is then performed block by block as follows: 1- Beginning of the reading loop by block of 64K of the original file 2- Processing of the blocks (except the last) 3- Final processing of the last block 4- End of the loop Then the processing is finalized with the following steps: 1- Adding the Audids certificate to the list of items in the Aud document 2- Closing the original file (releasing the block in read / write) 3- Releasing the memory (working variables, pointers, 7)
  • AES can only encrypt data blocks whose size is a multiple of 16 bytes (128 bits).
  • padding to encrypt blocks of any size. For example, if the block of data to be encrypted has a size of 28 bytes, then 4 bytes of padding will be added at the end of the block.
  • AES will encrypt a block of 32 bytes (28 bytes of data + 4 bytes of padding) and will therefore return the encrypted block on 32 bytes.
  • the padding bytes added to the end of the block to be encrypted will all contain the same value. This will be the number of bytes added for padding. In our example, each of the 4 padding bytes will contain the value 4.
  • the Mapping APIs used to optimally manipulate block files do not allow you to manipulate the blocks of a file only from an offset multiple of the granularity of the system.
  • the granularity is 65536 bytes (64 KB).
  • RULE 1 The 4 lines of the signature of the AUD document are always stored in the last block of the Aud file. If they overlap the penultimate block and the last block, then they are all placed in the last block. The penultimate block is then stuffed with bytes at 0x00. The padding of the penultimate block is also signed and is an integral part of the AUD document even if this padding data is not used for anything.
  • RULE 2 A set of information representing the context of the Aud document (its state at time "T") is created and saved. It will allow new signatures to be added to the AUD document (the variables present in the context are described below in this document).
  • FIG. 7 A processing of the final block is illustrated in Figure 7. Note that, in the processing of the last block: - we do not create a "buffer_block N + l" (which is completely normal since we are processing the last block of the file d 'origin and therefore this is the last round). - we add the "buffer_pied" at the end of the block (it was created in step 4 of the initialization phase and it obviously does not contain the 4 lines of the Audids signature).
  • the block has a size greater than 65536 bytes.
  • n therefore divides this block into 2 blocks: • A block of 65536 bytes which is added to the Aud file (it is therefore the penultimate block of the AUD file) • A block containing the rest of the "block final "where the 4 lines of the signature will be added
  • the block has a size less than 65536 bytes, but if we add the 4 lines of the signature and the AES padding (because the last block is encoded with padding), it will exceed 65536 bytes (the signature will therefore be written on 2 blocks, or according to RULE 1, it's impossible!). We therefore write the block in the penultimate block and initialize it up to 65536 bytes with bytes at 0x00. The last block of the Aud document will therefore contain only the 4 lines of the signature.
  • the block and the 4 lines of the signature which will be added to it will fit in the block to be written in the Aud file (size less than or equal to 65536 bytes).
  • the “final block” is therefore the last block of the Aud file.
  • the algorithm EC (elliptic curves) finally allows to generate the 2 lines of elliptical hash (ecLinel and ecLine2) from the hash imprint SHA-256 of all the AUD document and the Audids certificate of the AUD software on which is created this original.

Abstract

La présente invention se rapporte au domaine de la sécurisation des documents électroniques. Elle permet la sécurisation d'un document par formatage spécifique tout en maintenant l'intégrité absolue du document initial. Avec le format défini par l'invention, le texte de l'écrit électronique n'est pas dissocié des différents certificats d'authenticité. Ainsi, toute modification ou suppression du document ainsi que des certificats est décelable immédiatement . La présente invention se rapporte plus particulièrement à un procédé de génération d'un fichier authentifié par une application informatique à partir d'un écrit électronique pour le contrôle de l'accès audit fichier authentifié, caractérisé en ce qu'il comprend au moins les étapes consistant à : générer un premier ensemble de données sous forme d'entête ; - générer un second ensemble de données représentant ledit écrit électronique dans un des deux formats suivants : • format ASCII • format binaire - générer un troisième ensemble de données comprenant au moins une information correspondant à au moins un identifiant de ladite application informatique.

Description

PROCÉDÉ D'AUTHENTIFIECATION UNIVERSELLE DE DOCUMENTS
La présente invention se rapporte au domaine de l'intégrité, de la confidentialité et de la sécurisation des documents électroniques .
La présente invention se rapporte plus particulièrement à un procédé de sécurisation par formatage spécifique des documents électroniques, quel que soit le format initial du document. Ce procédé permet également un contrôle de l'accès efficace au document. Le problème technique majeur qui se pose dans le domaine de la sécurisation des documents électroniques est le maintien de l'intégrité du contenu d'un fichier initial.
Dans le domaine de la sécurisation des documents, l'art antérieur connaît déjà par la demande EP 1 320 010 un format spécifique de données sécurisées pour le contrôle d'accès. Selon un mode de réalisation de ce document, un fichier sécurisé est composé de deux parties : une en-tête (ou header) et un document crypté. L' en-tête inclut les informations de sécurité qui comporte les règles d'accès au document et une clé attachée au fichier. Les règles d'accès au document sécurisé facilitent l'accès restreint et déterminent essentiellement comment/où/quand/par qui le document est accessible. La clé associée au fichier est utilisée pour crypter et décrypter la portion du document correspondant aux données cryptées. Seuls les utilisateurs ayant un privilège d'accès au document ont la possibilité de récupérer la clé pour lire le document crypté.
L'inconvénient majeur d'un tel format de sécurisation est l'absence de certificats permettant d'authentifier les différentes personnes ayant eu accès au document. Les documents de l'art antérieur ne permettent pas non plus une traçabilité satisfaisantes des consultations et modifications des documents électroniques
La présente invention entend remédier aux inconvénients de l'art antérieur en permettant la sécurisation d'un document par formatage spécifique tout en maintenant l'intégrité absolue du document initial. Avec le format défini par l'invention, le texte de l'écrit électronique n'est pas dissocié des différents certificats d'authenticité. Ainsi, toute modification, substitution ou suppression du document ainsi que des certificats est décelable immédiatement .
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 procédé de génération d'un fichier authentifié par une application informatique à partir d'un écrit électronique pour le contrôle de l'accès audit fichier authentifié, caractérisé en ce qu'il comprend au moins les étapes consistant à : générer un premier ensemble de données sous forme d' entête; - générer un second ensemble de données représentant au moins une partie dudit écrit électronique dans un des deux formats suivants : • format ASCII • format binaire - générer un troisième ensemble de données comprenant au moins une information correspondant à au moins un identifiant de ladite application informatique. De préférence, ledit troisième ensemble de données comprend une information correspondant à un horodatage (interne ou externe) de la mise en œuvre dudit procédé.
Avantageusement, ledit identifiant de ladite application informatique comprend au moins une empreinte d'un certificat numérique de ladite application informatique. De préférence, ledit troisième ensemble de données comprend un hashage dudit identifiant de ladite application informatique .
Selon un mode de mise en oeuvre, ledit troisième ensemble de données comprend un hashage de l'ensemble de données constitué par ledit identifiant et ledit deuxième ensemble de données .
Selon un mode de réalisation, ledit troisième ensemble de données comprend un hashage de l'ensemble de données constitué par ledit identifiant, ledit deuxième ensemble de données et ledit premier ensemble de données .
De préférence, ledit identifiant de ladite application informatique comprend au moins un identifiant de l'utilisateur de ladite application informatique.
De préférence, ledit identifiant de ladite application informatique comprend au moins une signature numérique de l'utilisateur de ladite application informatique. Selon une variante, ledit premier ensemble de données comprend le numéro de version de ladite application informatique . De préférence, ledit premier ensemble de données comprend le type d'extension dudit écrit électronique.
Avantageusement, ledit premier ensemble de donnée comprend le type de confidentialité exigée pour ledit document identifié.
De préférence, ledit procédé comprend en outre une étape d'enregistrement dudit fichier authentifié avec une extension correspondant à ladite application informatique. Avantageusement, ledit identifiant de ladite application informatique comprend au moins un identifiant du matériel informatique sur lequel ladite application informatique est installée. On comprendra mieux l'invention à l'aide de la description, faite ci-aprè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 illustre le principe général de d' authentification et de signature d'un écrit électronique selon l'invention ; - la figure 2 illustre une représentation d'un document original «.aud®» en différents sous-ensembles ; la figure 3 illustre la procédure de signature multiple blocs de l'écrit à signer ; - la figure 4 illustre une représentation d'un document signé -c.aud ; - la figure 5 illustre une représentation d'un document signé -c.aud après l'insertion d'un cachet ; - la figure 6 illustre un mode de création d'un fichier . aud® ; - la figure 7 illustre un exemple de traitement du dernier bloc dans la création d'un fichier .aud® ; - la figure 8 illustre le traitement final du dernier bloc dans le cas où le bloc final a une taille supérieure à 65536 octets ; - la figure 9 illustre le traitement final du dernier bloc dans le cas où le bloc final à une taille inférieure à 65536 octets mais supérieure en ajoutant les signatures et le padding ; - la figure 10 illustre le traitement final du dernier bloc dans le cas où le bloc final a une taille inférieure à
65536 octets.
LΛétape initiale du procédé est l'installation sur le poste d'un utilisateur d'une application informatique spécifique A. Afin d'associer le hardware utilisé et l'utilisateur à cette application informatique, celui-ci saisit préalablement une fiche de renseignement correspondant à son identité professionnelle ou privée. Notons qu'une telle fiche peut correspondre à un particulier, à une entreprise privée ou à une profession libérale, etc. C'est une fiche d'identification de l'utilisateur de la licence du logiciel .
L'enregistrement de la licence de l'utilisateur et du logiciel correspond à une liste d'informations (AuDIds) comprenant par exemple les champs suivants dans le cas d'une «fiche» particulier : Numéro de licence et provenance de l'application informatique utilisée Nom de l'utilisateur Prénom de l'utilisateur - Adresse de l'utilisateur Adresse électronique de l'utilisateur Différentes données calculées comme le numéro de série du disque, le numéro Mac de la carte Ethernet... Cette fiche peut aussi être remplie à l'aide d'une carte d'identité électronique, d'un passeport électronique ou de tout autre mécanisme permettant une identification de 1' tilisateur. A partir de ces différents champs et données, un calcul est réalisé pour obtenir un certificat de l'application associée à l'utilisateur spécifique ayant réalisé l'identification et à l'ordinateur sur lequel se trouve l'application. Le hashage est du type SHA 256 de type connu, pour un algorithme de cryptage AES (Advanced Encryption Standard) et la base mathématique est issue de courbes elliptiques (EC) . Ce certificat est la «signature» de l'application informatique de l'utilisateur (Audlds) . Le certificat « Audlds » (ou signature de l'application) est ensuite stocké dans la « base locale », cryptée de l'ordinateur de l'utilisateur.
Successivement, un certificat «AudSig» (signature de l'utilisateur) propre à l'utilisateur est créé ou importé.
Cette signature est une combinaison d'un mot de passe d'au moins 8 caractères et de l'identité de l'utilisateur. Elle peut être stockée par exemple en externe : sous forme de fichier .sign crypté, sur une clé USB ou une carte mémoire ou directement dans la «base locale» du poste utilisateur. Elle peut également être associée à une donnée biométrique de l'utilisateur (empreinte digitale ou reconnaissance d'iris), son usage doit être confirmé par la validation de la donnée biométrique. La phase d'installation se termine par la création d'un contrat de licence électronique «AUD» que l'utilisateur a lu avant de faire « accepte », qui est signé par le certificat Audlds et le certificat AudSig. Ce contrat, signé électroniquement est envoyé automatiquement par E-mail chez le distributeur via Internet. Le contrat AUD et les attributs des certificats sont stockés dans une base de données. Ce stockage permet de vérifier les certificats de licence grâce au numéro de licence unique, dont une partie est calculée lors de l'installation du logiciel et à l'ID du certificat (empreinte) du produit dans une optique de traçabilité des documents. Une clef d' activation est renvoyée, dès l'enregistrement effectué.
En possession de ces «signatures», l'utilisateur peut maintenant créer des documents certifiés conformes dits originaux de type « .aud®».
A partir d'un écrit électronique initial Dl, l'application informatique A est apte à transformer le format du document pour en faire un document authentifié de type «.aud®». Notons que le document Dl peut être dans un format numérique quelconque ASCII ou binaire (texte, image, vidéo, musique) . La structure du format des documents originaux .aud® est la suivante : une en-tête, un corps correspondant à l'écrit électronique d'origine, un pied. Notons que les deux parties en-tête et corps ne sont pas modifiables une fois le document «.AUD®» crée. Par contre, le pied du fichier, qui contiendra les différentes signatures et les cachets, est variable et évolue au fur et à mesure de la diffusion du document.
Les différentes parties du document certifié sont sous forme de balises et de contenus. A partir d'un document originel, celui-ci est donc modifié selon l'invention sous la forme suivante :
Balise début en-tête Contenu en-tête Balise Fin en-tête
Balise début document originel Contenu document originel Balise fin document originel
Balise début pied Contenu pied
Illustré figure 2, le contenu de l' en-tête (bloc 1) contient plusieurs champs importants dont au moins : le numéro de version : c'est le numéro de la version de l'application qui a permis la création du document . aud® ; le type de document : ce champ identifie le type de document parmi les documents non signés, signés ou accusé de réception ; le nom du fichier originel ; - l'extension : c'est le type d'extension du fichier originel (.doc, .pdf, .xls pour les plus classiques) ; le type de diffusion désiré : ce champ définit les modalités de contrôle de l'accès au document ; le numéro d'original (numéro unique par original AUD® créé) .
Ce nombre de champs n'est bien sûr pas limité, mais une fois créée, cette en-tête est non modifiable une fois le fichier sécurisé .aud ® créé.
Le contenu du document originel n'est pas modifié par l'application informatique mettant en œuvre le procédé selon l'invention. Il est dans un format binaire ou ASCII gardant ainsi une parfaite intégrité (bloc 2) .
La partie essentielle de l' authentification est la signature de l'application informatique présente en pied de document . Ce pied contient d'une part un premier sous-ensemble AUDInfo limité par deux sous-balises de type Début AUDInfo et Fin AUDInfo (bloc 3) . Ce sous-ensemble comprend un horodatage de la création du fichier original .AUD® permettant la traçabilité de la création du document.
Le certificat de l'application informatique permettant de créer le document est alors inséré à la suite du sous- ensemble AUDInfo après une sous-balise du type Début AUDIds (bloc 4) .
Ce certificat inséré en pied du document .AUD® contient plusieurs champs en ligne dont au moins :
1. Les informations en clair Audlds correspondant à la licence du logiciel, au hardware et à l'utilisateur ; 2. L'empreinte du certificat (ID) de l'application informatique ; 3. Un hash du document à signer correspondant à l'ensemble du document depuis le début du Header jusqu'à la fin du sous-ensemble AUDInfo (donc jusqu'à la balise Fin AUDInfo) ; 4. Un hash des lignes précédentes 2 et 3.
Les hash des lignes 3 et 4 est encore réalisé par un algorithme de courbe elliptique et SHA-256. Notons que le hashage de la ligne 4 permet de lier mathématiquement le document à signer et l'empreinte du certificat de l'application informatique (ID) .
Une fois cette signature réalisée, le document est crypté et enregistré sur le disque du poste utilisateur en tant que fichier par exemple test . aud. Concrètement, ce type de fichier correspond à un document papier mis dans un parapheur et prêt à la signature.
Si ce document doit être modifié, il doit alors être réimprimé, ce qui correspond à la création d'un nouveau fichier «.AUD®» qui aura un certificat différent du premier.
Notons que la procédure de signature d'un document, le calcul du hash est effectué bloc par bloc comme sur la figure 3. En effet, le document DO à être signé devant être mis en mémoire avant d'insérer la signature, cette mise en mémoire est effectuée par blocs de plus petite taille afin de ne pas avoir un temps de traitement trop long. On obtient alors un ensemble de signatures (SI, S2, (...), Sn) pour les différents blocs. Une signature unique «S0» est alors obtenue par signature de la concaténation de ces différentes signatures. Ce procédé de traitement par bloc pour obtenir un traitement rapide et une sécurisation des données sera expliqué plus en détail dans un mode de réalisation de l'invention illustré figures 6, 7, 8, 9 et 10.
Notons enfin qu'un tel document «.AUD®» n'est lisible qu'avec une application informatique apte à lire le format tel que défini ci-dessus. En particulier, les applications classiques (Word, Excel) ne permettront pas d'ouvrir un document original «.AUD®».
Le document «.AUD®» décrit ci-dessus peut alors recevoir les différentes signatures ou cachets correspondant à la diffusion du document. Illustré figure 4, la signature est ajoutée en pied de document. Elle est toujours précédée d'un sous-ensemble AUDInfo (bloc 5) comprenant l'horodatage de l'insertion de la signature comme précédemment entre deux sous-balises Début AUDInfo et Fin AUDInfo. Si l'utilisateur est connecté à Internet, cet horodatage est obtenu par le protocole NTP.
La signature du document par l'utilisateur (bloc 6) comprend alors comme précédemment les 4 champs correspondants aux informations AUDIDs, à la signature de l'application informatique, au hashage du document à signer correspondant à l'ensemble du document depuis le début du Header (en-tête) jusqu'à la fin du sous-ensemble AUDInfo précédent (donc jusqu'à la balise Fin AUDInfo qui vient juste d'être créée) et au hashage des deux lignes précédentes . Notons que lors de l'insertion d'une signature, les hashages inclus dans les certificats précédents sont supprimés, d'une part parce qu'ils sont devenus désuets à cause de l'insertion d'un nouveau sous-ensemble du pied, et d'autre part pour qu'il ne soit absolument pas possible de supprimer des signatures, même en retrouvant les informations à partir du hashage. On obtient donc un bloc d'identification 4' légèrement différent du bloc 4, avec la dernière ligne hashage en moins . Le document «.AUD®» ainsi signé est alors enregistré en tant que document signé par exemple sous le nom test-c . aud. Illustré figure 5, il est également possible d'ajouter un certificat sous forme de cachet local (bloc 8) . Lors de l'insertion d'un tel cachet local, l'utilisateur (défini par les informations contenues dans AUDInfo) peut définir un type de cachet spécifique, par exemple «courrier» ou «service administratif», «Bon à Publier» qui sera inséré dans le certificat . Comme précédemment, le cachet (bloc 8) sera précédé d'un sous-ensemble AUDInfo (bloc 7) et des 4 champs spécifiques au cachet et à celui qui insère le cachet. L'ensemble du document est alors crypté. Le bloc 6' correspond encore au bloc 6 auquel a été retirée la dernière empreinte elliptique. Il est également possible d'insérer une co-signature . Cette co-signature permet d'ajouter une signature non activée à l'application informatique sur laquelle est lu le document qui va être signé. L'utilisateur de l'application informatique «ouvre» alors l'accès aux signatures extérieures par exemple par clé externe ou carte à puce.
L'application de cette co-signature est par exemple celle d'une réunion où chacun approuve par apposition de sa signature sur le document «ouvert» sur le poste du secrétaire général .
Comme précédemment, le cachet sera précédé d'un sous- ensemble AUDInfo correspondant à l'application de celui qui autorise la co-signature, et des 4 champs spécifiques au cosignataire. Il est ainsi possible de voir par exemple que «Martinez a signé le document sur le logiciel de Dupont».
Enfin, il est possible d'ajouter un certificat spécial correspondant à une demande d'accusé de réception. Cette demande est signée comme précédemment, mais elle modifie le champ de l' en-tête correspondant au type de confidentialité demandé . Ainsi, lors de la réception du document, le destinataire devra être connecté sur le réseau afin que l'application puisse envoyer un mail à l'expéditeur comprenant un fichier joint du type «test-ar. aud» comprenant : les attributs du certificat «Audlds» du logiciel qui ouvre le fichier AUD, les attributs du certificat «Audids» du fichier AUD, les attributs certificat «AudSig» et la signature de l'utilisateur qui ouvre le fichier AUD. Le fichier «-ar.aud» est alors signé et envoyé au demandeur de l'Accusé de réception.
Tant que l'accusé de réception n'est pas envoyé, il est impossible d'ouvrir le document AUD®.
Enfin, un second certificat spécial permet de restreindre la diffusion d'un document AUD®. Ceci est réalisable est stockant par exemple une clé de cryptage au niveau d'un serveur local. Les différentes applications informatiques ayant accès à ce réseau local peuvent alors décrypter le document, mais pas celles hors du réseau local . (Mode de diffusion restreinte) De la même façon, pour une communication confidentielle entre deux personnes, une clé spécifique est générée et échangée seulement entre les deux utilisateurs désirant échanger les documents de façon confidentielle.
Nous allons maintenant décrire un mode de mise en œuvre du procédé précédemment décrit. La création d'un fichier AUD® peut être réalisée en C++ sous Microsoft Visual C++. Ce langage de programmation est connu de l'homme du métier.
L'utilisateur doit d'abord sélectionner le fichier d'origine (écrit électronique à sécuriser) à partir duquel il veut créer l'original Aud. A ce niveau, le système ne fait que stocker le chemin du fichier choisit par l'utilisateur et bloquer ce fichier d'origine en lecture/écriture (pour ne pas qu'une autre application puisse l'utiliser pendant le traitement) . Cette action est instantanée car aucun traitement n'est effectué sur le fichier d'origine. Quand l'utilisateur va créer l'original AUD® (en cliquant sur le bouton approprié) , le système va mapper le fichier d'origine en mémoire par bloc de 64Ko (par la fonction « granularity » de Windows) et effectuer un traitement sur chaque bloc pour créer le fichier original Aud (fichier. aud) .
La création du fichier. aud est alors réalisée selon le processus suivant. Le processus comprend d'abord une phase d'initialisation comprend les étapes suivantes : 1- Vérification de l'existence du fichier d'origine 2- Création de l' en-tête du document Aud (HEADER) 3- Ajout de l' en-tête à une variable « buffer_block » 4- Création du pied du document Aud (PIED) - compléter fin de traitement par les deux hash 5- Ajout du pied à une variable « buffer_pied » 6- Création du fichier Aud (vide) 7- Création du fichier temporaire (vide) 8- Initialisation de la variable de hashage SHA256
Le traitement est alors réalisé bloc par bloc comme suit : 1- Début de la boucle de lecture par bloc de 64Ko du fichier d'origine 2- Traitement des blocs (sauf le dernier) 3- Traitement final du dernier bloc 4- Fin de la boucle Puis le traitement est finalisé avec les étapes suivantes : 1- Ajout du certificat Audids à la liste des items du document Aud 2- Fermeture du fichier d'origine (libération du blocage en lecture/écriture) 3- Libération de la mémoire (variables de travail, pointeurs, ...)
Le premier problème qui se pose dans ce type de traitement par bloc avec encodage AES pour des raisons de sécurité est que AES ne peut crypter que des blocs de données dont la taille est un multiple de 16 octets (128 bits) . On utilise alors un bourrage (padding) pour crypter des blocs de n'importe quelle taille. Par exemple, si le bloc de données à crypter a une taille de 28 octets, alors 4 octets de padding seront ajoutés à la fin du bloc. Ainsi AES cryptera un bloc de 32 octets (28 octets de données + 4 octets de padding) et retournera donc le bloc crypté sur 32 octets .
Les octets de padding ajoutés à la fin du bloc à crypter contiendront tous la même valeur. Ce sera le nombre d'octets ajoutés pour le padding. Dans notre exemple, chacun des 4 octets de padding contiendra la valeur 4.
Au contraire, lorsque l'on est sûr que le bloc à crypter a une taille multiple de 16 octets, on peut alors crypter le bloc de données SANS PADDING.
Cela présente l'avantage d'obtenir un bloc de données crypté ayant la même taille que le bloc de données non crypté .
Par ailleurs, les API de Mapping utilisés pour manipuler les fichiers par blocs de manière optimale ne permettent de manipuler les blocs d'un fichier qu'à partir d'un offset multiple de la granularité du système. Sur les plates-formes Windows 32 bits, la granularité est de 65536 octets (64 Ko) .
C'est pour cette raison qu'on est contraint d'utiliser des blocs de 64 Ko, car le pointeur de fichier ne peut accéder aux morceaux du fichier que tous les 65536 octets. Enfin, lors du traitement par bloc, les différents encodages AES et hashages SHA 256 doivent apporter des niveaux de sécurité suffisants.
Le procédé utilisé est alors celui illustré figure 6 pour le traitement d'un bloc quelconque (sauf le dernier) .
On remarque que le traitement d'un bloc peut se décomposer en 4 phases : 1- Récupération du bloc N du fichier d'origine (à partir d'un offset N * 64 Ko) et écriture de ce bloc dans le fichier temporaire (à l'offset N * 64 Ko) 2- Découpage du bloc N en 2 parties. La 2eme partie du bloc est placée dans le «buffer_block N+l» et sera utilisé dans le traitement du prochain bloc (N+l) tandis que la première partie du bloc N est ajoutée à la suite du « buffer_block N». 3- Récupération de l'empreinte de hachage SHA256 du nouveau bloc N. 4- Encodage AES (sans padding) du nouveau bloc N et écriture du bloc encodé dans le fichier Aud (à l'offset N * 64 Ko) Le traitement du dernier bloc du fichier d'origine, bien qu' identique dans le principe au traitement des autres blocs, est spécifique, car il y a des cas particuliers qu'il faut pouvoir contrôler efficacement. Les règles de traitement suivantes sont alors établies pour le traitement :
REGLE 1 : Les 4 lignes de la signature du document AUD sont toujours stockées dans le dernier bloc du fichier Aud. Si elles chevauchent l'avant-dernier bloc et le dernier bloc, elles sont alors toutes placées dans le dernier bloc. L'avant dernier bloc est alors bourré avec des octets à 0x00. Le padding de l'avant dernier bloc aussi est signé et fait partie intégrante du document AUD même si ces données de bourrage ne servent à rien.
REGLE 2 : Un ensemble d' informations représentant le contexte du document Aud (son état à l'instant «T») est créé et sauvegardé. Il permettra d'ajouter de nouvelles signatures au document AUD (les variables présentent dans le contexte sont décrites plus bas dans ce document) .
Un traitement du bloc final est illustré figure 7. Remarquons que, dans le traitement du dernier bloc : - on ne crée pas de « buffer_block N+l » (ce qui est tout à fait normal puisqu'on traite le dernier bloc du fichier d'origine et qu'il s'agit donc de la dernière ronde) . - on ajoute le « buffer_pied » à la fin du bloc (il a été crée dans l'étape 4 de la phase d'initialisation et il ne contient évidemment pas les 4 lignes de la signature Audids) .
On a donc au final un bloc appelé « final block » qui regroupe le « buffer_block » de la ronde précédente, le dernier bloc du fichier d'origine et le pied du document AUD. Il y a alors 3 cas de figures possibles (chaque cas est traité dans le processus « Traitement Final du bloc ») illustrés figures 8, 9, et 10 :
1. Le bloc a une taille supérieure à 65536 octets. Dans ce cas, n découpe donc ce bloc en 2 blocs : • Un bloc de 65536 octets qu'on ajoute au fichier Aud (c'est donc l'avant-dernier bloc du fichier AUD) • Un bloc contenant le reste du "bloc final" où il sera ajouté les 4 lignes de la signature
2. Le bloc a une taille inférieure à 65536 octets, mais si on lui ajoute les 4 lignes de la signature et le padding AES (car le dernier bloc est encodé avec padding) , il dépassera 65536 octets (la signature sera donc écrite sur 2 blocs, or d'après la REGLE 1, c'est impossible !) . On écrit donc le bloc dans l'avant-dernier bloc et on l'initialise jusqu'à 65536 octets avec des octets à 0x00. Le dernier bloc du document Aud contiendra donc uniquement les 4 lignes de la signature.
3. Le bloc et les 4 lignes de la signature qui vont y être ajoutées tiendront dans le bloc à écrire dans le fichier Aud (taille inférieure ou égal à 65536 octets) . Le «final block » est donc le dernier bloc du fichier Aud.
Une fois le traitement de l'un de ces 3 cas de figures (en fonction de la taille du « final block ») , on traite le dernier bloc à écrire dans le fichier AUD en effectuant les opérations suivantes : • génération de l'empreinte de hashage SHA256 globale du document AUD. • génération des 2 lignes de hashages elliptiques (ecLinel et ecLine2) . • ajout des 4 lignes de la signature à la fin du bloc . • encodage AES (avec padding) du bloc. • écriture du dernier bloc dans le fichier AUD. • sauvegarde d'un contexte (ensemble de variables) pour pouvoir ajouter des signatures au document Aud qui vient d'être crée.
L'algorithme EC (courbes elliptiques) permet enfin de générer les 2 lignes de hash elliptique (ecLinel et ecLine2) à partir de l'empreinte de hashage SHA-256 de tout le document AUD et du certificat Audids du logiciel AUD sur lequel est créé cet original.
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.

Claims

REVENDICATIONS
1. Procédé de génération d'un fichier authentifié par une application informatique à partir d'un écrit électronique pour le contrôle de l'accès audit fichier authentifié, caractérisé en ce qu'il comprend au moins les étapes consistant à : générer un premier ensemble de données sous forme d' entête; - générer un second ensemble de données représentant au moins une partie dudit écrit électronique dans un des deux formats suivants : • format ASCII • format binaire - générer un troisième ensemble de données comprenant au moins une information correspondant à au moins un identifiant de ladite application informatique ; et en ce que ledit identifiant de ladite application informatique comprend au moins un identifiant de l'utilisateur de ladite application informatique.
2. Procédé de génération d'un fichier authentifié par une application informatique à partir d'un écrit électronique selon la revendication 1, caractérisé en ce que ledit troisième ensemble de données comprend une information correspondant à un horodatage de la mise en œuvre dudit procédé .
3. Procédé de génération d'un fichier authentifié par une application informatique à partir d'un écrit électronique selon la revendication 1, caractérisé en ce que ledit identifiant de ladite application informatique comprend au moins une empreinte d'un certificat numérique de ladite application informatique.
4. Procédé de génération d'un fichier authentifié par une application informatique à partir d'un écrit électronique selon la revendication 1, caractérisé en ce que ledit troisième ensemble de données comprend un hashage dudit identifiant de ladite application informatique.
5. Procédé de génération d'un fichier authentifié par une application informatique à partir d'un écrit électronique selon la revendication 1, caractérisé en ce que ledit troisième ensemble de données comprend un hashage de l'ensemble de données constitué par ledit identifiant et ledit deuxième ensemble de données .
6. Procédé de génération d'un fichier authentifié par une application informatique à partir d'un écrit électronique selon la revendication 1, caractérisé en ce que ledit troisième ensemble de données comprend un hashage de l'ensemble de données constitué par ledit identifiant, ledit deuxième ensemble de données et ledit premier ensemble de données .
7. Procédé de génération d'un fichier authentifié par une application informatique à partir d'un écrit électronique selon la revendication 1, caractérisé en ce que ledit identifiant de ladite application informatique comprend au moins une signature numérique de l'utilisateur de ladite application informatique.
8. Procédé de génération d'un fichier authentifié par une application informatique à partir d'un écrit électronique selon la revendication 1, caractérisé en ce que ledit premier ensemble de données comprend le numéro de version de ladite application informatique.
9. Procédé de génération d'un fichier authentifié par une application informatique à partir d'un écrit électronique selon la revendication 1, caractérisé en ce que ledit premier ensemble de données comprend le type d'extension dudit écrit électronique .
10. Procédé de génération d'un fichier authentifié par une application informatique à partir d'un écrit électronique selon la revendication 1, caractérisé en ce que ledit premier ensemble de données comprend le type de confidentialité exigée pour ledit document identifié.
11. Procédé de génération d'un fichier authentifié par une application informatique à partir d'un écrit électronique selon la revendication 1, caractérisé en ce que ledit procédé comprend en outre une étape d'enregistrement dudit fichier authentifié avec une extension correspondant à ladite application informatique.
12. Procédé de génération d'un fichier authentifié par une application informatique à partir d'un écrit électronique selon la revendication 1, caractérisé en ce que ledit identifiant de ladite application informatique comprend au moins un identifiant du matériel informatique sur lequel ladite application informatique est installée.
13. Procédé de génération d'un fichier authentifié par une application informatique à partir d'un écrit électronique selon la revendication 1, caractérisé en ce qu'il comprend en outre une étape de découpage dudit écrit électronique en un ensemble de blocs .
14. Procédé de génération d'un fichier authentifié par une application informatique à partir d'un écrit électronique selon la revendication 13, caractérisé en ce que la taille de chaque bloc est au plus 64 Ko.
PCT/FR2005/050416 2004-06-03 2005-06-03 Procede d'authentification universelle de documents WO2005124503A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0451097 2004-06-03
FR0451097A FR2871251B1 (fr) 2004-06-03 2004-06-03 Procede d'authentification universelle de documents

Publications (1)

Publication Number Publication Date
WO2005124503A1 true WO2005124503A1 (fr) 2005-12-29

Family

ID=34945062

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2005/050416 WO2005124503A1 (fr) 2004-06-03 2005-06-03 Procede d'authentification universelle de documents

Country Status (2)

Country Link
FR (1) FR2871251B1 (fr)
WO (1) WO2005124503A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010023482A1 (en) * 1999-12-08 2001-09-20 Hewlett-Packard Company Security protocol
WO2002028007A1 (fr) * 2000-09-28 2002-04-04 Curl Corporation Metadonnees de composants extensibles en toute securite
US20020048372A1 (en) * 2000-10-19 2002-04-25 Eng-Whatt Toh Universal signature object for digital data
WO2003034652A1 (fr) * 2001-10-17 2003-04-24 Byers James T Procede et appareil permettant d'utiliser des renseignements biometriques comme signature pour un contrat

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010023482A1 (en) * 1999-12-08 2001-09-20 Hewlett-Packard Company Security protocol
WO2002028007A1 (fr) * 2000-09-28 2002-04-04 Curl Corporation Metadonnees de composants extensibles en toute securite
US20020048372A1 (en) * 2000-10-19 2002-04-25 Eng-Whatt Toh Universal signature object for digital data
WO2003034652A1 (fr) * 2001-10-17 2003-04-24 Byers James T Procede et appareil permettant d'utiliser des renseignements biometriques comme signature pour un contrat

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
SCHNEIER B: "Applied Cryptography", APPLIED CRYPTOGRAPHY. PROTOCOLS, ALGORITHMS, AND SOURCE CODE IN C, NEW YORK, JOHN WILEY & SONS, US, 1996, pages 29 - 31,47, XP002206240, ISBN: 0-471-11709-9 *
SEARCHSMALLBIZIT: "GUID", SEARCHSMALLBIZIT.COM DEFINITIONS, 26 March 2003 (2003-03-26), XP002312187, Retrieved from the Internet <URL:http://searchsmallbizit.techtarget.com/sDefinition/0,,sid44_gci213990,00.html> [retrieved on 20041229] *

Also Published As

Publication number Publication date
FR2871251B1 (fr) 2007-02-16
FR2871251A1 (fr) 2005-12-09

Similar Documents

Publication Publication Date Title
EP3547202B1 (fr) Méthode d&#39;accès à des données anonymisées
EP3547203B1 (fr) Méthode et système de gestion d&#39;accès à des données personnelles au moyen d&#39;un contrat intelligent
EP2071798B1 (fr) Procédé et serveur de coffres-forts électroniques avec mutualisation d&#39;informations
US8078880B2 (en) Portable personal identity information
EP3590223A1 (fr) Procede et dispositif pour memoriser et partager des donnees integres
EP2949070B1 (fr) Procédé de vérification de l&#39;intégrité d&#39;un bloc de données numériques
WO2007077324A1 (fr) Procede de certification et d&#39;authentification ulterieure de documents originaux papier ou numeriques pour constitution de preuves
FR3082023A1 (fr) Une application logicielle et un serveur informatique pour authentifier l’identite d’un createur de contenu numerique et l’integrite du contenu du createur publie
EP1095491A1 (fr) Procede, systeme, serveur et dispositif pour securiser un reseau de communication
FR3048530B1 (fr) Systeme ouvert et securise de signature electronique et procede associe
FR3100631A1 (fr) Méthode d’authentification sélective d’un utilisateur de chaine de blocs auprès d’un contrat intelligent
CA2589223C (fr) Procede d&#39;identification d&#39;un utilisateur au moyen de caracteristiques biometriques modifiees et base de donnees pour la mise en oeuvre de ce procede
CA2694335C (fr) Gestion et partage de coffres-forts dematerialises
WO2003034654A2 (fr) Procede et dispositif de protection de donnees
WO2005124503A1 (fr) Procede d&#39;authentification universelle de documents
WO2020225292A1 (fr) Procede de generation d&#39;un code d&#39;archivage pour creer une empreinte d&#39;un contenu multimedias
EP3545448A1 (fr) Procédé d&#39;insertion de données à la volée dans une base de données tatouées et dispositif associé
FR3073111A1 (fr) Procede et dispositif pour memoriser et partager des donnees integres
EP4193283A1 (fr) Procede pour generer un document numerique securise stocke sur un terminal mobile et associe a une identite numerique
EP0595720A1 (fr) Procédé et système d&#39;incription d&#39;une information sur un support permettant de certifier ultérieurement l&#39;originalité de cette information
FR3085508A1 (fr) Procede securise de partage retarde de donnees entre au moins un utilisateur emetteur et au moins un utilisateur destinataire, avec horodatage sur blockchain.
FR2903509A1 (fr) Module electronique pour le stockage de donnees
FR2861519A1 (fr) Procede de securisation et verification d&#39;un document etabli et signe par voie electronique ainsi que le dispositif pour la mise en oeuvre de ce procede.
FR2862827A1 (fr) Procede de gestion de donnees de securite
WO2008132393A2 (fr) Procédé et système d&#39;authentification d&#39;un utilisateur

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase