FR2811174A1 - Procede pour apposer et authentifier un sceau electronique sur un document electronique - Google Patents

Procede pour apposer et authentifier un sceau electronique sur un document electronique Download PDF

Info

Publication number
FR2811174A1
FR2811174A1 FR0008314A FR0008314A FR2811174A1 FR 2811174 A1 FR2811174 A1 FR 2811174A1 FR 0008314 A FR0008314 A FR 0008314A FR 0008314 A FR0008314 A FR 0008314A FR 2811174 A1 FR2811174 A1 FR 2811174A1
Authority
FR
France
Prior art keywords
seal
authentication
document
question
authentication server
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
FR0008314A
Other languages
English (en)
Inventor
Remi Equoy
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
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 Individual filed Critical Individual
Priority to FR0008314A priority Critical patent/FR2811174A1/fr
Publication of FR2811174A1 publication Critical patent/FR2811174A1/fr
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

La présente invention concerne un procédé pour apposer un sceau électronique sur un document électronique, pour authentifier le scellé apposé sur un document électronique et pour identifier le porteur du sceau dont le scellé est apposé sur un document électronique. L'authentification du scellé et l'identification du signataire est possible par le biais d'un tiers de confiance qui peut certifier, si besoin est, de l'authenticité du scellé. Le procédé selon l'invention est particulièrement destiné à sécuriser les transactions bancaires nécessaires au commerce électronique, et à permettre d'une façon plus générale, la signature officielle de documents contractuels.

Description

