OA20002A - Open and secure electronic signature request processing system and associated method. - Google Patents
Open and secure electronic signature request processing system and associated method. Download PDFInfo
- Publication number
- OA20002A OA20002A OA1202000386 OA20002A OA 20002 A OA20002 A OA 20002A OA 1202000386 OA1202000386 OA 1202000386 OA 20002 A OA20002 A OA 20002A
- Authority
- OA
- OAPI
- Prior art keywords
- request
- documents
- manager
- signature
- signed
- Prior art date
Links
Abstract
L'invention concerne un système ouvert et sécurisé de traitement de demandes de signature électronique de documents comprenant une application métier, chargée de créer une demande de signature d'au moins un document pour un utilisateur signataire, ladite application métier étant hébergée par une entité demandeur. Le système est caractérisé en ce qu'il permet de signer des documents avec un certificat serveur créé à la volée et en ce qu'il comprend en outre trois services indépendants, un service gestionnaire de demandes qui héberge les demandes de signatures et les documents joints; une page de consentement, constitué d'une application HTML, étant apte à gérer le protocole de consentement en s'interfaçant avec un service sécurisé d'identification de l'utilisateur et en générant une paire de clés client (KcliPub, KcliPriv) et un service gestionnaire de preuves, hébergé par un fournisseur de signature, collectant les preuves de signature et comprenant un composant serveur hébergeant la clé cryptographique du signataire, ledit service gestionnaire de preuves étant apte à générer une paire de clés serveur (KservPriv et KservPub) à dériver une clé secrète Ks en utilisant la clé publique du client (Kclipub) et la clé privée du serveur (KservPriv) ; à générer une clé publique (KPub) et une clé privée, (KPriv) du signataire, à créer une demande de certificat, à récupérer un certificat auprès d'une autorité de certification, et en ce que la clé secrète Ks étant utilisée pour envelopper la clé privée du signataire. L'invention concerne en outre les procédés de traitement et d'élaboration de signature électronique de document mis en œuvre dans le système cidessus.The invention relates to an open and secure system for processing requests for electronic signature of documents comprising a business application, responsible for creating a request for signing at least one document for a signing user, said business application being hosted by a requesting entity. The system is characterized in that it allows documents to be signed with a server certificate created on the fly and in that it further comprises three independent services, a request manager service which hosts the signature requests and the attached documents; a consent page, consisting of an HTML application, being able to manage the consent protocol by interfacing with a secure user identification service and generating a client key pair (KcliPub, KcliPriv) and a proof manager service, hosted by a signature provider, collecting the signature proofs and comprising a server component hosting the cryptographic key of the signer, said proof manager service being able to generate a server key pair (KservPriv and KservPub) to derive a secret key Ks using the client's public key (Kclipub) and the server's private key (KservPriv); to generate a public key (KPub) and a private key, (KPriv) of the signer, to create a certificate request, to retrieve a certificate from a certification authority, and in that the secret key Ks is used to wrap the signer's private key. The invention further relates to the methods for processing and developing an electronic document signature implemented in the above system.
Description
DescriptionDescription
Titre de l'invention : Système ouvert et sécurisé de traitement de demande de signature électronique et procédé associeTitle of the invention: Open and secure electronic signature request processing system and associated process
[1] DOMAINE TECHNIQUE DE L’INVENTION[1] TECHNICAL FIELD OF THE INVENTION
[2] L’invention se rapporte au domaine de la signature électronique. Plus particulièrement, l’invention concerne un système ouvert et sécurisé pour traiter des demandes de signatures de documents électronique. L’invention concerne en outre un procédé d’élaboration et de traitement d’une demande de signature.[2] The invention relates to the field of electronic signature. More particularly, the invention relates to an open and secure system for processing electronic document signature requests. The invention further relates to a method of generating and processing a signature request.
[3] ETAT DE LA TECHNIQUE ANTERIEUR[3] STATE OF THE PRIOR ART
[4] La signature électronique consiste principalement à permettre à un utilisateur 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 est nécessaire de s’assurer que l’association entre la clé publique et l’identité du signataire soit certifiée par une autorité compatible avec les exigences de sécurité et de confiance associée à la signature électronique, que cette certification soit vérifiée comme étant toujours valide, et que le signataire soit bien d’accord avec le contenu à signer.[4] The electronic signature consists mainly in allowing a human user to encrypt the fingerprint of a document to be signed, with a private key corresponding to a public key associated with his identity, this private key being generally protected by a cryptographic device. and a secret code, the result of the encryption then having to be incorporated or associated with the document to be signed so as to constitute proof. During this operation, it is necessary to ensure that the association between the public key and the identity of the signatory is certified by an authority compatible with the security and trust requirements associated with the electronic signature, that this certification is verified as being still valid, and that the signer agrees with the content to be signed.
[5] Par ailleurs, l’enchaînement des tâches de calcul, de gestion et de vérifications nécessaires à la réalisation d’une signature électronique est excessivement complexe. En effet, les algorithmes sur lesquels s’appuient les calculs doivent eux-mêmes être compatibles avec les exigences de sécurité et de confiance. De plus, les données à signer ne sont pas forcément accessibles directement par le processus de signature mais peuvent être distantes, et ces mêmes données à signer doivent pouvoir être encadrées par des éléments de contexte comme la date et l’heure de la signature, la chaîne de certification du signataire, son rôle, un lieu de signature, une politique de signature, etc. Par ailleurs, la clé privée peut être sur un dispositif cryptographique local ou distant de l’utilisateur, et l’environnement même de ces opérations est tantôt sur le poste de travail de l’utilisateur, mais peut être également distant ou s’exécuter en mode clientserveur dans un navigateur Web, ou encore sur un smartphone ou une tablette.[5] Furthermore, the sequence of calculation, management and verification tasks necessary for the creation of an electronic signature is excessively complex. Indeed, the algorithms on which the calculations are based must themselves be compatible with the requirements of security and trust. In addition, the data to be signed is not necessarily directly accessible by the signing process but can be remote, and the same data to be signed must be able to be framed by context elements such as the date and time of the signature, the certification chain of the signatory, his role, a place of signature, a signature policy, etc. Furthermore, the private key can be on a local or remote cryptographic device from the user, and the very environment for these operations is sometimes on the user's workstation, but can also be remote or run in client-server mode in a web browser, or on a smartphone or tablet.
[6] Document EP 1393144 B1 divulgue un procédé et un système basé sur le Web permettant la signature juridiquement exécutoire de documents dans un environnement Web. Le système comprend un premier moyen d'accès pour accéder à l'environnement Web depuis un système électronique, et comprend également une pluralité de modules. Un module de rendu du document pour présenter à l'utilisateur une représentation Web du document, un module d'information juridique pour présenter à l'utilisateur, dans l'environnement Web, de l'information juridique relative à la signature électronique du document, et pour obtenir l'accord de l'utilisateur de cette information juridique. Un module d'approbation des documents pour intégrer la signature de l'utilisateur au document, avec l'accord de l'utilisateur de l'information juridique. Le système comprend également un module de journalisation pour générer un journal des processus de la signature du document en associant ce journal de processus avec le document signé. Enfin, un module de distribution de document pour rendre le document signé disponible. Ce document concerne la traçabilité du processus. Il y a un besoin particulier de rationaliser le processus de signature électronique et aussi de masquer la complexité du processus aux utilisateurs.[6] EP 1393144 B1 discloses a web-based method and system for legally binding signing of documents in a web environment. The system includes a first access means for accessing the web environment from an electronic system, and also includes a plurality of modules. A document rendering module to present to the user a Web representation of the document, a legal information module to present to the user, in the Web environment, legal information relating to the electronic signature of the document, and to obtain the user's consent to this legal information. A document approval module to integrate the user's signature into the document, with the consent of the user of the legal information. The system also includes a logging module for generating a process log of the signing of the document by associating this process log with the signed document. Finally, a document distribution module to make the signed document available. This document concerns the traceability of the process. There is a particular need to streamline the electronic signature process and also to hide the complexity of the process from users.
[7] Document EP 3423982 A1 (demandeur Lex persona) divulgue un système ouvert et sécurisé de signature électronique comprenant une application métier qui effectue une demande de signature d’un document auprès d’un gestionnaire de signature pour un utilisateur. L'application métier définit le cahier des charges de la ou des signatures, par exemple le contenu à signer, la sélection d’un utilisateur signataire, d’un format de signature, etc... Le gestionnaire de signature coordonne la demande de signature et sert d’intermédiaire entre l'application métier et l'utilisateur en vérifiant l’habilitation de l’application métier, l’identité de l’utilisateur signataire ; en récupérant le document à signer, en préparant la demande de signature avec les calculs d’empreintes des données à signer, l’envoi d’une notification de la demande de signature à des services de signatures de l’utilisateur. L’utilisateur, au moyen des services de signatures, peut 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 au gestionnaire de signature par l’application métier en vue du chiffrement de l’empreinte des données à signer. Dans ce document, le processus de signature électronique est décomposé en tâches indépendantes dont les interactions entre elles sont sécurisées. Ce document montre une rationalisation du processus de signature électronique et masque la complexité aux utilisateurs de la signature électronique et aux applications métiers qui souhaitent la mettre en œuvre.[7] Document EP 3423982 A1 (applicant Lex persona) discloses an open and secure electronic signature system comprising a business application which requests a signature of a document from a signature manager for a user. The business application defines the specifications for the signature (s), for example the content to sign, the selection of a signing user, a signature format, etc. The signature manager coordinates the signature request and acts as an intermediary between the business application and the user by verifying the authorization of the business application, the identity of the signing user; by retrieving the document to be signed, by preparing the signature request with fingerprint calculations of the data to be signed, sending a notification of the signature request to the user's signature services. The user, by means of the signature services, can control the execution of the signature process by activating the private key corresponding to a certificate of the user meeting the selection criteria sent to the signature manager by the business application in view. encryption of the fingerprint of the data to be signed. In this document, the electronic signature process is broken down into independent tasks whose interactions between them are secure. This document shows a rationalization of the electronic signature process and hides the complexity from the users of the electronic signature and from the business applications that wish to implement it.
[8] Le but de la présente invention est de permettre la création à la volée d’un certificat de signature sur le poste même du signataire et de signer un document. La présente invention simplifie considérablement la problématique de signature à distance et notamment la contrainte de prouver le contrôle de la clé privée par son titulaire, mais aussi la problématique de la sécurisation de cette clé privée gérée de manière centralisée ou bien la confidentialité des informations signées.[8] The aim of the present invention is to allow the on-the-fly creation of a signing certificate on the signatory's own workstation and to sign a document. The present invention considerably simplifies the problem of remote signing and in particular the constraint of proving control of the private key by its holder, but also the problem of securing this private key managed centrally or the confidentiality of the signed information.
[9] Un autre but de l’invention est d’améliorer le niveau de sécurité de la transaction de signature et de permettre une identité substantielle ou renforcée mais aussi la génération d’un identifiant de la transaction de la signature permettant ainsi de générer à la volée une identité numérique spécifiquement créée pour une transaction particulière.[9] Another object of the invention is to improve the security level of the signature transaction and to allow a substantial or reinforced identity but also the generation of an identifier of the signature transaction thus making it possible to generate the fly a digital identity specifically created for a particular transaction.
[10] EXPOSE DE L’INVENTION[10] DISCLOSURE OF THE INVENTION
[11] La présente invention à pour but de simplifier la problématique de signature électronique d’un document à distance, de sécuriser la gestion des clés privées et aussi d’améliorer davantage le niveau de sécurité ainsi que la confidentialité des informations qui sont signées. Pour ce faire, il est proposé un système ouvert et sécurisé de traitement de demande de signature électronique de documents comprenant une application métier, chargée de créer une demande de signature d’au moins un document pour un utilisateur signataire, ladite application métier étant hébergée par une entité demandeur, le système est caractérisé en ce qu’il permet de signer des documents avec un certificat serveur créé à la volée et en ce qu’il comprend en outre trois services indépendants, un service gestionnaire de demande qui héberge les demandes de signatures et les documents joints;[11] The present invention aims to simplify the problem of electronic signature of a document remotely, to secure the management of private keys and also to further improve the level of security as well as the confidentiality of the information which is signed. To do this, there is proposed an open and secure system for processing a request for electronic signature of documents comprising a business application, responsible for creating a signature request for at least one document for a signing user, said business application being hosted by a requesting entity, the system is characterized in that it makes it possible to sign documents with a server certificate created on the fly and in that it also comprises three independent services, a request manager service which hosts the signature requests and attached documents;
une page de consentement, constitué d’une application HTML, étant apte à gérer ie protocole de consentement en s’interfaçant avec un service sécurisé d’identification de l’utilisateur et en générant une paire de clés client, KcliPub et KcliPriv, dans le navigateur web du signataire, et un service gestionnaire de preuve, hébergé par un fournisseur de signature, collectant les preuves de signature et comprenant un composant serveur hébergeant la clé cryptographique du signataire, ledit service gestionnaire de preuve étant apte à récupérer un certificat auprès d’une autorité de certification, à générer une paire de clés serveur, KservPub, KservPriv à dériver une clé secrète Ks en utilisant la clé publique du client et la clé privée du serveur, et à générer une clé publique KPub et une clé privée (KPriv) du signataire, la clé secrète Ks étant utilisée pour envelopper la clé privée du signataire.a consent page, made up of an HTML application, being able to manage the consent protocol by interfacing with a secure user identification service and by generating a pair of client keys, KcliPub and KcliPriv, in the web browser of the signatory, and a proof manager service, hosted by a signature provider, collecting the signature proofs and comprising a server component hosting the signatory's cryptographic key, said proof manager service being able to retrieve a certificate from a certification authority, to generate a pair of server keys, KservPub, KservPriv to derive a secret key Ks using the public key of the client and the private key of the server, and to generate a public key KPub and a private key (KPriv) of the signer, the secret key Ks being used to wrap the private key of the signer.
[12] Selon des caractéristiques particulières, le service gestionnaire de demandes est protégé par une clé API de telle sorte que seule l'application métier est apte à lui faire des demandes de signature et en ce que ledit service gestionnaire de demandes étant apte à générer une requête pour la demande de signature, puis à générer un identifiant aléatoire unique pour un ou plusieurs documents de la demande de signature et à calculer le hash du ou desdits documents, à calculer le hash de ladite requête de demande de signature, à créer un jeton de la demande, avec une durée de vie limitée, à utiliser une phrase secrète, partagée avec le gestionnaire de preuve, pour signer ledit jeton de la demande, puis modifier le statut de la demande de signature en ‘démarré’ et renvoyer le jeton signé de la demande à l’application métier.[12] According to particular characteristics, the request manager service is protected by an API key so that only the business application is able to make signature requests to it and in that said request manager service is able to generate a request for the signature request, then to generate a unique random identifier for one or more documents of the signature request and to calculate the hash of said document (s), to calculate the hash of said signature request request, to create a request token, with a limited lifetime, to use a passphrase, shared with the proof manager, to sign said request token, then change the status of the signing request to 'started' and resend the token signed the request to the business application.
[131 Selon des caractéristiques particulières, la page de consentement est généré sur le navigateur de l’utilisateur, à la demande de l’application métier qui transmet le jeton de la demande via le service de demande de signature, ladite page de consentement génère une paire de clé client (kcliPriv et kcliPub) puis s’interface avec le service d’identification de l’utilisateur, via un nouvel onglet sur le navigateur, une fois l’utilisateur authentifié par le fournisseur d’identité, celui-ci transmet un code à l’utilisateur, le gestionnaire de preuve demande ensuite au fournisseur d’identité un jeton d’identification en échange du code, selon le protocole Openld Connect.[131 According to particular characteristics, the consent page is generated on the user's browser, at the request of the business application which transmits the token of the request via the signature request service, said consent page generates a client key pair (kcliPriv and kcliPub) then interfaces with the user identification service, via a new tab on the browser, once the user has been authenticated by the identity provider, the latter transmits a code to the user, the proof manager then asks the identity provider for an identification token in exchange for the code, according to the Openld Connect protocol.
r 20002 r 20002
I 5 s l J 'I 5 s the I
[14] Selon des caractéristiques particulières, la page de consentement est servie par le service gestionnaire de preuve, de telle sorte que le gestionnaire de preuve renvoie la chaîne de certificat et la clé publique du serveur à savoir KservPub à la page de consentement, ladite page de consentement en utilisant la clé privé du client (Kclipriv) et la clé publique du serveur (KservPub) est apte à dériver la clé secrète Ks, le signataire étant le seul à disposer de ladite clé secrète Ks, nécessaire pour décomposer sa clé privée, Kpriv, via ladite page de consentement qui s’exécute dans son navigateur web.[14] According to particular characteristics, the consent page is served by the proof manager service, so that the proof manager returns the certificate chain and the public key of the server, namely KservPub to the consent page, said consent page using the private key of the client (Kclipriv) and the public key of the server (KservPub) is able to derive the secret key Ks, the signer being the only one to have said secret key Ks, necessary to break down his private key , Kpriv, via said consent page which runs in their web browser.
[15] Selon des caractéristiques particulières, le gestionnaire de preuve est apte à valider le jeton de la demande, à générer un ID de preuve et à créer un fichier de preuves, l’ID de preuve étant dérivé du jeton de demande cle telle sorte que la création de preuves ne puisse pas être rejouée.[15] According to particular characteristics, the proof manager is able to validate the token of the request, to generate a proof ID and to create a proof file, the proof ID being derived from the key request token such that the creation of evidence cannot be replayed.
[16] Selon des caractéristiques particulières, le service d’identification avec lequel s’interface la page de consentement est telle qu’il permet d’obtenir une identité substantielle ou renforcée de l’utilisateur et de créer un certificat qualifié.[16] According to particular characteristics, the identification service with which the consent page interfaces is such that it makes it possible to obtain a substantial or enhanced identity of the user and to create a qualified certificate.
[17] Selon des caractéristiques particulières, la page de consentement est apte à récupérer la demande de signature et la liste des documents à signer du gestionnaire de demandes, la page de consentement présentant les documents au signataire, lui permettant de les lire avant de les signer.[17] According to particular characteristics, the consent page is able to retrieve the request for signature and the list of documents to be signed from the request manager, the consent page presenting the documents to the signatory, allowing him to read them before reading them. sign.
[18] Selon des caractéristiques particulières, le gestionnaire de demandes est apte à générer la valeur des documents à signer, DTBS, et à envoyer à la page de consentement en y attachant un code d'authentification, HMAC, ladite page de consentement est apte à envoyer les HMAC et la clé secrète Ks, et que le gestionnaire de preuve étant apte à valider les HMAC et décompresser la clé privée KPriv du signataire à l’aide de la clé secrète Ks, ledit gestionnaire de preuve signe ensuite les valeurs DTBS, avec la clé privé KPriv du signataire et ajoute les valeurs DTBS et la signature au fichier de preuves.[18] According to particular characteristics, the request manager is able to generate the value of the documents to be signed, DTBS, and to send to the consent page by attaching an authentication code, HMAC, said consent page is suitable in sending the HMACs and the secret key Ks, and that the proof manager being able to validate the HMACs and decompress the private key KPriv of the signatory using the secret key Ks, said proof manager then signs the DTBS values, with the signer's private key KPriv and adds the DTBS values and signature to the evidence file.
[19] Selon des caractéristiques particulières, le fichier de preuves est exporté au format XML, ledit fichier étant signé par un certificat de sécurité et est envoyé à la page de consentement qui le transfert au gestionnaire de demandes pour la validation et le stockage dudit fichier de preuves.[19] According to particular characteristics, the evidence file is exported in XML format, said file being signed by a security certificate and is sent to the consent page which transfers it to the request manager for the validation and storage of said file. evidence.
[20] Selon des caractéristiques particulières, le gestionnaire de demandes après avoir reçu le fichier de preuves au format XML, est apte à produire les documents signés de manière asynchrone et à informer l’application métier de ces documents, l’application métier étant apte à récupérer les documents signés et le fichier de preuves XML à l’aide d’une clé API, après avoir archivés le fichier XML et les documents signés, l'application métier étant apte à transmettre les documents signés au signataire.[20] According to particular characteristics, the request manager after having received the evidence file in XML format, is able to produce the signed documents asynchronously and to inform the business application of these documents, the business application being capable of producing the signed documents asynchronously. in retrieving the signed documents and the XML proof file using an API key, after having archived the XML file and the signed documents, the business application being able to transmit the signed documents to the signatory.
[21] Selon des caractéristiques particulières, le système comprend en outre une application native qui accède à la clé cryptographique clu signataire, ladite application native pouvant s’exécuter sur l’ordinateur du signataire ou sur son smartphone, et permettant audit signataire de signer des documents avec son propre certificat en utilisant soit son ordinateur, soit une application mobile s’il souhaite signer sur son smartphone.[21] According to particular characteristics, the system further comprises a native application which accesses the cryptographic key of the signatory, said native application being able to be executed on the signatory's computer or on his smartphone, and allowing said signatory to sign documents. documents with his own certificate using either his computer or a mobile application if he wishes to sign on his smartphone.
[22] Selon des caractéristiques particulières, la page de consentement après avoir récupéré les documents à signer sur le gestionnaire de demandes et après avoir obtenu le consentement du signataire est apte à ouvrir l’application native soit sur l’ordinateur soit sur le smartphone du signataire, ladite application native étant apte à demander au signataire de choisir un certificat de signature, à récupérer le DTBS des documents à signer sur le gestionnaire de demandes, à envoyer le DTBS signé au gestionnaire de preuves, demander de produire le fichier de preuves, et à transférer le fichier de preuves au gestionnaire de demandes pour générer les documents signés de manière asynchrone.[22] According to particular characteristics, the consent page after having retrieved the documents to be signed on the request manager and after having obtained the consent of the signatory is able to open the native application either on the computer or on the smartphone of the signatory, said native application being able to ask the signatory to choose a signing certificate, to retrieve the DTBS of the documents to be signed on the request manager, to send the signed DTBS to the proof manager, to request the production of the proof file, and transferring the evidence file to the request manager to generate the signed documents asynchronously.
[23] L’invention concerne également un procédé d’élaboration et de traitement d’une demande de signature mis en œuvre dans le système ci-dessus, comprenant une application métier pour effectuer une demande de signature, un service de gestionnaire de demandes qui prend en compte la demande de signature depuis l'application métier, une page de consentement pour gérer le protocole de consentement, et un service gestionnaire de preuves pour générer et mettre à jour un fichier de preuves, le procédé étant caractérisé en ce qu’il permet la signature d’un ou plusieurs documents avec un certificat serveur et en ce qu’il comprend les étapes suivantes :[23] The invention also relates to a method for developing and processing a signature request implemented in the above system, comprising a business application for making a signature request, a request manager service which takes into account the signature request from the business application, a consent page for managing the consent protocol, and an evidence manager service for generating and updating an evidence file, the method being characterized in that it allows the signature of one or more documents with a server certificate and in that it includes the following steps:
lancement de l’application métier par un utilisateur pour signer un document ;launch of the business application by a user to sign a document;
- lancement de la demande de signature par l’application métier auprès du gestionnaire de demandes puis transfère du ou des documents à signer et la redirection de l’utilisateur vers la page de consentement;- launch of the signature request by the business application from the request manager then transfers the document (s) to be signed and redirecting the user to the consent page;
- identification du signataire par la page de consentement avec le fournisseur d’identité via le protocole OpenID Connect ;- identification of the signatory by the consent page with the identity provider via the OpenID Connect protocol;
- récupération de la demande de signature et le ou les documents à signer par la page de consentement auprès du gestionnaire de demande ;- retrieval of the signature request and the document (s) to be signed by the consent page from the request manager;
- demande de consentement pour le ou les documents à signer par la page de consentement auprès du signataire ;- request for consent for the document (s) to be signed using the consent page with the signatory;
- génération de la clé de signature sur le composant serveur du gestionnaire de preuve, récupération du DTBS du ou des documents à signer auprès du gestionnaire de demandes par la page de consentement ;- generation of the signing key on the server component of the proof manager, recovery of the DTBS of the document (s) to be signed from the request manager via the consent page;
- demande de signature de DTBS du ou des documents auprès du serveur et la production d’un fichier de preuves auprès de gestionnaire de preuve par la page de consentement ;- DTBS signature request for the document (s) from the server and the production of an evidence file to the evidence manager via the consent page;
- transfère du fichier de preuves au gestionnaire de demande pour générer les documents signés de manières asynchrone ;- transfers the evidence file to the request manager to generate the signed documents asynchronously;
- redirection du signataire vers gestionnaire de demandes ;- redirection of the signatory to the request manager;
- envoie du ou des documents signés et le fichier de preuves à l’application métier ;- send the signed document (s) and the evidence file to the business application;
- archivage du ou des documents signés et le fichier de preuves par l’application métier.- archiving of the signed document (s) and the evidence file by the business application.
[24] Le procédé comprend en outre les étapes suivantes :[24] The method further comprises the following steps:
- validation de jeton de demande, génération d’un ID de preuve, et la création d’un ficher de preuves par le gestionnaire de preuves ;- request token validation, generation of an evidence ID, and creation of an evidence file by the evidence manager;
- génération d’une paire de clés client KcliPriv, Kclipub par la page de consentement ;- generation of a KcliPriv, Kclipub client key pair via the consent page;
- création de la clé du signataire par le gestionnaire de preuves ;- creation of the signatory's key by the evidence manager;
- génération d’une paires de clés privée et publique du serveur et l’utilisation de la clé privée du serveur et la clé publique du client pour dériver une clé r . 20002 ’ ' l J s ecrète Ks qui enveloppe la clé privée du signataire, par le gestionnaire de preuve;- generation of a private and public key pair of the server and the use of the private key of the server and the public key of the client to derive a key r . 20002 '' l J is secreted by Ks which envelops the private key of the signatory, by the proof manager;
- demande de certificat à l’autorité de certification et renvoie la chaîne de certificat et la clé publique du serveur à la page de consentement par le gestionnaire de preuves ;- request a certificate from the certification authority and return the server's certificate chain and public key to the consent page by the evidence manager;
- génération des valeurs DTBS de la demande et des documents par le gestionnaire de demandes ;- generation of the DTBS values of the request and of the documents by the request manager;
- transmission des valeurs DTBS par ia page de consentement (43) au gestionnaire de preuves ;- transmission of the DTBS values by the consent page (43) to the evidence manager;
- signature des valeurs DTBS avec ia clé privée du signataire et ajout les valeurs DTBS et la signature au fichier de preuves ;- signing the DTBS values with the signer's private key and adding the DTBS values and signature to the evidence file;
e xport du fichier de preuves au format XML et renvoie à ia page de consentement qui le transmet ensuite au gestionnaire de demandes ;exporting the evidence file in XML format and returning it to the consent page which then forwards it to the request manager;
production des documents signés et envoie desdits documents à l’application métier ;production of signed documents and sends said documents to the business application;
- archivage du fichier de preuves au format XML et les documents signés par l’application métier et ensuite le transfert des documents signés au signataire.- archiving of the evidence file in XML format and the documents signed by the business application and then the transfer of the signed documents to the signatory.
[25] L’invention concerne également le procédé d’élaboration et de traitement d’une demande de signature mis en œuvre dans le système ci-dessus, et comprenant en outre une application native qui accède à une clé cryptographique du signataire. Le procédé, après la récupération des documents à signer sur le gestionnaire de demandes et après avoir obtenu le consentement du signataire, comprend les étapes suivantes :[25] The invention also relates to the method of generating and processing a signature request implemented in the above system, and further comprising a native application which accesses a cryptographic key of the signer. The process, after retrieving the documents to be signed from the request manager and having obtained the consent of the signatory, comprises the following steps:
- ouverture de l’application native soit sur l’ordinateur du signataire soit sur son smartphone ;- opening of the native application either on the signatory's computer or on his smartphone;
- demande de choix d’un certificat ce signature par l’application native ;- request for the choice of a certificate and signature by the native application;
- récupération du DTBS des documents à signer sur le gestionnaire de demandes, puis envoi le DTBS signé au gestionnaire de preuves par l’application native;- retrieving the documents to be signed from the DTBS on the request manager, then sending the signed DTBS to the proof manager by the native application;
- demande de production du fichier de preuves, et le transfère du fichier de preuves au gestionnaire de demandes pour générer les documents signés de manière asynchrone ;- request for production of the evidence file, and transfers it from the evidence file to the request manager to generate the signed documents asynchronously;
- fermeture de l’application native et la redirection du signataire vers l’application métier;- closing the native application and redirecting the signer to the business application;
- récupération des documents signés par l’application métier;- recovery of documents signed by the business application;
- récupération du fichier de preuves et archivage des fichiers ainsi que les documents signés par l’application métier.- recovery of the evidence file and archiving of the files as well as the documents signed by the business application.
[26] BREVE DESCRIPTION DES FIGURES[26] BRIEF DESCRIPTION OF THE FIGURES
[27] 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, qui illustrent :[27] Other characteristics, details and advantages of the invention will become apparent on reading the following description, with reference to the appended figures, which illustrate:
[Fig. 1 ] illustre l’architecture générale du système selon la présente invention;[Fig. 1] illustrates the general architecture of the system according to the present invention;
[Fig.2] représente un diagramme simplifié du serveur de signature avec un certificat crée à la volé selon la présente invention ;[Fig.2] represents a simplified diagram of the signature server with a certificate created on the fly according to the present invention;
[Fig.3] illustre l’architecture du système dans le cas d’utilisation d’un jeton d’authentification et signature locale ;[Fig. 3] illustrates the architecture of the system in the case of using a local authentication and signature token;
[Fig.4] représente un diagramme simplifié dans le cas de signature locale.[Fig.4] represents a simplified diagram in the case of local signature.
[28] Pour plus de clarté, les éléments identiques ou similaires sont repérés par des signes de références identiques sur l’ensemble des figures.[28] For clarity, identical or similar elements are identified by identical reference signs in all of the figures.
[29] DESCRIPTION DETAILLEE[29] DETAILED DESCRIPTION
[30] L’architecture générale du système selon la présente invention représente d’une part, un utilisateur 30 qui doit signer un document et d’autre part l’environnement internet d’un gestionnaire de demande de signature. Un utilisateur 30 est une personne physique qui souhaite ou doit signer un ou plusieurs documents.[30] The general architecture of the system according to the present invention represents on the one hand, a user 30 who must sign a document and on the other hand the internet environment of a signature request manager. A user 30 is a natural person who wishes or must sign one or more documents.
[31] La distinction entre une signature effectuée à l’initiative même de l’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 implique nécessairement une préparation liée au choix du document, à sa rédaction, à la sélection de l’identité numérique et à sa mise en place, à l’éventuelle politique de signature à 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 du signataire pour se focaliser sur la valeur probatoire de la transaction, en contraignant éventuellement l’utilisateur, avant de pouvoir signer, à lire l’intégralité du document, à s’authentifier pour prouver son identité numérique, etc.[31] The distinction between a signature made at the user's own initiative or requested by a third party (other user) is essential. Indeed, the user experience is very different because, in the first case, it necessarily involves preparation related to the choice of the document, its drafting, the selection of the digital identity and its implementation, the possible signature policy to be applied, etc., while in the second case, it requires a particular ease of action regarding access to the document and the digital identity of the signatory in order to focus on the probative value of the transaction, possibly forcing the user, before being able to sign, to read the entire document, to authenticate himself to prove his digital identity, etc.
[32] L’architecture du système telle que représentée sur la figure 1 comprend une application métier 10, ladite application métier 10 peut être développée et exécutée dans des environnements variés tels que des serveurs Web, des navigateurs Internet, dans un environnement natif PC ou Mac, ou encore depuis un téléphone portable ou une tablette. L’application métier est à l’origine du processus 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 un tiers en vue de faire signer un document, doit nécessairement passer par cette application métier 10. Ladite application métier 10 est conçue de sorte qu’elle est apte à effectuer une demande de signature d’au moins d’un document auprès d’un service gestionnaire de demandes 41, ledit gestionnaire de demandes 41 est un composant serveur qui prend en compte une demande de signature venant de ladite application métier 10 et il est hébergé par une entité demandeur 40. Le système comprend en outre deux autres services indépendants à savoir un service gestionnaire ou une page de consentement 43 et un service gestionnaire de preuves 45. La page de consentement 43 gère le protocole de consentement et est une application HTML qui pilote le signataire 30 tout au long du processus de consentement et de la création de la signature. Ce composant réside dans le navigateur Internet 11 du signataire 30. Le service gestionnaire de preuves 45 est un composant serveur qui collecte les preuves, ce composant est hébergé par le fournisseur de signature 50 (LEXPERSONA). La référence 48 est un composant serveur hébergeant la clé cryptographique du signataire 30. Ce composant est intégré au gestionnaire de preuves 45. L’autorité de certification 46 est une infrastructure de clé publique PKI qui émet le certificat de signataire, ce composant est hébergé par le fournisseur de signature 50. Le fournisseur d’identité 44 est un serveur d’autorisation conforme à Open ID Connect qui émet le jeton d’identification d’un signataire à partir duquel le certificat de signataire est dérivé. Ce composant est hébergé par un fournisseur d’enregistrement 60.[32] The architecture of the system as shown in Figure 1 comprises a business application 10, said business application 10 can be developed and executed in various environments such as web servers, Internet browsers, in a native PC environment or Mac, or even from a cell phone or tablet. The business application is at the origin of the signature process, thus, any request for signature, whether it is carried out at the initiative of the signing user 30 himself, or that it is carried out by a third party in in order to have a document signed, must necessarily go through this business application 10. Said business application 10 is designed so that it is capable of making a request for signature of at least one document from a management service. requests 41, said request manager 41 is a server component which takes into account a signature request coming from said business application 10 and it is hosted by a requesting entity 40. The system further comprises two other independent services, namely a manager service or a consent page 43 and an evidence manager service 45. The consent page 43 manages the consent protocol and is an HTML application which guides the signer 30 through the counseling process. ntement and creation of the signature. This component resides in the Internet browser 11 of the signatory 30. The evidence manager service 45 is a server component which collects the evidence, this component is hosted by the signature provider 50 (LEXPERSONA). Reference 48 is a server component hosting the cryptographic key of the signer 30. This component is integrated into the evidence manager 45. The certification authority 46 is a public key infrastructure PKI which issues the signer's certificate, this component is hosted by signature provider 50. Identity provider 44 is an Open ID Connect compliant authorization server that issues the identification token of a signer from which the signer certificate is derived. This component is hosted by a 60 recording provider.
[33] La figure 2 illustre le diagramme simplifié du processus de signature d’un document à distance. Le signataire 30 navigue avec son navigateur internet 11 sur l’application métier 10 où il doit signer certains documents. L’application métier 10 lance une demande de signature sur le gestionnaire de demandes 41 et lui transfère les documents à signer. Le service gestionnaire de demandes 41 redirige le signataire 30 vers la page de consentement 43. Ledit page de consentement 43 identifie le signataire 30 en s’interfaçant avec un fournisseur d’identité 44 à l’aide du protocole Open ID Connect. Ensuite, la page de consentement 43 récupère la demande de signature ainsi que les documents à signer sur le gestionnaire de demandes 41. La page de consentement 43 montre les documents à signer au signataire 30 en lui demandant son consentement. La page de consentement demande la génération de la clé de signataire sur le composant serveur 48 qui est intégré au composant gestionnaire de preuves 45. La page de consentement 43 récupère le DTBS des documents à signer sur le gestionnaire de demandes 41 et demande au serveur 48 de signer le DTBS et au gestionnaire de preuves 45 de produire le fichier de preuves, pour transférer au gestionnaire de demandes 41 afin que ledit gestionnaire de demandes 41 puisse générer les documents signés de manière asynchrones. Ensuite, la page de consentement 43 redirige le signataire vers l’application métier 10. Une fois les documents signés produites par le gestionnaire de demandes 41, l’application métier 10 les récupère. L’application métier 10 récupère aussi le fichier de preuves et l’archive avec les documents signés.[33] Figure 2 shows the simplified diagram of the remote document signing process. The signatory 30 navigates with his internet browser 11 on the business application 10 where he must sign certain documents. The business application 10 initiates a signature request on the request manager 41 and transfers the documents to be signed to it. The request manager service 41 redirects the signer 30 to the consent page 43. The consent page 43 identifies the signer 30 by interfacing with an identity provider 44 using the Open ID Connect protocol. Then, the consent page 43 retrieves the signature request as well as the documents to be signed on the request manager 41. The consent page 43 shows the documents to be signed to the signatory 30 by asking him for his consent. The consent page requests the generation of the signer key on the server component 48 which is integrated with the evidence manager component 45. The consent page 43 retrieves the DTBS of the documents to be signed on the request manager 41 and requests the server 48 to sign the DTBS and to the evidence manager 45 to produce the evidence file, to transfer to the request manager 41 so that said request manager 41 can generate the signed documents asynchronously. Then, the consent page 43 redirects the signer to the business application 10. Once the signed documents produced by the request manager 41, the business application 10 retrieves them. The business application 10 also retrieves the evidence file and archives it with the signed documents.
[34] Nous allons décrire comment une application métier 10 fournit une demande de signature sur le gestionnaire de demandes 41. En effet, l’application métier 10 lance la création d’une demande de signature auprès du gestionnaire de demandes 41 qui est protégé par une clé APL L’application métier 10 est la seule application apte à faire une demande de signature auprès du gestionnaire de demandes 41. Il est à noter que, l’application métier 10 comimunique avec ΙΆΡΙ REST du gestionnaire de demandes 41 en arrière plan afin que la clé de i’API reste secrète. Le gestionnaire de demandes 41 génère ensuite un ID de demande de signature et l’envoi à l’application métier 10, ladite application métier 10 télécharge un document à signer dans le gestionnaire de demandes 41 en transmettant l’ID de demande en tant que paramètre. De même, le gestionnaire de demandes 41 génère un ID unique du document et le renvoi à l’application métier 10. Les étapes précédentes sont répétées autant de fois qu’il y ait de document à signer. Une fois les documents téléchargés, l’application métier 10 demande au gestionnaire de demandes 41 de lancer la demande de signature.[34] We will describe how a business application 10 provides a signature request on the request manager 41. Indeed, the business application 10 initiates the creation of a signature request from the request manager 41 which is protected by an APL key The business application 10 is the only application capable of making a request for signature from the request manager 41. It should be noted that the business application 10 communicates with ΙΆΡΙ REST of the request manager 41 in the background in order to that the API key remains secret. The request manager 41 then generates a signature request ID and sending to the business application 10, said business application 10 downloads a document to be signed in the request manager 41 by transmitting the request ID as a parameter . Likewise, the request manager 41 generates a unique ID of the document and returns it to the business application 10. The preceding steps are repeated as many times as there is a document to be signed. Once the documents have been downloaded, the business application 10 requests the request manager 41 to initiate the signature request.
[35] Le gestionnaire de demandes 41 calcul le hachage de demande ainsi que les hachages des documents à partir du JSON de demande et des JSON des documents (incluant les hachages de documents). Le JSON de demande incluant un ID de demande. Le gestionnaire de demandes 41 crée également le jeton de demande contenant l’ID de demande et son hachage et utilise une phrase secrète partagée avec le gestionnaire de preuves 45 pour le signer. En suite, le gestionnaire de demandes 41 modifie le statut de la demande en démarré et renvoie le jeton de la demande à l’application métier 10. Le jeton de la demande a une durée de vie de cinq minutes. Une durée plus courte, poserait des problèmes si les horloges du gestionnaire de demandes 41 et le gestionnaire de preuves 45 ne sont pas correctement synchronisées.[35] Request Manager 41 calculates request hash as well as document hashes from request JSON and document JSON (including document hashes). The request JSON including a request ID. The request manager 41 also creates the request token containing the request ID and its hash and uses a passphrase shared with the evidence manager 45 to sign it. Subsequently, the request manager 41 changes the status of the request to started and sends the request token back to the business application 10. The request token has a lifetime of five minutes. A shorter duration would cause problems if the clocks of the request manager 41 and the evidence manager 45 are not properly synchronized.
Création d’une page de consentement :Creation of a consent page:
[36] Le signataire est redirigé vers l’URL de la page de consentement 43 par l’application métier 10, en transmettant le jeton de la demande en tant que paramètre. Le gestionnaire de preuves 45, derrière l’URL de la page de consentement 43 valide le jeton de la demande, génère un ID de preuve et crée le fichier de preuves, en renvoyant une redirection HTTP avec l’ID de preuve en tant que paramètre. L’ID de preuve est dérivé du jeton de la demande afin que la création de preuve ne puisse pas être rejouée. En effet, la redirection empêche la tentative de création de preuves à chaque fois que le signataire actualise l’onglet de son navigateur. En suite, le signataire ouvre l’URL de la page de consentement 43 en transmettant l’ID de preuve en tant que paramètre. Le gestionnaire de preuves 45 renvoie une page HTML comprenant l’ID de la demande, le hachage de la demande, l’URL d’autorisation du fournisseur d’identité 44, les feuilles de style, etc., à la page de consentement 43.[36] The signer is redirected to the URL of consent page 43 by business application 10, passing the request token as a parameter. Evidence Manager 45, behind the URL for consent page 43 validates the request token, generates an evidence ID and creates the evidence file, returning an HTTP redirect with the evidence ID as a parameter . The evidence ID is derived from the request token so that the evidence creation cannot be replayed. This is because the redirect prevents the attempt to create evidence each time the signer refreshes their browser tab. Next, the signer opens the URL of the consent page 43, passing the proof ID as a parameter. Evidence manager 45 returns an HTML page including request ID, request hash, identity provider authorization URL 44, stylesheets, etc., to consent page 43 .
Récupération de l’identité du signataire et le déroulement d’autorisation Open ID Connect :Retrieving the identity of the signer and the Open ID Connect authorization process:
[37] Une fois la page de consentement 43 signifiée, le signataire 30 la charge dans son navigateur 11. Tout d’abord, la page de consentement génère une paire de clés publique et privée du cHent (KcliPriv et KcliPub). L’URL autorisé est ensuite renseignée avec un état contenant HD de preuve, un identifiant aléatoire unique pour un ou plusieurs documents et la clé publique du client. Une redirection vers le fournisseur d’identité 44 aura lieu via un bouton présenté au signataire 30. Le bouton permet également à la page d’autorisation de s’ouvrir sans aucune restriction du navigateur. Une fois le bouton cliqué, l’URL d’autorisation du fournisseur d’identité 44 est ouverte dans un nouvel onglet de navigateur 11, laissant ainsi la page de consentement 43 en arrière plan. Le fait de garder la page de consentement 43 ouvert permet de conserver la clé privée du client (KcliPriv) dans la RAM et de limiter les risques d’attaque sur l’ordinateur du signataire 30. Une fois le signataire 30 s’est authentifié et a accordé l’autorisation d’accéder à son identité, le fournisseur d’identité 44 le redirige vers une page de rappel en lui transmettant un code. Le navigateur du signataire 30 ouvre la page de rappel en transmettant HD de preuve en tant que paramètre avec le code. Le gestionnaire de preuves 45 demande au fournisseur d’identité 44 d’échanger le code avec un jeton d’identification tel que spécifié par le protocole Open ID Connect. Le fournisseur d’identité 44 renvoie le jeton d’identification au gestionnaire de preuves 45. Ledit gestionnaire de preuves 45 crée le jeton de signataire à partir du jeton ID et met à jour le fichier de preuves et une page HTML est renvoyée, y compris ie jeton de signataire. A noter que le jeton de signataire contient le hachage de la demande et certains éléments de base fournie par ie fournisseur d’identités 44, telle que le nom du signataire, l’adresse de la messagerie et l’identificateur. Une fois ouvert par le navigateur 11 du signataire, la page de rappel envoi le jeton de signataire à la page de consentement 43, à l’aide d’un message inter-onglet. Puisque les deux pages sont sur le même domaine, il n’y a pas de restriction du navigateur.[37] Once the consent page 43 is served, the signer 30 loads it into their browser 11. First, the consent page generates a public and private key pair of the cHent (KcliPriv and KcliPub). The authorized URL is then populated with a report containing HD proof, a unique random identifier for one or more documents and the client's public key. A redirection to identity provider 44 will take place via a button presented to signer 30. The button also allows the authorization page to open without any browser restrictions. Once clicked, the Identity Provider Authorization URL 44 is opened in a new browser tab 11, leaving the consent page 43 in the background. Keeping the consent page 43 open makes it possible to keep the client's private key (KcliPriv) in the RAM and to limit the risk of an attack on the computer of the signer 30. Once the signer 30 has authenticated and has granted authorization to access his identity, the identity provider 44 redirects him to a reminder page by sending him a code. The signer's browser 30 opens the callback page transmitting HD proof as a parameter with the code. Evidence manager 45 requests identity provider 44 to exchange the code with an identification token as specified by the Open ID Connect protocol. Identity provider 44 returns the identification token to evidence manager 45. Said evidence manager 45 creates signer token from ID token and updates the evidence file and an HTML page is returned including ie signer token. Note that the signer token contains the hash of the request and some basic elements provided by the identity provider 44, such as the name of the signer, the e-mail address and the identifier. Once opened by the signer’s browser 11, the reminder page sends the signer token to the consent page 43, using a cross-tab message. Since both pages are on the same domain, there is no browser restriction.
Consentement du signataire :Consent of signatory:
[38] La page de consentement 43 récupère la demande de signature du gestionnaire de demandes 41 en transmettant HD de la demande et le jeton de signataire en tant que paramètre. Le gestionnaire de demandes 41 renvoi ie JSON de la demande après avoir vérifié que le jeton de signataire contient les[38] The consent page 43 retrieves the signing request from the request handler 41 by passing HD of the request and the signer token as a parameter. The request manager 41 returns the JSON of the request after verifying that the signer token contains the
éléments d’identité attendus ainsi que le hachage de la demande attendu. La page de consentement 43 récupère la liste des documents du gestionnaire de demandes 41 en transmettant ΓID de la demande et le jeton de signataire en tant que paramètre. Le gestionnaire cle demandes 41 renvoie les JSON des documents après avoir vérifié que te jeton de signature contient les éléments d’identité et le hachage de la demande prévu. La page de consentement 43 garantit que le hachage de la demande est cohérent avec le JSON de la demande et les JSON des documents. Pour chaque document que le signataire doit ou veut lire ou télécharger, la page de consentement 43 récupère le contenu du document en transmettant comme paramètre HD du document et le jeton de signataire. Le gestionnaire de demandes 41 renvoie ie contenu du document après avoir vérifié que le jeton de signataire contient les éléments d'identité attendues et le hachage de demande prévu. Avant de présenter le contenu du document au signataire, la page de consentement 43 garantit que le hachage du contenu est cohérent avec le hachage contenu dans le document JSON. En suite la page de consentement 43 présente les documents au signataire 30, lui permettant de les lire. Une fois qu'il accepte, le signataire clique sur le bouton «J'accepte».expected identity elements as well as the expected request hash. The consent page 43 retrieves the list of documents from the request manager 41 by passing ΓID of the request and the signer token as a parameter. The request manager 41 returns the JSON of the documents after verifying that the signature token contains the identity elements and the hash of the intended request. The consent page 43 ensures that the hash of the request is consistent with the JSON of the request and the JSON of the documents. For each document that the signer must or wants to read or download, the consent page 43 retrieves the content of the document by transmitting as the HD parameter of the document and the signer token. The request manager 41 returns the content of the document after verifying that the signer token contains the expected identity elements and the expected request hash. Before presenting the content of the document to the signer, the consent page 43 ensures that the hash of the content is consistent with the hash contained in the JSON document. Next, the consent page 43 presents the documents to the signatory 30, allowing him to read them. Once they accept, the signatory clicks on the "I accept" button.
Création de la clé de signataireCreating the signer key
[39] La clé du signataire est crée et protégée par le gestionnaire de preuves 45. En effet, la page de consentement 43 demande au gestionnaire de preuves 45 de créer la clé de signataire 30, en passant l'ID de preuve, le jeton de signataire, le JSON de demande, les JSON de documents et la clé publique de client (kcliPub) en tant que paramètres. Le gestionnaire de preuves 45 s'assure que le hachage de la demande est cohérent avec le JSON de la demande et avec les JSON des documents. Le gestionnaire de preuves 45 vérifie également que le nombre aléatoire unique contenu dans le jeton d'ID produit par le fournisseur d'identité 44 correspondant au hachage du défi et à la clé publique du client (kcliPub). Ensuite, le gestionnaire de preuves 45 génère une paire de clés serveur (kservPriv et kservPub) et utilise la clé privée du serveur (kservPriv) et la clé publique du client (kcliPub) pour dériver une clé secrète (ks) avec l'algorithme Diffie-Helîman. La paire de clés (kPriv et kPub) du signataire est ensuite créée par le gestionnaire de preuves 45 avec une demande de certificat, et la clé secrète (ks) est utilisée pour envelopper la clé privée (kPriv) du signataire. Une fois que la clé du signataire a été encapsulée, la clé secrète (ks) est détruite par le gestionnaire de preuves 45. La demande de certificat est envoyée à l’autorité de certification 46. L’autorité de certification 46 renvoie le certificat au gestionnaire de preuve 45. Après avoir stocké la clé privée encapsulée et mis à jour le fichier de preuves avec le certificat de signataire, le gestionnaire de preuves 45 renvoie la chaîne de certificats et la clé publique du serveur (kservPub) à la page de consentement 43. La page de consentement 43 utilise la clé privée du client (kcliPriv) et la clé publique du serveur (kservPub) pour dériver la clé secrète (ks) avec l'algorithme Diffie-Hellman. À ce stade, le signataire 30, via la page de consentement 43 qui s'exécute dans son propre navigateur 11, est le seul à disposer de la clé secrète (ks) nécessaire pour décompresser la clé privée du signataire (kPriv) dans le gestionnaire de preuves.[39] The signer's key is created and protected by the evidence manager 45. Indeed, the consent page 43 asks the evidence manager 45 to create the signatory key 30, passing the evidence ID, the token Signer, Request JSON, Document JSON, and Client Public Key (kcliPub) as parameters. The evidence manager 45 ensures that the hash of the request is consistent with the JSON of the request and with the JSON of the documents. The evidence manager 45 also verifies that the unique random number contained in the ID token produced by the identity provider 44 matches the hash of the challenge and the client's public key (kcliPub). Then Evidence Manager 45 generates a server key pair (kservPriv and kservPub) and uses the server's private key (kservPriv) and the client's public key (kcliPub) to derive a secret key (ks) with the Diffie algorithm. -Helîman. The signer's key pair (kPriv and kPub) is then created by the evidence manager 45 with a certificate request, and the secret key (ks) is used to wrap the signer's private key (kPriv). Once the signer's key has been encapsulated, the secret key (ks) is destroyed by the evidence manager 45. The certificate request is sent to the certification authority 46. The certification authority 46 returns the certificate to the Evidence Manager 45. After storing the encapsulated private key and updating the evidence file with the signer certificate, Evidence Manager 45 returns the server's certificate chain and public key (kservPub) to the consent page 43. The consent page 43 uses the client's private key (kcliPriv) and the server's public key (kservPub) to derive the secret key (ks) with the Diffie-Hellman algorithm. At this point, the signer 30, via the consent page 43 which runs in his own browser 11, is the only one who has the secret key (ks) needed to decompress the private key of the signer (kPriv) in the manager evidence.
[40] Nous décrivons comment les documents DTBS sont générés par le gestionnaire de demandes 41 et comment ils sont signés par le gestionnaire de preuves 45 à l’aide de la clé du signataire 30. En effet, pour chaque document à signer, la page de consentement 43 envoie la chaîne de certificats au gestionnaire de demandes 41 avec ND de document et le jeton de signataire. Après avoir vérifié que le jeton de signataire contient les éléments d'identité attendus et le hachage de la demande, le gestionnaire de demandes 41 génère la valeur DTBS et la renvoie à la page de consentement 43 en y attachant un HMAC. Le HMAC est calculé à partir de la valeur DTBS et de l'ID de document à l'aide de la phrase secrète partagée avec le gestionnaire de preuves 45. Une fois que toutes les valeurs DTBS ont été générées, la page de consentement 43 les envois au gestionnaire de preuves 45 avec les HMAC et la clé secrète (ks). Le gestionnaire de preuves 45 valide les HMAC et décompresse la clé privée du signataire (kPriv) avec la clé secrète (ks). Le gestionnaire de preuves 45 signe ensuite les valeurs DTBS avec la clé privée du signataire (kPriv) et ajoute les valeurs DTBS et la signature au fichier de preuves. Le fichier de preuves est exporté au format XML, signé par le gestionnaire de preuves 45 avec un certificat de scellement et est renvoyé à la page de consentement 43. Ladite page de consentement 43 transmet le fichier de preuves XML au gestionnaire de demandes 41. Le gestionnaire de demandes 41 valide et stocke le fichier de preuves XML, modifie le statut de la demande en ‘signé’ et renvoie une réponse vide à la page de consentement 43.[40] We describe how the DTBS documents are generated by the request manager 41 and how they are signed by the evidence manager 45 using the signer's key 30. Indeed, for each document to be signed, the page consent 43 sends the certificate chain to the request manager 41 with document ND and the signer token. After verifying that the signer token contains the expected identity elements and the hash of the request, the request handler 41 generates the DTBS value and returns it to the consent page 43 by attaching an HMAC to it. The HMAC is calculated from the DTBS value and the document ID using the passphrase shared with Evidence Manager 45. After all DTBS values have been generated, consent page 43 them. sends to the proof manager 45 with the HMACs and the secret key (ks). The proof manager 45 validates the HMACs and decompresses the private key of the signer (kPriv) with the secret key (ks). The evidence manager 45 then signs the DTBS values with the signer's private key (kPriv) and adds the DTBS values and signature to the evidence file. The evidence file is exported in XML format, signed by the evidence manager 45 with a seal certificate and is returned to the consent page 43. Said consent page 43 transmits the XML evidence file to the request manager 41. The Request Manager 41 validates and stores the XML evidence file, changes the status of the request to 'signed', and returns an empty response to the consent page 43.
[41] Le gestionnaire de demandes 41 termine le traitement de la demande en produisant les documents signés en arrière-pian. En effet, après avoir reçu le fichier de preuves XML, le gestionnaire de demandes 41 lance une tâche en arrière-plan pour produire les documents signés et terminer le traitement de la demande. Pendant ce temps, la page de consentement 43 redirige le signataire 30 vers l'URL de rappel de l'application métier 10. Le navigateur du signataire 30 ouvre la page de rappel de l'application métier 10. Selon le cas d’utilisation de l'application métier 10, la page de rappel peut demander au signataire 30 d'attendre pendant la préparation des documents signés ou peut l'informer que les documents signés seront disponibles ultérieurement. Une fois que le gestionnaire de demandes 41 a produit les documents signés, le statut de la demande est modifié pour être terminé. Le gestionnaire de demandes 41 informe l'application métier 10 via un Webhook. L'application métier 10 récupère les documents signés à partir du gestionnaire de demandes 41 à l'aide de sa clé API. Le gestionnaire de demandes 41 renvoi le fichier de preuves XML à l'application métier 10. Une fois le fichier de preuve XML et les documents signés archivés, l'application métier 10 transmet les documents signés au signataire 30.[41] The request manager 41 completes the processing of the request by producing the documents signed in reverse. Indeed, after having received the XML evidence file, the request manager 41 launches a background task to produce the signed documents and to complete the processing of the request. During this time, the consent page 43 redirects the signer 30 to the callback URL of the business application 10. The browser of the signer 30 opens the callback page of the business application 10. Depending on the use case of business application 10, the reminder page can ask the signer 30 to wait while the signed documents are being prepared or can inform him that the signed documents will be available later. After the request manager 41 produces the signed documents, the status of the request is changed to be completed. The request manager 41 informs the business application 10 via a Webhook. The business application 10 retrieves the signed documents from the request manager 41 using its API key. The request manager 41 sends the XML evidence file back to the business application 10. Once the XML proof file and the signed documents have been archived, the business application 10 transmits the signed documents to the signer 30.
[42] A noter que un Webhook est une méthode permettant d’augmenter ou de modifier le comportement d’une page Web , ou d’une application Web , avec des rappels personnalisés.[42] Note that a webhook is a method of augmenting or modifying the behavior of a web page, or web application, with personalized callbacks.
[43] L’invention permet également à un signataire de signer des documents avec son propre certificat, un jeton cryptographique, par exemple, en utilisant une application locale s’il souhaite signer sur son ordinateur ou s’il souhaite utiliser son smartphone. Les différents composants impliqués dans la création de la signature locale sont illustrés sur la figure 3. Cette architecture comprend une application métier 10 qui est chargée de créer les demandes de signature. Ce composant est hébergé par l'entité demandeur 40. Le gestionnaire de demandes 41 est une composant du serveur qui héberge les demandes de signature et les documents joints. Ce composant est hébergé par l'entité demandeur 40. La page de consentement 43 est une application HTML qui pilote le signataire 30 tout au long du processus de consentement et de la création de la signature. Ce composant réside dans le navigateur Web 11 du signataire 30. Le gestionnaire de preuves 45 est un composant serveur qui collecte les preuves de signature. Ce composant est hébergé par le fournisseur de signature 50 (LEX PERSONA). Le système comprend en outre une application native locale 47 qui peut être installée sur un ordinateur fixe du bureau ou sur un smartphone et qui accède à la clé cryptographique du signataire pour signer les documents. Ce composant s'exécute sur l'ordinateur du signataire ou sur son smartphone.[43] The invention also allows a signer to sign documents with their own certificate, a cryptographic token, for example, using a local application if they wish to sign on their computer or if they wish to use their smartphone. The various components involved in the creation of the local signature are illustrated in FIG. 3. This architecture comprises a business application 10 which is responsible for creating the signature requests. This component is hosted by the requesting entity 40. The request manager 41 is a component of the server which hosts the signature requests and the attached documents. This component is hosted by the requesting entity 40. The consent page 43 is an HTML application which guides the signer 30 throughout the consent process and the creation of the signature. This component resides in the web browser 11 of the signer 30. The evidence manager 45 is a server component which collects the signature proofs. This component is hosted by the signature provider 50 (LEX PERSONA). The system further comprises a local native application 47 which can be installed on a fixed office computer or on a smartphone and which accesses the cryptographic key of the signer to sign the documents. This component runs on the signer's computer or on their smartphone.
[44] La figure 4 illustrant un flux simplifié de ce mode de signature locale. Dans ce mode de signature locale, une fois que la page de consentement 43 montre les documents au signataire 30 et demande son consentement, ledit page de consentement 43 ouvre l’application locale bureau/mobile, ladite application locale 47 bureau/mobile demande au signataire 30 de choisir un certificat de signature. L’application locale bureau/mobile récupère le DTBS des documents à signer sur le gestionnaire de demandes 41 et ensuite envoie le DTBS signé au gestionnaire de preuves 45 et lui demande de produire le fichier de preuves. Le fichier de preuves est transféré au gestionnaire de demandes 41 pour générer les documents signés de manière asynchrones. Ensuite, la page de consentement 43 redirige le signataire 30 vers l'application métier 10. Le signataire accède à l'application métier 10, et une fois que les documents signés ont été produits par le gestionnaire de demandes 41, l'application métier 10 les récupère. L'application métier 10 récupère le fichier de preuves et l'archive avec les documents signés.[44] FIG. 4 illustrating a simplified flow of this local signature mode. In this local signature mode, once the consent page 43 shows the documents to the signatory 30 and requests his consent, said consent page 43 opens the local desktop / mobile application, said local desktop / mobile application 47 requests the signer 30 to choose a signing certificate. The local desktop / mobile application retrieves the DTBS of the documents to be signed from the request manager 41 and then sends the signed DTBS to the evidence manager 45 and asks it to produce the evidence file. The evidence file is transferred to the request manager 41 to generate the signed documents asynchronously. Then, the consent page 43 redirects the signer 30 to the business application 10. The signer accesses the business application 10, and once the signed documents have been produced by the request manager 41, the business application 10 get them back. The business application 10 retrieves the evidence file and archives it with the signed documents.
Ouverture de l’application locale bureau/Mobile :Opening of the local desktop / mobile application:
[45] Le signataire 30 passe de la page de consentement 43 à l’application locale 47 bureau/mobile afin de signer avec son jeton cryptographique. Dans ce mode de signature locale, la page de consentement 43 demande du signataire 30 à installer l’application locale 47 sur son bureau ou sur son smartphone ou à l'ouvrir si l’application est déjà installée en transmettant comme paramètres l'ID de demande, l'ID de preuve et un ID d'instance aléatoire. Si la page de consentement 43 est ouverte sur un navigateur Web du bureau, le signataire peut passer à application Mobile sur son smartphone à l'aide d'un code QR.[45] Signer 30 moves from consent page 43 to local desktop / mobile application 47 in order to sign with their cryptographic token. In this local signature mode, the consent page 43 asks the signer 30 to install the local application 47 on his desktop or on his smartphone or to open it if the application is already installed by transmitting the ID of the user as parameters. request, evidence ID, and a random instance ID. If the consent page 43 is opened on a desktop web browser, the signer can switch to the Mobile app on their smartphone using a QR code.
Sinon, l’application locale bureau/mobile est ouverte via un URL personnalisé. Une fois ouverte, l’application locale bureau/mobile appelle le gestionnaire de demandes 41 pour définir l'ÎD d'instance correspondant à l'ID de demande spécifié. Le but est que la page de consentement 43 soit notifiée lorsque l’application locale 47 bureau/mobile a été ouverte. Le gestionnaire de demandes 41 renvoi le JSON de la demande. L’application locale bureau/mobile récupère la liste de documents du gestionnaire de demandes 41 en transmettant l'ID de demande en tant que paramètre. Le gestionnaire de demandes 41 renvoi les JSON des documents. Le signataire 30 est invité à choisir un certificat de signature et ensuite le signataire clique sur le bouton Signer.Otherwise, the local desktop / mobile app is opened via a custom URL. Once opened, the local desktop / mobile application calls the request handler 41 to set the instance ID for the specified request ID. The goal is for the consent page 43 to be notified when the local desktop / mobile application 47 has been opened. The request handler 41 returns the JSON of the request. The local desktop / mobile application retrieves the document list from the request manager 41 by passing the request ID as a parameter. The request manager 41 returns the JSON documents. The signer 30 is prompted to choose a signing certificate and then the signer clicks on the Sign button.
[46] Dans ce mode de signature locale, le gestionnaire de preuves 45 renvoi la chaîne de certificats à l'application locale bureau/mobile. Pour chaque document à signer, l’application locale bureau/mobile envoie la chaîne de certificats au gestionnaire de demandes 41 avec l'ID du document. Le gestionnaire de demandes 41 génère la valeur DTBS et la renvoie à la page de consentement 43. Une fois que toutes les valeurs DTBS ont été générées, l’application locale, bureau/mobile, les signe à l'aide de la clé du signature et les envois au gestionnaire de preuves 45 avec les HMAC et les valeurs de signature. Le gestionnaire de preuves 45 valide les HMAC et les valeurs de signature, puis ajoute le DTBS et les valeurs de signature au fichier de preuves. Le fichier de preuves est exporté au format XML, signé par le gestionnaire de preuves 45 avec un certificat de scellement et renvoyé à l'application locale, bureau/mobile. La page de consentement 43 transmet le fichier de preuves XML. au gestionnaire de demandes 41. Le gestionnaire de demandes 41 valide et stocke le fichier de preuves, modifie le statut de la demande en signé et renvoi une réponse vide à la page de consentement 43. Ensuite, l'application locale, bureau/mobile se ferme et ramène le signataire 30 à la page de consentement 43. |[46] In this local signature mode, the evidence manager 45 sends the certificate chain back to the local desktop / mobile application. For each document to be signed, the local desktop / mobile application sends the certificate chain to the request manager 41 with the document ID. Request handler 41 generates the DTBS value and returns it to the consent page 43. After all DTBS values have been generated, the local, desktop / mobile application signs them using the signing key. and sends to Evidence Manager 45 with HMACs and signature values. Evidence Manager 45 validates HMACs and signature values, then adds DTBS and signature values to the evidence file. The evidence file is exported in XML format, signed by the evidence manager 45 with a seal certificate and returned to the local, desktop / mobile application. The consent page 43 transmits the XML evidence file. to the request manager 41. The request manager 41 validates and stores the evidence file, changes the status of the request to signed and sends an empty response back to the consent page 43. Then, the local, desktop / mobile application is closes and returns signer 30 to consent page 43. |
RevendicationsClaims
Claims (11)
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1912020 | 2019-10-27 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| OA20002A true OA20002A (en) | 2021-08-31 |
Family
ID=
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111277573B (en) | Resource locator with key | |
| US11870902B2 (en) | Authenticating a messaging program session | |
| WO2018131004A9 (en) | Methods and systems for executing smart contracts in secure environments | |
| FR3162089A1 (en) | Secure sharing of identity verification information | |
| EP2279581A1 (en) | Method of secure broadcasting of digital data to an authorized third party | |
| EP3812945B1 (en) | Open and secure system for processing electronic signature request and associated method | |
| EP2301187A1 (en) | Terminal for strong authentication of a user | |
| EP2614458A2 (en) | Method of authentification for access to a website | |
| WO2006021661A2 (en) | Secured authentication method for providing services on a data transmission network | |
| FR3048530A1 (en) | OPEN AND SECURE SYSTEM OF ELECTRONIC SIGNATURE AND ASSOCIATED METHOD | |
| EP3923542A1 (en) | Computer device and method for authenticating a user | |
| EP3928272B1 (en) | Method for processing a payment transaction, and corresponding device, system and programs | |
| FR3035248A1 (en) | SECURE-OPERATING-ON-CHIP SYSTEM AND USES THEREOF | |
| OA20002A (en) | Open and secure electronic signature request processing system and associated method. | |
| EP3673633B1 (en) | Method for authenticating a user with an authentication server | |
| EP3672193A1 (en) | Method and system for authenticating a client terminal by a target server, by triangulation via an authentication server | |
| Marković et al. | One possible model of secure e/m-government system | |
| EP4128700A1 (en) | Method and device for authenticating a user with an application | |
| EP4657299A1 (en) | Method for electronic signature preserving privacy of document to be signed to the electronic signature service | |
| WO2025125562A1 (en) | Method for authenticating an individual for the execution of a transaction on a merchant terminal | |
| WO2022214768A1 (en) | Method for controlling access to goods or services distributed via a data communication network | |
| FR3156939A1 (en) | Method for controlling access of a user of a blockchain to a computer server linked to said blockchain | |
| EP3948596A1 (en) | Method for running secure code, corresponding devices, system and programs | |
| FR2888437A1 (en) | Service e.g. marine meteorological consultation service, access controlling method for e.g. mobile telephone, involves downloading marked validation tokens in multimedia terminal before user chooses service to be utilized | |
| EP3394780A1 (en) | Method and device for connecting to a remote server |