[go: up one dir, main page]

EP3423982A1 - Systeme ouvert et securise de signature electronique et procede associe - Google Patents

Systeme ouvert et securise de signature electronique et procede associe

Info

Publication number
EP3423982A1
EP3423982A1 EP17713441.8A EP17713441A EP3423982A1 EP 3423982 A1 EP3423982 A1 EP 3423982A1 EP 17713441 A EP17713441 A EP 17713441A EP 3423982 A1 EP3423982 A1 EP 3423982A1
Authority
EP
European Patent Office
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.)
Pending
Application number
EP17713441.8A
Other languages
German (de)
English (en)
Inventor
François DEVORET
Julien Pasquier
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Lex Persona
Original Assignee
Lex Persona
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Lex Persona filed Critical Lex Persona
Publication of EP3423982A1 publication Critical patent/EP3423982A1/fr
Pending legal-status Critical Current

Links

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 OR CALCULATING; 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 OR CALCULATING; 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

Definitions

  • the invention relates to the field of electronic signature. More particularly, the invention relates to an open and secure system for signing an electronic document. The invention further relates to a method for preparing and processing a signature request.
  • the electronic signature mainly consists 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 to be incorporated or associated with the document to be signed so as to constitute a proof.
  • 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 to be incorporated or associated with the document to be signed so as to constitute a proof.
  • the sequence of calculation, management and verification tasks necessary for the realization 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 confidence.
  • the data to be signed are not necessarily accessible directly by the signature process but can be remote, that the same data to be signed must be able to be framed by contextual elements such as the date and time of the signature, the signatory certification chain, role, signature location, signature policy, etc.
  • the private key can be on a local or remote cryptographic device of the user, and the environment of these operations is sometimes on the user's workstation, but can also be remote or run in fashion client-server in a web browser, or on a smartphone or tablet.
  • EP 1393144 B1 discloses a method and a web-based system for the legally enforceable signature of documents in a Web environment.
  • the system includes first access means for accessing the web environment from an electronic system, and also includes a plurality of modules.
  • a rendering module of the document for presenting the user with a web representation of the document
  • a legal information module for presenting to the user, in the Web environment, legal information relating to the electronic signature of the document, and to obtain the agreement of the user of this legal information.
  • a document approval module to integrate the user's signature into the document, with the user's consent of the legal information.
  • the system also includes a logging module for generating a log of the signature processes of the document by associating this log of the process with the signed document.
  • 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 mask the complexity of the process to users.
  • the invention therefore aims, on the one hand, to streamline the electronic signature process, to break it down into independent tasks whose interactions between them will be secured by exchange protocols specifically designed for this purpose, and on the other hand, to mask this complexity to the users of the electronic signature and the business applications that want to implement it.
  • an open and secure electronic signature system comprising a business application, developed and executed in various environments, said business application having a programming interface configured to request a signature of a document from a signature manager for a user.
  • the system is characterized in that said business application is able to define a content to be signed, to identify criteria and to select a signatory user, define the use of a type of digital identity, that it is also able to perform a collection of signature properties and require a signature format.
  • Said signature manager is able to coordinate said signature request by performing the following steps: verification of the identity and the authorization of the business application; - verification of the identity of the signing user; - recovery of the document to be signed; - preparation of the signature request with fingerprint calculations of the data to be signed, via signature servers; sending a notification of the signature request via a notification server to the signature services of the user.
  • the user by means of said signature services, is able to 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 said signature manager by the business application in question. view of the encryption of the fingerprint of the data to be signed.
  • the signature manager is able to identify the identity of the signing user by means of a user directory managed by said signature manager. Data fingerprint calculations are performed either by a signature server or by a reverse signature server.
  • the signature manager is also able to retrieve the signatures made and to send said signatures to the business application.
  • the notification server being configured to notify said business application of the arrival of said signatures beforehand.
  • the system further comprises timestamped and archived log files, in which the steps of the signature transaction are written.
  • the signature manager is configured to manage said log files so as to constitute a proof file for each signature transaction.
  • the signature service is a light and downloadable software component on a device of the user and in that said device is a PC and / or a Mac and / or a tablet and / or a smartphone of said user .
  • the system further comprises a personal signature manager belonging to the user and that the business application is able to make a signature request from said personal signature manager.
  • Said personal signature manager runs on a device of said user so as to allow said user to sign a document in local mode when there is no available internet connection or that the signature manager is not usable in this context.
  • the system further comprises a local signature creation device in the form of a hardware or software component, and / or a remote signature creation device and that the user is able to sign.
  • the document is using the local signature creation device using the hardware component, such as a cryptographic device, or the software component, such as a software certificate accessible on the user's device, or using the remote signature creation device, said remote signature creation device being able to incorporate a certificate generated on the fly, during a displacement of said user.
  • said certificates generated on the fly are generated so that they have a security level compliant with the requirements formulated in the signature request sent by the business application and that they are able to perform the encryption of the application. the fingerprint of the data to be signed by an associated private key.
  • the business application accesses the data to be signed, said data to be signed are located either in the local environment of said business application, or in the network environment of said business application (10) .
  • the local signature creation device is in the form of a cryptographic chip or a software certificate, the user locally accesses said local signature creation device from his device, said device being a workstation, or a smartphone or tablet.
  • the remote signature creation device is characterized in that it is located in the network environment of the signature manager and contains a certificate generated on the fly, and that the system includes an infrastructure. Key management key capable of generating said certificate on the fly, and in that the private key associated with said certificate on the fly is generated and stored securely by the signature servers.
  • the signature manager by means of the notification server is able to notify the signature request of the document to the signature services of the user and the notification server is associated with an execution environment of said services. of signatures.
  • the signature service is configured to register with the notification server associated with its execution environment and is able to communicate with the signature manager to indicate to him that he knows the information enabling auditing. signature manager to notify it.
  • the invention also relates to a method for preparing and processing a signature application, by a business application, of a document with a signature manager for a user, registered and identified with said manager of a signature, said method being implemented in the system described above and comprises the following steps: connection of a user to the business application to sign document;
  • a signature request to said signature manager by the business application, said request includes content to be signed, criteria for identifying and selecting the signatory user, a type of digital identity to be used, performs a collection of signature properties and requires a signature format;
  • FIG. 1 illustrates the general architecture of the system according to the present invention
  • FIG. 2 illustrates the steps of the method implemented in the system according to the invention
  • Figure 1 represents the general architecture of the system according to the present invention. This architecture represents, on the one hand, the environment 1 of a user 30 of the system and, on the other hand, the internet environment 2 of a signature manager 40.
  • a user 30 is a natural person who wishes or must sign a or several documents.
  • the architecture of the system as shown in Figure 1 comprises a business application 10, said business application can be developed and executed in various environments such as web servers, Internet browsers, in a native PC or Mac environment , or from a mobile phone or tablet.
  • the business application is at the origin of the signature process, thus, any request for signature, whether made at the initiative of the signatory user himself, or whether it is carried out by a third party. to sign a document, must necessarily go through this business application 10.
  • Said application 10 is designed so that it is able to make a request for signing a document 20 with a signature manager 40 for a user 30.
  • the business application 10 contains a programming interface 42, developed with specific libraries, enabling it to communicate with the signature manager 40.
  • the purpose of the business application 10 is to define the specification of the signature or signatures to be made, ie defining a content to be signed, criteria for identifying and selecting a signatory user 30, a type of digital identity to be used, performs r a collection of signature properties, require a signature format.
  • the business application 10 submits this signature request to the central component of the system, namely the signature manager 40.
  • the role of the signature manager 40 is to process a request for signature of the business application 10 and to coordinate its execution by following the following steps: verification of the identity and the authorization of the business application 10, taking into account the request, identification of the signatory user 30, recovery of the document 20 to sign indicated by the business application, preparation of the signature request with the fingerprint calculation of the data to be signed, via a signature server 50 or 51, notification of the signature request, via a notification server 70 to all the signature services 60 of the user 30, and finally making available the result of the operations with the business application 10.
  • Said signature manager 40 verifies the identity of the signatory user 30 at the through a user directory 41.
  • Said user directory 41 is associated and managed by a set of signature managers 40.
  • the document or documents 20 to be signed may be located in the local environment of the business application 10 called "local DTBS" 21 (the local data to be signed) generally on a device of the user, and accessible locally by this one; in this case, it is the responsibility of the business application 10 to retrieve this data to compose the signature request to be sent to the signature manager 40.
  • the documents to be signed may also be located in the network environment of the business application 10 called "DTBS remote" 22 (the remote data to be signed), typically in a GED (electronic document management tool) to which the business application 10 accesses, which will thus be able to upload this data to the signature manager 40.
  • the signature manager 40 After the recovery of the document (s) 20 to be signed by the signature manager 40, the latter prepares the signature request (s) with the fingerprint calculations of the data to be signed, namely the content of the document (s) as well as the properties. These fingerprint calculations of the data are performed either by a signature server 50 or by an inverse signature server 51.
  • the system comprises a signature creation device 61, it is a hardware or software component that can perform the encryption of the fingerprint data to be signed by the private key associated with the certificate of the user signatory 30.
  • Said signature creation device 61 may be located in the local environment of the user 30 and be accessible only by the latter, typically in the form of a cryptographic device (smart card, cryptographic USB token) or a software certificate accessible locally from the user's workstation or from his mobile terminal (smartphone, tablet).
  • the signature creation device 61 may also be located in the network environment of the signature manager 40, referenced 62 in the figure, typically in the form of a certificate generated on the fly by a key management infrastructure. Indeed, the signature manager 40 can instruct said key management infrastructure to generate this certificate on the fly.
  • the private key associated with said user's on-the-fly certificate is generated and securely stored by the signature servers.
  • the idea is, at each signature, to generate a "certificate on the fly” or “single use” valid for a single use.
  • the signature server 50 is a centralized signature server to which the signature manager 40 sends a signature request.
  • a typical example of the signature server 50 is the LP7SignBox software developed by the company Lex Persona (applicant), but it could be envisaged to access other signature servers complying, for example, with the OASIS DSS protocol (signature service). digital).
  • the reverse signature server 51 is a decentralized signature server called by the signature manager 40 to compose the signature in a desired format, for example, for the signatures, according to the formats: CAdES, PAdES, XAdES, etc. Said reverse signature server 51 is also able to calculate the hash of the data to be signed in the case of a decentralized signature request.
  • This fingerprint will be sent by the signature manager 40 to the signature service 60 of the user 30.
  • the signature service 60 uses a signature creation device 61 to encrypt the fingerprint with the private key and returns the result of the signature. generated signature signature manager 40 which in turn transmits it to the reverse signature server 51 which then finalizes the composition of the signature.
  • a typical example of a reverse signing server that offers the above functionality is the LP7SignBox software developed by Lex Persona (Applicant). This case is particularly suitable for the decentralized signature with a local signature creation device 61 in the form of a cryptographic device produced from a mobile terminal of the user (smartphone or tablet).
  • the signature manager 40 notifies the signature services 60 of the signing user 30 by means of a notification server 70 in order to notify said user to sign the document or documents 20.
  • the manager signature 40 sends notifications to the notification servers (push) 70 associated with the signature services 60 of the user 30. It is therefore necessary for a signature service 60 to be able to register, as soon as it is launched, with the server 70 push notification associated with its execution environment for example: GCM for Android, APN for Apple, WNS for Windows, etc.
  • the signature service 60 associated with the device of the user, then communicates to the signature managers 40 that he knows, the information that will allow them to notify it.
  • a signature service 60 therefore has a configuration file containing the list of signature managers 40 with which it can declare itself.
  • a signature service 60 is a universal personal application, which allows the user 30 to control the execution of the signature process, namely the activation of the private key corresponding to one of the certificates of the user 30 meeting the selection criteria sent to the signature manager 40 by the business application 10, for the purpose of encrypting the fingerprint of the data to be signed. Due to the separation between the business application 10, to which the signatory user 30 generally has access, and the signature service 60, the signature service 60 may be qualified as a companion application.
  • the signature service 60 is a software component that is as light as possible so that it can be downloaded quickly and take up the least possible space on the user's device 30.
  • the user interface of the signature service 60 is very simple and intuitive with a graphic identity as general as possible.
  • the signature service 60 is able to sign in local mode.
  • an Internet connection may be absent for a longer or shorter time, in which case the signature service 60 is able to finalize the signature without an Internet connection, or automatically as soon as the Internet connection is available. new effective.
  • a user 30 may have several signature services 60, so it is for example possible for the user 30 to sign with a local signature-creation device 61, from his Windows or Mac workstation when he is at home. his office, using a hardware component (smart card) or software (certificate), or to sign from his smartphone when on the move, with a remote signature creation device 62 in the form a certificate generated on the fly. Only if the security level of the certificate on the fly complies with the requirements formulated in the signature request sent by the business application 10 to the signature manager 40.
  • the signature manager 40 is capable of recovering the signature (s) once that (s) -ci performed (s) and, in the case of wraparound or enveloped signatures, it proceeds to the formatting of the (s) signatures made. It is also able to make available to the business application 10 the result of the operations performed or errors possibly encountered. Indeed, all the steps of the signature operations managed by the signature manager 40 are written in newspapers. The logs are time stamped and archived to form a complete and secure proof file for each signature transaction.
  • the business application 10 may submit the signature request to a personal signature manager, not shown in the figure.
  • Said personal signature manager is personal in that it is in the local environment of the user and in that it executes on his personal workstation, whatever the typology of said workstation, tablet, smartphone ... Said personal signature manager is able to perform and coordinate all steps of the signature process like the signature manager. It should be noted that the personal signature manager can also be requested by the application even if the user has an Internet connection to sign it directly without going through a signature manager.
  • the user directory 41 is associated and managed by a set of signature managers 40.
  • the users can be of three categories.
  • the business application will signify to the signature manager that it already knows the user, which is anonymous for the signature manager, but not for the business application.
  • the business application may be responsible for launching the user's signature service and sending the signature request to the personal signature manager that can be packaged with the signature service. Possibly, if the user already has an account on a signature manager of his choice, he can log in to possibly retrieve different information and credit his account of the signature that will be made.
  • Each qualified user has the following data: User ID, SHA256 fingerprint of the user's password, last name and / or alias, date of birth, telephone number on which it is possible to send messages. short, Mail address, pushTokenIDs corresponding to the devices on which it is possible to notify the user when it is the subject of a signature request, user certificates and reference of the associated signature creation device. Some of this data is optional and may not be in the directory.
  • This user directory 41 will enable a signature manager 40 to identify the signatory designated by a signature request sent to it by a business application 10, to select the appropriate certificate corresponding to the signature request, from access the user's pushTokenIDs for notifying the user, notifying that user that he is the subject of a signature request on the various signature services capable of processing the signature request.
  • the system includes a directory of signature managers. Indeed, from the moment when it is possible to have different signature managers each able to process requests for signatures from different business applications, it is possible to give the possibility to a business application to send a request for a signature. signing not to a specific signature manager, but to query a signature manager directory in order to be able to identify the most appropriate signature manager to process the request. Also, if for example a business application allows a user to report tax on the company, it might be convenient for the business application to query a directory of signature managers to select the "national" signature manager that will allow the company to declare its tax in the country of the company.
  • the IGC server designates a server Public Key Management Infrastructure. Its role is to deliver certificates to users on the fly and whose associated private keys are stored securely by a signature server that will perform the signature requests that will be assigned to it.
  • a timestamp authority (TSA: Time StampAuthority) issuing timestamp tokens.
  • TSA Time StampAuthority
  • certain modules require the possibility of calling on a time stamp, such as the writing of all the steps of the signature transaction in timestamped logs or the time stamp of the electronic signatures generated. .
  • FIG. 2 represents the various steps of the method for preparing and processing a signature request, by a business application 10, of a document 20 with a signature manager 40 for a registered user 30. and identified with said signature manager 40, implemented in the system of the invention and comprising the steps below. Each step corresponds to one or more numbers represented by arrows.
  • said request includes content to be signed, identification and selection criteria of the signatory user, a type of digital identity to use , signature properties and a signature format, (arrow 8).
  • the document to be signed may be accessible to the user locally, on his workstation, or remotely, in a network environment.
  • the signature creation device can be accessible locally, in the form of a smart card for example, or remotely, in the network environment of the system, in the form of a signature server with generation certificate on the fly.
  • the signature manager can be accessed locally or via the network. The skilled person will choose one or the other of the different possibilities according to the economic, ergonomic, dimensional or other constraints that must be respected.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • Bioethics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Système ouvert et sécurisé de signature électronique comprenant une application métier (10), ladite application métier comportant une interface de programmation (42) configurée à effectuer une demande de signature d'un document (20) auprès d'un gestionnaire de signature (40) pour un utilisateur (30), le système est caractérisé en ce que ladite application métier (10) est apte à définir un contenu à signer, à identifier des critères et à sélectionner un utilisateur signataire (30), à définir l'utilisation d'un type d'identité numérique, à effectuer une collecte des propriétés de signature et à exiger un format de signature. Le 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érification de 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'empreintes des données à signer, - envoi d'une notification de la demande de signature à des services de signatures (60) de l'utilisateur (30). L'utilisateur (30), au moyen desdits services de signatures (60), est apte à contrôler l'exécution du 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 audit gestionnaire de signature (40) par l'application métier (10) 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 ET