La présente invention concerne un procédé pour apposer un sceau
électronique sur un document électronique, pour authentifier le scellé apposé sur un document électronique et pour identifier le porteur du sceau dont le scellé est apposé sur un document électronique. La notion d'authentification du scellé et de l'identification du signataire est possible par le biais d'un tiers de confiance qui peut certifier, si besoin
est, de l'authenticité du scellé.
D'une façon générale, mais pas exclusive, le tiers de confiance sera accessible indirectement, à travers un réseau de télécommunication. Ce réseau peut être un réseau ouvert tel qu'est le réseau mondial Internet, o tout autre type de réseau ou l'identité et les intentions des acteurs en présence sont inconnues. Ce réseau est susceptible d'être le point faible de la sécurité. Ce vecteur est couramment utilisé par les pirates du réseau. A ce jour, les dispositifs de sécurité mis en place, comme le cryptage, permettent une sécurité au niveau de la transmission. Cette sécurité ne garantie pas de
l'utilisation qui va être faite des informations transmises.
Un numéro de carte bleue, par exemple, peut donc être
réutilisé pour effectuer des achats en lignes tant que celui-
ci n'est pas actualisé dans une liste noire. De plus, dans un réseau ouvert, rien ne garantit de l'identité de l'interlocuteur. Ce sont quelques unes des raisons qui interdisent aujourd'hui la maturation du commerce électronique. Un problème similaire se constate aussi dans le domaine plus générale de l'EDI (Echange de Données Informatiques). Il est quasi impossible actuellement de transmettre des documents officiels, dûmnent signés et
authentifiés par les parties présentes dans un réseau ouvert.
Le procédé selon l'invention permet de remédier à ces inconvénients. Il permet d'apposer un scellé avec un sceau sur un document de façon unique. Le scellé déposé sur un document
n'est pas réutilisable pour un autre document, même identique.
Il permet d'authentifier un scellé, par un tiers de confiance, lui-même simultanément authentifié. Il permet de connaître -2- l'identité du signataire d'un scellé telle qu'elle est connue
par ce même tiers de confiance.
On entend par tiers de confiance une personne morale ou physique, une société, une organisation, une banque ou un département du gouvernement capable de délivrer des sceaux, et
capables de certifier les scellés émis par ces mêmes sceaux.
On entend par sceau électronique un dispositif électronique dont la propriété essentielle est d'être le
support d'une mémoire en lecture écriture non volatile.
On entend par porteur, une personne physique ou morale qui détient un sceau électronique délivré par un tiers de confiance. On entend par scellé une signature unique et non
réutilisable apposé avec un sceau sur un document.
On entend par signataire la personne morale ou physique porteur du sceau, ou habilitée à l'utiliser par le tiers de
confiance, qui a apposé son sceau sur un document.
On entend qu'un porteur qui a apposé son sceau sur un
document a par là même, signé ce document.
Le sceau électronique est délivré par un tiers de confiance, qui peut être dans le cadre du commerce électronique une banque, dans le cadre de l'EDI, un organisme
central. D'une façon générale, on entend dans la description
qui suit que le serveur informatique mis en place par le tiers de confiance, et qui délivre des comptes-rendus d'authentification, est appelé serveur d'authentification. Le serveur d'authentification n'est pas nécessairement un ordinateur central. Ce peut être, par exemple, un réseau d'ordinateur, relié entre eux par un réseau de télécommunication privé, ultra sécurisé (tel que cela existe aujourd'hui dans les réseaux bancaires). Cela va permettre au porteur d'un sceau électronique, d'authentifier un scellé et d'identifier le signataire d'un document en toute sécurité, alors que celui-ci utilise un sceau électronique délivré par un tiers de confiance différent. Le serveur d'authentification permet d'émettre des comptes-rendus d'authentification en -3- réponse à des demandes d'authentification, à travers un réseau
de télécommunication.
Lorsque le tiers de confiance délivre un nouveau sceau, il crée un compte avec toutes les informations nécessaires pour identifier le signataire sur le serveur d'authentification. De plus il crée une base de données propre
à chaque compte.
Cette base de données est constituée de deux séries de données. La première série de données est appelée base d'authentification, la seconde série de données est appelée
base de signature. Chaque série est constituée de N questions.
A chaque question il existe une réponse. Le nombre N est adapté aux besoins de l'utilisation. Dans une série, les questions et les réponses sont toujours unique. On entend par doublon n le couple de la question n et de sa réponse. Chaque doublon n'est utilisable qu'une fois. Le nombre de doublon d'une série est toujours beaucoup plus grand que le nombre de questions, ou que le nombre de réponses possibles. La base d'authentification et la base de signature n'ont pas nécessairement le même nombre de doublons. La base de
signature est utilisée pour déposer un scellé sur un document.
La base d'authentification est utilisée pour authentifier un scellé. Chaque réponse de la base d'authentification est décomposée en deux parties. La première partie est appelée réponse publique. La seconde partie est appelée réponse privée. La base de signature contient, ou peut contenir, en plus, pour chaque doublon, un espace mémoire dans lequel
seront rangés des informations obtenues ultérieurement.
Cette base de données peut être constituée aléatoirement. Cette base de données est copiée dans le sceau électronique, de façon à ce que le serveur d'authentification et le sceau disposent initialement de la même base de données.
Le sceau est ensuite délivré au porteur.
-4. Avant d'être signé par un porteur, un document électronique doit être codé par un calcul de codage de document (connue faisant partie de l'état de la technique). Le codage peut être fait sur différents formats, et le codage lui-même peut être de nature différente suivant les besoins retenus. Le résultat de ce codage délivre un nombre appelé "code opération". Un codage bien réalisé permet de penser qu'il n'y a qu'un code opération possible pour un document donné dans un format donné. Par exemple, dans le cadre du commerce électronique, le code opération d'un bon de commande peut comporter en plus du codage le prix et le numéro du bon
de commande.
Pour apposer son sceau sur un document (pour signer un document), le procédé va utiliser le code opération ainsi que l'information contenue dans sa base de signature. Parmi les N doublons contenus dans la base de signature, certains ont déjà été utilisés. Il reste donc N' doublons possible. C'est une fonction de calcul avec le code opération et N' comme argument qui détermine le doublon à utiliser(connue faisant partie de l'état de la technique). C'est, par exemple, le calcul de: code opération modulo N', qui va permettre de déterminer le doublon à utiliser pour signer le document. Une fois le doublon déterminé, il est joint au document avec le code opération calculé et le numéro du sceau, puis transmis à l'intéressé. Le doublon déterminé est aussi marqué comme étant utilisé dans le sceau. Les informations suivantes sont donc transmises à l'intéressé:
- Le document.
- Le numéro du sceau du signataire.
- Le code opération du document.
- Un doublon issu de la base de signature, faisant
office de scellé.
On entend par intéressé, la personne morale ou physique
porteur d'un sceau, qui désire authentifier un scellé.
Pour authentifier un scellé, un intéressé peut commencer par vérifier que le format du document qu'il a réceptionné est un format valide, et que le code opération correspond bien au -5- contenu du document. Ensuite, l'intéressé va utiliser le Code opération ainsi que la question transmise par le signataire pour calculer le numéro de l'identification à utiliser. Parmi les N doublons contenus dans la base d'authentification, certains ont déjà été utilisés. Il reste donc N' doublons possible. C'est une fonction de calcul avec le code opération, la question contenue dans le doublon et N' comme argument qui détermine le doublon à utiliser(connue faisant partie de l'état de la technique).C'est, par exemple, le calcul de: code opération + question du signataire, le tout modulo N', qui va permettre de déterminer le doublon à utiliser pour authentifier le document. Le doublon utilisé est marqué dans le sceau comme étant utilisé. Une fois le doublon déterminé, les informations suivantes sont transmises au serveur d'authentification de l'intéressé:
- Le code opération du document.
- Le numéro du sceau du signataire.
- La question issue de la base de signature délivrée par
le signataire.
- Le numéro du sceau de l'intéressé.
- La question issue de la base d'authentification
déterminée par le sceau de l'intéressé.
- La demande de l'identification du signataire (facultatif). - Des documents complémentaires (facultatif) L'ensemble de ces informations est appelé demande d'authentification. A la réception d'une demande d'authentification, le serveur d'authentification va vérifier la justesse des deux questions transmises en fonction des informations dont il dispose. Pour vérifier que la question du signataire est juste, il va déterminer, en suivant le même calcul que le signataire, en fonction du code opération et du nombre de doublons utilisables, le numéro du doublon à utiliser. Il peut alors vérifier que la question trouvée est bien identique à celle que l'on lui a transmise. Il procède de même pour la question demandée par l'intéressé. Que les -6- questions soient justes ou fausses, le serveur retournera toujours un compte-rendu avec des réponses au questions posées. Seul le porteur qui a émit la demande d'authentification pourra savoir si les réponses sont justes ou fausses. Si une question est juste, le compte-rendu délivrera la réponse à cette question. Si une question est fausse, le compte-rendu délivrera une réponse fausse à cette question. Seule la réponse publique sera retournée pour la question posée dans la base d'authentification. Lorsqu'une question est fausse, aucun doublon n'est considéré comme utilisé. Lorsqu'une question est juste, le doublon est alors considéré comme utilisé. Dans la base de signature, comme dans la base d'authentification, une information est mémorisée pour signifier que le doublon a été utilisé. De plus, lorsque les deux questions sont justes, le code opération est mémorisé dans la base de signature, de façon à permettre une
authentification ultérieure.
Les documents complémentaires reçus, si il y en a, peuvent être le document lui même, des pièces justificatives que le serveur va mémoriser, ou des ordres. Par exemple un commerçant pourra transmettre ici le prix de la commande signée, de façon à ce que le serveur d'authentification pilote l'opération bancaire entre le compte du signataire et le
compte de celui qui authentifie.
Dans le compte-rendu, l'identité du signataire est signifiée dans un format précis (si c'est spécifié dans la demande d'authentification). Cette identité est codée par un calcul de codage de document (connue faisant partie de l'état de la technique) pour obtenir le code identité. Ce codage va tenir compte de la réponse privée issue de la base d'authentification. Le codage doit être tel qu'il ne doit pas être possible de retrouver la réponse privée issue de la base d'authentification à partir de l'identité du signataire et du
code identité. Le compte-rendu est transmis à l'intéressé.
L'intéressé va donc recevoir le compte-rendu de la demande d'authentification. Celui-ci contient: -7- - La réponse publique à la question issue de la base
d'authentification qu'il a déterminée.
- La réponse à la question issue de la base de signature
délivrée par le signataire.
- L'identité du signataire et le code d'identité s'il
l'a demandé dans sa demande d'authentification.
L'intéressé peut alors authentifier le scellé grâce aux
informations qu'il a reçues avec le document, et le compte-
rendu d'authentification qu'il a reçu en retour de sa demande d'authentification. Cela consiste à comparer les réponses reçues dans le compte-rendu d'authentification et les réponses qu'il détient. Si les deux réponses sont justes, alors le scellé (la signature) est authentique. Si le code d'identité est juste, alors l'identité du signataire qu'il a reçue est authentique. La réponse reçue à une question posée dans la demande d'authentification est juste lorsqu'elle est identique
à la réponse que l'intéressé détient de cette même question.
Ce peut donc être, suivant la question, soit la réponse qui est présente dans le scellé qui lui a été délivré avec le document, soit la réponse publique issue de la base d'authentification de son propre sceau. Le code d'identité reçu dans le compte-rendu d'authentification est juste lorsque le calcul effectué sur l'identité du signataire, avec la réponse privée issue de la base d'authentification, délivre un code d'identité identique. Le calcul effectué pour trouver le code d'identité est identique à celui utilisé par le serveur
d'authentification pour établir le code d'identité.
La réponse privée peut aussi être utilisée comme clé
pour coder ou crypter le compte-rendu d'authentification.
Le procédé tel qu'il est décrit ci-dessus considère que dans la base de données du sceau électronique et dans la base de données du serveur d'authentification, l'état d'utilisation des doublons est identique. Ce cas est envisageable lorsque
les échanges sont synchronisés, ou effectués en temps réel.
Dans le cas o les échanges sont asynchrones, le porteur doit émettre un message vers le serveur d'authentification pour lui 8- signifier qu'il va procédé à la signature d'un document. Il va donc transmettre au serveur d'authentification une demande d'authentification. Si le compte-rendu d'authentification est valide, il peut alors marquer le doublon utilisé pour la signature comme utilisé, et émettre le scellé. Il est envisageable qu'un porteur ne soit pas connecté à réseau au moment o il désire apposé un scellé. Le serveur d'authentification du porteur doit avoir été au préalable informé que le sceau doit être capable d'apposer des scellés sans qu'il en soit informé. Il est aussi informé de combien de signatures non synchronisées peuvent être diffusées au maximum, à un moment donné, par ce sceau. Lors d'une demande d' authentification d'un scellé émis par un sceau de ce type, le sceau électronique et le serveur d'authentification risquent d'être désynchronisés. Dans ce cas, lorsque le serveur d'authentification va recevoir une demande d'authentification signée par un sceau autorisé à émettre B signature, il va alors essayer de retrouver la question issue de la base d'authentification, à partir d'un nombre N' représentant le nombre de questions non utilisées. Si la question qu'il trouve pour ce nombre, et pour le code opération, n'est pas juste, il va alors essayer, une à une, en décrémentant de un toutes les possibilités jusque N'-B, et ce jusqu'a ce qu'il trouve la question dans la base qui est juste. Ce porteur doit pouvoir, s'il le désire, synchroniser son sceau et le serveur d'authentification, soit en contactant son tiers de confiance, soit en faisant une demande d'authentification pour chacun des scellés qu'il a
précédemment émis.
Dans les modes de réalisation présentés ci-dessous, on utilise le procédé dans le but d'effectuer des opérations bancaires sur Internet en minimisant les risques encourus:
Le tiers de confiance est composé de plusieurs banques.
Chacune d'elles met à disposition sur Internet un serveur d'authentification. Plutôt que les banques, ce pourrait être le distributeur des cartes bancaires qui met en place les -9 - serveurs d'authentification. Les serveurs d'authentification, sont interconnectés entre eux par un réseau privé. Les sceaux, dans ce mode de réalisation, pourraient êtres réalisés avec une disquette tout à fait standard, lisible par un ordinateur personnel tel qu'en dispose les clients des banques. La disquette est protégée contre l'utilisation par un pirate d'une copie de celle-ci par cryptage. Selon les modes de réalisation, le sceau électronique peut se présenter sous la forme d'une carte à puce, d'une disquette, d'un disque dur, d'une puce, d'une bague, d'un petit boîtier, d'une montre ou
même d'une calculatrice.
Dans le cas d'un sceau électronique de type calculatrice, c'est à dire avec une interface autonome comme un clavier et un écran, c'est alors directement le porteur qui
pourra faire la liaison entre le sceau et son ordinateur.
Sinon le sceau doit pouvoir se connecter sur un ordinateur, ou
plutôt, d'une façon générale, sur un terminal relié au réseau.
Le sceau doit conserver, si possible, la particularité d'être détachable de l'ordinateur. Pour un commerçant qui vend des millions d'articles par jour, le sceau pourra être réalisé
avec un disque dur extractible.
Le sceau peut être intégré dans une carte à puce sécurisé. Celle-ci apporterait une sécurité, toute relative, contre la fabrication de faux. Il serait intéressant que le lecteur du sceau, ou le sceau lui-même, quelque soit sa forme, ne soit actif que sur une action de l'utilisateur qui désire signer ou authentifier. Il est par exemple imaginable que les ordinateurs de demain soit équipés de lecteur de cartes à puces sécurisés. Lorsqu'il désire signer une commande ou un document, l'utilisateur devra appuyer sur sa carte, et saisir
son code secret.
Les banques ont équipés les commerçants du net avec des sceaux dont le nombre de signatures est égal pour chacun au nombre des articles vendus sur deux ans. Vu le volume, les sceaux sont réalisés avec des disques durs extractibles. A chaque fois qu'un client va commander un article, le site Internet du commerçant va établir un bon de commande. Celui-ci
- 10 -
est réalisé dans un format ASCII et détient le numéro du bon
de commande, le prix et la description du ou des articles. Un
codeur est utilisé pour obtenir un code opération, dans lequel le niveau de prix est inclus. Le niveau de prix indique par exemple que la commande est inférieur à 5000 Francs. Avec un bon de commande simplifié, le code opération pourrait contenir le prix exact. Suivant les besoins, les constructeurs informatique établiront les formats des documents utiles, et le codage nécessaire. Avant d'envoyer le bon de commande au client, le site envoie automatiquement une demande
d'authentification du scellé qu'il va délivré, pour que celui-
ci reste synchronisé. Le client qui reçoit son bon de commande vérifie le contenu du bon de commande. Comme c'est un format ASCII, il est facile de visualiser son contenu. Si le bon de commande était dans un format plus évolué, il aurait à utiliser un outil pour vérifier que l'on visualise bien tout le contenu du document. Comme le code opération est bon, il insère sa disquette et la décrypte. Comme il n'est pas sûr de son interlocuteur, il fait une demande d'authentification pour connaître l'identité légale du commerçant. A la réception du
compte-rendu, et avec l'identité complète du commerçant (peut-
être son adresse si la loi du pays le permet), il désire commander. Si l'utilisateur connaît bien le site du commerçant, et qu'il a l'intuition que le réseau n'est pas piraté, il peut très bien commander directement. Il signe la commande en apposant son sceau sur le bon de commande et l'envoie en demande d'authentification avant de le transmettre au commerçant (pour synchroniser). Le site du commerçant va
effectuer une authentification de la signature de son client.
Comme c'est un commerçant, et qu'il authentifie un bon de commande, le commerçant lui a aussi transmis le bon de commande, ou tout au moins le prix, s'il n'est pas inclus dans le code opération, de façon à ce que le serveur
d'authentification puisse effectuer l'opération bancaire.
Après les contrôles habituels, Le commerçant reçoit un compte-
rendu. La vente est faite, le commerçant peut maintenant livrer en toute sécurité la commande de son client. Suivant
- 1i -
les besoins, les dates, les documents, les prix peuvent être
mémorisées lors de l'authentification.
Dans un autre mode de réalisation le sceau est utilisé pour signer un mail. L'outils de réception de mail enverra alors dès réception d'un mail signé avec un scellé une demande d'authentification. L'intéressé aura alors une information officielle de l'identité du signataire ainsi que la certitude
de l'authenticité de la signature.
Le procédé selon l'invention est particulièrement destiné à sécuriser les transactions bancaires nécessaires au commerce électronique, et à permettre d'une façon plus générale, la signature officielle de documents contractuels, tel que des ordres, dans le domaine de l'EDI. Il est aussi utilisable dans tous les systèmes o il est nécessaire d'avoir un sceau pour être identifié, car la reproduction du signal électronique émis par un scellé ne suffit pas à obtenir une nouvelle authentification, et donc potentiellement une nouvelle autorisation. Enfin, grâce au certificat émis par le tiers de confiance, et tant que le serveur d'authentification conserve la base de données des signatures utilisées, il apporte une solution quant aux problèmes posés par la
nécessité d'authentifier une signature électronique.
- 12 -

