EP2301187A1 - Terminal d'authentification forte d'un utilisateur - Google Patents

Terminal d'authentification forte d'un utilisateur

Info

Publication number
EP2301187A1
EP2301187A1 EP09734547A EP09734547A EP2301187A1 EP 2301187 A1 EP2301187 A1 EP 2301187A1 EP 09734547 A EP09734547 A EP 09734547A EP 09734547 A EP09734547 A EP 09734547A EP 2301187 A1 EP2301187 A1 EP 2301187A1
Authority
EP
European Patent Office
Prior art keywords
terminal
certificate
data
key
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP09734547A
Other languages
German (de)
English (en)
Inventor
Jonathan Attia
Bernard Pinot
Original Assignee
Etsem Ltd
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 Ltd filed Critical Etsem Ltd
Publication of EP2301187A1 publication Critical patent/EP2301187A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • 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/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • 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
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • 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
    • 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/3226—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 using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3231—Biological data, e.g. fingerprint, voice or retina
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • 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
    • 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/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/082—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying multi-factor authentication
    • 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/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • 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/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/61—Time-dependent
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/63—Location-dependent; Proximity-dependent

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 terminal for performing a strong authentication of a user wishing to access services provided by a server.
  • 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 best-known examples of so-called asymmetric cryptographic protocols with public keys are: the RSA system (named after the inventors Rivest, Shamir and Adleman) based on the factorization of integers;
  • 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 The unique identifier of the public key holder.
  • Signature Digital signature of the CA on the previous fields.
  • 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 strong authentication terminal of a user, comprising: a user authentication parameter reader; a receiver of a geolocation signal; a communication interface with another apparatus; a processor, extracting the date and time of the geolocation signal, generating encrypted data comprising authentication parameters read by the reader and the extracted date and time, and controlling the transmission of said encrypted data via of the communication interface.
  • the processor extracts the position of the terminal from the geolocation signal and includes the extracted position in the encrypted data.
  • the terminal comprises a non-volatile memory storing a symmetric encryption key, the processor generating the encrypted data using this symmetric encryption key.
  • the terminal comprises:
  • control interface through which a user can control the end of a session of use of the terminal
  • the processor controlling the erasure of the storage memory at the end of each session of use.
  • the terminal stores interpreting applications of different types of files stored in the storage memory, the processor being able to execute these applications, able to generate an image of the content of an interpreted file and able to transmit this image via the communication interface.
  • the authentication parameter reader is a fingerprint reader.
  • the authentication parameter reader is a retinal reader.
  • the authentication parameter reader is a keyboard, the terminal further comprising a smart card reader.
  • the communication interface is a wireless communication interface.
  • the receiver is configured to receive a GPS signal.
  • 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 strong authentication terminal of a user.
  • the terminal includes a user authentication parameter reader, a receiver of a geolocation signal and a communication interface with another device.
  • the terminal further comprises a processor extracting the date and time of the geolocation signal, generating encrypted data including authentication parameters read by the reader and the extracted date and time, and controlling the transmission of said encrypted data by via the communication interface.
  • 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 biometric 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 manufacture 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 to 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.
  • 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 KeS 1 key.
  • the server 5 In 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 11 later to define whether the publication of the public certificate CePc is authorized, restricted or prohibited (for example if the public certificate is visible only by invitation issued by the entity owner).
  • 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
  • - Optionally a certificate of the proprietary entity in X. 509 format;
  • 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;
  • KeS 3 a third KeS 3 symmetric encryption key for encrypting the secure data streams broadcast from the database 6 to the proprietary entity itself;
  • KeS4 a fourth 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.
  • the KeS3 symmetric broadcast encryption key (as well as the Kse third-party broadcast key detailed later) will be further sized to allow transmission and reduced processing time of the transmitted secure data.
  • This symmetric KeS3 encryption key (as well as the Kse third-party broadcast key 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 can thus 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.
  • -Hash digital fingerprint of CePr digital certificate guaranteeing the mathematical link with the private digital certificate
  • -DHC Date timestamp of creation
  • CePc digital certificate unique serial number of said CePc 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.
  • the two users initiate a negotiation process.
  • the initial exchanges between the users can be signed, timestamped and then stored by the server 5.
  • Figure 5 details the process of 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 certificate respective public digital publication, either by publication of the corresponding public digital certificate or by a secret
  • 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.
  • step 504 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 are encrypted respectively with the public key KpcB and the public key
  • KpcA contained respectively in the private digital certificates CePrB and CePrA.
  • the 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 can be used for the dissemination of digital data to the non-proprietary entity of this 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. -TTL: validity period of the certificate; -Val Emp: digital fingerprints of private digital certificates used during its generation;
  • -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 to import a digital certificate of the X.509 standard ...
  • 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.
  • the user starts the application 12 on his terminal 1.
  • the terminal 1 detects the presence of the authentication terminal 3.
  • the terminal 3 reads authentication information entered by the user, for example his fingerprint on the reader 31.
  • the read authentication information is transmitted encrypted (with the key Kst) to the terminal 1.
  • the Terminal 1 encrypts the authentication information read to the server 5.
  • the server 5 consults the biometric database 65 and compares the authentication information read with the stored reference.
  • the server 5 also compares the time stamp information generated by the terminal 3 with time stamp 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 appropriate for encrypting the certificate digital private 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 KeS1 in step 607.
  • the values contained in the private digital certificate and useful for subsequent operations are stored in the server 5.
  • An asymmetric encryption key pair Kpc and Kpr is in particular loaded in memory, to allow the encryption or decryption of the negotiated certificate CeNe.
  • 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 database 64 at step 808.
  • the owning entity will be able to select default access control settings offered 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 settings corresponding to the imported access policy template (s).
  • Figure 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.
  • the encryption key KeS4A is extracted from the CePrA certificate and loaded into the server 5
  • the CeSeA access policy certificate is decrypted with the KeS4A key.
  • the access rights are read by the server 5.
  • the server 5 validates the access to the digital data for the third party B.
  • the server 5 then 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.
  • the data to be broadcast is encrypted with the broadcast encryption key KSeB.
  • 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 access to secure data 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 an 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 comprises the public certificates of the different users of the server 5.
  • the public certificates for which the access is not restricted are accessible by a directory or a search engine running on the server 5.
  • the cryptographic protocol database 67 contains the various cryptosystems required to perform the ciphers / decryptions at the server 5.
  • Figure 11 represents a phase of creation of a new certificate negotiated from two existing negotiated 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.
  • Such a procedure makes it easy to set up tools for distributing the digital data of a proprietor entity to a third party, even when the latter does not yet have absolute trust in this third party: the proprietor entity remains free to provide Rights gradually gain access to the third party, once the owning entity has the guarantee of being able to trust the third party.
  • Figures 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.
  • Figure 15 shows 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.
  • Fig. 18 is a packet datagram of an acknowledgment of the end of the digital data broadcast, 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 indexing information of the 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.
  • the stored digital data of the proprietary entity are decrypted.
  • Data packets for broadcast are formed and are encapsulated optimally.
  • 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. It could also be envisaged that 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.

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)
  • Life Sciences & Earth Sciences (AREA)
  • Biodiversity & Conservation Biology (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Power Engineering (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un terminal d'authentification forte (3) d'un utilisateur, comprenant: - un lecteur (31, 34) de paramètres d'authentification d'un utilisateur; - un récepteur d'un signal de géolocalisation (33); - une interface de communication (37) avec un autre appareil; - un processeur (38), extrayant la date et l'heure du signal de géolocalisation, générant des données chiffrées comprenant des paramètres d'authentification lus par le lecteur et la date et l'heure extraites, et commandant la transmission desdites données chiffrées par l'intermédiaire de l'interface de communication (37).

Description

TERMINAL D'AUTHENTIFICATION FORTE D'UN UTILISATEUR
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 terminal permettant de réaliser une authentification forte d'un utilisateur souhaitant accéder à des services fournis par un serveur.
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. II 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 terminal d'authentification forte d'un utilisateur, comprenant: -un lecteur de paramètres d'authentification d'un utilisateur ; -un récepteur d'un signal de géolocalisation ; -une interface de communication avec un autre appareil ; -un processeur, extrayant la date et l'heure du signal de géolocalisation, générant des données chiffrées comprenant des paramètres d'authentification lus par le lecteur et la date et l'heure extraites, et commandant la transmission desdites données chiffrées par l'intermédiaire de l'interface de communication. Selon une variante, le processeur extrait la position du terminal à partir du signal de géolocalisation et inclut la position extraite dans les données chiffrées.
Selon encore une variante, le terminal comprend une mémoire non volatile mémorisant une clé de chiffrement symétrique, le processeur générant les données chiffrées en utilisant cette clé de chiffrement symétrique. Selon une autre variante, le terminal comprend :
-une mémoire de stockage accessible par l'intermédiaire de l'interface de communication ;
-une interface de commande par l'intermédiaire de laquelle un utilisateur peut commander la fin d'une session d'utilisation du terminal ;
-le processeur commandant l'effacement de la mémoire de stockage à la fin de chaque session d'utilisation.
Selon encore une variante, le terminal mémorise des applications d'interprétation de différents types de fichiers mémorisés dans la mémoire de stockage, le processeur étant apte à exécuter ces applications, apte à générer une image du contenu d'un fichier interprété et apte à transmettre cette image par l'intermédiaire de l'interface de communication. Selon encore une autre variante, le lecteur de paramètres d'authentification est un lecteur d'empreintes digitales.
Selon une variante, le lecteur de paramètres d'authentification est un lecteur d'empreintes rétiniennes.
Selon une autre variante, le lecteur de paramètres d'authentification est un clavier, le terminal comprenant en outre un lecteur de carte à puce.
Selon encore une variante, l'interface de communication est une interface de communication sans fil.
Selon encore une autre variante, le récepteur est configuré pour recevoir un signal GPS.
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 terminal d'authentification forte d'un utilisateur. Le terminal comprend un lecteur de paramètres d'authentification d'un utilisateur, un récepteur d'un signal de géolocalisation et une interface de communication avec un autre appareil. Le terminal comprend de plus un processeur extrayant la date et l'heure du signal de géolocalisation, générant des données chiffrées comprenant des paramètres d'authentification lus par le lecteur et la date et l'heure extraites, et commandant la transmission desdites données chiffrées par l'intermédiaire de l'interface de communication.
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'authentifïcation, 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'authentifïcation, 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é KeS 1.
À 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 KeS 3 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 authentification 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'authentification 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'authentification 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'authentification 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é KeSl à 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 authentifïcation 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 authentifïcation 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. Terminal d'authentifïcation forte (3) d'un utilisateur, caractérisé en ce qu'il comprend : -un lecteur (31,34) de paramètres d'authentifïcation d'un utilisateur ; -un récepteur d'un signal de géolocalisation (33) ;
-une interface de communication (37) avec un autre appareil ;
-un processeur (38), extrayant la date et l'heure du signal de géolocalisation, générant des données chiffrées comprenant des paramètres d'authentifïcation lus par le lecteur et la date et l'heure extraites, et commandant la transmission desdites données chiffrées par l'intermédiaire de l'interface de communication (37).
2. Terminal (3) selon la revendication 1, dans lequel le processeur (38) extrait la position du terminal à partir du signal de géolocalisation et inclut la position extraite dans les données chiffrées.
3. Terminal selon la revendication 1 ou 2, comprenant une mémoire non volatile (36) mémorisant une clé de chiffrement symétrique, le processeur générant les données chiffrées en utilisant cette clé de chiffrement symétrique.
4. Terminal selon l'une quelconque des revendications précédentes, comprenant :
-une mémoire de stockage (35) accessible par l'intermédiaire de l'interface de communication (37) ; -une interface de commande par l'intermédiaire de laquelle un utilisateur peut commander la fin d'une session d'utilisation du terminal ; le processeur (38) commandant l'effacement de la mémoire de stockage à la fin de chaque session d'utilisation.
5. Terminal selon la revendication 4, mémorisant des applications d'interprétation de différents types de fichiers mémorisés dans la mémoire de stockage (35), le processeur (38) étant apte à exécuter ces applications, apte à générer une image du contenu d'un fichier interprété et apte à transmettre cette image par l'intermédiaire de l'interface de communication.
6. Terminal selon l'une quelconque des revendications précédentes, dans lequel le lecteur de paramètres d'authentification est un lecteur d'empreintes digitales.
7. Terminal selon l'une quelconque des revendications précédentes, dans lequel le lecteur de paramètres d'authentification est un lecteur d'empreintes rétiniennes.
8. Terminal selon l'une quelconque des revendications précédentes, dans lequel le lecteur de paramètres d'authentification est un clavier, le terminal comprenant en outre un lecteur de carte à puce.
9. Terminal selon l'une quelconque des revendications précédentes, dans lequel l'interface de communication est une interface de communication sans fil.
10. Terminal selon l'une quelconque des revendications précédentes, dans lequel le récepteur est configuré pour recevoir un signal GPS.
EP09734547A 2008-04-21 2009-03-16 Terminal d'authentification forte d'un utilisateur Withdrawn EP2301187A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0802202A FR2930391B1 (fr) 2008-04-21 2008-04-21 Terminal d'authentification d'un utilisateur.
PCT/EP2009/053084 WO2009130088A1 (fr) 2008-04-21 2009-03-16 Terminal d'authentification forte d'un utilisateur

Publications (1)

Publication Number Publication Date
EP2301187A1 true EP2301187A1 (fr) 2011-03-30

Family

ID=40199923

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09734547A Withdrawn EP2301187A1 (fr) 2008-04-21 2009-03-16 Terminal d'authentification forte d'un utilisateur

Country Status (5)

Country Link
US (2) US9094207B2 (fr)
EP (1) EP2301187A1 (fr)
FR (1) FR2930391B1 (fr)
GB (1) GB2465525A (fr)
WO (1) WO2009130088A1 (fr)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8914905B2 (en) * 2009-11-09 2014-12-16 Nec Corporation Access control system, communication terminal, server, and access control method
GB2492050A (en) * 2011-06-13 2012-12-26 Torben Kuseler One-time multi-factor biometric representation for remote client authentication
JP5786670B2 (ja) * 2011-11-17 2015-09-30 ソニー株式会社 情報処理装置、情報記憶装置、情報処理システム、および情報処理方法、並びにプログラム
US8800027B1 (en) 2012-09-14 2014-08-05 Emc Corporation Authentication using privacy protected personally identifiable information
US9525668B2 (en) * 2014-06-27 2016-12-20 Intel Corporation Face based secure messaging
US10069822B2 (en) * 2016-02-23 2018-09-04 Verizon Patent And Licensing Inc. Authenticated network time for mobile device smart cards
CN107332667A (zh) * 2017-07-04 2017-11-07 四川云物益邦科技有限公司 一种采用数字证书的查询系统
US10797885B1 (en) * 2018-04-18 2020-10-06 Wells Fargo Bank, N.A. Systems and methods for privacy preserving distributed ledger consensus
US11611558B2 (en) 2019-11-13 2023-03-21 Google Llc Integration of third-party encryption key managers with cloud services
CN113704728B (zh) * 2021-07-19 2024-03-01 桂林电子科技大学 一种基于d-h密钥交换和密钥分享的指纹认证方法

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6959387B2 (en) * 1996-03-21 2005-10-25 Walker Digital, Llc Method and apparatus for verifying secure document timestamping
US5923763A (en) * 1996-03-21 1999-07-13 Walker Asset Management Limited Partnership Method and apparatus for secure document timestamping
US20020056043A1 (en) * 1999-01-18 2002-05-09 Sensar, Inc. Method and apparatus for securely transmitting and authenticating biometric data over a network
GB0130404D0 (en) 2001-12-20 2002-02-06 Wylie Samuel J Improved shear grab
JP2004172865A (ja) * 2002-11-19 2004-06-17 Casio Comput Co Ltd 電子機器及び認証システム
US7979698B2 (en) * 2003-02-19 2011-07-12 Hewlett-Packard Development Company, L.P. Apparatus and method for proving authenticity with personal characteristics
US7499548B2 (en) * 2003-06-24 2009-03-03 Intel Corporation Terminal authentication in a wireless network
US20050076198A1 (en) * 2003-10-02 2005-04-07 Apacheta Corporation Authentication system
US7424040B2 (en) * 2004-05-07 2008-09-09 Ltas Holdings, Llc Communication systems and methods for transmitting data in parallel over multiple channels
KR100564731B1 (ko) * 2004-08-13 2006-03-28 (주)잉카엔트웍스 네트워크를 통하여 개인 휴대 단말기로 데이터를 전송하는방법 및 그 시스템
US7496347B2 (en) * 2004-11-12 2009-02-24 Velocita Wireless Llc Method and apparatus for providing secure wireless communication
WO2010059960A1 (fr) * 2008-11-21 2010-05-27 Dafca, Inc. Authentification d’un circuit intégré en se basant sur les informations stockées

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2009130088A1 *

Also Published As

Publication number Publication date
US9094207B2 (en) 2015-07-28
FR2930391B1 (fr) 2010-04-16
WO2009130088A1 (fr) 2009-10-29
GB2465525A (en) 2010-05-26
US20160112417A1 (en) 2016-04-21
FR2930391A1 (fr) 2009-10-23
GB201005175D0 (en) 2010-05-12
US20110040972A1 (en) 2011-02-17

Similar Documents

Publication Publication Date Title
EP2279581A1 (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é
FR2971599A1 (fr) Procede de transaction securisee a partir d'un terminal non securise
EP2619941A1 (fr) Procede, serveur et systeme d'authentification d'une personne
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é
EP1911194A1 (fr) Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d'ordinateur correspondants
WO2006035159A1 (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
FR3002056A1 (fr) Authentification de signature manuscrite numerisee.
WO2012156365A1 (fr) Procede de securisation d'une platforme d'authentification, dispositifs materiels et logiciels correspondants
FR3141538A1 (fr) Procede et dispositif de stockage en ligne reparti de fichiers dans un contexte zero confiance
EP2409474A1 (fr) Procédé de production de données de sécurisation, dispositif et programme d'ordinateur correspondant
FR2786049A1 (fr) Procede de cryptographie a cle dynamique
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
EP2254275A1 (fr) Procédé de chiffrement de parties particulières d'un document pour les utilisateurs privilèges
FR3116133A1 (fr) Procédé de délégation d’accès à une chaîne de blocs
FR2990818A1 (fr) Procede de transfert et de stockage securise de documents et appareils associes au procede.
WO2008081150A2 (fr) Procede et systeme d'autorisation d'acces a un serveur
FR2862827A1 (fr) Procede de gestion de donnees de securite
FR2898448A1 (fr) Authentification d'un dispositif informatique au niveau utilisateur

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20101027

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Extension state: AL BA RS

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ATTIA, JONATHAN JACOB

PUAJ Public notification under rule 129 epc

Free format text: ORIGINAL CODE: 0009425

32PN Public notification

Free format text: CONSTATATION DE LA PERTE D'UN DROIT CONFORMEMENT A LA REGLE 112(1) CBE (OEB FORM 2524 EN DATE DU 04.01.2016)

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20160301