WO2009130089A1 - Procede de diffusion securisee de donnees numeriques vers un tiers autorise - Google Patents

Procede de diffusion securisee de donnees numeriques vers un tiers autorise Download PDF

Info

Publication number
WO2009130089A1
WO2009130089A1 PCT/EP2009/053087 EP2009053087W WO2009130089A1 WO 2009130089 A1 WO2009130089 A1 WO 2009130089A1 EP 2009053087 W EP2009053087 W EP 2009053087W WO 2009130089 A1 WO2009130089 A1 WO 2009130089A1
Authority
WO
WIPO (PCT)
Prior art keywords
party
certificate
entity
encryption key
digital certificate
Prior art date
Application number
PCT/EP2009/053087
Other languages
English (en)
Inventor
Jonathan Attia
Bernard Pinot
Original Assignee
Etsem Limited
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 Etsem Limited filed Critical Etsem Limited
Priority to EP09733859A priority Critical patent/EP2279581A1/fr
Priority to GB1005174A priority patent/GB2465326B/en
Priority to US12/988,778 priority patent/US8719575B2/en
Publication of WO2009130089A1 publication Critical patent/WO2009130089A1/fr

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/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
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • 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/321—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 a third party or a trusted authority
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution
    • H04L2209/601—Broadcast encryption