Claims (11)

REVENDICATIONS
1)Procédé pour apposer un scellé avec un sceau électronique sur un document électronique, pour faire authentifier par un serveur d'authentification, via un réseau de communication, à l'aide d'un protocole de communication, comprenant un message appelé demande d'authentification et une réponse à ce message appelé compte-rendu d'authentification, le scellé apposé sur un document et pour identifier le porteur du sceau dont le scellé est apposé sur un document principalement caractérisé par deux bases de données, l'une disponible sur le sceau et l'autre disponible sur le compte du serveur d'authentification de ce même sceau, dont le contenu
est initialisé avec les mêmes données.
2)Procédé selon la revendication 1 caractérisé en ce que la base de données est constituée par une première base de signature, dont le contenu sera utilisé pour apposer un sceau sur un document, et par une seconde base d'authentification, dont le contenu sera utilisé pour émettre une demande d'authentification d'un scellé auprès d'un serveur d'authentification, ces deux bases étant chacune constituée d'une série de questions et d'une réponse à chaque question, elle-même décomposée en une réponse publique, qui sera diffusée, et d'une réponse privée, qui ne sera jamais diffusée. 3)Procédé selon la revendication 1 ou la revendication 2 caractérisé en ce que le scellé peut être déposé sur des documents de formats diverses, dès lors qu'une méthode de codage du document permet d'obtenir un code opération significatif.
4)Procédé selon l'une quelconque des revendications
précédentes caractérisé en ce que l'action de déposer un scellé sur un document consiste à fournir avec le document le
- 13 -
code opération, le numéro du sceau du signataire, et un doublon issu de la base de signature déterminé par le code opération.
5)Procédé selon l'une quelconque des revendications
précédentes caractérisé en ce que le message de demande d'authentification comporte le code opération du document, le numéro du sceau du signataire, la question issue du doublon délivré par le signataire, le numéro du sceau de l'intéressé, la question issue de la base d'authentification de l'intéressé déterminée par, le code opération et la question du signataire.
6)Procédé selon l'une quelconque des revendications
précédentes caractérisé en ce que le message de compte-rendu d'authentification délivré par le serveur d'authentification comporte la réponse publique issue de la base d'authentification de l'intéressé à la question d'authentification si cette question est considérée juste et la réponse publique issue de la base de signature du signataire à la question issue du doublon délivré par le
signataire si cette question est considérée juste.
7)Procédé selon l'une quelconque des revendications
précédentes caractérisé en ce que le message de compte-rendu d'authentification peut comporter l'identité du signataire, et un code d'identité obtenu avec l'identité et la réponse privée
issue de la base d'authentification de l'intéressé.
8)Procédé selon l'une quelconque des revendications
précédentes caractérisé en ce que la réponse privée peut être utilisée comme clé pour coder ou crypter un message ou une
information dans le compte-rendu.
9)Procédé selon l'une quelconque des revendications
précédentes caractérisé en ce que l'intéressé vérifie les réponses délivrées dans le compte-rendu d'authentification
- 14 -
pour authentifier le compte-rendu d'authentification et le scellé, et pour connaître l'identité du porteur du sceau qui a apposé le scellé, telle qu'elle est connue par le serveur d'authentification.
)Procédé selon l'une quelconque des revendications
précédentes caractérisé en ce que le sceau électronique a pour propriété essentielle d'être le support d'une mémoire en
lecture écriture non volatile.
11)Procédé selon l'une quelconque des revendications
précédentes caractérisé en ce qu'un doublon, composé d'une question et d'une réponse, est utilisé pour apposer une signature ou pour constituer un message de demande d'authentification, et que par la suite il ne sera plus utilisé.
12)Procédé selon l'une quelconque des revendications
précédentes caractérisé en ce que le serveur d'authentification, à la réception d'un demande d'authentification, vérifie plusieurs questions dans la base de signature afin de trouver la question juste, pour un code
opération donné.
13)Procédé selon l'une quelconque des revendications
précédentes caractérisé en ce que le serveur d'authentification mémorise dans la base de signature, lors d'une demande d'authentification, le code opération et toutes les autres informations possibles et nécessaires comme le
document, la date, le prix.
FR0008314A 2000-06-28 2000-06-28 Procede pour apposer et authentifier un sceau electronique sur un document electronique Pending FR2811174A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR0008314A FR2811174A1 (fr) 2000-06-28 2000-06-28 Procede pour apposer et authentifier un sceau electronique sur un document electronique

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0008314A FR2811174A1 (fr) 2000-06-28 2000-06-28 Procede pour apposer et authentifier un sceau electronique sur un document electronique