PROCEDE ASSOCIE
DOMAINE TECHNIQUE DE L'INVENTION
[0001] L'invention se rapporte au domaine de la signature électronique. Plus particulièrement, l'invention concerne un système ouvert et sécurisé pour signer un document électronique. L'invention concerne en outre un procédé d'élaboration et de traitement d'une demande de signature.
ETAT DE LA TECHNIQUE ANTERIEURE
[0002] 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.
[0003] Par ailleurs, l'enchainement 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, que 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 client-serveur dans un navigateur Web, ou encore sur un smartphone ou une tablette.
[0004] 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. EXPOSE DE L'INVENTION
[0005] L'invention a donc pour objet, d'une part, de rationaliser le processus de signature électronique, pour le décomposer en tâches indépendantes dont les interactions entre elles seront sécurisées par des protocoles d'échanges spécifiquement conçus à cet effet, et, d'autre part, de masquer cette complexité aux utilisateurs de la signature électronique et aux applications métiers qui souhaitent la mettre en œuvre. 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 des environnements variés, ladite application métier comportant une interface de programmation configurée à effectuer une demande de signature d'un document auprès d'un gestionnaire de signature pour un utilisateur. Le système est caractérisé en ce que ladite application métier est apte à définir un contenu à signer, à identifier des critères et à sélectionner un utilisateur signataire, à définir l'utilisation d'un type d'identité numérique, qu'elle est en outre apte à effectuer une collecte des propriétés de signature et à exiger un format de signature. Ledit gestionnaire de signature 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 ; - vérification de l'identité de l'utilisateur signataire ; - récupération du document à signer ; - préparation de la demande de signature avec les calculs d'empreintes des données à signer, via des serveurs de signature ; - envoi d' une notification de la demande de signature via un serveur de notification à des services de signatures de l'utilisateur. L'utilisateur au moyen desdits 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.
[0006] Selon des caractéristiques particulières, le gestionnaire de signature est apte à identifier l'identité de l'utilisateur signataire au moyen d'un annuaire d'utilisateurs géré par ledit gestionnaire de signature. Les calculs d'empreintes des données sont effectués soit par un serveur de signature, soit par un serveur de signature inverse. Le gestionnaire de signature est, en outre, apte à récupérer les signatures effectuées et à envoyer lesdites signatures à l'application métier. Le serveur de notification étant configuré pour notifier préalablement ladite application métier de l'arrivé desdits signatures.
[0007] Selon des caractéristiques particulières, le système comprend en outre des fichiers journaux horodatés et archivés, dans lesquels sont écrites les étapes de la transaction de signature. Le gestionnaire de signature est configuré à gérer lesdits fichiers journaux de sorte à constituer un dossier de preuve pour chaque transaction de signature.
[0008] De préférence, le service de signature est un composant logiciel léger et téléchargeable sur un périphérique de l'utilisateur et en ce que ledit périphérique est un PC et/ou un Mac et/ou une tablette et/ou un smartphone dudit utilisateur.
[0009] Selon des caractéristiques particulières, le système comprend en outre un gestionnaire de signature personnel appartenant à l'utilisateur et que l'application métier est apte à effectuer une demande de signature auprès dudit gestionnaire de signature personnel. Ledit gestionnaire de signature personnel s'exécute sur un périphérique dudit utilisateur de sorte à permettre audit utilisateur de signer un document en mode local lorsqu'il n'y a pas de connexion internet disponible ou que le gestionnaire de signature n'est pas utilisable dans ce contexte.
[0010] Selon des caractéristiques particulières, le système comprend en outre un dispositif de création de signature local sous forme d'un composant matériel ou logiciel, et/ou un dispositif de création de signature à distance et que l'utilisateur est capable à signer le document soit à l'aide dudit dispositif de création de signature local en utilisant le composant matériel, tel qu'un dispositif cryptographique, ou le composant logiciel, tel qu'un certificat logiciel accessible sur le périphérique de l'utilisateur, soit à l'aide du dispositif de création de signature à distance, ledit dispositif de création de signature à distance étant apte à incorporer un certificat généré à la volée, lors d'un déplacement dudit utilisateur.
[0011] Avantageusement, lesdits certificats générés à la volée sont générés de sorte qu'ils ont un niveau de sécurité conforme aux exigences formulées dans la demande de signature envoyée par l'application métier et qu'ils sont apte à effectuer le chiffrement de l'empreinte des données à signer par une clé privée associée.
[0012] Selon des caractéristiques particulières, l'application métier accède aux données à signer, lesdites données à signer sont situées soit dans l'environnement local de ladite l'application métier, soit dans l'environnement réseau de ladite application métier (10).
[0013] Selon des caractéristiques particulières, le dispositif de création de signature local est sous la forme d'une puce cryptographique ou d'un certificat logiciel, l'utilisateur accède localement audit dispositif de création de signature local depuis son périphérique, ledit périphérique étant un poste de travail, ou un smartphone ou une tablette.
[0014] Selon des caractéristiques particulières, le dispositif de création de signature à distance est caractérisé en ce qu'il est situé dans l'environnement réseau du gestionnaire de signature et contient un certificat généré à la volée, et que le système comprend une infrastructure de gestion de clés apte à générer ledit certificat à 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 de signatures. [0015] De préférence, le gestionnaire de signature au moyen du serveur de notification est apte à notifier la demande de signature du document aux services de signatures de l'utilisateur et que le serveur de notifications est associé à un environnement d'exécution desdits services de signatures.
[0016] De préférence, le service de signature est configuré à s'enregistrer auprès du serveur de notification associé à son environnement d'exécution et est apte à communiquer avec le gestionnaire de signature afin de lui indiquer qu'il connaît les informations permettant audit gestionnaire de signature de le notifier.
[0017] L'invention concerne encore un procédé d'élaboration et de traitement d'une demande de signature, par une application métier, d'un document auprès d'un gestionnaire de signature pour un utilisateur, inscrit et identifié auprès dudit gestionnaire de signature, ledit procédé étant mis en œuvre dans le système décrit ci-dessus et comprend les étapes suivantes : connexion d'un utilisateur à l'application métier pour signer document ;
- récupération par l'application métier du document à signer ;
- interrogation du gestionnaire de signature par l'application métier afin d'identifier l'utilisateur qui doit signer le document ;
- envoi d'une demande de signature audit gestionnaire de signature par l'application métier, ladite demande comprend un contenu à signer, des critères d'identification et de sélection de l'utilisateur signataire, un type d'identité numérique à utiliser, elle effectue une collecte des propriétés de signature et exige un format de signature ;
- coordination des étapes de la transaction de la signature par le gestionnaire de signature comprenant les étapes suivantes :
- vérification de l'identité et de l'habilitation de l'application métier ;
- vérification de l'identité de l'utilisateur signataire ;
- récupération dudit document à signer auprès de l'application métier; - préparation de la demande de signature avec le calcul de l'empreinte des données à signer, via des serveurs de signatures ;
- envoi d'une notification de la demande de signature à un service de signature de l'utilisateur via un serveur de notification ;
- contrôle de l'exécution du processus de signature par le service de signature, en activant une 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 ;
- horodatage et sauvegarde des événements de la transaction dans des journaux ;
- envoi à l'application métier du résultat des opérations après notification, ou des erreurs éventuellement rencontré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 des opérations.
BREVE DESCRIPTION DES FIGURES
[0018] 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 : la figure 1 illustre l'architecture générale du système selon la présente invention;
la figure 2 illustre les étapes du procédé mis en œuvre dans le système selon l'invention ;
[0019] Pour plus de clarté, les éléments identiques ou similaires sont repérés par des signes de référence identiques sur l'ensemble des figures.
DESCRIPTION DETAILLEE [0020] La figure 1 représente l'architecture générale du système selon la présente invention. Cette architecture représente d'une part, l'environnement 1 d'un utilisateur 30 du système et d'autre part l'environnement internet 2 d'un gestionnaire de signature 40. Un utilisateur 30 est une personne physique qui souhaite ou doit signer un ou plusieurs documents.
[0021] 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.
[0022] L'architecture du système telle que représentée sur la figure 1 comprend une application métier 10, ladite application métier 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 10 est conçue de sorte qu'elle est apte à effectuer une demande de signature d'un document 20 auprès d'un gestionnaire de signature 40 pour un utilisateur 30. Pour ce faire, l'application métier 10 contient une interface de programmation 42, développée avec des librairies spé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 des charges de la ou des signatures à effectuer, soit définir un contenu à signer, des critères d'identification et de sélection d'un utilisateur signataire 30, un type d'identité numérique à utiliser, effectuer une collecte des propriétés de signature, exiger un format de signature. [0023] L'application métier 10 soumet cette demande de signature au composant central du système, à savoir le gestionnaire de signature 40. Le rôle du gestionnaire de signature 40 est de traiter une demande de signature de l'application métier 10 et de coordonner son exécution en suivant les étapes suivantes : 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éparation de la demande de signature avec le calcul d'empreinte des données à signer, via un serveur de signature 50 ou 51 , notification de la demande de signature, via un serveur de notification 70 à tous les services de signatures 60 de l'utilisateur 30, et enfin 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 30 au moyen d'un annuaire d'utilisateurs 41 . Ledit annuaire d'utilisateurs 41 est associé et géré par un ensemble de gestionnaires de signatures 40.
[0024] Le ou les documents 20 à signer peuvent être situés dans l'environnement local 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 localement par celui-ci ; dans ce cas il est du ressort de l'application métier 10 de récupérer ces données pour composer la demande de signature à envoyer au gestionnaire de signature 40. Les documents à signer peuvent aussi être situés dans l'environnement réseau de l'application métier 10 appelés « DTBS remote >> 22 (les données à distance à signer), typiquement dans une GED (outil de gestion électronique de documents) à laquelle accède l'application métier 10 qui pourra ainsi téléverser ces données au gestionnaire de signature 40.
[0025]Après la récupération du ou des document(s) 20 à signer par le gestionnaire 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 des document(s) ainsi que les propriétés. Ces calculs d'empreintes des données sont effectués soit par un serveur de signature 50, soit par un serveur de signature inverse 51 .
[0026] Le système comprend un dispositif de création de signature 61 , il s'agit d'un composant matériel ou logiciel qui permet d'effectuer le chiffrement de l'empreinte des données à signer par la clé privée associée au certificat de l'utilisateur signataire 30. Ledit dispositif de création de signature 61 peut être situé dans l'environnement local de l'utilisateur 30 et être accessible uniquement par celui-ci, typiquement sous la forme d'un dispositif cryptographique (carte à puce, token USB cryptographique) ou d'un certificat logiciel accessibles localement depuis le poste 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é dans l'environnement réseau du gestionnaire de signature 40, référencé 62 sur la figure, typiquement sous la forme d'un certificat généré à la volée par une infrastructure de gestion de clés. En effet, le gestionnaire de signature 40 peut donner l'instruction à ladite infrastructure de gestion de clés de générer ce certificat à 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 serveurs de signatures. L'idée est donc, à chaque signature, de générer un « certificat à la volée >> ou « à usage unique >> valable pour une seule utilisation.
[0027] Le serveur de signature 50 est un serveur de signature centralisé auquel le gestionnaire de signature 40 adresse une demande de signature. Un exemple typique du serveur de signature 50 est le logiciel LP7SignBox développé par la socié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).
[0028] 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 un format 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 demande de signature décentralisée. Cette empreinte sera envoyée par le gestionnaire de signature 40 au service de signature 60 de l'utilisateur 30. Le service de signature 60 utilise alors un dispositif de création de signature 61 pour chiffrer l'empreinte avec la clé privée et retourne le résultat de la signature générée au gestionnaire de signature 40 qui la transmet à son tour au serveur de signature inverse 51 qui finalise alors la composition de la signature. Un exemple typique d'un serveur de signature inverse qui offre la fonctionnalité ci-dessus est le logiciel LP7SignBox dé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 sous la forme d'un dispositif cryptographique réalisée depuis un terminal mobile de l'utilisateur (smartphone ou tablette).
[0029] Par ailleurs, le gestionnaire de signature 40 notifie les services de signatures 60 de l'utilisateur signataire 30 au moyen d'un serveur de notification 70 afin de notifier ledit utilisateur de signer le ou les documents 20. Pour cela, le gestionnaire de signature 40 envoie des notifications sur les serveurs de notification (push) 70 associés aux services de signatures 60 de l'utilisateur 30. Il est donc nécessaire qu'un service de signature 60 puisse s'enregistrer, dès son lancement, auprès du serveur de notification (push) 70 associé à son environnement 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 de l'utilisateur, communique ensuite, aux gestionnaires de signatures 40 qu'il connaît, les informations qui leurs permettront de le notifier. Un service de signature 60 dispose donc d'un fichier de configuration contenant la liste des gestionnaires de signatures 40 auprès desquels il pourra se déclarer.
[0030] Un service de signature 60 est une application personnelle universelle, qui permet à 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 de l'utilisateur 30 répondant aux critères de sélection envoyés au gestionnaire de signature 40 par l'application métier 10, en vue du chiffrement de l'empreinte des données à signer. Du fait de la séparation entre l'application métier 10, à laquelle l'utilisateur signataire 30 a généralement accès, et le service de signature 60, on pourra 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 possible afin qu'il puisse être téléchargé rapidement et prendre le moins de place possible sur le périphérique de l'utilisateur 30. L'interface utilisateur du service de signature 60 est très simple et intuitive avec une identité graphique la plus générale possible. Le service de signature 60 est capable de signer en mode local. En effet dans un environnement Mobile, une connexion Internet peut être absente pendant un instant plus ou moins long, dans ce cas, le service de signature 60 est capable de finaliser la signature sans connexion Internet, ou bien automatiquement dès que la connexion Internet sera de nouveau effective. [0031] Un utilisateur 30 peut posséder plusieurs services de signatures 60, ainsi il est par exemple possible pour l'utilisateur 30 de signer avec un dispositif de création de signature local 61 , depuis son poste de travail Windows ou Mac lorsqu'il est à son bureau, à l'aide d'un composant matériel (carte à puce) ou logiciel (certificat), ou bien de signer depuis son Smartphone lorsqu'il est en déplacement, avec un dispositif de création de signature à distance 62 sous la forme d'un certificat généré à la volée. A la seule condition que le niveau de sécurité du certificat à la volée soit conforme aux exigences formulées dans la demande de signature envoyée par l'application métier 10 au gestionnaire de signature 40.
[0032] Le gestionnaire de signature 40 est capable de récupérer la ou des signatures une fois celle(s)-ci effectuée(s) et, dans le cas de signatures enveloppantes ou enveloppées, il procède à la mise en forme de la ou des signatures effectuées. Il est par ailleurs apte à mettre à disposition de l'application métier 10 le résultat des opérations effectuées ou bien des erreurs éventuellement rencontrées. En effet, toutes les étapes des opérations de signatures gérées par le gestionnaire de signature 40 sont écrites dans des journaux. Lesdits journaux sont horodatés et archivés afin de constituer un fichier de preuve complet et sécurisé pour chaque transaction de signature.
[0033] Dans certain cas il peut être nécessaire pour un utilisateur de signer un ou plusieurs documents alors qu'aucune connexion Internet n'est disponible ou que le gestionnaire de signature n'est pas utilisable, on parlera dans ce cas de signature en mode local. De tels cas peuvent se présenter lorsqu'il est nécessaire de signer lors d'un déplacement ou bien dans le cas où il n'y a pas de connexion Internet ou l'absence du réseau. Dans ce cas, selon la présente invention, l'application métier 10 pourra soumettre la demande de signature auprès d'un gestionnaire de signature personnel, non représenté sur la figure. Ledit gestionnaire de signature personnel est personnel en ce qu'il est dans l'environnement local de l'utilisateur et en ce qu'il s'exécute sur son poste de travail personnel, quelle que soit la typologie dudit poste de travail, tablette, smartphone... Ledit gestionnaire de signature personnel est apte à effectuer et à coordonner toutes les étapes du processus de signature à l'instar du gestionnaire de signature. Il est à noter que le gestionnaire de signature personnel peut également être sollicité par l'application métier même si l'utilisateur dispose d'une connexion Internet afin de le faire signer de manière directe sans passer par un gestionnaire de signature.
[0034] L'annuaire des utilisateurs 41 est associé et géré par un ensemble de gestionnaires de signature 40. Les utilisateurs peuvent êtres de trois catégories. L'utilisateur « Anonyme >> : Cet utilisateur est unique par gestionnaire de signature 40, 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é par le gestionnaire de signature 40.
[0035] Dans le cas d'une application métier qui souhaite faire signer immédiatement l'utilisateur qui est en train de l'utiliser, il n'est pas nécessaire d'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 au gestionnaire de signature qu'elle connaît déjà l'utilisateur, qui est anonyme pour le gestionnaire 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 de l'utilisateur et d'envoyer la demander de signature au gestionnaire de signature personnel 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 son choix, il pourra se connecter pour éventuellement récupérer différentes informations et créditer son compte de la signature qui sera effectuée.
[0036] Dans le cas d'une application métier qui souhaite faire signer immédiatement l'utilisateur, sans qu'il soit nécessaire de bénéficier d'un utilisateur déjà référencé par le gestionnaire de signature utilisé (« signature rapide >> ), on fait confiance à priori à l'utilisateur qui répond à certains critères, alors l'application mé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éphone portable, etc.). Eventuellement, si l'utilisateur dispose déjà d'un compte sur le gestionnaire de signature spécifié par l'application métier, il pourra se connecter pour éventuellement récupérer différentes informations et créditer son compte de la signature qui sera effectuée.
[0037] Dans le cas d'une application métier qui souhaite faire signer immédiatement un utilisateur qu'elle connaît comme étant défini et authentifié par le gestionnaire de signature, alors elle pourra spécifier un 'utilisateur Qualifié'. L'utilisateur devra alors s'authentifier sur le gestionnaire de signature sollicité par ladite application métier pour signer le ou les documents.
[0038]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 des messages courts, Adresse Mail, pushTokenIDs correspondants aux dispositifs sur lequel il est possible de notifier l'utilisateur lorsqu'il fait l'objet d'une demande de signature, 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 pas figurer dans l'annuaire. Cet annuaire d'utilisateurs 41 va permettre à un gestionnaire de signature 40 d'identifier le signataire désigné par une demande de signature qui lui a été adressée par une application métier 10, de sélectionner le certificat approprié correspondant à la demande de signature, d'accéder aux pushTokenIDsde l'utilisateur permettant de le notifier, de notifier cet utilisateur qu'il fait l'objet d'une demande de signaturesur les différents services de signature capables de traiter la demande de signature.
[0039] Dans le système de l'invention, trois autres modules sont présents mais n'apparaissent pas sur la figure 1 pour des raisons de lisibilité. Ainsi, le système comprend un annuaire de gestionnaires de signatures. En effet, à partir du moment où il est possible d'avoir différents gestionnaires de signature capables chacun de traiter des demandes de signatures en provenance de différentes applications métiers, il est possible de donner la possibilité à une application métier d'envoyer une demande de signature non pas à un gestionnaire de signature déterminé, mais d'interroger un annuaire de gestionnaires de signature afin 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 à un utilisateur de déclarer l'impôt sur la société, il pourrait être pratique à l'application métier d'interroger un annuaire de gestionnaires de signatures afin de sélectionner le gestionnaire de signature « national » qui permettra à l'entreprise de déclarer son impôt dans le pays de l'entreprise.
[0040] 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 serveur d'Infrastructure de Gestion de Clés publiques. Son rôle est de délivrer des certificats à la volée aux utilisateurs et dont les clés privées associées sont stockées de manière sécurisée par un serveur de signature qui réalisera les demandes de signature qui lui seront affectées.
[0041] Enfin un dernier module concerne une autorité d'horodatage (TSA : Time StampAuthority) délivrant des jetons d'horodatage. En effet, dans le système de l'invention, certains modules nécessitent la possibilité de faire appel à un horodatage, telle que l'écriture de toutes les étapes de la transaction de signature dans des journaux horodatés ou encore l'horodatage des signatures électroniques générées.
[0042] La figure 2 représente les différents étapes du procédé d'élaboration et de traitement d'une demande de signature, par une application métier 10, d'un document 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 le système de l'invention et comprenant les étapes ci-dessous. Chaque étape correspond à 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 document 20 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 afin d'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 par l'application métier 10, ladite demande comprend un contenu à signer, des critères d'identification et de sélection de l'utilisateur signataire, un type d'identité numérique à utiliser, des propriétés de signature et un format de signature, (flèche n° 8).
- Coordination des étapes de la transaction de la signature par le gestionnaire de signature 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, 10 ou 1 1 , 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 et
16).
- 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 audit gestionnaire 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).
[0043] De nombreuses combinaisons peuvent être envisagées sans sortir du cadre de l'invention ; par exemple, le document à signer peut être accessible à l'utilisateur localement, sur son poste de travail, ou bien à distance, dans un environnement réseau. De même, le dispositif de création de signature peut être accessible 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 de signature avec génération de certificat à la volée. Aussi, le gestionnaire de signature peut être accessible localement ou via le réseau. L'homme de métier choisira l'une ou l'autre des différentes possibilités en fonction des contraintes économiques, ergonomiques, dimensionnelles ou autres qu'il devra respecter.

