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

Applications Claiming Priority (2)

Publications (1)

Family

ID=40199923

Family Applications (1)

Country Status (5)

Families Citing this family (10)

Family Cites Families (12)

• 2008
  • 2008-04-21 FR FR0802202A patent/FR2930391B1/fr not_active Expired - Fee Related
• 2009
  • 2009-03-16 GB GB1005175A patent/GB2465525A/en not_active Withdrawn
  • 2009-03-16 EP EP09734547A patent/EP2301187A1/de not_active Withdrawn
  • 2009-03-16 WO PCT/EP2009/053084 patent/WO2009130088A1/fr active Application Filing
  • 2009-03-16 US US12/988,899 patent/US9094207B2/en not_active Expired - Fee Related
• 2015
  • 2015-06-25 US US14/750,617 patent/US20160112417A1/en not_active Abandoned

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events