Publications (1)

Publication Number Publication Date
FR2811174A1 true FR2811174A1 (fr) 2002-01-04

Family

ID=8851798

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0008314A Pending FR2811174A1 (fr) 2000-06-28 2000-06-28 Procede pour apposer et authentifier un sceau electronique sur un document electronique

Country Status (1)

Country Link
FR (1) FR2811174A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000155524A (ja) * 1998-11-19 2000-06-06 Mitsubishi Electric Corp 電子検印システム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000155524A (ja) * 1998-11-19 2000-06-06 Mitsubishi Electric Corp 電子検印システム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
PATENT ABSTRACTS OF JAPAN vol. 09, no. 1 13 October 2000 (2000-10-13) *

Similar Documents

Publication Publication Date Title
US10673632B2 (en) Method for managing a trusted identity
EP0995177B1 (fr) Systeme de communication electronique protege de maniere symetrique
JP5016749B2 (ja) 認証された文書の電子的送信、格納および検索システムおよび方法
CA2417406C (fr) Recu numerique de transaction
US20090113205A1 (en) Method and apparatus for the secure identification of the owner of a portable device
EP1412926B8 (fr) Procede de gestion d'achat de contenus numeriques diffuses et moyens de telechargement de tels contenus
EP1459479A2 (fr) Systeme cryptographique de signature de groupe
CN105610578A (zh) 区块链信息存证及隐私保护方法
EP1107203A2 (fr) Procédé de transmission d'information et serveur le mettant en oeuvre
FR2795262A1 (fr) Certificat du fabricant de module d'identite de protocole d'application sans fil
WO2011117486A1 (fr) Infrastructure non hierarchique de gestion de bi-cles de securite de personnes physiques
EP1456999B1 (fr) Procede de signature electronique
KR20080094000A (ko) 사용자 신뢰성 확립 방법, 컴퓨터 판독가능 매체, 사용자신뢰성 확립 장치 및 신뢰성 조사 방법
US20090037340A1 (en) Digital certification method and apparatus
FR2811174A1 (fr) Procede pour apposer et authentifier un sceau electronique sur un document electronique
EP1978479A1 (fr) Cryptogramme dynamique
EP2689552B1 (fr) Infrastructure non hiérarchique de gestion de bi-clés de sécurité de personnes physiques ou d'éléments (igcp/pki).
EP1480106A1 (fr) Système de transaction électronique
EP1258844A1 (fr) Procédé et système pour l'établissement de la preuve d'une transaction électronique
Choudhary Strategic issues in implementing electronic-ID services: prescriptions for managers
CA2285642A1 (fr) Procede de certification d'un cumul dans un lecteur
FR2849973A1 (fr) Procede permettant de faire des transactions securisees a l'aide d'un dispositif a memoire passive seulement
FR2814261A1 (fr) Billet electronique de valeur fiduciaire, protocole de paiement d'achats par commerce electronique et systeme serveur correspondant