FR3048530B1 - Systeme ouvert et securise de signature electronique et procede associe - Google Patents
Systeme ouvert et securise de signature electronique et procede associe Download PDFInfo
- Publication number
- FR3048530B1 FR3048530B1 FR1670070A FR1670070A FR3048530B1 FR 3048530 B1 FR3048530 B1 FR 3048530B1 FR 1670070 A FR1670070 A FR 1670070A FR 1670070 A FR1670070 A FR 1670070A FR 3048530 B1 FR3048530 B1 FR 3048530B1
- Authority
- FR
- France
- Prior art keywords
- signature
- user
- business application
- manager
- signed
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 27
- 230000008569 process Effects 0.000 claims abstract description 18
- 238000004364 calculation method Methods 0.000 claims abstract description 12
- 238000013475 authorization Methods 0.000 claims abstract description 7
- 230000003213 activating effect Effects 0.000 claims abstract description 6
- 238000012545 processing Methods 0.000 claims abstract description 5
- 238000013461 design Methods 0.000 claims description 28
- 238000011084 recovery Methods 0.000 claims description 9
- 238000012795 verification Methods 0.000 claims description 9
- 238000002360 preparation method Methods 0.000 claims description 5
- 238000006073 displacement reaction Methods 0.000 claims description 2
- 230000002093 peripheral effect Effects 0.000 claims 1
- 238000007726 management method Methods 0.000 description 6
- 108010042833 7,8-diaminopelargonic acid aminotransferase Proteins 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- TVZRAEYQIKYCPH-UHFFFAOYSA-N 3-(trimethylsilyl)propane-1-sulfonic acid Chemical compound C[Si](C)(C)CCCS(O)(=O)=O TVZRAEYQIKYCPH-UHFFFAOYSA-N 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 238000012550 audit Methods 0.000 description 1
- 238000012938 design process Methods 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic 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/3247—Cryptographic 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
-
- 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/602—Providing cryptographic facilities or services
-
- 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
- G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/126—Applying verification of the received information the source of the received data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic 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/3263—Cryptographic 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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic 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/3297—Cryptographic 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 time stamps, e.g. generation of time stamps
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- General Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
L'invention concerne un système ouvert et sécurisé de signature électronique comprenant une application métier, comportant une interface de programmation apte à effectuer une demande de signature d'un document auprès d'un gestionnaire de signature pour un utilisateur, caractérisé en ce que ladite application métier définie un contenu à signer, des critères d'identification et de sélection d'un utilisateur signataire, un type d'identité numérique à utiliser, qu'elle effectue une collecte des propriétés de signature et exige un format de signature ; en ce que ledit gestionnaire de signature est apte à coordonner les étapes de ladite demande de signature en vérifiant l'identité et l'habilitation de l'application métier, en vérifiant l'identité de l'utilisateur signataire, en récupérant ledit document à signer, en préparant la demande de signature avec les calculs d'empreintes des données à signer,via des serveurs de signature,, en envoyant une notification de la demande de signature via un serveur de notification à des services de signatures de l'utilisateur et en ce que l'utilisateur, au moyen desdites services de signatures, est apte à contrôler l'exécution du processus de signature en activant la clé privée correspondant à un certificat de l'utilisateur répondant aux critères de sélection envoyés audit gestionnaire de signature par l'application métier en vue du chiffrement de l'empreinte des données à signer. L'invention concerne en outre le procédé d'élaboration et de traitement d'une demande de signature mis en œuvre dans le système ci-dessus .
Description
SYSTEME OUVERT ET SECURISE DE SIGNATURE ELECTRONIQUE ETPROCEDE ASSOCIE
DOMAINE TECHNIQUE DE L’INVENTION
[0001] L’invention se rapporte au domaine de la signature électronique. Plusparticulièrement, l’invention concerne un système ouvert et sécurisé pour signerun document électronique. L’invention concerne en outre un procédé d’élaborationet de traitement d’une demande de signature.
ETAT DE LA TECHNIQUE ANTERIEURE
[0002] La signature électronique consiste principalement à permettre à unutilisateur humain de chiffrer l’empreinte d’un document à signer, avec une cléprivée correspondant à une clé publique associée à son identité, cette clé privéeétant généralement protégée par un dispositif cryptographique et un code secret,le résultat du chiffrement devant ensuite être incorporé ou associé au document àsigner de manière à constituer une preuve. Au cours de cette opération, il estnécessaire de s’assurer que l’association entre la clé publique et l’identité dusignataire soit certifiée par une autorité compatible avec les exigences de sécuritéet de confiance associée à la signature électronique, que cette certification soitvérifiée comme étant toujours valide, et que le signataire soit bien d’accord avec lecontenu à signer.
[0003] Par ailleurs, l’enchaînement des tâches de calcul, de gestion et devérifications nécessaires à la réalisation d’une signature électronique estexcessivement complexe. En effet, les algorithmes sur lesquels s’appuient lescalculs doivent eux-mêmes être compatibles avec les exigences de sécurité et deconfiance. De plus, les données à signer ne sont pas forcément accessiblesdirectement par le processus de signature mais peuvent être distantes, que cesmêmes données à signer doivent pouvoir être encadrées par des éléments decontexte comme la date et l’heure de la signature, la chaîne de certification dusignataire, son rôle, un lieu de signature, une politique de signature, etc. Parailleurs, la clé privée peut être sur un dispositif cryptographique local ou distant del’utilisateur, et l’environnement même de ces opérations est tantôt sur le poste detravail de l’utilisateur, mais peut être également distant ou s’exécuter en mode client-serveur dans un navigateur Web, ou encore sur un smartphone ou unetablette.
[0004]Document EP 1393144 B1 divulgue un procédé et un système basé sur leWeb permettant la signature juridiquement exécutoire de documents dans unenvironnement Web. Le système comprend un premier moyen d'accès pouraccéder à l'environnement Web depuis un système électronique, et comprendégalement une pluralité de modules. Un module de rendu du document pourprésenter à l'utilisateur une représentation Web du document, un moduled'information juridique pour présenter à l'utilisateur, dans l'environnement Web, del'information juridique relative à la signature électronique du document, et pourobtenir l'accord de l'utilisateur de cette information juridique. Un moduled'approbation des documents pour intégrer la signature de l'utilisateur audocument, avec l'accord de l'utilisateur de l'information juridique. Le systèmecomprend également un module de journalisation pour générer un journal desprocessus de la signature du document en associant ce journal de processus avecle document signé. Enfin, un module de distribution de document pour rendre ledocument signé disponible. Ce document concerne la traçabilité du processus. Il ya un besoin particulier de rationaliser le processus de signature électronique etaussi de masquer la complexité du processus aux utilisateurs.
EXPOSE DE L’INVENTION
[0005] L’invention a donc pour objet, d’une part, de rationaliser le processus designature électronique, pour le décomposer en tâches indépendantes dont lesinteractions entre elles seront sécurisées par des protocoles d’échangesspécifiquement conçus à cet effet, et, d’autre part, de masquer cette complexitéaux utilisateurs de la signature électronique et aux applications métiers quisouhaitent la mettre en œuvre.
[0006] Pour ce faire, il est proposé un système ouvert et sécurisé de signatureélectronique comprenant une application métier, développée et exécutée dans desenvironnements variés, ladite application métier comportant une interface deprogrammation apte à effectuer une demande de signature d’un document, auprèsd’un gestionnaire de signature, pour un utilisateur. Le système est caractérisé ence que ladite application métier définie un contenu à signer, des critères d’identification et de sélection d’un utilisateur signataire, un type d’identiténumérique à utiliser, et effectue une collecte des propriétés de signature et exigeun format de signature. Ledit gestionnaire de signature est apte à coordonner lesétapes de ladite demande de signature en vérifiant l’identité et l’habilitation del’application métier, en vérifiant l’identité de l’utilisateur signataire, en récupérantledit document à signer, en préparant la demande de signature avec les calculsd’empreintes des données à signer, via des serveurs de signatures, en envoyantune notification de la demande de signature via un serveur de notification à desservices de signatures de l’utilisateur. L’utilisateur, au moyen desdits services designatures, est apte à contrôler l’exécution du processus de signature en activantune clé privée correspondant à un certificat de l’utilisateur répondant aux critèresde sélection envoyés audit gestionnaire de signature par l’application métier envue du chiffrement de l’empreinte des données à signer.
[0007] De préférence, le gestionnaire de signature est apte à vérifier l’identité del’utilisateur signataire au moyen d’un annuaire d’utilisateurs géré par leditgestionnaire de signature. Les calculs d’empreintes des données sont effectuéssoit par un serveur de signature, soit par un serveur de signature inverse. Legestionnaire de signature est, en outre, apte à récupérer les signatures effectuéeset à mettre lesdites signatures à disposition de l’application métier aprèsnotification par le serveur de notification.
[0008] De préférence, le système comprend en outre des fichiers journauxhorodatés et archivés, dans lesquels sont écrites les étapes de la transaction designature, gérés par le gestionnaire de signature, de sorte à constituer un dossierde preuve pour chaque transaction de signature.
[0009] De préférence, le service de signature est un composant logiciel léger ettéléchargeable sur un périphérique de l’utilisateur et en ce que ledit périphériqueest un PC et/ou un Mac et/ou une tablette et/ou un smartphone dudit utilisateur.
[0010] De préférence, l’application métier est apte à effectuer une demande designature auprès d’un gestionnaire de signature personnel de l’utilisateur, leditgestionnaire de signature personnel s’exécutant sur le périphérique duditutilisateur de sorte à permettre audit utilisateur de signer un document en modelocal lorsqu’il n’y a pas de connexion Internet disponible ou que le gestionnaire designature n’est pas utilisable dans ce contexte.
[0011] De préférence, l’utilisateur est apte à signer le document soit à l’aide d’undispositif de création de signature local pouvant être un composant matériel, telqu’un dispositif cryptographique, ou logiciel, tel qu’un certificat logiciel accessiblesur le périphérique de l’utilisateur soit à l’aide d’un dispositif de création designature à distance étant apte à incorporer un certificat généré à la volée, lorsd’un déplacement dudit utilisateur.
[0012]Avantageusement, lesdits certificats générés à la volée ont un niveau desécurité conforme aux exigences formulées dans la demande de signatureenvoyée par l’application métier et qu’ils sont apte à effectuer le chiffrement del’empreinte des données à signer par une clé privée associée.
[0013] En outre, les données à signer sont, soit dans l’environnement local del’application métier sur le périphérique de l’utilisateur, soit dans l’environnementréseau de ladite application métier, auquel accède ladite application métier.
[0014] De préférence, le dispositif de création de signature local est sous la formed’une puce cryptographique ou d’un certificat logiciel accessible localement parl’utilisateur depuis son périphérique, ledit périphérique étant un poste de travail ouun smartphone ou une tablette.
[0015] De préférence, le dispositif de création de signature à distance est situédans l’environnement réseau du gestionnaire de signature et contient un certificatgénéré à la volée de sorte que le gestionnaire de signature est apte à donnerl’instruction à une infrastructure de gestion de clés de générer ledit certificat à lavolée et que la clé privée associée audit certificat à la volée étant générée etconservée de manière sécurisée par les serveurs de signatures.
[0016] De préférence, le serveur de notification est associé à un environnementd’exécution du service de signature de l’utilisateur de sorte que le gestionnaire designature au moyen dudit serveur de notification notifie la demande de signaturedu document auxdites services de signatures de l’utilisateur.
[0017] De préférence, le service de signature est apte à s’enregistrer auprès duserveur de notification associé à son environnement d’exécution et communiqueau gestionnaire de signature qu’il connaît les informations qui permettront auditgestionnaire de signature de le notifier.
[0018] L’invention concerne encore un procédé d’élaboration et de traitementd’une demande de signature par une application métier d’un document auprèsd’un gestionnaire de signature pour un utilisateur, inscrit et identifié auprès duditgestionnaire de signature, ledit procédé étant mis en œuvre dans le systèmedécrit ci-dessus et comprend les étapes suivantes : - connexion d’un utilisateur à l’application métier pour signer undocument ; - récupération par l’application métier du document à signer ; - interrogation du gestionnaire de signature par l’application métierafin d’identifier l’utilisateur qui doit signer le document ; - envoi d’une demande de signature audit gestionnaire de signaturepar l’application métier, ladite demande comprend un contenu àsigner, des critères d’identification et de sélection de l’utilisateursignataire, un type d’identité numérique à utiliser, elle effectue unecollecte des propriétés de signature et exige un format de signature ; - coordination des étapes de la transaction de la signature par legestionnaire de signature comprenant les étapes suivantes : - vérification de l’identité et de l’habilitation de l’applicationmétier ; - vérification de l’identité de l’utilisateur signataire ; - récupération dudit document à signer auprès del’application métier; - préparation de la demande de signature avec le calcul del’empreinte des données à signer,via des serveurs designatures ; - envoi d’une notification de la demande de signature à unservice de signature de l’utilisateur via un serveur denotification ; - contrôle de l’exécution du processus de signature par leservice de signature, en activant une clé privéecorrespondant à un certificat de l’utilisateur répondant aux critères de sélection envoyés audit gestionnaire designature par l’application métier ; - horodatage et sauvegarde des évènements de latransaction dans des journaux ; - envoi à l’application métier du résultat des opérationsaprès notification, ou des erreurs éventuellementrencontrées ; - récupération par l’application métier du résultat des opérations ; - mise à disposition de l’utilisateur par l’application métier du résultat.
BREVE DESCRIPTION DES FIGURES
[0019] D’autres caractéristiques, détails et avantages de l’invention ressortiront àla lecture de la description qui suit, en référence aux figures annexées, quiillustrent : la figure 1 illustre l’architecture générale du système selon la présenteinvention; la figure 2 illustre les étapes du procédé mis en œuvre dans le systèmeselon l’invention ; [0020] Pour plus de clarté, les éléments identiques ou similaires sont repérés pardes signes de référence identiques sur l’ensemble des figures.
DESCRIPTION DETAILLEE
[0021] La figure 1 représente l’architecture générale du système selon la présenteinvention. Cette architecture représente d’une part, l’environnement 1 d’unutilisateur 30 du système et d’autre part l’environnement internet 2 d’ungestionnaire de signature 40. Un utilisateur 30 est une personne physique quisouhaite ou doit signer un ou plusieurs documents.
[0022] La distinction entre une signature effectuée à l’initiative même del’utilisateur ou bien sollicitée par un tiers (autre utilisateur) est essentielle. En effet,l’expérience utilisateur est très différente car, dans le premier cas, celle-ci impliquenécessairement une préparation liée au choix du document, à sa rédaction, à lasélection de l’identité numérique et à sa mise en place, à l’éventuelle politique designature à appliquer, etc., alors que dans le deuxième cas, elle exige une facilité d’action particulière quant à l’accès au document et à l’identité numérique dusignataire pour se focaliser sur la valeur probatoire de la transaction, encontraignant éventuellement l’utilisateur, avant de pouvoir signer, à lire l’intégralitédu document, à s’authentifier pour prouver son identité numérique, etc.
[0023] L’architecture du système telle que représentée sur la figure 1 comprendune application métier 10, ladite application métier peut être développée etexécutée dans des environnements variés tels que des serveurs Web, desnavigateurs Internet, dans un environnement natif PC ou Mac, ou encore depuisun téléphone portable ou une tablette. L’application métier est à l’origine duprocessus de signature, ainsi, toute demande de signature, qu’elle soit effectuée àl’initiative de l’utilisateur signataire 30 lui-même, ou qu’elle soit effectuée par untiers en vue de faire signer un document, doit nécessairement passer par cetteapplication métier 10. Ladite application 10 est conçue de sorte qu’elle est apte àeffectuer une demande de signature d’un document 20 auprès d’un gestionnairede signature 40 pour un utilisateur 30. Pour ce faire, l’application métier 10contient une interface de programmation 42, développée avec des librairiesspécifiques, lui permettant de communiquer avec le gestionnaire de signature 40.L’application métier 10 selon l’invention a pour objectif de définir le cahier descharges de la ou des signatures à effectuer, soit définir un contenu à signer, descritères d’identification et de sélection d’un utilisateur signataire 30, un typed’identité numérique à utiliser, effectuer une collecte des propriétés de signature,exiger un format de signature.
[0024] L’application métier 10 soumet cette demande de signature au composantcentral du système, à savoir le gestionnaire de signature 40. Le rôle dugestionnaire de signature 40 est de traiter une demande de signature del’application métier 10 et de coordonner son exécution en suivant les étapessuivantes : vérification de l’identité et de l’habilitation de l’application métier 10,prise en compte de la demande, identification de l’utilisateur signataire 30,récupération du document 20 à signer indiqué par l’application métier, préparationde la demande de signature avec le calcul d’empreinte des données à signer, viaun serveur de signature 50 ou 51, notification de la demande de signature, via unserveur de notification 70 à tous les services de signatures 60 de l’utilisateur 30, etenfin mise à disposition du résultat des opérations auprès de l’application métier 10. Ledit gestionnaire de signature 40 vérifie l’identité de l’utilisateur signataire 30au moyen d’un annuaire d’utilisateurs 41. Ledit annuaire d’utilisateurs 41 estassocié et géré par un ensemble de gestionnaires de signatures 40.
[0025] Le ou les documents 20 à signer peuvent être situés dans l’environnementlocal de l’application métier 10 appelés « DTBS local >> 21 (les données locales àsigner) en général sur un périphérique de l’utilisateur, et accessibles localementpar celui-ci ; dans ce cas il est du ressort de l’application métier 10 de récupérerces données pour composer la demande de signature à envoyer au gestionnairede signature 40. Les documents à signer peuvent aussi être situés dansl’environnement réseau de l’application métier 10 appelés « DTBS remote >>22 (lesdonnées à distance à signer), typiquement dans une GED (outil de gestionélectronique de documents) à laquelle accède l’application métier 10 qui pourraainsi téléverser ces données au gestionnaire de signature 40.
[0026]Après la récupération du ou des document(s) 20 à signer par legestionnaire de signature 40, celui-ci prépare la ou les demande(s) de signature(s)avec les calculs d’empreintes des données à signer, à savoir le contenu du ou desdocument(s) ainsi que les propriétés. Ces calculs d’empreintes des données sonteffectués soit par un serveur de signature 50, soit par un serveur de signatureinverse 51.
[0027] Le système comprend un dispositif de création de signature 61, il s’agit d’uncomposant matériel ou logiciel qui permet d’effectuer le chiffrement de l’empreintedes données à signer par la clé privée associée au certificat de l’utilisateursignataire 30. Ledit dispositif de création de signature 61 peut être situé dansl’environnement local de l’utilisateur 30 et être accessible uniquement par celui-ci,typiquement sous la forme d’un dispositif cryptographique (carte à puce, tokenUSB cryptographique) ou d’un certificat logiciel accessibles localement depuis leposte de travail de l’utilisateur ou bien depuis son terminal nomade (smartphone,tablette). Le dispositif de création de signature 61 peut aussi être situé dansl’environnement réseau du gestionnaire de signature 40, référencé 62 sur lafigure, typiquement sous la forme d’un certificat généré à la volée par uneinfrastructure de gestion de clés. En effet, le gestionnaire de signature 40 peutdonner l’instruction à ladite infrastructure de gestion de clés de générer cecertificat à la volée. En outre, la clé privée associée audit certificat à la volée de l’utilisateur 30 étant générée et conservée de manière sécurisée par les serveursde signatures. L’idée est donc, à chaque signature, de générer un « certificat à lavolée >> ou « à usage unique >> valable pour une seule utilisation.
[0028] Le serveur de signature 50 est un serveur de signature centralisé auquel legestionnaire de signature 40 adresse une demande de signature. Un exempletypique du serveur de signature 50 est le logiciel LP7SignBox développé par lasociété Lex Persona (demandeur), mais il pourrait être envisagé d’accéder àd’autres serveurs de signature respectant par exemple le protocole DSS d’OASIS(Service de signature digital).
[0029] Le serveur de signature inverse 51 est un serveur de signature décentraliséappelé par le gestionnaire de signature 40 pour composer la signature selon unformat souhaité, par exemple, pour les signatures, selon les formats : CAdES,PAdES, XAdES, etc. Ledit serveur de signature inverse 51 est en outre apte àcalculer l’empreinte de hachage des données à signer dans le cas d’une demandede signature décentralisée. Cette empreinte sera envoyée par le gestionnaire designature 40 au service de signature 60 de l’utilisateur 30. Le service de signature60 utilise alors un dispositif de création de signature 61 pour chiffrer l’empreinteavec la clé privée et retourne le résultat de la signature générée au gestionnairede signature 40 qui la transmet à son tour au serveur de signature inverse 51 quifinalise alors la composition de la signature. Un exemple typique d’un serveur designature inverse qui offre la fonctionnalité ci-dessus est le logiciel LP7SignBoxdéveloppée par Lex Persona (Demandeur). Ce cas est particulièrement adapté àla signature décentralisée avec un dispositif de création de signature local 61 sousla forme d’un dispositif cryptographique réalisée depuis un terminal mobile del’utilisateur (smartphone ou tablette).
[0030] Par ailleurs, le gestionnaire de signature 40 notifie les services designatures 60 de l’utilisateur signataire 30 au moyen d’un serveur de notification70 afin de notifier ledit utilisateur de signer le ou les documents 20. Pour cela, legestionnaire de signature 40 envoie des notifications sur les serveurs denotification (push) 70 associés aux services de signatures 60 de l’utilisateur 30. Ilest donc nécessaire qu’un service de signature 60 puisse s’enregistrer, dès sonlancement, auprès du serveur de notification (push) 70 associé à sonenvironnement d’exécution par exemple : GCM pour Android, APN pour Apple, WNS pour Windows, etc. Le service de signature 60, associé au périphérique del’utilisateur, communique ensuite, aux gestionnaires de signatures 40 qu’il connaît,les informations qui leurs permettront de le notifier. Un service de signature 60dispose donc d’un fichier de configuration contenant la liste des gestionnaires designatures 40 auprès desquels il pourra se déclarer.
[0031] Un service de signature 60 est une application personnelle universelle, quipermet à l’utilisateur 30 de contrôler l’exécution du processus de signature, àsavoir l’activation de la clé privée correspondant à l’un des certificats del’utilisateur 30 répondant aux critères de sélection envoyés au gestionnaire designature 40 par l’application métier 10, en vue du chiffrement de l’empreinte desdonnées à signer. Du fait de la séparation entre l’application métier 10, à laquellel’utilisateur signataire 30 a généralement accès, et le service de signature 60, onpourra qualifier ledit service de signature 60 du terme d’application compagnon.Le service de signature 60 est un composant logiciel qui est le plus léger possibleafin qu’il puisse être téléchargé rapidement et prendre le moins de place possiblesur le périphérique de l’utilisateur 30. L’interface utilisateur du service de signature60 est très simple et intuitive avec une identité graphique la plus généralepossible. Le service de signature 60 est capable de signer en mode local. En effetdans un environnement Mobile, une connexion Internet peut être absente pendantun instant plus ou moins long, dans ce cas, le service de signature 60 est capablede finaliser la signature sans connexion Internet, ou bien automatiquement dèsque la connexion Internet sera de nouveau effective.
[0032] Un utilisateur 30 peut posséder plusieurs services de signatures 60, ainsi ilest par exemple possible pour l’utilisateur 30 de signer avec un dispositif decréation de signature local 61, depuis son poste de travail Windows ou Maclorsqu’il est à son bureau, à l’aide d’un composant matériel (carte à puce) oulogiciel (certificat),ou bien de signer depuis son Smartphone lorsqu’il est endéplacement, avec un dispositif de création de signature à distance 62 sous laforme d’un certificat généré à la volée. A la seule condition que le niveau desécurité du certificat à la volée soit conforme aux exigences formulées dans lademande de signature envoyée par l’application métier 10 au gestionnaire designature 40.
[0033] Le gestionnaire de signature 40 est capable de récupérer la ou dessignatures une fois celle(s)-ci effectuée(s) et, dans le cas de signaturesenveloppantes ou enveloppées, il procède à la mise en forme de la ou dessignatures effectuées. II est par ailleurs apte à mettre à disposition de l’applicationmétier 10 le résultat des opérations effectuées ou bien des erreurs éventuellementrencontrées. En effet, toutes les étapes des opérations de signatures gérées parle gestionnaire de signature 40 sont écrites dans des journaux. Lesdits journauxsont horodatés et archivés afin de constituer un fichier de preuve complet etsécurisé pour chaque transaction de signature.
[0034] Dans certain cas il peut être nécessaire pour un utilisateur de signer un ouplusieurs documents alors qu’aucune connexion Internet n’est disponible ou que legestionnaire de signature n’est pas utilisable, on parlera dans ce cas de signatureen mode local. De tels cas peuvent se présenter lorsqu’il est nécessaire de signerlors d’un déplacement ou bien dans le cas où il n’y a pas de connexion Internet oul’absence du réseau. Dans ce cas, selon la présente invention, l’application métier10 pourra soumettre la demande de signature auprès d’un gestionnaire designature personnel, non représenté sur la figure. Ledit gestionnaire de signaturepersonnel est personnel en ce qu’il est dans l’environnement local de l’utilisateuret en ce qu’il s’exécute sur son poste de travail personnel, quelle que soit latypologie dudit poste de travail, tablette, smartphone... Ledit gestionnaire designature personnel est apte à effectuer et à coordonner toutes les étapes duprocessus de signature à l’instar du gestionnaire de signature. II est à noter que legestionnaire de signature personnel peut également être sollicité par l’applicationmétier même si l’utilisateur dispose d’une connexion Internet afin de le faire signerde manière directe sans passer par un gestionnaire de signature.
[0035] L’annuaire des utilisateurs 41 est associé et géré par un ensemble degestionnaires de signature 40. Les utilisateurs peuvent êtres de trois catégories.L’utilisateur « Anonyme >> : Cet utilisateur est unique par gestionnaire de signature40, il est non définie et non authentifié. L’utilisateur « Virtuel >> : Cet utilisateur est partiellement défini et non authentifié.L’utilisateur « Qualifié >> : Cet utilisateur est complètement défini et authentifié parle gestionnaire de signature 40.
[0036] Dans le cas d’une application métier qui souhaite faire signerimmédiatement l’utilisateur qui est en train de l’utiliser, il n’est pas nécessaired’authentifier d’une quelconque manière ledit utilisateur, puisque celui-ci est déjàauthentifié par l’application métier. Ainsi l’application métier va signifier augestionnaire de signature qu’elle connaît déjà l’utilisateur, qui est anonyme pour legestionnaire de signature, mais pas pour l’application métier. Dans ce cas,l’application métier pourra se charger de lancer le service de signature del’utilisateur et d’envoyer la demander de signature au gestionnaire de signaturepersonnel qui pourra être packagé avec le service de signature. Eventuellement,si l’utilisateur dispose déjà d’un compte sur un gestionnaire de signature de sonchoix, il pourra se connecter pour éventuellement récupérer différentesinformations et créditer son compte de la signature qui sera effectuée.
[0037] Dans le cas d’une application métier qui souhaite faire signerimmédiatement l’utilisateur, sans qu’il soit nécessaire de bénéficier d’un utilisateurdéjà référencé par le gestionnaire de signature utilisé (« signature rapide >> ), onfait confiance à priori à l’utilisateur qui répond à certains critères, alors l’applicationmétier va signifier au gestionnaire de signature qu’elle se contentera d’un‘utilisateur Virtuel’ qui répondra à certains critères (email, numéro de téléphoneportable, etc.). Eventuellement, si l’utilisateur dispose déjà d’un compte sur legestionnaire de signature spécifié par l’application métier, il pourra se connecterpour éventuellement récupérer différentes informations et créditer son compte dela signature qui sera effectuée.
[0038] Dans le cas d’une application métier qui souhaite faire signerimmédiatement un utilisateur qu’elle connaît comme étant défini et authentifié parle gestionnaire de signature, alors elle pourra spécifier un ‘utilisateur Qualifié’.L’utilisateur devra alors s’authentifier sur le gestionnaire de signature sollicité parladite application métier pour signer le ou les documents.
[0039]A chaque utilisateur Qualifié correspond les données suivantes : Identifiant,Empreinte SHA256 du mot de passe de l’utilisateur, Nom et prénom et / ou alias,Date de naissance, Numéro de téléphone sur lequel il est possible d’adresser desmessages courts, Adresse Mail, pushTokenIDs correspondants aux dispositifs surlequel il est possible de notifier l’utilisateur lorsqu’il fait l’objet d’une demande designature, certificats de l’utilisateur et référence du dispositif de création de signature associé. Certaines de ces données sont facultatives et peuvent ne pasfigurer dans l’annuaire. Cet annuaire d’utilisateurs 41 va permettre à ungestionnaire de signature 40 d’identifier le signataire désigné par une demande designature qui lui a été adressée par une application métier 10, de sélectionner lecertificat approprié correspondant à la demande de signature, d’accéder auxpushTokenIDsde l’utilisateur permettant de le notifier, de notifier cet utilisateur qu’ilfait l’objet d’une demande de signaturesur les différents services de signaturecapables de traiter la demande de signature.
[0040] Dans le système de l’invention, trois autres modules sont présents maisn’apparaissent pas sur la figure 1 pour des raisons de lisibilité. Ainsi, le systèmecomprend un annuaire de gestionnaires de signatures. En effet, à partir dumoment où il est possible d’avoir différents gestionnaires de signature capableschacun de traiter des demandes de signatures en provenance de différentesapplications métiers, il est possible de donner la possibilité à une applicationmétier d’envoyer une demande de signature non pas à un gestionnaire designature déterminé, mais d’interroger un annuaire de gestionnaires de signatureafin d’être en mesure d’identifier le gestionnaire de signature le plus appropriépour traiter la demande. Aussi, si par exemple une application métier permet à unutilisateur de déclarer l’impôt sur la société, il pourrait être pratique à l’applicationmétier d’interroger un annuaire de gestionnaires de signatures afin de sélectionnerle gestionnaire de signature « national » qui permettra à l’entreprise de déclarerson impôt dans le pays de l’entreprise.
[0041] Un autre module du système de l’invention est le serveur IGC. En effet,dans l’architecture de l’invention, le serveur IGC désigne un serveurd’infrastructure de Gestion de Clés publiques. Son rôle est de délivrer descertificats à la volée aux utilisateurs et dont les clés privées associées sontstockées de manière sécurisée par un serveur de signature qui réalisera lesdemandes de signature qui lui seront affectées.
[0042] Enfin un dernier module concerne une autorité d’horodatage (TSA : TimeStampAuthority) délivrant des jetons d’horodatage. En effet, dans le système del’invention, certains modules nécessitent la possibilité de faire appel à unhorodatage, telle que l’écriture de toutes les étapes de la transaction de signature dans des journaux horodatés ou encore l’horodatage des signatures électroniquesgénérées.
[0043] La figure 2 représente les différents étapes du procédé d’élaboration et detraitement d’une demande de signature, par une application métier 10, d’undocument 20 auprès d’un gestionnaire de signature 40 pour un utilisateur 30,inscrit et identifié auprès dudit gestionnaire de signature 40, mis en œuvre dans lesystème de l’invention et comprenant les étapes ci-dessous. Chaque étapecorrespond à un ou plusieurs numéros représentés par des flèches. - Connexion d’un utilisateur 30 à l’application métier 10 pour signer un document20 de son environnement local 21. (flèche n°1). - Récupération par l’application métier du document à signer, (flèche n°2 et 3). - Interrogation du gestionnaire de signature 40 par l’application métier 10 afind’identifier l’utilisateur 30 qui doit signer le document 20. (flèche n°4). - Envoi d’une demande de signature audit gestionnaire de signature 40 parl’application métier 10, ladite demande comprend un contenu à signer, descritères d’identification et de sélection de l’utilisateur signataire, un typed’identité numérique à utiliser, des propriétés de signature et un format designature, (flèche n°8). - Coordination des étapes de la transaction de la signature par le gestionnaire designature 40 comprenant les étapes suivantes : - Vérification de l’identité et de l’habilitation de l’application métier 10 et de l’utilisateur signataire 30 (flèches n°5, 6); - Récupération du document 20 à signer auprès de l’application métier 10 ( flèche n°7). - Préparation de la demande de signature avec le calcul de l’empreinte des données à signer, via des serveurs de signatures 50 ou 51. (flèches n°9, 10ou 11, 12). - Envoi d’une notification de la demande de signature à un service de signature 60 de l’utilisateur 30 au moyen du serveur de notification 70. (flèches n° 13 et16). - Contrôle de l’exécution du processus de signature par le service de signature 60 (flèches n° 14 et 15) en activant une clé privée correspondant à un certificat de l’utilisateur 30 répondant aux critères de sélection envoyés auditgestionnaire de signature 40 par l’application métier 10. - Horodatage et sauvegarde des évènements de la transaction dans des journaux ; - Envoi à l’application métier 10 du résultat des opérations après notification, ou bien des erreurs éventuellement rencontrées, (flèche n° 17). - Récupération par l’application métier 10 du résultat des opérations ; - Mise à disposition de l’utilisateur 30 par l’application métier 10 du résultat (flèche n°18).
[0044] De nombreuses combinaisons peuvent être envisagées sans sortir ducadre de l’invention ; par exemple, le document à signer peut être accessible àl’utilisateur localement, sur son poste de travail, ou bien à distance, dans unenvironnement réseau. De même, le dispositif de création de signature peut êtreaccessible localement, sous la forme d’une carte à puce par exemple, ou bien àdistance, dans l’environnement réseau du système, sous la forme d’un serveur designature avec génération de certificat à la volée. Aussi, le gestionnaire designature peut être accessible localement ou via le réseau. L’homme de métierchoisira l’une ou l’autre des différentes possibilités en fonction des contrainteséconomiques, ergonomiques, dimensionnelles ou autres qu’il devra respecter.
Claims (3)
- REVENDICATIONS1. Système ouvert et sécurisé de signature électronique comprenant uneapplication métier (10), développée et exécutée dans des environnementsvariés, ladite application métier (10) comportant une interface deprogrammation (42) configurée à effectuer une demande de signature d’undocument (20) auprès d’un gestionnaire de signature (40) pour un utilisateur (30), caractérisé en ce que ladite application métier (10) est apte à définir uncontenu à signer, à identifier des critères et à sélectionner un utilisateursignataire (30), à définir l’utilisation d’un type d’identité numérique, qu’elle esten outre apte à effectuer une collecte des propriétés de signature et à exiger unformat de signature ; en ce que ledit gestionnaire de signature (40) est apte àcoordonner ladite demande de signature en effectuant les étapes suivantes : -vérification de l’identité et l’habilitation de l’application métier (10), - vérificationde l’identité de l’utilisateur signataire (30), - récupération du document (20) àsigner, - préparation de la demande de signature avec les calculs d’empreintesdes données à signer, via des serveurs de signature (50, 51), - envoi d’unenotification de la demande de signature via un serveur de notification (70) à desservices de signatures (60) de l’utilisateur (30) ; et en ce que l’utilisateur (30),au moyen desdits services de signatures (60), est apte à contrôler l’exécutiondu processus de signature en activant la clé privée correspondant à un certificat(61) de l’utilisateur (30) répondant aux critères de sélection envoyés auditgestionnaire de signature (40) par l’application métier (10) en vue duchiffrement de l’empreinte des données à signer.
- 2. Système selon la revendication 1 caractérisé en ce que le gestionnaire designature (40) est apte à identifier l’identité de l’utilisateur signataire (30) aumoyen d’un annuaire d’utilisateurs (41) géré par ledit gestionnaire de signature(40), en ce que les calculs d’empreintes des données sont effectués soit par unserveur de signature (50), soit par un serveur de signature inverse (51) et en ceque le gestionnaire de signature (40) est en outre apte à récupérer lessignatures effectuées et à envoyer lesdites signatures à l’application métier(10), le serveur de notification (70) étant configuré pour notifier préalablementledit application métier (10) de l’arrivé desdits signatures. 3. Système selon la revendication 1 caractérisé en ce qu’il comprend en outre desfichiers journaux horodatés et archivés, dans lesquels sont écrites les étapes dela transaction de signature, et en ce que le gestionnaire de signature (40) estconfiguré à gérer lesdits fichiers journaux de sorte à constituer un dossier depreuve pour chaque transaction de signature. 4. Système selon la revendication 1 dans lequel le service de signature (60) est uncomposant logiciel léger et téléchargeable sur un périphérique de l’utilisateur(30) et en ce que ledit périphérique est un PC et/ou un Mac et/ou une tabletteet/ou un smartphone dudit utilisateur. 5. Système selon la revendication 1 caractérisé en ce qu’il comprend en outre ungestionnaire de signature personnel (41) appartenant de l’utilisateur (30), en ceque l’application métier (10) est apte à effectuer une demande de signatureauprès dudit gestionnaire de signature personnel (41), et que ledit gestionnairede signature personnel (41) s’exécute sur un périphérique dudit utilisateur (30)de sorte à permettre audit utilisateur de signer un document en mode locallorsqu’il n’y a pas de connexion internet disponible ou que le gestionnaire designature (40) n’est pas utilisable dans ce contexte. 6. Système selon l’une quelconque des revendications précédentes caractérisé ence qu’il comprend en outre un dispositif de création de signature local (61), sousforme d’un composant matériel ou logiciel, et/ou un dispositif de création designature à distance (62),l’utilisateur (30) est apte à signer le document (20)soit à l’aide dudit dispositif de création de signature local (61) en utilisant lecomposant matériel, tel qu’un dispositif cryptographique, ou le composantlogiciel, tel qu’un certificat logiciel accessible sur le périphérique de l’utilisateur(30), soit à l’aide du dispositif de création de signature à distance (62), leditdispositif de création de signature à distance (62) étant apte à incorporer uncertificat généré à la volée, lors d’un déplacement dudit utilisateur (30). 7. Système selon la revendication 6 caractérisé en ce que lesdits certificatsgénérés à la volée sont généré de sorte qu’ils ont un niveau de sécuritéconforme aux exigences formulées dans la demande de signature envoyée parl’application métier (10). 8. Système selon l’une des revendications précédentes dans lequel l’applicationmétier (10) accède aux données à signer, lesdites données à signer sont situés soit dans l’environnement local de ladite l’application métier (10), soit dansl’environnement réseau de ladite application métier (10).
- 9. Système selon la revendication 6 dont ledit dispositif de création de signaturelocal (61) est sous la forme d’une puce cryptographique ou d’un certificatlogiciel, l’utilisateur (30) accède localement audit dispositif de création designature local (61) depuis son périphérique, ledit périphérique étant un postede travail, ou un smartphone ou une tablette. 10. Système selon la revendication 6 caractérisé en ce que le dispositif de créationde signature à distance (62) est situé dans l’environnement réseau dugestionnaire de signature (40) et contient un certificat généré à la volée, et quele système comprend une infrastructure de gestion de clés apte à générer leditcertificat à la volée, et en ce que la clé privée associée audit certificat à la voléeétant générée et conservée de manière sécurisée par les serveurs designatures (50, 51). 11. Système selon l’une quelconque des revendications précédente dans lequel legestionnaire de signature (40) au moyen du serveur de notification (70) est apteà notifier la demande de signature du document (20) aux services designatures (60) de l’utilisateur (30), le serveurs de notifications (70) est associéà un environnement d’exécution desdits services de signatures (60). 12. Système selon la revendication précédente dans lequel le service de signature(60) est configuré à s’enregistrer auprès du serveur de notification (70) associéà son environnement d’exécution et à communiquer avec le gestionnaire designature (40). 13. Procédé d’élaboration et de traitement d’une demande de signature, par uneapplication métier (10), d’un document (20) auprès d’un gestionnaire designature (40) pour un utilisateur (30), inscrit et identifié auprès duditgestionnaire de signature (40), mis en œuvre dans le système selon l’une desrevendication 1 à 12 comprenant les étapes suivantes : - connexion de l’utilisateur (30) à l’application métier (10) pour signer ledocument (20) ; - récupération par l’application métier (10) du document (20) à signer ; - interrogation du gestionnaire de signature (40) par l’application métier(10) afin d’identifier l’utilisateur (30) qui doit signer le document (20) ; - envoi d’une demande de signature audit gestionnaire de signature (40)par l’application métier (10), ladite demande comprend un contenu àsigner, des critères d’identification et de sélection de l’utilisateursignataire, un type d’identité numérique à utiliser, elle effectue unecollecte des propriétés de signature et exige un format de signature ; - coordination des étapes de la transaction de la signature par legestionnaire de signature (40) comprenant les étapes suivantes : - vérification de l’identité et de l’habilitation de l’application métier(10); - vérification de l’identité de l’utilisateur signataire (30) ; - récupération dudit document (20) à signer auprès del’application métier (10) ; - préparation de la demande de signature avec le calcul del’empreinte des données à signer via des serveurs de signatures (50,51) ; - envoi d’une notification de la demande de signature à desservices de signatures (60) de l’utilisateur (30) via un serveur denotification (70) ; - contrôle de l’exécution du processus de signature par les servicesde signatures (60), en activant une clé privée correspondant à uncertificat de l’utilisateur (30) répondant aux critères de sélectionenvoyés audit gestionnaire de signature (40) par l’application métier(10); - horodatage et sauvegarde des évènements de la transactiondans des journaux ; - envoi à l’application métier (10) du résultat des opérations aprèsnotification, ou des erreurs éventuellement rencontrées ; - récupération par l’application métier (10) du résultat des opérations ; - mise à disposition de l’utilisateur (30) par l’application métier (10) du résultat des opérations.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1670070A FR3048530B1 (fr) | 2016-03-01 | 2016-03-01 | Systeme ouvert et securise de signature electronique et procede associe |
| US16/081,161 US20190097811A1 (en) | 2016-03-01 | 2017-02-28 | Open, secure electronic signature system and associated method |
| EP17713441.8A EP3423982A1 (fr) | 2016-03-01 | 2017-02-28 | Systeme ouvert et securise de signature electronique et procede associe |
| PCT/IB2017/051168 WO2017149453A1 (fr) | 2016-03-01 | 2017-02-28 | Systeme ouvert et securise de signature electronique et procede associe |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1670070A FR3048530B1 (fr) | 2016-03-01 | 2016-03-01 | Systeme ouvert et securise de signature electronique et procede associe |
| FR1670070 | 2016-03-01 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3048530A1 FR3048530A1 (fr) | 2017-09-08 |
| FR3048530B1 true FR3048530B1 (fr) | 2019-09-06 |
Family
ID=57045214
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1670070A Active FR3048530B1 (fr) | 2016-03-01 | 2016-03-01 | Systeme ouvert et securise de signature electronique et procede associe |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US20190097811A1 (fr) |
| EP (1) | EP3423982A1 (fr) |
| FR (1) | FR3048530B1 (fr) |
| WO (1) | WO2017149453A1 (fr) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR3092419B1 (fr) * | 2019-02-05 | 2021-05-21 | In Idt | Procédé et Système pour authentifier une signature manuscrite. |
| US11050571B2 (en) * | 2019-02-14 | 2021-06-29 | Carrott Richard F | Systems for producing and maintaining verified electronic signatures |
| FR3102589B1 (fr) | 2019-10-27 | 2022-05-13 | Lex Persona | Système ouvert et sécurisé de traitement de demande de signature électronique et procédé associe |
| CN112202719B (zh) * | 2020-09-04 | 2022-09-13 | 广州江南科友科技股份有限公司 | 基于数字证书的签名方法、***、装置及存储介质 |
| CN112836227B (zh) * | 2021-02-07 | 2021-11-19 | 新大陆（福建）公共服务有限公司 | 一种可信数字身份应用的方法 |
| JP2022146811A (ja) * | 2021-03-22 | 2022-10-05 | 富士フイルムビジネスイノベーション株式会社 | 情報処理装置及び情報処理プログラム |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2002048843A2 (fr) | 2000-12-14 | 2002-06-20 | Silanis Technology Inc. | Procede et systeme bases sur le web permettant d'appliquer une signature legale sur un document electronique |
| US8484723B2 (en) * | 2009-06-05 | 2013-07-09 | Signix, Inc. | Method and system for signing and authenticating electronic documents via a signature authority which may act in concert with software controlled by the signer |
| US8874923B2 (en) * | 2012-07-24 | 2014-10-28 | Adobe Systems Incorporated | Policy-based signature authentication system and method |
| NO335397B1 (no) * | 2012-11-15 | 2014-12-08 | Maestro Soft As | Signaturportering |
| US10158491B2 (en) * | 2013-04-08 | 2018-12-18 | Antonio Salvatore Piero Vittorio Bonsignore | Qualified electronic signature system, method and mobile processing terminal for qualified electronic signature |
-
2016
- 2016-03-01 FR FR1670070A patent/FR3048530B1/fr active Active
-
2017
- 2017-02-28 WO PCT/IB2017/051168 patent/WO2017149453A1/fr active Application Filing
- 2017-02-28 US US16/081,161 patent/US20190097811A1/en not_active Abandoned
- 2017-02-28 EP EP17713441.8A patent/EP3423982A1/fr active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| US20190097811A1 (en) | 2019-03-28 |
| EP3423982A1 (fr) | 2019-01-09 |
| FR3048530A1 (fr) | 2017-09-08 |
| WO2017149453A1 (fr) | 2017-09-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR3048530B1 (fr) | Systeme ouvert et securise de signature electronique et procede associe | |
| EP2071798B1 (fr) | Procédé et serveur de coffres-forts électroniques avec mutualisation d'informations | |
| EP2619941B1 (fr) | Procede, serveur et systeme d'authentification d'une personne | |
| FR2930390A1 (fr) | Procede de diffusion securisee de donnees numeriques vers un tiers autorise. | |
| EP3241137B1 (fr) | Procede mis en oeuvre dans un document d'identite et document d'identite associe | |
| EP3803670A1 (fr) | Une application logicielle et un serveur informatique pour authentifier l'identité d'un créateur de contenu numérique et l'intégrité du contenu du créateur publié | |
| US20200242717A1 (en) | Prevention of identification document forgery through use of blockchain technology and biometrics based authentication | |
| EP3812945B1 (fr) | Système ouvert et sécurisé de traitement de demande de signature électronique et procédé associé | |
| CN105515959A (zh) | 基于cms技术的即时通信保密***的实现方法 | |
| CA2694335C (fr) | Gestion et partage de coffres-forts dematerialises | |
| US10972455B2 (en) | Secure authentication in TLS sessions | |
| CN103684989B (zh) | 从移动通信终端设备上传个人信息的方法及装置 | |
| US8516609B2 (en) | Personal encryption device | |
| FR3047622B1 (fr) | Procede de controle d'un parametre indicatif d'un niveau de confiance associe a un compte utilisateur d'un service en ligne | |
| EP2071799B1 (fr) | Procédé et serveur pour l'accès a un coffre-fort électronique via plusieurs entités | |
| WO2024079144A1 (fr) | Procédé de gestion de données d'authentification permettant l'accès à un service d'un utilisateur depuis un terminal | |
| US20210334390A1 (en) | System for on-demand capture and exchange of media items that are not recorded at the point of capture | |
| FR2898423A1 (fr) | Procede securise de configuration d'un dispositif de generation de signature electronique. | |
| FR3007929A1 (fr) | Procede d'authentification d'un utilisateur d'un terminal mobile | |
| EP3979109A1 (fr) | Procédé et système d'authentification d'un utilisateur sur un appareil utilisateur | |
| OA20002A (fr) | Système ouvert et sécurisé de traitement de demande de signature électronique et procédé associé. | |
| WO2023001845A1 (fr) | Procédé d'enrôlement d'un utilisateur par un organisme sur une chaîne de blocs | |
| FR2888437A1 (fr) | Procede et systeme de controle d'acces a un service d'un fournisseur d'acces implemente sur un serveur multimedia, module, serveur, terminal et programmes pour ce systeme | |
| FR3051091A1 (fr) | Procede d'authentification pour autoriser l'acces a un site web ou l'acces a des donnees chiffrees | |
| FR3023039A1 (fr) | Authentification d'un utilisateur |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20170908 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| PLFP | Fee payment |
Year of fee payment: 7 |
|
| CA | Change of address |
Effective date: 20220603 |
|
| CJ | Change in legal form |
Effective date: 20220603 |
|
| PLFP | Fee payment |
Year of fee payment: 8 |
|
| PLFP | Fee payment |
Year of fee payment: 9 |