Definitions

  • the present invention relates to the field of securing, storage, access control and digital data broadcasting.
  • the present invention relates more particularly to a method capable of securing data and autonomously and securely broadcasting data streams to fixed or mobile terminals of the PDA (Personal Digital Assistant) type.
  • PDA Personal Digital Assistant
  • Kq is a public key that is published in some kind of directory as belonging to a certain entity. Thus, anyone can recover this key Kq, test the origin, and use it to encrypt a message that it wants to send confidentially to the entity owner of the key Kq.
  • Ke is a private key that is known only to its owner and must be kept secret. The entity owning the key Kq uses the key Ke to decrypt the messages it receives and which have been encrypted with Kq.
  • the most well-known examples of so-called asymmetric cryptographic public-key protocols are the RSA system (named after the inventors Rivest, Shamir and Adleman) based on the integer factorization, the Diffie-Hellman key exchange, the system of El Gamal based on the discrete logarithm.
  • This method is based on encryption schemes and public key signatures implementing at least one public key infrastructure, which will be designated later by PKI (for Public Key Infrastructure in English) , which ensures the authenticity of the public keys used.
  • a CA subsequently designated by CA, issues, after performing a number of checks, an X.509 standardized digital certificate to a candidate entity, and certifies, by affixing its private signature on the digital certificate, the relationship which exists between a public key and the identity of the legitimate entity having access to the corresponding private key.
  • a digital certificate conforming to the X.509v3 format consists of the following main fields:
  • Version Indicates which version of X.509 matches this certificate.
  • Serial number certificate serial number specific to each PKI.
  • Signature Algo ID identifier of the type of signature used.
  • Issuer Name Distinguished name of the CA issuing the certificate.
  • - Validity period validity period.
  • Subject Name Distinguished name of the holder of the public key.
  • Subject public Key info Information (value, algorithm type %) on the public key of this certificate.
  • Issuer Unique ID unique identifier of the issuer of this certificate.
  • Subject Unique ID Unique identifier of the holder of the public key.
  • Signature Digital signature of the CA on the previous fields.
  • the prior art is known in particular by publications FIPS-197, RFC 2405, the realization of standard cryptosystems secret key.
  • the secure data are systematically dissociated from the authentication when it is interpreted by a user: There is a real risk of usurpation and / or alteration of the contents without any means of effective control. It is thus difficult to determine who has accessed or modified secure data.
  • the invention thus relates to a method of securely distributing encrypted digital data of a proprietary entity, this data being stored in a storage module of a server, comprising the steps of:
  • the access policy certificate authorizes the third party to access the encrypted digital data of the proprietary entity, decrypting the encrypted digital data with a symmetric storage encryption key contained in a private digital certificate of the proprietary entity; private digital certificate being stored in a storage module of a server; -digit the digital data by means of the encryption key for the dissemination of the digital data to the authenticated third party and disseminate the digital data to the authenticated third party.
  • the reading of the access policy certificate drawn up by the proprietary entity includes the prior decryption of this certificate with a symmetric encryption key contained in the private digital certificate of the proprietary entity.
  • the symmetric encryption key used to decrypt the access policy certificate is distinct from the symmetric storage encryption key.
  • obtaining the symmetric storage encryption key comprises decrypting the private digital certificate by means of a first symmetric encryption key dedicated to the proprietary entity.
  • the method comprises previously:
  • the process comprises:
  • the method comprises the retrieval of information on the hardware configuration of a third party terminal, the generation of a symmetric encryption key based on this information, the storage of this encryption key in the negotiated digital certificate. , the encryption of the digital data to be broadcast by means of this encryption key.
  • the method comprises: the generation of a public digital certificate of the proprietary entity and its memorization in a storage module of a server, the public digital certificate being linked mathematically to the private digital certificate of the proprietary entity;
  • the proprietary entity sets restrictions on viewing its public digital certificate for certain categories of third parties, and in which the search engine prevents access to the public digital certificate of the proprietary entity for these third-party categories.
  • the process comprises:
  • the private digital certificate of the proprietary entity comprises a symmetric diffusion encryption key to the proprietary entity, the method comprising an access request from the proprietary entity to its encrypted digital data, a strong authentication the proprietary entity, decrypting the encrypted digital data with the symmetric storage encryption key, encrypting the digital data by means of the broadcast encryption key to the proprietary entity, and broadcasting the encrypted data to the owner entity.
  • the method comprises storing a history of access to the encrypted digital data of the proprietary entity in a storage module of a server.
  • the method comprises the inclusion of a history of access to encrypted digital data in the digital data broadcast to the authenticated third party.
  • the method comprises previously: the entry of information relating to the identity of the third party;
  • the method comprises in advance: the strong authentication of the proprietary entity and the third party;
  • the method comprises prior to the definition by the proprietary entity and by the third party of the encryption parameters for broadcasting the digital data: the generation of another digital certificate negotiated between a first entity from the third party and the owner entity, and another third party;
  • the method comprises: strong authentication of the proprietary entity
  • the invention also relates to a system for securely distributing encrypted digital data, comprising:
  • an encrypted digital data storage module hosted in a server; a strong authentication module of users, hosted in a server; a module for storing private digital certificates dedicated to respective users, each private digital certificate comprising a first symmetric encryption key, a pair of asymmetric encryption keys and a symmetric storage encryption key dedicated to its user, this module of storage being hosted in a server;
  • each negotiated digital certificate comprising a symmetric encryption key for the dissemination of digital data from one of the two users to the other of the two users, this storage module being hosted in a waiter ;
  • an access policy certificate storage module defining the access rights to the digital data of a user by another user, this storage module being hosted in a server;
  • an encryption / decryption module able to: decrypt the private digital certificate of a first user with his first symmetric encryption key after his authentication;
  • the first user has a right of access to the digital data of the second user, decrypting digital data using the storage encryption key of the second user, encrypting the digital data by means of the encryption key for the distribution of the second user; first user, and broadcast this digital data to the first user.
  • FIG. 1 schematically represents a computer communication network in which the invention is implemented
  • FIG. 2 represents a user terminal and its applications intended to implement the invention
  • FIG. 3 represents a strong authentication terminal of a user
  • FIGS. 4 to 9 illustrate processes implemented in the context of the invention
  • FIG. 10 illustrates the structure of a global database of a server
  • FIG. 11 diagrammatically illustrates the certificates implemented during the generation of a certificate negotiated from pre-existing negotiated certificates;
  • FIGS. 12 to 19 illustrate datagrams of data
  • FIG. 20 illustrates the principle of storage of digital data broadcast, remote in the terminal 3;
  • FIG. 21 illustrates a data dissemination process.
  • the invention proposes a method of securely distributing encrypted digital data of a proprietary entity and stored in a storage module of a server to a third party. After a strong authentication of the third party requesting the dissemination of the data, a private digital certificate of this third party is decrypted with a symmetric encryption key which is dedicated to it. By means of a private key of an asymmetric encryption key pair contained in the third party's private digital certificate, a digital certificate negotiated with the proprietary entity is decrypted. The negotiated digital certificate includes a symmetric encryption key for distributing the data to the third party. Once the decryption of the negotiated digital certificate has been performed, an access policy certificate of the proprietary entity is read.
  • This access policy certificate defines the rights to access the digital data of the proprietary entity.
  • this certificate authorizes access to the third party, the digital data is decrypted with a symmetric encryption key contained in a private digital certificate of the proprietary entity. The digital data is then encrypted by means of the encryption key for the dissemination of the data to the third party, and then the digital data is broadcast to the third party.
  • FIG. 1 schematically shows a system 9 for controlling access to secure data.
  • the system 9 includes IA to In terminals such as personal computers, intended to be used by different users.
  • the terminals IA to 1n respectively have access to databases 2A to 2n typically stored locally.
  • the terminals IA to In are able to communicate with authentication terminals 3A to 3n.
  • the terminals IA to In are connected to a network 4, in this case the Internet network.
  • a server 5 is connected to the network 4 and has access to a database 6.
  • a dating server 7, such as an NTP server, is connected to the network 4. The server 7 can be used to perform most timestamps implemented in the context of the invention.
  • Figure 2 shows a terminal 1 and its applications 11 to 17 to be executed to implement different features of access control. These applications 11 to 17 can be installed as thin clients on the terminal 1.
  • FIG. 3 represents an authentication terminal 3.
  • the authentication terminal 3 is intended to allow strong authentication of a user.
  • the terminal 3 comprises in this case a fingerprint reader 31, and a retinal reader 34 to implement biometric measurements during authentication.
  • the terminal 3 also includes a screen 32 for displaying messages for the user.
  • the terminal 3 further comprises a receiver 33 of a geolocation signal, for example a GPS receiver.
  • the terminal 3 comprises a processing and control module 38.
  • the module 38 is connected to an input / output interface 37, for example a wired or radio-frequency interface, intended to put the terminal 3 in communication with the terminal 1.
  • the geolocation receiver 33 is connected to the module 38.
  • a secure data storage medium 35 is connected to the processing and control module 38.
  • the module 38 is connected to the readers 31 and 34, and can communicate with a database 36.
  • the database 36 comprises a symmetric encryption key Kst for the transmissions of the terminal 3. This encryption key Kst will advantageously be defined during the manufacturing of the terminal 3 and stored. in a non-volatile memory.
  • the server 5 previously stores the symmetric key Kst of the terminal 3 to ensure the decryption of the data it receives from the terminal 3.
  • the terminal 3 is used both to register strong authentication credentials on the server 5, and then to authenticate a user during his accesses to the server 5 by comparison between these references and an instantaneous reading of parameters to be compared to these references.
  • an interface not shown for example a push button, the user can define the beginning or the end of a session of use of the authentication terminal 3.
  • the terminal 3 measures a biometric fingerprint via the readers 31 and 34.
  • the terminal 3 may also include a smart card reader and a data entry keyboard. 'a personal identification code of the smart card.
  • the identifier of the smart card is used to be compared with the reference stored in the server 5.
  • the terminal 3 retrieves via its receiver 33 a geolocation signal. Terminal 3 extracts its position and the current date and time.
  • the terminal 3 transmits the authentication data (measured biometric fingerprints or smart card references for example) and the date and time extracted from the geolocation signal.
  • the authentication data measured biometric fingerprints or smart card references for example
  • the date and time extracted from the geolocation signal we can still achieve a strong authentication timestamp.
  • This time stamp can in particular make it possible to enrich the history of access of a user to the server or to restrict access to secure data according to the time of authentication.
  • the position of the terminal 3 is also transmitted to the server 5.
  • the position of the user can be taken into account to restrict access to secure data.
  • This transmission is encrypted by means of the symmetric encryption key Kst stored in the terminal 3.
  • the secure storage medium 35 may be of any suitable type, for example a hard disk or an EEPROM type memory. Depending on the access rights to the secure data, defined in the detailed access policy certificate later, the storage of secure data in the terminal 1 may be prohibited. The access rights may require that the secure data from the server 5 are stored in the storage medium 35, accessed by means of an application 17 by reading the medium 35, then erased from the support 35 at the end of the session of use . The application 17 will thus have to manage the storage of data in the terminal 3. The exchanges between the application 17 and the storage medium 35 will advantageously be encrypted. The rights of use in the access policy certificate defined by the owner of the secure data may also apply to its own access to secure data. The data stored on the medium 35 may be subject to hardware encryption to prevent fraudulent access.
  • the digital data coming from the base 66 and broadcast to the user of the terminal 3 arrive on the network card 18 of the terminal 1.
  • the data are stored temporarily in the support 35 of the terminal 3 instead of they are stored in a hard disk 19 of the terminal 1.
  • the data temporarily stored by the medium 35 are then processed by the central unit 111 or transferred to the random access memory 112, where these data are not duplicable by a fraudulent third party.
  • Terminal 3 is intended not to be nominative. To this end, the terminal 3 erases all the personal data of its user at the end of the session, including all the data stored on the support 35. The terminal 3 can thus be used successively by users without links between them without their information nominative is vulnerable. In order to be compatible with different operating systems of the user's terminals, the terminal 3 will include APIs compatible with several types of operating systems. The terminal 3 can thus be used indifferently by all types of users, which strengthens its ability to be used successively by different users according to their needs. The terminal 3 can send display frames without the data themselves being recordable in the terminal 1. The terminal 3 may have in particular read applications of different file formats to allow viewing these types of files on the terminal 1.
  • the interface 37 may in particular be a wireless interface (defined by an IEEE 802.11 standard or an IEEE 802.15 standard) or a wired interface (RJ45 or USB for example).
  • FIG. 4 details a process for generating a private digital certificate implemented using the application 12.
  • the user fills out textual fields relating to the identity of the proprietary entity. This data will include for example a name, a first name, a company name, a legal representative, coordinates etc.
  • the user also provides any other field that can facilitate its identification or selection by filtering.
  • step 402 one or more strong authentication references are captured via the authentication terminal 3.
  • the strong authentication reference or references are transmitted to the terminal 1.
  • step 403 the user selects the type of cryptographic protocols and their different encryption parameters. These choices will define the parameters for the storage and transmission of the digital data of the user. These parameters could for example define the size of the encryption keys used or the encryption algorithms used.
  • step 404 all the data retrieved by the terminal 1 is encrypted by means of the symmetric key Kst stored in the terminal 3.
  • step 405 the terminal 1 transmits the encrypted data to the server 5.
  • step 406 the server 5 generates the private digital certificate CePr and stores it in the database 6.
  • the server 5 dynamically generates the various encryption keys included in the private certificate CePr and generates a first symmetric encryption key KeSl that it associates with the strong authentication reference of the user.
  • the CePr private certificate is encrypted with this key
  • step 407 the server 5 generates a public certificate CePc associated with the private digital certificate CePr, and publishes this public certificate CePc.
  • the user may limit or prohibit the publication or consultation of the CePc public certificate at his convenience. The user can use the application
  • Public certificates may be published in a dedicated directory and made public to any user based on publication restrictions.
  • the CePr digital private certificate may also be completed later using the application 12, to include information that does not affect the ciphers.
  • the owner entity may, for example, fill in the information fields of its private digital certificate, for example by specifying the network address of a server storing the encrypted digital data.
  • the digital private certificate CePr thus contains the essential data of the identity of its owning entity as well as the data useful to the cryptosystem.
  • the Cepr digital private certificate contains:
  • one or more strong authentication references for example the fingerprint or the retinal fingerprint of the proprietary entity
  • KeS2 a second KeS2 symmetric encryption key dedicated to the encryption of the secure data of the proprietary entity during their storage in the database 6;
  • KeS3 a third KeS3 symmetric encryption key for encrypting the secure data streams broadcast from the database 6 to the proprietary entity itself;
  • KeS4 symmetric encryption key for encrypting an access policy certificate
  • the private digital certificate may include the following fields:
  • -VaI FPT binary image of one or more fingerprints
  • -VaI Ks Value of KeS2 symmetric encryption key
  • -Info Ks Information of the symmetric cryptographic protocol retained
  • the server 5 may have an asymmetric encryption key pair to generate the CRC field of a private digital certificate.
  • the value of the CRC field is calculated from a non-reversible hash function applied to the information contained in this private digital certificate.
  • the private key of this pair of keys makes it possible to encrypt the result of the hash function to generate the CRC field of the private digital certificate.
  • the owner of this private digital certificate will thus be able to prove by a particular server control procedure 5 that this certificate has been issued by said server.
  • the control procedure will allow the server 5 to check the authenticity of a private digital certificate imported by its owner as follows:
  • the symmetric encryption key KeS2 will preferably be sized to perform strong encryption of the stored digital data.
  • KeS3 (as well as the Kse third-party delivery key detailed later) will be further dimensioned to allow transmission and reduced processing time of the transmitted secure data.
  • This KeS3 symmetric encryption key (as well as the broadcast key to a third Kse detailed later) may for example be of the 3DES type and have a size between 64 and 192 bits.
  • the CePc public certificate guarantees the existence of its associated digital private certificate CePr, which makes it possible to initiate negotiations for data access by a third party.
  • the public certificate CePc is mathematically linked to the associated private digital certificate, so that a third party wishing to check the validity of this CePc certificate may require a check by the server 5.
  • the public certificate CePc may include a digital signature of the associated private certificate CePr, for example a signature by a hash function. A third party will thus be able to submit a public certificate CePc to the server 5 which will verify the mathematical link with its associated private digital certificate.
  • the search and consultation of third party public certificates may be carried out using the application 16.
  • -Info User Restricted data identifying the legitimate holder of the private digital certificate such as Name, First names, Pseudonym, ...; -Hash: digital fingerprint of CePr digital certificate guaranteeing the mathematical link with the private digital certificate;
  • the CePc public digital certificate and the CePr digital private certificate may be irrevocable and have an unlimited period of validity.
  • a temporary access policy certificate is advantageously created to define the access policy that will be applied for the dissemination of the digital data.
  • the temporary access policy certificate may provide for very restrictive access rights by default, for example a distribution limited only to the owner entity.
  • the application 16 allows a user to search for public digital certificates from other proprietary entities.
  • the application 16 makes it possible in particular to query a database of public digital certificates and select public certificates whose content meets criteria defined by the user.
  • the application 16 makes it possible to view the information provided by a selected public digital certificate.
  • the application 16 can be deported and be made in the form of a search engine searchable via the Internet.
  • FIG. 5 details the process for negotiating access rights between the entity that owns the secure data and a third party.
  • the third party may itself hold secure data, and the negotiation may lead to defining a reciprocal access right to the secure data of the two entities.
  • the users carry out this negotiation through their application 13 intended to create a Negotiated digital certificate CeNe.
  • the exchanges between the users and the server 5 are secured by appropriate encryption.
  • step 501 the third party authenticates by strong authentication to the server 5.
  • the application 15 makes it possible in particular to transmit biometric data read on the terminal 3 to the server 5.
  • the data transmitted by the terminal 1 of the third party are compared to a strong authentication reference previously stored on the server 5.
  • the third party issues a secure data access negotiation request to the owner of this data.
  • the owning entity authenticates by strong authentication to the server 5.
  • the owning entity accepts the negotiation request.
  • the owner entity returns a proposal defining the conditions of access to this secure data.
  • the proprietary entity may, in particular, propose a type of cryptographic protocol for the transmission of the secured data, a desired type of publication of a public digital certificate corresponding to the Negotiated certificate, or define the lifetime of this negotiated digital certificate (the revocation automatic certificate that can be managed by the server 5).
  • Different types of publication of the negotiated digital certificate may be envisaged, either by updating their respective public digital certificate, or by publication of the corresponding public digital certificate or by secret maintenance of this certificate.
  • the conditions for access to the secured data may possibly be the subject of prior negotiation.
  • the users sign and transmit their acceptance of the conditions to the server 5.
  • the signature can be carried out with their private key contained in their respective private digital certificate.
  • the signature can be done on a hash of the values of the negotiated parameters. Their acceptance is timestamped and stored by the server 5.
  • the server 5 creates and stores a CeNeaB negotiated digital certificate for the third party and a Negotiated CeNeAb digital certificate for the owning entity.
  • CeNeaB and CeNeAb certificates are encrypted respectively with the public key KpcB and the public key KpcA respectively contained in the private digital certificates CePrB and CePrA. Access to the data of the negotiated certificate is thus secured by both strong authentication and cryptographic authentication by means of a private key.
  • A is an entity that owns digital data and that B is a third party for this data.
  • B may be a proprietary entity of digital data stored in base 66. A is then considered a third party for this data.
  • KeSe symmetric encryption key can be used to broadcast digital data to the non-proprietary entity of that data. It is also conceivable that the CeNeaB and CeNeAb certificates respectively comprise KeSeB and KeSeA broadcast encryption keys for broadcasting respectively to B and A as third parties.
  • These negotiated certificates may include the following fields: -SN: unique serial number of the digital certificate.
  • -VaI Ks Value of the symmetric distribution encryption key to the entity holding the negotiated certificate
  • -Info Ks Information on the symmetric encryption protocol chosen; -Import_X.509: possibility of importing a digital certificate of the X.509 standard ... -Hash: checksum of integrity of all the fields;
  • Figure 6 illustrates a process of accessing a user's private digital certificate. This process is notably implemented during the updating of the private certificate, or during any secure data access operation.
  • step 601 the user launches the application 12 on his terminal 1.
  • step 602 the user launches the application 12 on his terminal 1.
  • the terminal 1 detects the presence of the authentication terminal 3.
  • the terminal 3 reads an authentication information entered by the user, for example its fingerprint on the reader 31.
  • the read authentication information is transmitted encrypted (with the Kst key) to the terminal 1.
  • the terminal 1 transmits
  • the server 5 consults the biometric database 65 and compares the authenticating information read with the stored reference.
  • the server 5 also compares the time stamp information generated by the terminal 3 with timestamp information provided by the server 7.
  • the Symmetric encryption key KeS 1 associated with the stored authentication reference is stored in the server 5.
  • a symmetric key is particularly suitable for encrypting the private digital certificate since only the owner of the private digital certificate uses it directly.
  • the private digital certificate of the user stored in the database 62 is then decrypted by means of this key KeS 1 in step 607.
  • the server 5 is mounted in memory.
  • a pair of asymmetric encryption keys Kpc and Kpr is in particular loaded into memory, in order to enable the encryption or decryption of the Negotiated certificate.
  • FIG. 7 illustrates a process of accessing the different negotiated certificates held by the user.
  • the user starts the application 13 on his terminal 1.
  • the steps 702 to 705 of strong authentication are identical to the steps 602 to 605.
  • the server 5 consults the database biometric 65 and compares the authentication information read with the reference stored at the end of step 706, once the authenticated user, the private key KPr asymmetric key pair is loaded into memory.
  • the negotiated user certificates stored in the database 63 are decrypted by means of this private key Kpr.
  • the list of its negotiated certificates is transmitted to the user. The transmission of this list is encrypted by means of a session key Kse2.
  • FIG 8 illustrates a process for defining the access policy certificate of the user who owns the digital data.
  • the proprietary entity A starts the application 14 on its terminal 1.
  • the terminal 1 detects the presence of the authentication terminal 3.
  • a strong authentication of the proprietary entity is performed as detailed before.
  • the proprietary entity authenticated its KeSlA symmetric encryption key associated with its authentication reference is loaded into the server 5.
  • the CePrA digital private certificate is then decrypted by means of this key KeSlA in step 803.
  • the KeS4A symmetric encryption key is then loaded into the server 5 at step 804.
  • the proprietary entity sets access rights: which entity has a right to access to digital data, which rights are associated with each entity (reading, modification, copying, loading limited to an authentication terminal support ...), access restrictions depending on the location, the time
  • the access policy certificate may also define whether an access history is to be stored and whether an access history must be included in the digital data disseminated, forming a mark. ur for these data.
  • a CeSeA access policy certificate containing this information is generated in step 806.
  • the CeSeA access policy certificate is encrypted with the key KeS4A in step 807.
  • the CeSeA access policy certificate is stored in the database 64 at step 808.
  • the proprietor entity can select default access control settings proposed by the server 5 when creating the CeSe access policy certificate.
  • the owner entity may use a knowledge base of access policy certificate templates to generate its own access policy certificate.
  • the owning entity may later access its access policy certificate by strong authentication in order to modify the access rights defined for third parties or for itself to its digital data.
  • the digital access policy certificate, CeSe comprises at least the following fields:
  • SN unique serial number of this digital certificate
  • SN CeNe unique serial number corresponding to CeNe
  • - IPS Index of security parameters corresponding to the imported access policy template (s).
  • FIG 9 shows the process of broadcasting the digital data from the proprietary entity to the authenticated third party.
  • the third party B launches the application 17 on its terminal 1.
  • the terminal 1 detects the presence of the authentication terminal 3.
  • a strong authentication of the user B is performed as detailed before.
  • the authenticated user B his symmetric encryption key KeSlB associated with its authentication reference is loaded into the server 5.
  • the private digital certificate CePrB is then decrypted using this key KeSlB at step 903.
  • the negotiated digital certificate CeNeaB is decrypted using the private key KprB.
  • the broadcast key KseB for broadcasting the digital data to B is then loaded into the server 5.
  • step 906 the encryption key KeS4A is extracted from the CePrA certificate and loaded into the server 5
  • step 907 the CeSeA access policy certificate is decrypted with the KeS4A key.
  • the access rights are read by the server 5.
  • step 908 the server 5 validates access to the digital data for the third party B.
  • the server 5 loads in memory the KeS2A storage encryption key from the certificate CePrA decrypts the digital data of the proprietary entity stored in the base 66.
  • step 909 the data to be broadcast is encrypted with the broadcast encryption key KSeB.
  • step 910 the encrypted data is broadcast to the third party B.
  • the application 17 allows the user of the terminal 1 to which data has been broadcast to view their content.
  • the data to be broadcast to the third party B are also encrypted with a KeMaB symmetric encryption key based on the hardware configuration of the terminal 1 and / or the terminal 3 of the third party.
  • the KeMaB encryption key will for example be based on the physical address of the network card 18 of the terminal 1, on hard disk references of the terminal 1, on a value of the system clock of the terminal 1 or the terminal 3, or on the processor references of the terminal 1.
  • the KeMaB encryption key will typically be generated at each access session to the encrypted data.
  • the KeMaB encryption key will be stored in the CeNeaB negotiated certificate or in a CeMaB hardware digital certificate.
  • the digital hardware certificates CeMa will include at least the following fields:
  • SN unique serial number of said CeMa digital certificate
  • MAC physical address of the network card 18 of the terminal 1;
  • SND serial number of the hard disk 19 corresponding to the terminal 1
  • SNP serial number of the processor 111 of the terminal 1
  • SNA serial number of the authentication device 3 connected to the terminal 1.
  • the authentication phase applies to each of the requests transmitted to the server via a fixed or mobile terminal.
  • Each process then initially comprising a strong authentication the history of secure data access is particularly accurate, and each step may involve access to sensitive data is secure.
  • the database 6 comprises a public certificate database 61, a private digital certificate database 62, a negotiated certificate database 63, an access policy certificate database 64, a reference database biometric 65, an encrypted digital data storage base 66 and a cryptographic protocol base 67.
  • the different encryption keys are not provided to the users but only loaded into memory by the server 5 for use in the various encryption / decryption operations.
  • the server 5 will load in memory the required keys only when authentication of a user issuing an access request is validated.
  • storing keys of a private certificate of a first user in his negotiated certificate does not allow a second user holding the negotiated certificate to obtain the keys of the first user.
  • the database 61 includes the public certificates of the different users of the server
  • Public certificates for which access is not restricted are accessible through a directory or search engine running on the server 5.
  • the cryptographic protocol database 67 contains the different cryptosystems required to perform the ciphers / decryptions at the server 5.
  • FIG. 11 represents a phase of creation of a new certificate negotiated from two existing negotiated certificates. Holders A and B of the CeprA and CePrB digital private certificates, and holders C and D of the private digital certificates CePrC and CePrD previously created respectively the CeNeAb, CeNeaB, CeNeCd and CeNecD traded certificates.
  • the CePcAb CePcaB, CePcCd and CePccD public certificates corresponding to these CeNeAb, CeNeaB, CeNeCD and CeNecD certificates are published in a directory.
  • CeNeaBcd and CeNeabCd public certificates will allow users B and C to re-negotiate the creation of a negotiated certificate with another entity.
  • this negotiated solution has been described from negotiated certificates, the creation and negotiation of a new negotiated certificate may be based on one or more private digital certificates and one or more negotiated certificates.
  • This process of creating the new negotiated certificate is not a security breach for the holders of negotiated certificates not participating in this negotiation: the use of their negotiated certificate to create a new negotiated certificate does not imply a mutual access to their secure data. In fact, these holders retain their access policy certificate to define the access rights to their digital data and can therefore prohibit access to the holders of the new negotiated certificate.
  • the new negotiated certificate thus constitutes only a step towards access to the secure data, each holder being then free to define the access policy certificate to his own secure data corresponding to this new negotiated certificate.
  • FIGS. 12 to 18 show examples of exchange datagrams to allow the dissemination of encrypted data. To achieve the decryption of the digital data broadcast to the authorized third party, it must first have the symmetric encryption key used for broadcasting.
  • FIG. 12 represents a datagram of a packet of a request sent by the authorized third party to the server 5 and intended to establish a hardware symmetric encryption key KCeMa for the dissemination of the data.
  • the first IDS field is a numeric identifier of the data broadcast session.
  • the second ID field CePr is a unique identifier of the private digital certificate of the owning entity.
  • the third field ID CeNe is a unique identifier of the negotiated digital certificate of the proprietary entity with the authorized third party.
  • the fourth field ID CePr ' is a unique identifier of the private digital certificate of the authorized third party.
  • the fifth field Ord is the number of the packet among the different packets intended to establish the hardware encryption key.
  • the sixth field Qr indicates whether the exchange concerns a request from the user or a response from the server.
  • the integrity of the first seven fields of the packet of Figure 12 is guaranteed by the Checksum field, containing an integrity checksum of these fields.
  • the authentication of the first eight fields is guaranteed by the K CePr field which is a signature of all these fields from the private key contained in the private certificate of the proprietary entity.
  • the set of fields is encrypted by means of a symmetric encryption key Kst of the terminal 3.
  • FIG. 13 represents a datagram of a packet of a response transmitted by the server 5 to the authorized third party and intended to provide it with the symmetric encryption key used for the dissemination of the data.
  • the first six fields have a function identical to those of the datagram of FIG. 12.
  • the seventh field Val_K_217 contains the symmetric diffusion encryption key. This key combines the hardware encryption key transmitted by the authorized third party with a session key in the negotiated certificate.
  • the Checksum Histo field is a cumulative sum of integrity checks of all packages.
  • the authentication of the first eight fields is guaranteed by the K CePr field which is a signature of all these fields from the private key contained in the private certificate of the proprietary entity.
  • the set of fields is encrypted by means of the symmetric encryption key K CeMa transmitted in the packet of FIG.
  • Fig. 14 shows a datagram of a packet of an acknowledgment request of an authorized third party access request to the digital data of the proprietary entity.
  • the first four fields of the packet have the same function as the datagram fields of Figures 12 and 13.
  • the fifth field ID F contains a numeric identifier of a digital file to which access is required.
  • the sixth and seventh fields correspond to the fifth and sixth fields of the datagrams of Figures 12 and 13.
  • the eighth NTP field includes a schedule of an official organization, either provided by the terminal 3, or provided by an NTP server.
  • the ninth CeSe # CePr field contains an encapsulated access policy parameter index.
  • the tenth Q AR field identifies a request for acknowledgment.
  • the eleventh VaI-SHA field contains an integrity check value of the file to be broadcast.
  • the Checksum Histo field is a cumulative sum of integrity checks of all packages.
  • the KcePr field is a signature of all these fields from the private key contained in the private certificate of the proprietary entity.
  • the set of fields of the packet is encrypted by means of the key K 217.
  • FIG. 15 represents a datagram of a packet of an acknowledgment of the server transmitted to the authorized third party.
  • the first nine fields of the packet have the same function as the fields of the packet of Figure 14.
  • the tenth field R AR identifies an acknowledgment.
  • the eleventh field KcePr is a signature of all these fields from the private key contained in the private certificate of the proprietary entity.
  • the Options field contains a qualification code (validate, archive, good for agreement ...) of the file to be broadcast and is associated with the signature KCePr '.
  • the VaI-SHA field contains an integrity check value of the file to be broadcast.
  • the Checksum Histo field is a cumulative sum of integrity checks of all previous packets.
  • the field KCePr ' contains a signature of all the preceding fields by the private key of the digital certificate of the authorized third party.
  • the set of fields of the packet is encrypted with the key K 217.
  • Fig. 16 is a simplified datagram of a packet of the digital data stream of the proprietary entity broadcast to the authorized third party.
  • the first field defines the order of the packet in the stream
  • the second field identifies that the packet corresponds to a response from the server
  • the third field comprises the digital data broadcast
  • the fifth field comprises a cumulative sum of integrity checks of the server. set of previous packages.
  • the KCePr field contains a signature of all the preceding fields by the private key of the digital certificate of the proprietary entity.
  • the set of fields of the packet is encrypted with the key K 217.
  • Fig. 17 is a datagram of a packet of an acknowledgment request of the end of the digital data broadcast, transmitted from the authorized third party to the server.
  • the first eight fields of the packet have the same function as the fields of the packets of Figures 14 and 15.
  • the ninth field R AR identifies an acknowledgment request.
  • the SG # field is intended to propagate a new secret server initialization key in the terminal 3. This key will notably make it possible to secure the first exchanges between the terminal and the server 5.
  • the field Checksum Histo is a cumulative sum of control of the server. integrity of all previous packets.
  • the KCePr field contains a signature of all the preceding fields by the private key of the digital certificate of the proprietary entity.
  • the set of fields of the packet is encrypted with the key K 217.
  • the 18 is a datagram of a packet of an acknowledgment of the end of the broadcast of the digital data, transmitted from the server to the authorized third party.
  • the first eight fields of the packet have the same function as the fields of the packets of Figures 14 and 15.
  • the ninth AR field identifies an acknowledgment.
  • the KcePr field is a signature of all the preceding fields from the private key contained in the private certificate of the proprietary entity.
  • the Options field contains a qualification code of the broadcast file and is associated with the signature KCePr '.
  • the VaI-SHA field contains an integrity check value of the broadcast file.
  • the Checksum Histo field is a cumulative sum of integrity checks of all previous packets.
  • the field KCePr 'contains a signature of all the preceding fields by the private key of the digital certificate of the authorized third party.
  • the set of fields in the packet is encrypted with the key K 217.
  • Figure 19 shows the digital data storage format of a proprietary entity during storage in the server.
  • the ID field corresponds to the identifier of the stored digital data.
  • the NTP field contains timestamp information of the stored data, for example the date of last modification of this data.
  • the TOS field for 'Type Of Service' defines the type of service associated with the data.
  • the TTL cache field defines the lifespan of the stored digital data and facilitates the archiving of this data.
  • the Metadata field contains information for indexing stored digital data.
  • the CePr ID field contains the unique identifier of the private digital certificate of the owning entity.
  • VaI SHA includes an integrity check value of the stored digital data.
  • the following field is a signature by the private key of the entity that owns all the previous fields.
  • the Data field includes the digital data of the owning entity itself.
  • the Histo field includes the history of all stored digital data accesses. The Histo field may notably include the datagrams of FIGS. 15 and 18.
  • the Checksum file field is a checksum of the stored digital data.
  • the following field is a signature by the private key of the entity that owns all the previous fields.
  • Figure 21 illustrates a method of disseminating data to the authorized third party. In a first step, the stored digital data of the proprietary entity are decrypted. of the data packets intended for broadcast are formed and are subject to optimized encapsulation.
  • the packets to be broadcast are encrypted using the authorized third party's broadcast encryption key.
  • Data packets are compressed before they are broadcast.
  • the authorized third party terminal decompresses the received data packets, decrypts the digital data and performs encryption for storing the data in the terminal.
  • the data is transmitted to a module for viewing by the authorized third party.
  • the server 5 is accessible by the users via the Internet.
  • the server 5 is a corporate server accessible on a local network.
  • the server 5 only allows viewing and access to a private digital certificate to its own entity.
  • all the aforementioned digital certificates (CePr, CePu, CeNe, CeSe, CeMa) are stored on one or more secure remote servers in a database according to a suitable client / server architecture.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un procédé de diffusion sécurisée de données numériques chiffrées d'une entité propriétaire, ces données étant mémorisées dans un module de stockage (6) d'un serveur (5), comprenant le chiffrement des données numériques au moyen d'une clé de chiffrement pour la diffusion des données numériques vers le tiers authentifié et la diffusion de ces données numériques vers le tiers authentifié.