Claims

REVENDICATIONS
1 . Système ouvert et sécurisé de signature électronique comprenant une application métier (10), développée et exécutée dans des environnements variés, ladite application métier (10) comportant une interface de programmation (42) configurée à effectuer une demande de signature d'un document (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 un contenu à signer, à identifier des critères et à sélectionner un utilisateur signataire (30), à définir l'utilisation d'un type d'identité numérique, qu'elle est en outre apte à effectuer une collecte des propriétés de signature et à exiger un format 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érification de 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'empreintes des données à signer, via des serveurs de signature (50, 51 ), - envoi d' une notification de la demande de signature via un serveur de notification (70) à des services 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écution du 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 audit gestionnaire de signature (40) par l'application métier (10) en vue du chiffrement de l'empreinte des données à signer.
2. Système selon la revendication 1 caractérisé en ce que le gestionnaire de signature (40) est apte à identifier l'identité de l'utilisateur signataire (30) au moyen 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 un serveur de signature (50), soit par un serveur de signature inverse (51 ) et en ce que le gestionnaire de signature (40) est en outre apte à récupérer les signatures effectuées et à envoyer lesdites signatures à l'application métier (10), le serveur de notification (70) étant configuré pour notifier préalablement ledit 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 des fichiers journaux horodatés et archivés, dans lesquels sont écrits les étapes de la transaction de signature, et en ce que le gestionnaire de signature (40) est configuré à gérer lesdits fichiers journaux de sorte à constituer un dossier de preuve pour chaque transaction de signature.
4. Système selon la revendication 1 caractérisé en ce que le service de signature (60) est un composant 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 tablette et/ou un smartphone dudit utilisateur.
5. Système selon la revendication 1 caractérisé en ce qu'il comprend en outre un gestionnaire de signature personnel (41 ) appartenant à l'utilisateur (30), en ce que l'application métier (10) est apte à effectuer une demande de signature auprès dudit gestionnaire de signature personnel (41 ), et que ledit gestionnaire de 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 local lorsqu'il n'y a pas de connexion internet disponible ou que le gestionnaire de signature (40) n'est pas utilisable dans ce contexte.
6. Système selon l'une quelconque des revendications précédentes caractérisé en ce qu'il comprend en outre un dispositif de création de signature local (61 ), sous forme d'un composant matériel ou logiciel, et/ou un dispositif de création de signature à distance (62), l'utilisateur (30) est capable à signer le document (20) soit à l'aide dudit dispositif de création de signature local (61 ) en utilisant le composant matériel, tel qu'un dispositif cryptographique, ou le composant logiciel, 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), ledit dispositif de création de signature à distance (62) étant apte à incorporer un certificat 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 certificats générés à la volée sont générés de sorte qu'ils ont un niveau de sécurité conforme aux exigences formulées dans la demande de signature envoyée par l'application métier (10) et qu'ils sont apte à effectuer le chiffrement de l'empreinte des données à signer par une clé privée associée.
8. Système selon l'une des revendications précédentes dans lequel l'application métier (10) accède aux données à signer, lesdites données à signer sont situées soit dans l'environnement local de ladite l'application métier (10), soit dans l'environnement réseau de ladite application métier (10).
9. Système selon la revendication 6 dans lequel le dispositif de création de signature local (61 ) est sous la forme d'une puce cryptographique ou d'un certificat logiciel, l'utilisateur (30) accède localement audit dispositif de création de signature local (61 ) depuis son périphérique, ledit périphérique étant un poste de travail, ou un smartphone ou une tablette.
10. Système selon la revendication 6 caractérisé en ce que le dispositif de création de signature à distance (62) est situé dans l'environnement réseau du gestionnaire de signature (40) et contient un certificat généré à la volée, et que le système comprend une infrastructure de gestion de clés apte à générer ledit certificat à 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 de signatures (50, 51 ).
1 1 . Système selon l'une quelconque des revendications précédente caractérisé en ce que le gestionnaire de signature (40) au moyen du serveur de notification (70) est apte à notifier la demande de signature du document (20) aux services de signatures (60) de l'utilisateur (30), et que le serveur 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 est apte à communiquer avec le gestionnaire de signature (40) afin de lui indiquer qu'il connaît les informations permettant audit gestionnaire de signature de le notifier. Procédé d'élaboration et de traitement d'une demande de signature, par une application métier (10), d'un document (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 le système selon l'une des revendications 1 à 12 comprenant les étapes suivantes :
- connexion de l'utilisateur (30) à l'application métier (10) pour signer le document (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'utilisateur signataire, un type d'identité numérique à utiliser, elle effectue une collecte des propriétés de signature et exige un format de signature ;
- coordination des étapes de la transaction de la signature par le gestionnaire 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 de l'application métier (10) ;
- préparation de la demande de signature avec le calcul de l'empreinte des données à signer via des serveurs de signatures (50, 51 ) ;
- envoi d'une notification de la demande de signature à des services de signatures (60) de l'utilisateur (30) via un serveur de notification (70) ;
- contrôle de l'exécution du processus de signature par les services de signatures (60), en activant une clé privée correspondant à un certificat de l'utilisateur (30) répondant aux critères de sélection envoyés audit gestionnaire 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 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.
EP17713441.8A 2016-03-01 2017-02-28 Systeme ouvert et securise de signature electronique et procede associe Pending EP3423982A1 (fr)

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
PCT/IB2017/051168 WO2017149453A1 (fr) 2016-03-01 2017-02-28 Systeme ouvert et securise de signature electronique et procede associe

Publications (1)

Publication Number Publication Date
EP3423982A1 true EP3423982A1 (fr) 2019-01-09

Family

ID=57045214

Family Applications (1)

Application Number Title Priority Date Filing Date
EP17713441.8A Pending EP3423982A1 (fr) 2016-03-01 2017-02-28 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)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3812945A1 (fr) 2019-10-27 2021-04-28 Lex Persona Système ouvert et sécurisé de traitement de demande de signature électronique et procédé associe

Families Citing this family (6)

* Cited by examiner, † Cited by third party
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
CN112202719B (zh) * 2020-09-04 2022-09-13 广州江南科友科技股份有限公司 基于数字证书的签名方法、系统、装置及存储介质
CN112836227B (zh) * 2021-02-07 2021-11-19 新大陆（福建）公共服务有限公司 一种可信数字身份应用的方法
JP7694085B2 (ja) * 2021-03-22 2025-06-18 富士フイルムビジネスイノベーション株式会社 情報処理装置及び情報処理プログラム
EP4457972A1 (fr) * 2021-12-30 2024-11-06 Cloudpeer Global Teknoloji A. S. Système de signature électronique mobile

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1393144B9 (fr) 2000-12-14 2009-08-12 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
WO2014166519A1 (fr) * 2013-04-08 2014-10-16 Bonsignore Antonio Salvatore Piero Vittorio Système et procédé de signature électronique qualifiée et terminal de traitement mobile pour signature électronique qualifiée

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3812945A1 (fr) 2019-10-27 2021-04-28 Lex Persona Système ouvert et sécurisé de traitement de demande de signature électronique et procédé associe
FR3102589A1 (fr) 2019-10-27 2021-04-30 Lex Persona Système ouvert et sécurisé de traitement de demande de signature électronique et procédé associe

Also Published As

Publication number Publication date
FR3048530A1 (fr) 2017-09-08
FR3048530B1 (fr) 2019-09-06
US20190097811A1 (en) 2019-03-28
WO2017149453A1 (fr) 2017-09-08

Similar Documents

Publication Publication Date Title
FR3048530B1 (fr) Systeme ouvert et securise de signature electronique et procede associe
EP2619941B1 (fr) Procede, serveur et systeme d'authentification d'une personne
US10205723B2 (en) Distributed storage of authentication data
EP2567502A2 (fr) Procede d'authentification d'un utilisateur requerant une transaction avec un fournisseur de service
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
FR2930391A1 (fr) Terminal d'authentification d'un utilisateur.
EP3241137A1 (fr) Procede mis en oeuvre dans un document d'identite et document d'identite associe
EP3812945B1 (fr) Système ouvert et sécurisé de traitement de demande de signature électronique et procédé associé
EP3435601B1 (fr) Système de messagerie certifié et procédé
CN109388923A (zh) 一种程序执行方法及装置
CA2694335C (fr) Gestion et partage de coffres-forts dematerialises
EP3673633B1 (fr) Procédé d'authentification d'un utilisateur auprès d'un serveur d'authentification
FR3047622B1 (fr) Procede de controle d'un parametre indicatif d'un niveau de confiance associe a un compte utilisateur d'un service en ligne
WO2023001846A1 (fr) Procédé de transaction entre un organisme et un établissement sur une chaîne de blocs
EP2071799B1 (fr) Procédé et serveur pour l'accès a un coffre-fort électronique via plusieurs entités
EP3899765B1 (fr) Réinitialisation d'un secret applicatif au moyen du terminal
WO2024079144A1 (fr) Procédé de gestion de données d'authentification permettant l'accès à un service d'un utilisateur depuis un terminal
EP3979109A1 (fr) Procédé et système d'authentification d'un utilisateur sur un appareil utilisateur
FR3007929A1 (fr) Procede d'authentification d'un utilisateur d'un terminal mobile
WO2008132393A2 (fr) Procédé et système d'authentification d'un utilisateur
EP3926499A1 (fr) Procédé d'authentification d'un utilisateur sur un équipement client avec un système d'archivage sécurisé de justificatifs d'identité
WO2022184726A1 (fr) Procédé pour permettre à des utilisateurs de déployer des contrats intelligents dans une chaîne de blocs au moyen d'une plateforme de déploiement
OA20002A (fr) Système ouvert et sécurisé de traitement de demande de signature électronique et procédé associé.
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

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20180930

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20200428

17Q First examination report despatched

Effective date: 20200901