Description

PROCEDE DE DIFFUSION SECURISEE DE DONNEES NUMERIQUES VERS UN TIERS AUTORISE
La présente invention se rapporte au domaine de la sécurisation, du stockage, du contrôle d'accès et de la diffusion de données numériques.
La présente invention se rapporte plus particulièrement à un procédé capable de sécuriser des données et de diffuser de façon autonome et sécurisée des flux de données vers des terminaux fixes ou mobiles de type PDA (de l'anglais Personnal Digital Assistant).
Dans le domaine de la sécurisation de l'accès à des données, l'art antérieur connaît déjà par les publications ISO/CEI 9594-8, RFC -2459 et RFC-2510, la réalisation de cryptosystèmes standards à clé publique. Le principe du chiffrement avec un système à clé publique repose sur l'existence d'un couple de clés noté Ke (clé privée) et Kq (clé publique), de valeurs différentes mais mathématiquement liées, appartenant à une même entité propriétaire.
Kq est une clé publique qui est publiée dans une sorte d'annuaire comme appartenant à une certaine entité. Ainsi, n'importe qui peut récupérer cette clé Kq, en tester l'origine, et l'utiliser pour chiffrer un message qu'elle veut envoyer de manière confidentielle à l'entité propriétaire de la clé Kq. Ke est une clé privée qui n'est connue que de son propriétaire et qui doit être maintenue secrète. L'entité propriétaire de la clé Kq utilise la clé Ke pour déchiffrer les messages qu'elle reçoit et qui ont été chiffrés avec Kq. Les exemples les plus connus des protocoles cryptographiques asymétriques dits à clé publique sont le système RSA (du nom des inventeurs Rivest, Shamir et Adleman) basé sur la factorisation d'entiers, l'échange de clé de Diffie-Hellman, le système d'El Gamal basé sur le logarithme discret.
Ce procédé, largement adopté, s'appuie sur des schémas de chiffrements et de signatures à clés publiques mettant en œuvre au moins une infrastructure de clé publique, que l'on désignera par la suite par PKI (pour Public Key Infrastructure en langue anglaise), qui assure l'authenticité des clés publiques utilisées. Une autorité de certification, désignée par la suite par CA, délivre, après avoir réalisé un certain nombre de contrôles, un certificat numérique normalisé X.509 à une entité candidate, et certifie, en apposant sa signature privée sur ledit certificat numérique, la relation qui existe entre une clé publique et l'identité de l'entité légitime ayant accès à la clé privée correspondante.
Dans ce contexte on suppose que les entités intervenant dans l'échange de flux de données chiffrées connaissent préalablement leurs identités et leurs clés publiques respectives qui sont enregistrées et publiées sur ledit certificat numérique.
Un certificat numérique conforme au format X.509v3 se compose des principaux champs suivants :
Version : indique à quelle version de X.509 correspond ce certificat. Sériai number : numéro de série du certificat propre à chaque PKI. Signature Algo ID : identifiant du type de signature utilisée. Issuer Name : Nom distinctif du CA qui émet le certificat. - Validity period : période de validité.
Subject Name : Nom distinctif du détenteur de la clé publique.
Subject public Key info : Informations (valeur, type d'algorithme...) sur la clé publique de ce certificat.
Issuer Unique ID : identifiant unique de l'émetteur de ce certificat. - Subject Unique ID : identifiant unique du détenteur de la clé publique. Signature : Signature numérique du CA sur les champs précédents. Par ailleurs, l'art antérieur connaît notamment par les publications FIPS-197, RFC 2405, la réalisation de cryptosystèmes standards à clé secrète.
Le principe du chiffrement avec un système à clé secrète repose sur l'existence d'une unique clé secrète notée K (avec K=Ke=Kq) utilisée à la fois pour le chiffrement et le déchiffrement des données. En pratique, on utilise principalement des chiffrements par flux (désigné par Stream Cipher en langue anglaise) lorsque la vitesse de traitement est essentielle (téléphonie, liaison entre unité centrale...) ; lorsque la sécurité prédomine, on utilise plutôt des chiffrements par blocs (désigné par Block Cipher en langue anglaise). De tels cryptosystèmes ont l'avantage principal d'être efficaces en termes de temps de calcul, tant pour le chiffrement que pour le déchiffrement. Les exemples les plus connus des protocoles cryptographiques symétriques (à clé secrète) sont :
- le système DES (de l'anglais Data Encryption Standard, RFC 2405) ;
- le système AES (de l'anglais Advanced Encryption Standard, FIPS-197);
- le système 3 -DES ; - le système IDEA ;
- le système RC6/RC4 (flux).
L'inconvénient majeur de tels cryptosystèmes, tant à clé publique qu'à clé secrète, réside dans la complexité de l'administration et la gestion des clés. Ce qu'on entend par la gestion des clés rattachées à tout cryptosystème ce sont les aspects de sécurisation liés au stockage, à la distribution, à l'échange, à l'archivage, à la diversification fonctionnelle, à la restauration, au remplacement, à la révocation et à l'historique des clés.
A cet inconvénient vient s'ajouter une faille bien plus importante encore des cryptosystèmes actuels lorsqu'il s'agit notamment de la lecture par un utilisateur des données sécurisées.
Dans le cas d'un cryptosystème à clé publique, les données sécurisées sont systématiquement dissociées de l'authentification lors de son interprétation par un utilisateur : II y a un risque réel d'usurpation et/ou d'altération des contenus sans aucun moyen de contrôle efficace. Il est ainsi délicat de déterminer qui a accédé ou à modifié des données sécurisées.
Dans le cas d'un cryptosystème à clé secrète, le risque est quant à lui plus axé sur la confidentialité des données. Lors de l'interprétation par un utilisateur des données sécurisées, (déchiffrement des données), ces dernières se trouvent vulnérables pendant toute la période de lecture : il existe donc un risque réel d'interception, d'écoute passive frauduleuse ou encore de détournement de ces données.
De plus, le manque d'interopérabilité entre les cryptosystèmes entre eux, qu'il s'agisse de PKI ou de cryptosystèmes à clé secrète, représente un obstacle essentiel à leur déploiement au sein des entreprises. On notera la complexité bien connue de l'art antérieur des certifications croisées entre PKI ou encore de leur incompatibilité avec des techniques de chiffrement d'un cryptosystème à clé secrète. Il est ainsi délicat pour une entité de mettre en place une politique de sécurité avec plusieurs autres entités utilisant des cryptosystèmes distincts.
L'invention porte ainsi sur un procédé de diffusion sécurisée de données numériques chiffrées d'une entité propriétaire, ces données étant mémorisées dans un module de stockage d'un serveur, comprenant les étapes de :
-dans un module d'authentification hébergé par un serveur, réaliser une authentification forte d'un tiers requérant la diffusion des données numériques chiffrées de l'entité propriétaire ;
-une fois le tiers authentifié, déchiffrer un certificat numérique privé du tiers avec une première clé de chiffrement symétrique dédiée au tiers authentifié, le certificat numérique privé du tiers étant mémorisé dans un module de stockage d'un serveur et comprenant un couple de clés de chiffrement asymétrique;
-au moyen de la clé privée dudit couple de clés, déchiffrer un certificat numérique négocié préalablement avec l'entité propriétaire et comprenant une clé de chiffrement symétrique pour la diffusion des données vers le tiers authentifié, le certificat numérique négocié étant mémorisé dans un module de stockage d'un serveur ;
-une fois que le certificat numérique négocié est déchiffré, lire un certificat de politique d'accès établi par l'entité propriétaire et définissant les droits d'accès aux données numériques chiffrées de l'entité propriétaire, le certificat de politique d'accès étant mémorisé dans un module de stockage d'un serveur ;
-si le certificat de politique d'accès autorise le tiers à accéder aux données numériques chiffrées de l'entité propriétaire, déchiffrer les données numériques chiffrées avec une clé de chiffrement symétrique de stockage contenue dans un certificat numérique privé de l'entité propriétaire, ce certificat numérique privé étant mémorisé dans un module de stockage d'un serveur ; -chiffrer les données numériques au moyen de la clé de chiffrement pour la diffusion des données numériques vers le tiers authentifié et diffuser ces données numériques vers le tiers authentifié.
Selon une variante, la lecture du certificat de politique d'accès établi par l'entité propriétaire comprend le déchiffrement préalable de ce certificat avec une clé de chiffrement symétrique contenue dans le certificat numérique privé de l'entité propriétaire.
Selon encore une variante, la clé de chiffrement symétrique utilisée pour déchiffrer le certificat de politique d'accès est distincte de la clé de chiffrement symétrique de stockage.
Selon une autre variante, l'obtention de la clé de chiffrement symétrique de stockage comprend le déchiffrement du certificat numérique privé au moyen d'une première clé de chiffrement symétrique dédiée à l'entité propriétaire.
Selon encore une variante, le procédé comprend préalablement :
-la saisie d'informations relatives à l'identité de l'entité propriétaire des données numériques ;
-la génération du certificat numérique privé de l'entité propriétaire contenant lesdites informations relatives à son identité et contenant ladite clé de chiffrement symétrique de stockage ; -la saisie d'un élément d'authentification forte de l'entité propriétaire des données et son stockage dans un module de stockage d'un serveur ;
-la génération de ladite première clé de chiffrement symétrique dédiée à l'entité propriétaire et l'association de cette clé à l'élément d'authentification forte saisi ;
-chiffrer le certificat numérique privé de l'entité propriétaire avec sa première clé de chiffrement symétrique et mémoriser le certificat numérique privé chiffré dans un module de stockage d'un serveur.
Selon une variante, le procédé comprend:
-la définition de paramètres de chiffrement par l'entité propriétaire pour le stockage et l'accès à ses données numériques ; -la génération de la première clé de chiffrement symétrique dédiée à l'entité propriétaire et la génération de la clé de chiffrement symétrique de stockage en fonction des paramètres définis.
Selon encore une variante, le procédé comprend la récupération d'informations sur la configuration matérielle d'un terminal du tiers, la génération d'une clé de chiffrement symétrique basée sur ces informations, la mémorisation de cette clé de chiffrement dans le certificat numérique négocié, le chiffrement des données numériques à diffuser au moyen de cette clé de chiffrement.
Selon une autre variante, le procédé comprend : -la génération d'un certificat numérique public de l'entité propriétaire et sa mémorisation dans un module de mémorisation d'un serveur, le certificat numérique public étant lié mathématiquement au certificat numérique privé de l'entité propriétaire ;
-l'indexation d'informations relatives à l'entité propriétaire et la mise à disposition d'un moteur de recherche accessible permettant l'identification et la consultation du certificat numérique public de l'entité propriétaire par des tiers à partir de la saisie d'informations relatives à l'entité propriétaire par des tiers.
Selon encore une autre variante, l'entité propriétaire définit des restrictions de consultation de son certificat numérique public pour certaines catégories de tiers, et dans lequel le moteur de recherche empêche la consultation du certificat numérique public de l'entité propriétaire pour ces catégories de tiers.
Selon une variante, le procédé comprend :
-la génération d'un certificat numérique public du tiers et sa mémorisation dans un module de mémorisation d'un serveur, le certificat numérique public étant lié mathématiquement au certificat numérique privé du tiers ;
-l'indexation d'informations relatives au tiers et la mise à disposition d'un moteur de recherche accessible permettant l'identification et la consultation du certificat numérique public du tiers par l'entité propriétaire ou par d'autres tiers à partir de leur saisie d'informations relatives au tiers.
Selon encore une variante, le certificat numérique privé de l'entité propriétaire comprend une clé de chiffrement symétrique de diffusion vers l'entité propriétaire, le procédé comprenant une requête d'accès de l'entité propriétaire à ses données numériques chiffrées, une authentification forte de l'entité propriétaire, le déchiffrement des données numériques chiffrées avec la clé de chiffrement symétrique de stockage, le chiffrement des données numériques au moyen de la clé de chiffrement de diffusion vers l'entité propriétaire et la diffusion des données ainsi chiffrées vers l'entité propriétaire. Selon une autre variante, le procédé comprend la mémorisation d'un historique des accès aux données numériques chiffrées de l'entité propriétaire dans un module de stockage d'un serveur.
Selon encore une autre variante, le procédé comprend l'inclusion d'un historique des accès aux données numériques chiffrées dans les données numériques diffusées vers le tiers authentifié.
Selon une variante, le procédé comprend préalablement : -la saisie d'informations relatives à l'identité du tiers ;
-la génération du certificat numérique privé du tiers contenant lesdites informations relatives à son identité, contenant le couple de clé de chiffrement asymétrique ;
-la saisie d'un élément d' authentification forte du tiers et son stockage dans un module de stockage d'un serveur ; -la génération de ladite première clé de chiffrement symétrique dédiée au tiers et l'association de cette clé à l'élément d' authentification forte ;
-chiffrer le certificat numérique privé du tiers avec sa première clé de chiffrement symétrique et mémoriser le certificat numérique privé chiffré dans un module de stockage d'un serveur.
Selon une variante, le procédé comprend préalablement : -l'authentification forte de l'entité propriétaire et du tiers ;
-la définition par l'entité propriétaire et le tiers de paramètres de chiffrement de diffusion des données numériques de l'entité propriétaire et la génération du certificat numérique négocié incluant ces paramètres de chiffrement.
Selon encore une variante, le procédé comprend préalablement à la définition par l'entité propriétaire et par le tiers des paramètres de chiffrement de diffusion des données numériques : -la génération d'un autre certificat numérique négocié entre une première entité parmi le tiers et l'entité propriétaire, et un autre tiers ;
-la publication d'un certificat numérique public associé à cet autre certificat numérique négocié ; -l'identification par une deuxième entité parmi le tiers et l'entité propriétaire, de cet autre certificat numérique.
Selon une autre variante, le procédé comprend: -l'authentification forte de l'entité propriétaire ;
-la saisie des paramètres de droits d'accès aux données numériques chiffrées de l'entité propriétaire, définissant des tiers vers lesquels les données numériques peuvent être diffusées et définissant le type d'accès des tiers à ces données ;
-la génération du certificat de politique d'accès en fonction de ces paramètres et la mémorisation dans ledit module de stockage.
L'invention porte également sur un système de diffusion sécurisée de données numériques chiffrées, comprenant :
-un module de stockage de données numériques chiffrées hébergé dans un serveur ; -un module d'authentification forte d'utilisateurs, hébergé dans un serveur ; -un module de stockage de certificats numériques privés dédiés à des utilisateurs respectifs, chaque certificat numérique privé comprenant une première clé de chiffrement symétrique, un couple de clés de chiffrement asymétrique et une clé de chiffrement symétrique de stockage dédiés à son utilisateur, ce module de stockage étant hébergé dans un serveur ;
-un module de stockage de certificats numériques négociés entre deux utilisateurs, chaque certificat numérique négocié comprenant une clé de chiffrement symétrique pour la diffusion des données numériques d'un des deux utilisateurs vers l'autre des deux utilisateurs, ce module de stockage étant hébergé dans un serveur ;
-un module de stockage de certificats de politique d'accès définissant les droits d'accès aux données numériques d'un utilisateur par un autre utilisateur, ce module de stockage étant hébergé dans un serveur ;
-un module de chiffrement/déchiffrement apte à : -déchiffrer le certificat numérique privé d'un premier utilisateur avec sa première clé de chiffrement symétrique après son authentification ;
-déchiffrer, au moyen de la clé privée du couple de clés du premier utilisateur, un certificat numérique négocié avec un deuxième utilisateur ;
-après le déchiffrement du certificat numérique négocié, la lecture d'un certificat de politique d'accès aux données numériques défini par le deuxième utilisateur ;
-si le premier utilisateur a un droit d'accès aux données numériques du deuxième utilisateur, déchiffrer des données numériques au moyen de la clé de chiffrement de stockage du deuxième utilisateur, chiffrer les données numériques au moyen de la clé de chiffrement pour la diffusion du premier utilisateur, et diffuser ces données numériques vers le premier utilisateur.
On comprendra mieux l'invention et ses autres caractéristiques et avantages à l'aide de la description faite ci-après, à titre purement explicatif, en référence aux figures annexées où :
-la figure 1 représente schématiquement un réseau de communication informatique dans lequel l'invention est mise en œuvre ; -la figure 2 représente un terminal d'utilisateur et ses applications destinées à mettre en œuvre l'invention ; -la figure 3 représente un terminal d'authentification forte d'un utilisateur ; -les figures 4 à 9 illustrent des processus mis en œuvre dans le cadre de l'invention ; -la figure 10 illustre la structure d'une base de donnée globale d'un serveur ; -la figure 11 illustre schématiquement les certificats mis en œuvre lors de la génération d'un certificat négocié à partir de certificats négociés préexistants ;
-les figures 12 à 19 illustrent des datagrammes de données ;
-la figure 20 illustre le principe du stockage de données numériques diffusées, déporté dans le terminal 3 ;
-la figure 21 illustre un processus de diffusion des données. L'invention propose un procédé de diffusion sécurisée de données numériques chiffrées d'une entité propriétaire et mémorisées dans un module de stockage d'un serveur vers un tiers. Après une authentification forte du tiers requérant la diffusion des données, un certificat numérique privé de ce tiers est déchiffré avec une clé de chiffrement symétrique qui lui est dédiée. Au moyen d'une clé privée d'un couple de clés de chiffrement asymétrique contenu dans le certificat numérique privé du tiers, un certificat numérique négocié avec l'entité propriétaire est déchiffré. Le certificat numérique négocié comprend une clé de chiffrement symétrique pour la diffusion des données vers le tiers. Une fois le déchiffrement du certificat numérique négocié effectué, un certificat de politique d'accès de l'entité propriétaire est lu. Ce certificat de politique d'accès définit les droits d'accès aux données numériques de l'entité propriétaire. Lorsque ce certificat autorise l'accès au tiers, les données numériques sont déchiffrées avec une clé de chiffrement symétrique contenue dans un certificat numérique privé de l'entité propriétaire. Les données numériques sont alors chiffrées au moyen de la clé de chiffrement pour la diffusion des données vers le tiers, puis les données numériques sont diffusées vers le tiers.
La figure 1 représente de façon schématique un système 9 de contrôle d'accès à des données sécurisées. Le système 9 comprend des terminaux IA à In tels que des ordinateurs personnels, destinés à être utilisés par différents utilisateurs. Les terminaux IA àln ont respectivement accès à des bases de données 2 A à 2n typiquement mémorisées en local. Les terminaux IA à In sont aptes à communiquer avec des terminaux d'authentification 3A à 3n.
Les terminaux IA à In sont connectés à un réseau 4, en l'occurrence le réseau Internet. Un serveur 5 est connecté au réseau 4 et dispose d'un accès à une base de données 6. Un serveur de datation 7, tel qu'un serveur NTP, est connecté au réseau 4. Le serveur 7 pourra être utilisé pour réaliser la plupart des horodatages mis en œuvre dans le cadre de l'invention.
La figure 2 représente un terminal 1 et ses applications 11 à 17 destinées à être exécutées pour mettre en œuvre différentes fonctionnalités du contrôle d'accès. Ces applications 11 à 17 pourront être installées sous forme de clients légers sur le terminal 1.
La figure 3 représente un terminal d'authentification 3. Le terminal d'authentification 3 est destiné à permettre une authentification forte d'un utilisateur. Le terminal 3 comprend en l'occurrence un lecteur d'empreintes digitales 31, et un lecteur d'empreintes rétiniennes 34 afin de mettre en œuvre des mesures biométriques durant l' authentification. Le terminal 3 comprend également un écran 32 destiné à afficher des messages pour l'utilisateur. Le terminal 3 comprend de plus un récepteur 33 d'un signal de géolocalisation, par exemple un récepteur GPS.
Le terminal 3 comprend un module de traitement et de commande 38. Le module 38 est connecté à une interface d'entrée/sortie 37, par exemple une interface câblée ou radiofréquence, destinée à mettre le terminal 3 en communication avec le terminal 1. Le récepteur 33 de géolocalisation est connecté au module 38. Un support 35 de stockage sécurisé de données est connecté au module de traitement et de commande 38. Le module 38 est connecté aux lecteurs biométriques 31 et 34, et peut communiquer avec une base de données 36. La base de données 36 comprend une clé de chiffrement symétrique Kst pour les transmissions du terminal 3. Cette clé de chiffrement Kst sera avantageusement définie durant la fabrication du terminal 3 et mémorisée dans une mémoire non volatile. Le serveur 5 mémorise préalablement la clé symétrique Kst du terminal 3 pour assurer le décryptage des données qu'il reçoit en provenance de ce terminal 3.
Le terminal 3 est utilisé à la fois pour enregistrer des références d'authentification forte sur le serveur 5, et pour authentifier ensuite un utilisateur lors de ses accès au serveur 5 par comparaison entre ces références et une lecture instantanée de paramètres à comparer à ces références. Par une interface non représentée, par exemple un bouton-poussoir, l'utilisateur pourra définir le début ou la fin d'une session d'utilisation du terminal d'authentification 3.
En l'occurrence, lors d'une authentification d'un utilisateur, le terminal 3 mesure une empreinte biométrique par l'intermédiaire des lecteurs 31 et 34. Le terminal 3 peut également comporter un lecteur de cartes à puce et un clavier de saisie d'un code d'identification personnelle de la carte à puce. Dans ce cas, l'identifiant de la carte à puce est utilisé pour être comparé à la référence mémorisée dans le serveur 5. Durant l'authentification, le terminal 3 récupère par l'intermédiaire de son récepteur 33 un signal de géolocalisation. Le terminal 3 en extrait sa position et la date et l'heure en cours.
Lors de l'authentification, le terminal 3 transmet les données d'authentification (empreintes biométriques mesurées ou références de cartes à puce par exemple) et la date et l'heure extraites du signal de géolocalisation. Ainsi, en l'absence de disponibilité d'un serveur de datation, par exemple si seule une connexion au réseau local est disponible, on pourra réaliser malgré tout un horodatage de l'authentification forte. Cet horodatage pourra notamment permettre d'enrichir l'historique des accès d'un utilisateur au serveur ou permettre de restreindre des accès aux données sécurisées selon l'heure de l'authentification. Avantageusement, la position du terminal 3 est également transmise au serveur 5. Ainsi, la position de l'utilisateur pourra être prise en compte pour restreindre l'accès aux données sécurisées. Cette transmission est chiffrée au moyen de la clé de chiffrement symétrique Kst mémorisée dans le terminal 3.
Le support de stockage sécurisé 35 peut être de tout type approprié, par exemple un disque dur ou une mémoire de type EEPROM. Selon les droits d'accès aux données sécurisées, définis dans le certificat de politique d'accès détaillé ultérieurement, la mémorisation des données sécurisées dans le terminal 1 pourra être interdite. Les droits d'accès pourront exiger que les données sécurisées issues du serveur 5 soient mémorisées dans le support de stockage 35, consultées au moyen d'une application 17 par lecture du support 35, puis effacées du support 35 en fin de session d'utilisation. L'application 17 devra donc ainsi gérer le stockage de données dans le terminal 3. Les échanges entre l'application 17 et le support de stockage 35 seront avantageusement chiffrés. Les droits d'utilisation dans le certificat de politique d'accès défini par le propriétaire des données sécurisées pourront également s'appliquer à ses propres accès aux données sécurisées. Les données stockées sur le support 35 pourront faire l'objet d'un chiffrage matériel afin d'empêcher des accès frauduleux. Comme illustré à la figure 20, les données numériques issues de la base 66 et diffusées vers l'utilisateur du terminal 3 arrivent sur la carte réseau 18 du terminal 1. Les données sont stockées transitoirement dans le support 35 du terminal 3 au lieu d'être stockées dans un disque dur 19 du terminal 1. Les données stockées transitoirement par le support 35 sont alors traitées par l'unité centrale 111 ou transférées dans la mémoire vive 112, où ces données ne sont pas duplicables par un tiers fraudeur.
L'utilisation de la date extraite par le terminal 3 permettra également de renforcer la sécurité par croisement avec une valeur éventuellement récupérée sur un serveur de type NTP. Le terminal 3 est destiné à ne pas être nominatif. À cette fin, le terminal 3 efface toutes données nominatives de son utilisateur à la fin de la session, notamment toutes les données mémorisées sur le support 35. Le terminal 3 peut ainsi être utilisé successivement par des utilisateurs sans lien entre eux sans que leur information nominative ne soit vulnérable. Afin d'être compatible avec différents systèmes d'exploitation des terminaux de l'utilisateur, le terminal 3 inclura des API compatibles avec plusieurs types de systèmes d'exploitation. Le terminal 3 pourra ainsi être utilisé indifféremment par tous types d'utilisateurs, ce qui renforce sa capacité à être utilisé successivement par différents utilisateurs en fonction de leurs besoins. Le terminal 3 pourra envoyer des trames d'affichage sans que les données elles-mêmes ne soient enregistrables dans le terminal 1. Le terminal 3 pourra notamment disposer d'applications de lecture de différents formats de fichiers afin de permettre de visionner ces types de fichiers sur le terminal 1.
L'interface 37 pourra notamment être une interface sans fil (définie par une norme IEEE 802.11 ou par une norme IEEE 802.15) ou une interface câblée (RJ45 ou USB par exemple).
La figure 4 détaille un processus de génération d'un certificat numérique privé mis en œuvre au moyen de l'application 12. Durant l'étape 401, l'utilisateur renseigne des champs textuels relatifs à l'identité de l'entité propriétaire. Ces données comprendront par exemple un nom, un prénom, un nom de société, un représentant légal, des coordonnées etc .. L'utilisateur renseigne également tout autre champ pouvant faciliter son identification ou sa sélection par un filtrage.
Durant l'étape 402, une ou plusieurs références d'authentification forte sont capturées par l'intermédiaire du terminal d'authentification 3. La ou les références d'authentification forte sont transmises au terminal 1.
À l'étape 403, l'utilisateur choisit le type de protocoles cryptographiques et leurs différents paramètres de chiffrement. Ces choix définiront les paramètres pour le stockage et la transmission des données numériques de l'utilisateur. Ces paramètres pourront par exemple définir la taille des clés de chiffrement utilisées ou les algorithmes de chiffrement utilisés.
À l'étape 404, l'ensemble des données récupérées par le terminal 1 est chiffré au moyen de la clé symétrique Kst mémorisée dans le terminal 3.
À l'étape 405, le terminal 1 transmet les données chiffrées au serveur 5.
À l'étape 406, le serveur 5 génère le certificat numérique privé CePr et le stocke dans la base de données 6. Le serveur 5 génère dynamiquement les différentes clés de chiffrement incluses dans le certificat privé CePr et génère une première clé de chiffrement symétrique KeSl qu'il associe à la référence d'authentification forte de l'utilisateur. Le certificat privé CePr est chiffré avec cette clé
KeSl.
À l'étape 407, le serveur 5 génère un certificat public CePc associé au certificat numérique privé CePr, et publie ce certificat public CePc. L'utilisateur pourra limiter ou interdire la publication ou la consultation du certificat public CePc à sa convenance. L'utilisateur pourra utiliser l'application
11 ultérieurement pour définir si la publication du certificat public CePc est autorisée, restreinte ou interdite (par exemple si le certificat public est visible uniquement sur invitation émise par l'entité propriétaire). Les certificats publics pourront être publiés dans un annuaire dédié et être rendus publics à tout utilisateur en fonction des restrictions de publication.
Le certificat numérique privé CePr pourra également être complété ultérieurement au moyen de l'application 12, pour inclure des informations sans incidence sur les chiffrements. L'entité propriétaire pourra par exemple compléter des champs d'information de son certificat numérique privé, par exemple en précisant l'adresse réseau d'un serveur mémorisant les données numériques chiffrées. Le certificat numérique privé CePr contient ainsi les données essentielles de l'identité de son entité propriétaire ainsi que les données utiles au cryptosystème.
Le certificat numérique privé CePr contient notamment :
-une ou plusieurs références d'authentification forte (par exemple l'empreinte digitale ou l'empreinte rétinienne de l'entité propriétaire) ;
-optionnellement un certificat de l'entité propriétaire au format X. 509 ;
-une deuxième clé de chiffrement symétrique KeS2 dédiée au chiffrement des données sécurisées de l'entité propriétaire durant leur stockage dans la base de données 6;
-une troisième clé de chiffrement symétrique KeS3 destinée au chiffrement des flux de données sécurisées diffusés depuis la base de données 6 vers l'entité propriétaire elle-même;
-une quatrième clé de chiffrement symétrique KeS4 destinée au chiffrement d'un certificat de politique d'accès;
-un couple de clés de chiffrement asymétrique Kpr et Kpc, destiné au chiffrement/déchiffrement de certificats négociés avec d'autres entités. En particulier, le certificat numérique privé pourra comprendre les champs suivants :
-VaI FPT : image binaire d'une ou plusieurs empreintes digitales ;
-VaI Kp : Valeur du couple de clés de chiffrement asymétrique Kpr et Kpc ;
-Info Kp : Information du protocole cryptographique asymétrique retenu;
-VaI Ks : Valeur de la clé de chiffrement symétrique KeS2; -Info Ks : Information du protocole cryptographique symétrique retenu ;
-Import_X.509 : possibilité d'importer un certificat numérique de la norme X.509...
-CRC : somme de contrôle d'intégrité de l'ensemble des champs ;
-SN : numéro de série unique dudit certificat numérique privé CePr.
Le serveur 5 pourra disposer d'un couple de clés de chiffrement asymétrique pour générer le champ CRC d'un certificat numérique privé. La valeur du champ CRC est calculée à partir d'une fonction de hachage non réversible appliquée aux informations contenue dans ce certificat numérique privé. La clé privée de ce couple de clés permet de chiffrer le résultat de la fonction de hachage pour générer le champ CRC du certificat numérique privé. Le propriétaire de ce certificat numérique privé pourra ainsi prouver par une procédure particulière de contrôle du serveur 5, que ce certificat a bien été émis par ledit serveur. Avantageusement, la procédure de contrôle permettra au serveur 5 de contrôler l'authenticité d'un certificat numérique privé importé par son propriétaire de la manière suivante :
-application de la fonction de hachage non réversible aux informations contenues dans le certificat numérique privé importé. Le résultat noté CRC temp est temporairement stocké par le serveur 5 ;
-chiffrement du résultat CRC temp avec la clé privée du couple de clés de chiffrement asymétrique du serveur 5. Le résultat de ce chiffrement est noté CRC temp sig ;
-comparaison de CRC temp sig avec le champ CRC du certificat numérique privé encore stocké dans le serveur. D'autres moyens de contrôle pourront être mis en œuvre par le serveur, notamment par le déchiffrement du champ CRC importé au moyen de la clé publique du serveur.
La clé de chiffrement symétrique KeS2 sera de préférence dimensionnée pour réaliser un chiffrement fort des données numériques stockées. La clé de chiffrement de diffusion symétrique
KeS3 (ainsi que la clé de diffusion vers un tiers Kse détaillée ultérieurement) sera davantage dimensionnée afin de permettre une transmission et un temps de traitement réduit des données sécurisées transmises. Cette clé de chiffrement KeS3 symétrique (ainsi que la clé de diffusion vers un tiers Kse détaillée ultérieurement) pourra par exemple être du type 3DES et présenter une taille comprise entre 64 et 192 bits.
Le certificat public CePc permet de garantir l'existence de son certificat numérique privé associé CePr, ce qui permet d'initier par la suite des négociations pour l'accès aux données par un tiers. Le certificat public CePc est lié mathématiquement au certificat numérique privé associé, de sorte qu'un tiers souhaitant vérifier la validité de ce certificat CePc puisse requérir une vérification effectuée par le serveur 5. Le certificat public CePc pourra comprendre une signature numérique du certificat privé associé CePr, par exemple une signature par une fonction de hash. Un tiers pourra ainsi soumettre un certificat public CePc au serveur 5 qui vérifiera le lien mathématique avec son certificat numérique privé associé. La recherche et la consultation de certificats publics de tiers pourra être effectuée au moyen de l'application 16.
Le certificat public CePc pourra comprendre les champs suivants :
-Info User : données restreintes d'identification du détenteur légitime du certificat numérique privé telles que le Nom, Prénoms, Pseudonyme, ... ; -Hash : empreinte numérique du certificat numérique CePr garantissant le lien mathématique avec le certificat numérique privé ;
-DHC : Date horodatée de création ;
-SN : numéro de série unique dudit certificat numérique CePc.
Le certificat numérique public CePc et le certificat numérique privé CePr pourront être irrévocables et présenter une durée de validité illimitée.
Lors de la création du certificat numérique privé CePr, un certificat de politique d'accès temporaire est avantageusement créé pour définir la politique d'accès qui sera appliquée pour la diffusion des données numériques. Le certificat de politique d'accès temporaire pourra prévoir des droits d'accès très restrictifs par défaut, par exemple une diffusion limitée seulement à l'entité propriétaire.
L'application 16 permet à un utilisateur de rechercher des certificats numériques publics d'autres entités propriétaires. L'application 16 permet notamment d'interroger une base de données de certificats numériques publics et de sélectionner des certificats publics dont le contenu répond à des critères définis par l'utilisateur. L'application 16 permet de visionner les informations fournies par un certificat numérique public sélectionné. L'application 16 peut être déportée et être réalisée sous la forme d'un moteur de recherche consultable par l'intermédiaire d'Internet.
Par l'intermédiaire de leur application 13, suite à une invitation du propriétaire des données, ou suite à une requête du tiers, les deux utilisateurs initient un processus de négociation. Les échanges initiaux entre les utilisateurs pourront être signés, horodatés puis stockés par le serveur 5. La figure 5 détaille le processus de négociation de droits d'accès entre l'entité propriétaire des données sécurisées et un tiers. Le tiers peut lui-même être détenteur de données sécurisées, et la négociation peut conduire à définir un droit d'accès réciproque aux données sécurisées des deux entités. Les utilisateurs réalisent cette négociation par l'intermédiaire de leur application 13 destinée à créer un certificat numérique négocié CeNe. Les échanges entre les utilisateurs et le serveur 5 sont sécurisés par un chiffrement adéquat.
À l'étape 501, le tiers s'authentifie par une authentifïcation forte auprès du serveur 5.
L'application 15 permet notamment de transmettre des données biométriques lues sur le terminal 3 au serveur 5. Les données transmises par le terminal 1 du tiers sont comparées à une référence d'authentification forte mémorisée au préalable sur le serveur 5. Le tiers émet une requête de négociation d'accès aux données sécurisées à destination du propriétaire de ces données. À l'étape 502, l'entité propriétaire s'authentifie par une authentification forte auprès du serveur 5. L'entité propriétaire accepte la requête de négociation. L'entité propriétaire renvoie une proposition définissant les conditions de l'accès à ces données sécurisées. L'entité propriétaire peut notamment proposer un type de protocole cryptographique pour la transmission des données sécurisées, un type de publication souhaitée d'un certificat numérique public correspondant au certificat négocié CeNe, ou définir la durée de vie de ce certificat numérique négocié (la révocation automatique du certificat pouvant être gérée par le serveur 5). Différents types de publication du certificat numérique négocié pourront être envisagés, soit par mise à jour de leur certificat numérique public respectif, soit par une publication du certificat numérique public correspondant soit par un maintien secret de ce certificat.
À l'étape 503, les conditions de l'accès aux données sécurisées peuvent éventuellement faire l'objet d'une négociation préalable. À l'issue de cette négociation, les utilisateurs signent et transmettent leur acceptation des conditions au serveur 5. La signature pourra être réalisée avec leur clé privée contenue dans leur certificat numérique privé respectif. La signature pourra être effectuée sur un hash des valeurs des paramètres négociés. Leur acceptation est horodatée et stockée par le serveur 5.
À l'étape 504, le serveur 5 crée et mémorise un certificat numérique négocié CeNeaB pour le tiers et un certificat numérique négocié CeNeAb pour l'entité propriétaire. Ces certificats CeNeaB et CeNeAb sont chiffrés respectivement avec la clé publique KpcB et la clé publique KpcA contenues respectivement dans les certificats numériques privés CePrB et CePrA. L'accès aux données du certificat négocié est ainsi sécurisé à la fois par l' authentification forte et par une authentification cryptographique au moyen d'une clé privée. Pour simplifier, on considère que A est une entité propriétaire de données numériques et que B est un tiers pour ces données. Cependant, B peut être une entité propriétaire de données numériques stockées dans la base 66. A est alors considéré comme un tiers pour ces données. Une même clé de chiffrement symétrique KeSe peut être utilisée pour la diffusion des données numériques vers l'entité non propriétaire de ces données. On peut également envisager que les certificats CeNeaB et CeNeAb comprennent respectivement des clés de chiffrement de diffusion KeSeB et KeSeA pour la diffusion respectivement vers B et A en tant que tiers.
Ces certificats négociés peuvent comprendre les champs suivants : -SN : numéro de série unique dudit certificat numérique.
-TTL : période de validité du certificat ;
-Val Emp : empreintes numériques des certificats numériques privés utilisés durant sa génération ;
-VaI Ks : Valeur de la clé de chiffrement symétrique de diffusion vers l'entité titulaire du certificat négocié ;
-Info Ks : Information sur le protocole de chiffrement symétrique retenu; -Import_X.509 : possibilité d'importer un certificat numérique de la norme X.509... -Hash : somme de contrôle d'intégrité de l'ensemble des champs ;
La figure 6 illustre un processus d'accès au certificat numérique privé d'un utilisateur. Ce processus est notamment mis en œuvre lors de la mise à jour du certificat privé, ou lors de toute opération d'accès aux données sécurisées.
Durant une étape 601, l'utilisateur lance l'application 12 sur son terminal 1. Durant une étape
602, le terminal 1 détecte la présence du terminal d'authentification 3. Durant une étape 603, le terminal 3 lit une information d'authentification entrée par l'utilisateur, par exemple son empreinte digitale sur le lecteur 31. Durant une étape 604, l'information d'authentification lue est transmise de façon chiffrée (avec la clé Kst) vers le terminal 1. Durant une étape 605, le terminal 1 transmet de façon chiffrée l'information d'authentifïcation lue au serveur 5. Durant une étape 606, le serveur 5 consulte la base de données biométriques 65 et compare l'information d'authentifïcation lue avec la référence mémorisée. Durant l'étape 606, le serveur 5 compare également les informations d'horodatage générées par le terminal 3 avec des informations d'horodatage fournies par le serveur 7. À la fin de l'étape 606, une fois l'utilisateur authentifié, la clé de chiffrement symétrique KeS 1 associée à la référence d'authentifïcation mémorisée est montée en mémoire dans le serveur 5. Une clé symétrique est particulièrement appropriée pour chiffrer le certificat numérique privé puisque seul le propriétaire du certificat numérique privé l'utilise directement. Le certificat numérique privé de l'utilisateur stocké dans la base de données 62 est alors déchiffré au moyen de cette clé KeS 1 à l'étape 607. À l'étape 608, les valeurs contenues dans le certificat numérique privé et utiles pour des opérations ultérieures sont montées en mémoire dans le serveur 5. Un couple de clés de chiffrement asymétrique Kpc et Kpr est notamment chargé en mémoire, afin de permettre le chiffrement ou le déchiffrement du certificat négocié CeNe.
La figure 7 illustre un processus d'accès aux différents certificats négociés dont l'utilisateur est détenteur. À l'étape 701, l'utilisateur lance l'application 13 sur son terminal 1. Les étapes 702 à 705 d'authentification forte sont identiques aux étapes 602 à 605. À l'étape 706, le serveur 5 consulte la base de données biométriques 65 et compare l'information d'authentification lue avec la référence mémorisée à la fin de l'étape 706, une fois l'utilisateur authentifié, la clé privée KPr du couple de clés asymétriques est chargée en mémoire. À l'étape 707, les certificats négociés de l'utilisateur mémorisés dans la base de données 63 sont déchiffrés au moyen de cette clé privée Kpr. À l'étape 708, la liste de ses certificats négociés est transmise à l'utilisateur. La transmission de cette liste est chiffrée au moyen d'une clé de session Kse2.
La figure 8 illustre un processus de définition du certificat de politique d'accès de l'utilisateur propriétaire des données numériques. Lors d'une étape 801, l'entité propriétaire A lance l'application 14 sur son terminal 1. Le terminal 1 détecte la présence du terminal d'authentification 3. Durant une étape 802, une authentification forte de l'entité propriétaire est réalisée comme détaillé auparavant. À la fin de l'étape 802, une fois l'entité propriétaire authentifiée, sa clé de chiffrement symétrique KeSlA associée à sa référence d'authentification est chargée dans le serveur 5. Le certificat numérique privé CePrA est alors déchiffré au moyen de cette clé KeSlA à l'étape 803. La clé de chiffrement symétrique KeS4A est alors chargée dans le serveur 5 à l'étape 804. A l'étape 805, l'entité propriétaire définit des droits d'accès : quelle entité a un droit d'accès aux données numériques, quels droits sont associés à chaque entité (lecture, modification, recopie, chargement limité à un support d'un terminal d'authentification...), des restrictions d'accès en fonction du lieu, de l'heure ou du matériel de connexion au serveur 5. Le certificat de politique d'accès pourra également définir si un historique des accès doit être mémorisé et si un historique des accès doit être inclus dans les données numériques diffusées, formant un marqueur pour ces données. Un certificat de politique d'accès CeSeA contenant ces informations est généré à l'étape 806. Le certificat de politique d'accès CeSeA est chiffré avec la clé KeS4A à l'étape 807. Le certificat de politique d'accès CeSeA est mémorisé dans la base de données 64 à l'étape 808. L'entité propriétaire pourra sélectionner des paramètres de contrôle d'accès par défaut proposés par le serveur 5 lors de la création du certificat de politique d'accès CeSe. L'entité propriétaire pourra par exemple utiliser une base de connaissance de modèles de certificats de politique d'accès pour générer son propre certificat de politique d'accès.
L'entité propriétaire pourra accéder ultérieurement à son certificat de politique d'accès par une authentification forte afin de modifier les droits d'accès définis pour des tiers ou pour lui-même à ses données numériques. De préférence, le certificat numérique de politique d'accès, CeSe, comprend au moins les champs suivants :
SN : numéro de série unique de ce certificat numérique ; SN CeNe : numéro de série unique correspondant au CeNe ; - IPS : Index des paramètres de sécurité correspondant au(x) modèle(s) de politique d'accès importé(s).
La figure 9 représente le processus de diffusion des données numériques de l'entité propriétaire vers le tiers authentifié. Lors d'une étape 901, le tiers B lance l'application 17 sur son terminal 1. Le terminal 1 détecte la présence du terminal d'authentification 3. Durant une étape 902, une authentification forte de l'utilisateur B est réalisée comme détaillé auparavant. À la fin de l'étape 902, une fois l'utilisateur B authentifié, sa clé de chiffrement symétrique KeSlB associée à sa référence d'authentification est chargée dans le serveur 5. Le certificat numérique privé CePrB est alors déchiffré au moyen de cette clé KeSlB à l'étape 903. A l'étape 904, le certificat numérique négocié CeNeaB est déchiffré au moyen de la clé privée KprB. Lors d'une étape 905, la clé de diffusion KseB pour la diffusion des données numériques vers B est alors chargée dans le serveur 5. A l'étape 906, la clé de chiffrement KeS4A est extraite du certificat CePrA et chargée dans le serveur 5. A l'étape 907, le certificat de politique d'accès CeSeA est déchiffré avec la clé KeS4A. Les droits d'accès sont lus par le serveur 5. A l'étape 908, le serveur 5 valide l'accès aux données numériques pour le tiers B. Le serveur 5 charge alors en mémoire la clé de chiffrement de stockage KeS2A depuis le certificat CePrA et déchiffre les données numériques de l'entité propriétaire mémorisées dans la base 66. A l'étape 909, les données à diffuser sont chiffrées avec la clé de chiffrement de diffusion KSeB. A l'étape 910, les données chiffrées sont diffusées vers le tiers B. L'application 17 permet à l'utilisateur du terminal 1 vers lequel des données ont été diffusées de visionner leur contenu.
Avantageusement, les données à diffuser vers le tiers B sont également chiffrées avec une clé de chiffrement symétrique KeMaB basée sur la configuration matérielle du terminal 1 et/ou du terminal 3 du tiers B. La clé de chiffrement KeMaB sera par exemple basée sur l'adresse physique de la carte réseau 18 du terminal 1, sur des références de disque dur du terminal 1, sur une valeur de l'horloge système du terminal 1 ou du terminal 3, ou sur les références du processeur du terminal 1.
La clé de chiffrement KeMaB sera typiquement générée à chaque session d'accès aux données chiffrées. La clé de chiffrement KeMaB sera par exemple stockée dans le certificat négocié CeNeaB ou dans un certificat numérique matériel CeMaB.
De préférence, les certificats numériques matériels CeMa, comprendront au moins les champs suivants :
SN : numéro de série unique dudit certificat numérique CeMa ; - MAC : adresse physique de la carte réseau 18 du terminal 1 ;
SND : numéro de série du disque dur 19 correspondant au terminal 1; SNP : numéro de série du processeur 111 du terminal 1 ;
SNA : numéro de série du dispositif d'authentification 3 connecté au terminal 1. Lorsque l'entité propriétaire A souhaitera la diffusion de ses données numériques vers elle- même, on réalisera l' authentification forte de A, le déchiffrement de son certificat numérique privé avec la clé KeSlA, le déchiffrement de son certificat de politique d'accès KeSeA avec la clé KeS4A, le déchiffrement de ses données numériques avec la clé KeS2A, le chiffrement des données à diffuser avec la clé KeS3A, puis la diffusion des données numériques vers A.
De préférence, la phase d'authentification s'applique à chacune des requêtes transmises au serveur via un terminal fixe ou mobile. Chaque processus comprenant alors initialement une authentification forte, l'historique des accès aux données sécurisées est particulièrement précis, et chaque étape pouvant impliquer un accès à des données sensibles est sécurisée.
Comme illustré à la figure 10, la base de données 6 comprend une base de certificats publics 61, une base de certificats numériques privés 62, une base de certificats négociés 63, une base de certificats de politique d'accès 64, une base de références biométriques 65, une base de stockage de données numériques chiffrées 66 et une base de protocoles cryptographiques 67.
Pour des raisons de sécurité, les différentes clés de chiffrement ne sont pas fournies aux utilisateurs mais seulement chargées en mémoire par le serveur 5 en vue de leur utilisation pour les différentes opérations de chiffrement/déchiffrement. Le serveur 5 chargera en mémoire les clés requises seulement lorsqu'une authentification d'un utilisateur émettant une requête d'accès est validée. Ainsi, la mémorisation de clés d'un certificat privé d'un premier utilisateur dans son certificat négocié ne permet pas à un second utilisateur titulaire du certificat négocié d'obtenir les clés du premier utilisateur. La base de données 61 comprend les certificats publics des différents utilisateurs du serveur
5. Les certificats publics pour lesquels l'accès n'est pas restreint sont accessibles par un annuaire ou un moteur de recherche exécuté sur le serveur 5.
La base de données des protocoles cryptographiques 67 contient les différents cryptosystèmes nécessaires pour réaliser les chiffrements/déchiffrements au niveau du serveur 5. La figure 11 représente une phase de création d'un nouveau certificat négocié à partir de deux certificats négociés existants. Les détenteurs A et B des certificats numériques privés CePrA et CePrB, et les détenteurs C et D des certificats numériques privés CePrC et CePrD ont préalablement créé respectivement les certificats négociés CeNeAb, CeNeaB, CeNeCd et CeNecD. Les certificats publics CePcAb CePcaB, CePcCd et CePccD correspondant à ces certificats négociés CeNeAb, CeNeaB, CeNeCd et CeNecD sont publiés dans un annuaire. L'utilisateur B (détenteur du certificat CeNeaB) et l'utilisateur C (détenteur du certificat CeNeCd) souhaitant définir des accès à des données numériques de l'un ou de l'autre, s'authentifient auprès du serveur 5, et négocient la création de nouveaux certificats négociés CeNeaBcd et CeNeabCd. Des certificats publics CePcaBcd et CePcabCd permettront aux utilisateurs B et C de négocier à nouveau la création d'un certificat négocié avec une autre entité. Bien qu'on ait décrit cette solution basée sur la négociation à partir de certificats négociés, la création et la négociation d'un nouveau certificat négocié pourra être basée sur un ou plusieurs certificats numériques privés et un ou plusieurs certificats négociés.
Ce processus de création du nouveau certificat négocié n'est pas une faille de sécurité pour les détenteurs de certificats négociés ne participant pas à cette négociation : en effet, l'utilisation de leur certificat négocié pour créer un nouveau certificat négocié n'implique pas un accès mutuel à leurs données sécurisées. En effet, ces détenteurs conservent leur certificat de politique d'accès pour définir les droits d'accès à leurs données numériques et peuvent donc interdire un accès aux détenteurs du nouveau certificat négocié. Le nouveau certificat négocié constitue ainsi seulement une étape vers l'accès aux données sécurisées, chaque détenteur étant alors libre de définir le certificat de politique d'accès à ses propres données sécurisées et correspondant à ce nouveau certificat négocié. Une telle procédure permet de mettre en place aisément des outils de diffusion vers un tiers des données numériques d'une entité propriétaire, même lorsque celle-ci n'a pas encore une confiance absolue dans ce tiers : l'entité propriétaire reste libre de fournir des droits d'accès au tiers progressivement, une fois que l'entité propriétaire a la garantie de pouvoir faire confiance au tiers. Les figures 12 à 18 représentent des exemples de datagrammes d'échanges visant à permettre la diffusion des données chiffrées. Pour réaliser le déchiffrement des données numériques diffusées vers le tiers autorisé, celui-ci doit disposer au préalable de la clé de chiffrement symétrique utilisée pour la diffusion.
La figure 12 représente un datagramme d'un paquet d'une requête émise par le tiers autorisé vers le serveur 5 et destinée à établir une clé de chiffrement symétrique matérielle KCeMa pour la diffusion des données. Le premier champ IDS est un identifiant numérique de la session de diffusion de données. Le second champ ID CePr est un identifiant unique du certificat numérique privé de l'entité propriétaire. Le troisième champ ID CeNe est un identifiant unique du certificat numérique négocié de l'entité propriétaire avec le tiers autorisé. Le quatrième champ ID CePr' est un identifiant unique du certificat numérique privé du tiers autorisé. Le cinquième champ Ord est le numéro du paquet parmi les différents paquets destinés à établir la clé de chiffrement matérielle. Le sixième champ Qr indique si l'échange concerne une requête de l'utilisateur ou une réponse du serveur. L'intégrité des sept premiers champs du paquet de la figure 12 est garantie par le champ Checksum, contenant une somme de contrôle d'intégrité de ces champs. L'authentification des huit premiers champs est garantie par le champ K CePr qui est une signature de l'ensemble de ces champs à partir de la clé privée contenue dans le certificat privé de l'entité propriétaire. L'ensemble des champs est chiffré au moyen d'une clé de chiffrement symétrique Kst du terminal 3.
La figure 13 représente un datagramme d'un paquet d'une réponse transmise par le serveur 5 vers le tiers autorisé et destinée à lui fournir la clé de chiffrement symétrique utilisée pour la diffusion des données. Les six premiers champs ont une fonction identique à ceux du datagramme de la figure 12. Le septième champ Val_K_217 contient la clé de chiffrement symétrique de diffusion. Cette clé combine la clé de chiffrement matérielle transmise par le tiers autorisé avec une clé de session se trouvant dans le certificat négocié. Le champ Checksum Histo est une somme cumulée de contrôle d'intégrité de l'ensemble des paquets. L'authentification des huit premiers champs est garantie par le champ K CePr qui est une signature de l'ensemble de ces champs à partir de la clé privée contenue dans le certificat privé de l'entité propriétaire. L'ensemble des champs est chiffré au moyen de la clé de chiffrement symétrique K CeMa transmise dans le paquet de la figure 12.
La figure 14 représente un datagramme d'un paquet d'une demande d'accusé de réception d'une requête d'accès du tiers autorisé aux données numériques de l'entité propriétaire. Les quatre premiers champs du paquet ont la même fonction que les champs des datagrammes des figures 12 et 13. Le cinquième champ ID F contient un identifiant numérique d'un fichier numérique auquel l'accès est requis. Les sixième et septième champs correspondent aux cinquième et sixième champs des datagrammes des figures 12 et 13. Le huitième champ NTP comprend un horaire d'un organisme officiel, soit fourni par le terminal 3, soit fourni par un serveur NTP. Le neuvième champ CeSe#CePr contient un index de paramètres de politique d'accès encapsulés. Le dixième champ Q AR identifie une requête d'accusé de réception. Le onzième champ VaI-SHA contient une valeur de contrôle d'intégrité du fichier à diffuser. Le champ Checksum Histo est une somme cumulée de contrôle d'intégrité de l'ensemble des paquets. Le champ KcePr est une signature de l'ensemble de ces champs à partir de la clé privée contenue dans le certificat privé de l'entité propriétaire. L'ensemble des champs du paquet est chiffré au moyen de la clé K 217. La figure 15 représente un datagramme d'un paquet d'un accusé de réception du serveur transmis au tiers autorisé. Les neuf premiers champs du paquet ont la même fonction que les champs du paquet de la figure 14. Le dixième champ R AR identifie un accusé de réception. Le onzième champ KcePr est une signature de l'ensemble de ces champs à partir de la clé privée contenue dans le certificat privé de l'entité propriétaire. Le champ Options contient un code de qualification (valider, archiver, bon pour accord...) du fichier à diffuser et est associé à la signature KCePr'. Le champ VaI- SHA contient une valeur de contrôle d'intégrité du fichier à diffuser. Le champ Checksum Histo est une somme cumulée de contrôle d'intégrité de l'ensemble des paquets précédents. Le champ KCePr' contient une signature de l'ensemble des champs précédents par la clé privée du certificat numérique du tiers autorisé. L'ensemble des champs du paquet est chiffré avec la clé K 217.
La figure 16 est un datagramme simplifié d'un paquet du flux de données numériques de l'entité propriétaire diffusées vers le tiers autorisé. Le premier champ définit l'ordre du paquet dans le flux, le second champ identifie que le paquet correspond à une réponse du serveur, le troisième champ comprend les données numériques diffusées, le cinquième champ comprend une somme cumulée de contrôle d'intégrité de l'ensemble des paquets précédents. Le champ KCePr contient une signature de l'ensemble des champs précédents par la clé privée du certificat numérique de l'entité propriétaire. L'ensemble des champs du paquet est chiffré avec la clé K 217.
La figure 17 est un datagramme d'un paquet d'une demande d'accusé de réception de la fin de la diffusion des données numériques, transmise du tiers autorisé vers le serveur. Les huit premiers champs du paquet ont la même fonction que les champs des paquets des figures 14 et 15. Le neuvième champ R AR identifie une requête d'accusé de réception. Le champ SG# est destiné à propager une nouvelle clé secrète d'initialisation de serveur dans le terminal 3. Cette clé permettra notamment de sécuriser les premiers échanges entre le terminal et le serveur 5. Le champ Checksum Histo est une somme cumulée de contrôle d'intégrité de l'ensemble des paquets précédents. Le champ KCePr contient une signature de l'ensemble des champs précédents par la clé privée du certificat numérique de l'entité propriétaire. L'ensemble des champs du paquet est chiffré avec la clé K 217. La figure 18 est un datagramme d'un paquet d'un accusé de réception de la fin de la diffusion des données numériques, transmise du serveur vers le tiers autorisé. Les huit premiers champs du paquet ont la même fonction que les champs des paquets des figures 14 et 15. Le neuvième champ AR identifie un accusé de réception. Le champ KcePr est une signature de l'ensemble des champs précédents à partir de la clé privée contenue dans le certificat privé de l'entité propriétaire. Le champ Options contient un code de qualification du fichier diffusé et est associé à la signature KCePr'. Le champ VaI-SHA contient une valeur de contrôle d'intégrité du fichier diffusé. Le champ Checksum Histo est une somme cumulée de contrôle d'intégrité de l'ensemble des paquets précédents. Le champ KCePr' contient une signature de l'ensemble des champs précédents par la clé privée du certificat numérique du tiers autorisé. L'ensemble des champs du paquet est chiffré avec la clé K 217. La figure 19 représente le format de stockage de données numériques d'une entité propriétaire durant leur stockage dans le serveur. Le champ ID correspond à l'identifiant des données numériques stockées. Le champ NTP contient des informations d'horodatage des données stockées, par exemple la date de dernière modification de ces données. Le champ TOS pour 'Type Of Service' définit le type de service associé aux données. Le champ TTL cache définit la durée de vie des données numériques stockées et facilite l'archivage de ces données. Le champ Metadata contient des informations d'indexation des données numériques stockées. Le champ ID CePr contient l'identifiant unique du certificat numérique privé de l'entité propriétaire. VaI SHA comprend une valeur de vérification d'intégrité des données numériques stockées. Le champ suivant est une signature par la clé privée de l'entité propriétaire de l'ensemble des champs précédents. Le champ Data comprend les données numériques de l'entité propriétaire elles-mêmes. Le champ Histo comprend l'historique de l'ensemble des accès aux données numériques stockées. Le champ Histo pourra notamment comprendre les datagrammes des figures 15 et 18. Le champ Checksum file est une somme de contrôle des données numériques stockées. Le champ suivant est une signature par la clé privée de l'entité propriétaire de l'ensemble des champs précédents. La figure 21 illustre un procédé de diffusion des données à destination du tiers autorisé. Lors d'une première étape, les données numériques stockées de l'entité propriétaire sont déchiffrées. Des paquets de données destinés à la diffusion sont formés et font l'objet d'une encapsulation optimisée.
Les paquets à diffuser sont chiffrés au moyen de la clé de chiffrement de diffusion du tiers autorisé.
Les paquets de données sont compressés avant leur diffusion. Le terminal du tiers autorisé décompresse les paquets de données reçues, déchiffre les données numériques et réalise un chiffrement pour le stockage de ces données dans le terminal. Les données sont transmis à un module pour leur visualisation par le tiers autorisé.
Dans l'exemple, le serveur 5 est accessible par les utilisateurs par l'intermédiaire d'Internet.
On pourrait également envisager que le serveur 5 soit un serveur d'entreprise accessible en réseau local. Le serveur 5 ne permet la visualisation et l'accès à un certificat numérique privé qu'à son entité propriétaire.
Dans l'exemple, bien qu'on ait illustré un seul serveur 5, les fonctions réalisées peuvent être réparties sur différents serveurs. De même, bien qu'on ait illustré une seule base de données 6, les différents contenus décrits pourront être stockés dans différentes bases de données distantes.
Avantageusement, tous les certificats numériques susmentionnés (CePr, CePu, CeNe, CeSe, CeMa) sont stockés sur un ou plusieurs serveurs distants sécurisés dans une base de données selon une architecture client/serveur adaptée.

Claims

REVENDICATIONS
1. Procédé de diffusion sécurisée de données numériques chiffrées d'une entité propriétaire (A), ces données étant mémorisées dans un module de stockage (66) d'un serveur (5), comprenant les étapes de :
-dans un module d'authentification hébergé par un serveur (5), réaliser une authentification forte d'un tiers (B) requérant la diffusion des données numériques chiffrées de l'entité propriétaire ; -une fois le tiers (B) authentifié, déchiffrer un certificat numérique privé (CePrB) du tiers avec une première clé de chiffrement symétrique (KeSlB) dédiée au tiers authentifié, le certificat numérique privé du tiers (CePrB) étant mémorisé dans un module de stockage (62) d'un serveur et comprenant un couple de clés (KprB, KpcB) de chiffrement asymétrique;
-au moyen de la clé privée (KprB) dudit couple de clés, déchiffrer un certificat numérique négocié (CeNeaB) préalablement avec l'entité propriétaire (A) et comprenant une clé de chiffrement symétrique (KseB) pour la diffusion des données vers le tiers authentifié, le certificat numérique négocié (CeNeaB) étant mémorisé dans un module de stockage (63) d'un serveur ;
-une fois que le certificat numérique négocié (CeNeaB) est déchiffré, lire un certificat de politique d'accès (CeSeA) établi par l'entité propriétaire (A) et définissant les droits d'accès aux données numériques chiffrées de l'entité propriétaire, le certificat de politique d'accès étant mémorisé dans un module de stockage (64) d'un serveur ; -si le certificat de politique d'accès autorise le tiers (B) à accéder aux données numériques chiffrées de l'entité propriétaire, déchiffrer les données numériques chiffrées avec une clé de chiffrement symétrique de stockage (KeS2A) contenue dans un certificat numérique privé (CePrA) de l'entité propriétaire (A), ce certificat numérique privé (CePrA) étant mémorisé dans un module de stockage (62) d'un serveur ; -chiffrer les données numériques au moyen de la clé de chiffrement (KseB) pour la diffusion des données numériques vers le tiers authentifié et diffuser ces données numériques vers le tiers authentifié (B).
2. Procédé de diffusion sécurisée selon la revendication 1, dans lequel la lecture du certificat de politique d'accès (CeSeA) établi par l'entité propriétaire (A) comprend le déchiffrement préalable de ce certificat (CeSeA) avec une clé de chiffrement symétrique (KeS2A, K2S4A) contenue dans le certificat numérique privé (CePrA) de l'entité propriétaire (A).
3. Procédé de diffusion sécurisée selon la revendication 2, dans lequel la clé de chiffrement symétrique (KeS4A) utilisée pour déchiffrer le certificat de politique d'accès est distincte de la clé de chiffrement symétrique de stockage (KeS2A).
4. Procédé de diffusion sécurisée selon l'une quelconque des revendications précédentes, dans lequel l'obtention de la clé de chiffrement symétrique de stockage (KeS2A) comprend le déchiffrement du certificat numérique privé au moyen d'une première clé de chiffrement symétrique (KeSlA) dédiée à l'entité propriétaire.
5. Procédé de diffusion sécurisée selon la revendication 4, comprenant préalablement :
-la saisie d'informations relatives à l'identité de l'entité propriétaire des données numériques ; -la génération du certificat numérique privé (CePrA) de l'entité propriétaire (A) contenant lesdites informations relatives à son identité et contenant ladite clé de chiffrement symétrique de stockage (KeS2A) ; -la saisie d'un élément d'authentification forte de l'entité propriétaire des données et son stockage dans un module de stockage (65) d'un serveur ; -la génération de ladite première clé de chiffrement symétrique (KeSlA) dédiée à l'entité propriétaire et l'association de cette clé à l'élément d'authentification forte saisi ; -chiffrer le certificat numérique privé (CePrA) de l'entité propriétaire avec sa première clé de chiffrement symétrique (KeSlA) et mémoriser le certificat numérique privé chiffré dans un module de stockage (62) d'un serveur.
6. Procédé de diffusion sécurisée selon la revendication 5, comprenant :
-la définition de paramètres de chiffrement par l'entité propriétaire (A) pour le stockage et l'accès à ses données numériques ;
-la génération de la première clé de chiffrement symétrique (KeSlA) dédiée à l'entité propriétaire et la génération de la clé de chiffrement symétrique de stockage (KeS2A) en fonction des paramètres définis.
7. Procédé de diffusion sécurisée selon l'une quelconque des revendications précédentes, comprenant la récupération d'informations sur la configuration matérielle d'un terminal du tiers, la génération d'une clé de chiffrement symétrique basée sur ces informations, la mémorisation de cette clé de chiffrement (KeMa) dans le certificat numérique négocié (CeNeaB), le chiffrement des données numériques à diffuser au moyen de cette clé de chiffrement (KeMa).
8. Procédé de diffusion sécurisée selon l'une quelconque des revendications précédentes, comprenant :
-la génération d'un certificat numérique public de l'entité propriétaire (CePcA) et sa mémorisation dans un module de mémorisation (61) d'un serveur, le certificat numérique public étant lié mathématiquement au certificat numérique privé de l'entité propriétaire ; -l'indexation d'informations relatives à l'entité propriétaire et la mise à disposition d'un moteur de recherche accessible permettant l'identification et la consultation du certificat numérique public de l'entité propriétaire par des tiers à partir de la saisie d'informations relatives à l'entité propriétaire par des tiers.
9. Procédé de diffusion sécurisée selon la revendication 8, dans lequel l'entité propriétaire définit des restrictions de consultation de son certificat numérique public pour certaines catégories de tiers, et dans lequel le moteur de recherche empêche la consultation du certificat numérique public de l'entité propriétaire pour ces catégories de tiers.
10. Procédé de diffusion sécurisée selon l'une quelconque des revendications précédentes, comprenant :
-la génération d'un certificat numérique public du tiers (CePcB) et sa mémorisation dans un module de mémorisation (61) d'un serveur, le certificat numérique public étant lié mathématiquement au certificat numérique privé du tiers ; -l'indexation d'informations relatives au tiers et la mise à disposition d'un moteur de recherche accessible permettant l'identification et la consultation du certificat numérique public du tiers par l'entité propriétaire ou par d'autres tiers à partir de leur saisie d'informations relatives au tiers.
11. Procédé de diffusion sécurisée selon l'une quelconque des revendications précédentes, dans lequel le certificat numérique privé de l'entité propriétaire comprend une clé de chiffrement symétrique de diffusion (KeS3A) vers l'entité propriétaire, le procédé comprenant une requête d'accès de l'entité propriétaire à ses données numériques chiffrées, une authentifïcation forte de l'entité propriétaire, le déchiffrement des données numériques chiffrées avec la clé de chiffrement symétrique de stockage (KeS2A), le chiffrement des données numériques au moyen de la clé de chiffrement de diffusion vers l'entité propriétaire (KeS3A) et la diffusion des données ainsi chiffrées vers l'entité propriétaire (A).
12. Procédé de diffusion sécurisée selon l'une quelconque des revendications précédentes, comprenant la mémorisation d'un historique des accès aux données numériques chiffrées de l'entité propriétaire dans un module de stockage (66) d'un serveur.
13. Procédé de diffusion sécurisée selon l'une quelconque des revendications précédentes, comprenant l'inclusion d'un historique des accès aux données numériques chiffrées dans les données numériques diffusées vers le tiers authentifié.
14. Procédé de diffusion sécurisée selon l'une quelconque des revendications précédentes, comprenant préalablement :
-la saisie d'informations relatives à l'identité du tiers ; -la génération du certificat numérique privé (CePrB) du tiers (B) contenant lesdites informations relatives à son identité, contenant le couple de clé de chiffrement asymétrique (KprB, KpcB) ;
-la saisie d'un élément d'authentification forte du tiers et son stockage dans un module de stockage
(65) d'un serveur ;
-la génération de ladite première clé de chiffrement symétrique (KeSlB) dédiée au tiers et l'association de cette clé à l'élément d'authentification forte ;
-chiffrer le certificat numérique privé (CePrB) du tiers avec sa première clé de chiffrement symétrique (KeSlB) et mémoriser le certificat numérique privé chiffré dans un module de stockage
(62) d'un serveur.
15. Procédé de diffusion sécurisée selon l'une quelconque des revendications précédentes, comprenant préalablement :
-l'authentification forte de l'entité propriétaire et du tiers ;
-la définition par l'entité propriétaire et le tiers de paramètres de chiffrement de diffusion des données numériques de l'entité propriétaire et la génération du certificat numérique négocié
(CeNeaB) incluant ces paramètres de chiffrement.
16. Procédé de diffusion sécurisée selon la revendication 15, comprenant préalablement à la définition par l'entité propriétaire et par le tiers des paramètres de chiffrement de diffusion des données numériques :
-la génération d'un autre certificat numérique négocié entre une première entité parmi le tiers et l'entité propriétaire, et un autre tiers ; -la publication d'un certificat numérique public associé à cet autre certificat numérique négocié ;
-l'identification par une deuxième entité parmi le tiers et l'entité propriétaire, de cet autre certificat numérique.
17. Procédé de diffusion sécurisée selon l'une quelconque des revendications précédentes, comprenant : -l'authentification forte de l'entité propriétaire ;
-la saisie des paramètres de droits d'accès aux données numériques chiffrées de l'entité propriétaire, définissant des tiers vers lesquels les données numériques peuvent être diffusées et définissant le type d'accès des tiers à ces données ;
-la génération du certificat de politique d'accès en fonction de ces paramètres et la mémorisation dans ledit module de stockage.
18. Système de diffusion sécurisée de données numériques chiffrées, caractérisé en ce qu'il comprend :
-un module de stockage (66) de données numériques chiffrées hébergé dans un serveur ; -un module d'authentification forte d'utilisateurs, hébergé dans un serveur ; -un module de stockage (62) de certificats numériques privés dédiés à des utilisateurs respectifs, chaque certificat numérique privé comprenant une première clé de chiffrement symétrique, un couple de clés de chiffrement asymétrique et une clé de chiffrement symétrique de stockage dédiés à son utilisateur, ce module de stockage étant hébergé dans un serveur ;
-un module de stockage (63) de certificats numériques négociés entre deux utilisateurs, chaque certificat numérique négocié comprenant une clé de chiffrement symétrique pour la diffusion des données numériques d'un des deux utilisateurs vers l'autre des deux utilisateurs, ce module de stockage étant hébergé dans un serveur ;
-un module de stockage (64) de certificats de politique d'accès définissant les droits d'accès aux données numériques d'un utilisateur par un autre utilisateur, ce module de stockage étant hébergé dans un serveur ; -un module de chiffrement/déchiffrement apte à :
-déchiffrer le certificat numérique privé d'un premier utilisateur avec sa première clé de chiffrement symétrique après son authentification ;
-déchiffrer, au moyen de la clé privée du couple de clés du premier utilisateur, un certificat numérique négocié avec un deuxième utilisateur ; -après le déchiffrement du certificat numérique négocié, la lecture d'un certificat de politique d'accès aux données numériques défini par le deuxième utilisateur ;
-si le premier utilisateur a un droit d'accès aux données numériques du deuxième utilisateur, déchiffrer des données numériques au moyen de la clé de chiffrement de stockage du deuxième utilisateur, chiffrer les données numériques au moyen de la clé de chiffrement pour la diffusion du premier utilisateur, et diffuser ces données numériques vers le premier utilisateur.
PCT/EP2009/053087 2008-04-21 2009-03-16 Procede de diffusion securisee de donnees numeriques vers un tiers autorise WO2009130089A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP09733859A EP2279581A1 (fr) 2008-04-21 2009-03-16 Procede de diffusion securisee de donnees numeriques vers un tiers autorise
GB1005174A GB2465326B (en) 2008-04-21 2009-03-16 Method for the secured broadcasting of digital data to an authorized third party
US12/988,778 US8719575B2 (en) 2008-04-21 2009-03-16 Method of secure broadcasting of digital data to an authorized third party

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR08/02201 2008-04-21
FR0802201A FR2930390B1 (fr) 2008-04-21 2008-04-21 Procede de diffusion securisee de donnees numeriques vers un tiers autorise.

Publications (1)

Publication Number Publication Date
WO2009130089A1 true WO2009130089A1 (fr) 2009-10-29

Family

ID=40091920

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2009/053087 WO2009130089A1 (fr) 2008-04-21 2009-03-16 Procede de diffusion securisee de donnees numeriques vers un tiers autorise

Country Status (5)

Country Link
US (1) US8719575B2 (fr)
EP (1) EP2279581A1 (fr)
FR (1) FR2930390B1 (fr)
GB (1) GB2465326B (fr)
WO (1) WO2009130089A1 (fr)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10867298B1 (en) 2008-10-31 2020-12-15 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US20100114768A1 (en) 2008-10-31 2010-05-06 Wachovia Corporation Payment vehicle with on and off function
US20130036455A1 (en) * 2010-01-25 2013-02-07 Nokia Siemens Networks Oy Method for controlling acess to resources
DE102011051498A1 (de) * 2011-06-06 2012-12-06 Kobil Systems Gmbh Gesicherter Zugriff auf Daten in einem Gerät
TW201320786A (zh) * 2011-11-07 2013-05-16 Univ Nat Taiwan 資訊分享方法、模組、裝置、以及電子裝置
US9009817B1 (en) 2013-03-12 2015-04-14 Open Invention Network, Llc Virtual smart card to perform security-critical operations
US11429975B1 (en) 2015-03-27 2022-08-30 Wells Fargo Bank, N.A. Token management system
US11170364B1 (en) 2015-07-31 2021-11-09 Wells Fargo Bank, N.A. Connected payment card systems and methods
US11935020B1 (en) 2016-07-01 2024-03-19 Wells Fargo Bank, N.A. Control tower for prospective transactions
US11886611B1 (en) 2016-07-01 2024-01-30 Wells Fargo Bank, N.A. Control tower for virtual rewards currency
US11615402B1 (en) 2016-07-01 2023-03-28 Wells Fargo Bank, N.A. Access control tower
US11386223B1 (en) 2016-07-01 2022-07-12 Wells Fargo Bank, N.A. Access control tower
US10992679B1 (en) 2016-07-01 2021-04-27 Wells Fargo Bank, N.A. Access control tower
US10461942B1 (en) * 2016-07-20 2019-10-29 United Services Automobile Association Multi-factor authentication with code rotation
US11556936B1 (en) 2017-04-25 2023-01-17 Wells Fargo Bank, N.A. System and method for card control
US11062388B1 (en) * 2017-07-06 2021-07-13 Wells Fargo Bank, N.A Data control tower
US11188887B1 (en) 2017-11-20 2021-11-30 Wells Fargo Bank, N.A. Systems and methods for payment information access management
CN110309663B (zh) * 2019-06-25 2023-03-03 湖南搜云网络科技股份有限公司 基于区块链的隐私认证方法及系统
JP2022020143A (ja) * 2020-07-20 2022-02-01 富士通株式会社 通信プログラム、通信装置、及び通信方法
US10992606B1 (en) 2020-09-04 2021-04-27 Wells Fargo Bank, N.A. Synchronous interfacing with unaffiliated networked systems to alter functionality of sets of electronic assets
US11546338B1 (en) 2021-01-05 2023-01-03 Wells Fargo Bank, N.A. Digital account controls portal and protocols for federated and non-federated systems and devices

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0907120A2 (fr) * 1997-10-02 1999-04-07 Tumbleweed Software Corporation Méthode et appareil de distribution de documents par réseau électronique
EP1381201A2 (fr) * 2002-07-10 2004-01-14 Sony Corporation Système, méthode et programme pour l'accès à distance à une ressource avec certificats
WO2007091002A1 (fr) * 2006-02-07 2007-08-16 Nextenders (India) Private Limited Système de gestion de sécurité de documents
US20070240203A1 (en) * 2006-04-11 2007-10-11 Medox Exchange, Inc. Relationship-based authorization

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7017046B2 (en) * 1997-09-22 2006-03-21 Proofspace, Inc. System and method for graphical indicia for the certification of records
KR100721078B1 (ko) * 1999-07-06 2007-05-22 소니 가부시끼 가이샤 데이터 처리 장치, 데이터 제공 시스템, 및 데이터 제공 방법
US7907733B2 (en) * 2004-03-05 2011-03-15 Electronics And Telecommunications Research Institute Method for managing traffic encryption key in wireless portable internet system and protocol configuration method thereof, and operation method of traffic encryption key state machine in subscriber station
EP1672831A1 (fr) * 2004-12-16 2006-06-21 Nagravision S.A. Méthode de transmission de données numériques dans un réseau local
KR100811046B1 (ko) * 2005-01-14 2008-03-06 엘지전자 주식회사 브로드캐스트/멀티캐스트 서비스에서 디지털 저작권관리방법
WO2008079433A1 (fr) * 2006-12-20 2008-07-03 Rowley, Richard Procédé et système pour l'installation d'un certificat racine sur un ordinateur à l'aide d'un mécanisme de mise à jour de certificats racine
US8539225B2 (en) * 2008-04-30 2013-09-17 Motorola Solutions, Inc. Method and device for dynamic deployment of trust bridges in an ad hoc wireless network

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0907120A2 (fr) * 1997-10-02 1999-04-07 Tumbleweed Software Corporation Méthode et appareil de distribution de documents par réseau électronique
EP1381201A2 (fr) * 2002-07-10 2004-01-14 Sony Corporation Système, méthode et programme pour l'accès à distance à une ressource avec certificats
WO2007091002A1 (fr) * 2006-02-07 2007-08-16 Nextenders (India) Private Limited Système de gestion de sécurité de documents
US20070240203A1 (en) * 2006-04-11 2007-10-11 Medox Exchange, Inc. Relationship-based authorization

Also Published As

Publication number Publication date
GB2465326A (en) 2010-05-19
FR2930390B1 (fr) 2010-04-16
US8719575B2 (en) 2014-05-06
GB2465326B (en) 2011-03-02
GB201005174D0 (en) 2010-05-12
US20110035596A1 (en) 2011-02-10
EP2279581A1 (fr) 2011-02-02
FR2930390A1 (fr) 2009-10-23

Similar Documents

Publication Publication Date Title
WO2009130089A1 (fr) Procede de diffusion securisee de donnees numeriques vers un tiers autorise
WO2009130088A1 (fr) Terminal d'authentification forte d'un utilisateur
EP1459479A2 (fr) Systeme cryptographique de signature de groupe
WO2011117486A1 (fr) Infrastructure non hierarchique de gestion de bi-cles de securite de personnes physiques
EP0456553A1 (fr) Procédé d'obtention d'une attestation en clair sécurisée dans un environnement de système informatique distribué
EP1829280A2 (fr) PROCEDE D'AUTHENTIFICATION SECURISEE POUR LA MISE EN ŒUVRE DE SERVICES SUR UN RESEAU DE TRANSMISSION DE DONNEES
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é
WO2007012583A1 (fr) Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d'ordinateur correspondants
EP1011223A1 (fr) Procédé de création et gestion d'au moins une clé cryptographique et système pour sa mise en oeuvre
EP1794926A1 (fr) Systeme et procede cryptographique a cle publique et serveur de certification, memoires adaptees pour ce systeme
WO2022200726A1 (fr) Gestion de droits d'accès à des fichiers numériques avec possible délégation des droits
EP4012972A1 (fr) Méthode de divulgation sélective de données via une chaine de blocs
CA2831167C (fr) Infrastructure non hierarchique de gestion de bi-cles de securite de personnes physiques ou d'elements (igcp/pki)
FR3141538A1 (fr) Procede et dispositif de stockage en ligne reparti de fichiers dans un contexte zero confiance
WO2021198606A1 (fr) Procede et dispositif d'authentification d'un utilisateur aupres d'une application
WO2023203301A1 (fr) Procédé et système de gestion des droits d'accès dans une transaction équitable de données numériques
EP1989819B1 (fr) Procéde de certification de clé publique par un prestataire non accrédité
WO2010133459A1 (fr) Procede de chiffrement de parties particulieres d' un document pour les utilisateurs privileges
FR2990818A1 (fr) Procede de transfert et de stockage securise de documents et appareils associes au procede.
FR2898448A1 (fr) Authentification d'un dispositif informatique au niveau utilisateur
FR2862827A1 (fr) Procede de gestion de donnees de securite
WO2008132393A2 (fr) Procédé et système d'authentification d'un utilisateur
FR3010559A1 (fr) Procede de transfert et de stockage securise de documents et appareils associes au procede

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09733859

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 1005174

Country of ref document: GB

Kind code of ref document: A

Free format text: PCT FILING DATE = 20090316

WWE Wipo information: entry into national phase

Ref document number: 1005174.6

Country of ref document: GB

WWE Wipo information: entry into national phase

Ref document number: 12988778

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2009733859

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2009733859

Country of ref document: EP