EP2301187A1

EP2301187A1 - Terminal for strong authentication of a user

Info

Publication number: EP2301187A1
Application number: EP09734547A
Authority: EP
Inventors: Jonathan Attia; Bernard Pinot
Original assignee: Etsem Ltd
Current assignee: ATTIA, JONATHAN JACOB
Priority date: 2008-04-21
Filing date: 2009-03-16
Publication date: 2011-03-30
Also published as: US20160112417A1; GB201005175D0; US9094207B2; WO2009130088A1; FR2930391B1; FR2930391A1; GB2465525A; US20110040972A1

Abstract

The invention relates to a terminal (3) for the strong authentication of a user, comprising: - a reader (31, 34) of a user’s authentication parameters; - a receiver of a geolocation signal (33); - an interface (37) for communication with another apparatus; - and a processor (38), extracting the date and time of the geolocation signal, generating encrypted data comprising authentication parameters read by the reader and the date and time extracted, and ordering the transmission of said encrypted data by way of the communication interface (37).

Description

STRONG AUTHENTICATION TERMINAL OF A USER

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.

In the field of securing access to data, the prior art already knows from the publications ISO / IEC 9594-8, RFC-2459 and RFC-2510, the realization of standard cryptosystems public key. The principle of encryption with a public key system is based on the existence of a pair of keys noted Ke (private key) and Kq (public key), different values but mathematically related, belonging to the same proprietary entity.

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;

- the Diffie-Hellman key exchange;

- El Gamal's system based on the discrete logarithm.

This method, widely adopted, 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.

In this context, it is assumed that the entities involved in the exchange of encrypted data streams first know their identities and their respective public keys which are recorded and published on said digital certificate. 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.

Moreover, the prior art is known in particular by publications FIPS-197, RFC 2405, the realization of standard cryptosystems secret key. The principle of encryption with a secret key system relies on the existence of a unique secret key denoted K (with K = K _e = K _q ) used for both encryption and decryption of data. In practice, mainly stream ciphers (referred to as Stream Cipher in English) are used when the speed of processing is essential (telephony, connection between central unit, etc.); when security predominates, block ciphers (Block Cipher in English) are used instead. Such cryptosystems have the main advantage of being efficient in terms of computation time, both for encryption and for decryption.

The best-known examples of symmetric (secret-key) cryptographic protocols are:

- the DES (Data Encryption Standard, RFC 2405); - AES (Advanced Encryption Standard English, FIPS-197);

- the 3-DES system;

- the IDEA system;

- the RC6 / RC4 system (stream).

The major disadvantage of such cryptosystems, both public key and secret key lies in the complexity of administration and key management. What is meant by the management of keys attached to any cryptosystem are the security aspects related to storage, distribution, exchange, archiving, functional diversification, restoration, replacement, revocation and key history.

To this drawback is added a much larger flaw of current cryptosystems when it comes in particular to the reading by a user of secure data.

In the case of a public key cryptosystem, 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.

In the case of a secret key cryptosystem, the risk is more focused on the confidentiality of the data. When interpreting a secure data by a user,

(decryption of data), the latter are vulnerable during the entire reading period: there is therefore a real risk of interception, passive fraudulent listening or diversion of these data.

In addition, the lack of interoperability between the cryptosystems, be they PKI or secret key cryptosystems, is a key obstacle to their deployment within companies. Note the well-known complexity of the prior art cross certifications between PKI or their incompatibility with encryption techniques of a cryptosystem secret key. It is thus delicate for an entity to set up a security policy with several other entities using different cryptosystems.

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. According to one variant, the processor extracts the position of the terminal from the geolocation signal and includes the extracted position in the encrypted data.

According to another variant, the terminal comprises a non-volatile memory storing a symmetric encryption key, the processor generating the encrypted data using this symmetric encryption key. According to another variant, the terminal comprises:

a storage memory accessible via the communication interface;

a 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.

According to another variant, 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. According to yet another variant, the authentication parameter reader is a fingerprint reader.

According to one variant, the authentication parameter reader is a retinal reader.

According to another variant, the authentication parameter reader is a keyboard, the terminal further comprising a smart card reader.

According to another variant, the communication interface is a wireless communication interface.

According to yet another variant, the receiver is configured to receive a GPS signal.

The invention and its other features and advantages will be better understood by means of the description given below, for purely explanatory purposes, with reference to the appended figures in which:

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.

Figure 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. . By 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.

In this case, during a user authentication, 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. In this case, the identifier of the smart card is used to be compared to the reference stored in the server 5. During authentication, the terminal 3 retrieves via its receiver 33 a geolocation signal. Terminal 3 extracts its position and the current date and time.

During authentication, 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. Thus, in the absence of availability of a dating server, for example if only a connection to the local network is available, 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. Advantageously, the position of the terminal 3 is also transmitted to the server 5. Thus, 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. As illustrated in FIG. 20, 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.

The use of the date extracted by the terminal 3 will also enhance the safety crossover with a value possibly recovered on a server type NTP.

Terminal 3 is intended not to be nominative. To this end, the terminal 3 erases all the personal data of its user at the end of the session, including all the data stored on the support 35. The terminal 3 can thus be used successively by users without links between them without their information nominative is vulnerable.

In order to be compatible with different operating systems of the user's terminals, the terminal 3 will include APIs compatible with several types of operating systems. The terminal 3 can thus be used indifferently by all types of users, which strengthens its ability to be used successively by different users according to their needs. The terminal 3 can send display frames without the data themselves being recordable in the terminal 1. The terminal 3 may have in particular read applications of different file formats to allow viewing these types of files on the terminal 1. The interface 37 may in particular be a wireless interface (defined by an IEEE 802.11 standard or an IEEE 802.15 standard) or a wired interface (RJ45 or USB for example).

FIG. 4 details a process for generating a private digital certificate implemented using the application 12. During step 401, 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.

During 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.

In 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. In step 404, all the data retrieved by the terminal 1 is encrypted by means of the symmetric key Kst stored in the terminal 3.

In step 405, the terminal 1 transmits the encrypted data to the server 5.

In 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.

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;

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;

a third KeS 3 symmetric encryption key for encrypting the secure data streams broadcast from the database 6 to the proprietary entity itself; a fourth KeS4 symmetric encryption key for encrypting an access policy certificate;

a pair of asymmetric encryption keys Kpr and Kpc, intended for the encryption / decryption of certificates negotiated with other entities. In particular, the private digital certificate may include the following fields:

-VaI FPT: binary image of one or more fingerprints;

-VaI Kp: Value of asymmetric encryption key pair Kpr and Kpc;

-Info Kp: Information of the asymmetric cryptographic protocol retained;

-VaI Ks: Value of KeS2 symmetric encryption key; -Info Ks: Information of the symmetric cryptographic protocol retained;

-Import_X.509: possibility to import a digital certificate of the X.509 standard ...

-CRC: checksum integrity of all fields;

-SN: unique serial number of said Cepr digital private certificate.

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. Advantageously, the control procedure will allow the server 5 to check the authenticity of a private digital certificate imported by its owner as follows:

-application of the non-reversible hash function to the information contained in the imported private digital certificate. The result noted CRC temp is temporarily stored by the server 5;

encrypting the result CRC temp with the private key of the pair of asymmetric encryption keys of the server 5. The result of this encryption is noted CRC temp sig;

-comparison of CRC temp sig with the CRC field of the private digital certificate still stored in the server. Other means of control may be implemented by the server, in particular by decrypting the CRC field imported using the public key of the server.

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.

The CePc public certificate may include the following fields:

-Info User: Restricted data identifying the legitimate holder of the private digital certificate such as Name, First names, Pseudonym, ...;

-Hash: digital fingerprint of CePr digital certificate guaranteeing the mathematical link with the private digital certificate; -DHC: Date timestamp of creation;

-SN: 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.

When creating the CePr private digital certificate, 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.

Through their application 13, following an invitation from the owner of the data, or following a request from the third party, 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.

In 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.

In step 502, 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

In step 503, the conditions for access to the secured data may possibly be the subject of prior negotiation. At the end of this 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.

In 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. These certificates

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. For simplicity, we consider that A is an entity that owns digital data and that B is a third party for this data.

However, B may be a proprietary entity of digital data stored in base 66. A is then considered a third party for this data. The same symmetric encryption key

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 ...

-Hash: integrity checksum of all fields;

Figure 6 illustrates a process of accessing a user's private digital certificate. This process is notably implemented during the updating of the private certificate, or during any secure data access operation. During a step 601, the user starts the application 12 on his terminal 1. During a step 602, the terminal 1 detects the presence of the authentication terminal 3. During a step 603, the terminal 3 reads authentication information entered by the user, for example his fingerprint on the reader 31. During a step 604, the read authentication information is transmitted encrypted (with the key Kst) to the terminal 1. During a step 605, the Terminal 1 encrypts the authentication information read to the server 5. During a step 606, the server 5 consults the biometric database 65 and compares the authentication information read with the stored reference. During step 606, the server 5 also compares the time stamp information generated by the terminal 3 with time stamp information provided by the server 7. At the end of step 606, once the user is authenticated, 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. In step 608, 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. Figure 7 illustrates a process of accessing the different negotiated certificates held by the user. In step 701, 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. In the step 706, 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. In step 707, the negotiated user certificates stored in the database 63 are decrypted by means of this private key Kpr. In step 708, 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.

Figure 8 illustrates a process for defining the access policy certificate of the user who owns the digital data. During a step 801, the proprietary entity A starts the application 14 on its terminal 1. The terminal 1 detects the presence of the authentication terminal 3. During a step 802, a strong authentication of the proprietary entity is performed as detailed before. At the end of step 802, once 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. In step 805, 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. For example, 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.

Preferably, 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. During a step 901, the third party B launches the application 17 on its terminal 1. The terminal 1 detects the presence of the authentication terminal 3. During a step 902, a strong authentication of the user B is performed as detailed before. At the end of step 902, once 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. At step 904, the negotiated digital certificate CeNeaB is decrypted using the private key KprB. During a step 905, the broadcast key KseB for broadcasting the digital data to B is then loaded into the server 5. In step 906, the encryption key KeS4A is extracted from the CePrA certificate and loaded into the server 5 In step 907, the CeSeA access policy certificate is decrypted with the KeS4A key. The access rights are read by the server 5. At the step 908, 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. In step 909, the data to be broadcast is encrypted with the broadcast encryption key KSeB. In step 910, the encrypted data is broadcast to the third party B. The application 17 allows the user of the terminal 1 to which data has been broadcast to view their content.

Advantageously, 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. For example, the KeMaB encryption key will be stored in the CeNeaB negotiated certificate or in a CeMaB hardware digital certificate.

Preferably, 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. When the proprietary entity A wishes to broadcast its digital data to itself, it will carry out the strong authentication of A, the decryption of its private digital certificate with the KeSlA key, the decryption of its KeSeA access policy certificate with the KeS4A key, the decryption of its digital data with the KeS2A key, the encryption of the data to be broadcast with the KeS3A key, and the dissemination of the digital data to AT.

Preferably, 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.

As illustrated in FIG. 10, 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.

For security reasons, 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. Thus, 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. Holders A and B of the CeprA and CePrB digital private certificates, and holders C and D of the private digital certificates CePrC and CePrD previously created respectively the CeNeAb, CeNeaB, CeNeCd and CeNecD traded certificates. The CePcAb CePcaB, CePcCd and CePccD public certificates corresponding to these CeNeAb, CeNeaB, CeNeCD and CeNecD certificates are published in a directory. User B (holder of the CeNeaB certificate) and user C (holder of the CeNeCd certificate) wishing to define access to digital data of one or the other, authenticate with the server 5, and negotiate the creation of new CeNeaBcd and CeNeabCd negotiated certificates. CePcaBcd and CePcabCd public certificates will allow users B and C to re-negotiate the creation of a negotiated certificate with another entity. Although 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.

In a first step, 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.

In the example, 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.

In the example, although only one server 5 has been illustrated, the functions performed can be distributed over different servers. Likewise, although only one database 6 has been illustrated, the various contents described can be stored in different remote databases. Advantageously, all the aforementioned digital certificates (CePr, CePu, CeNe, CeSe, CeMa) are stored on one or more secure remote servers in a database according to a suitable client / server architecture.

Claims

1. strong authentication terminal (3) of a user, characterized in that it comprises: a reader (31,34) of authentication parameters of a user; a receiver of a geolocation signal (33);

a communication interface (37) with another apparatus;

a processor (38), extracting the date and time of the geolocation signal, generating encrypted data including read 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 (37).

Terminal (3) according to claim 1, wherein the processor (38) extracts the position of the terminal from the geolocation signal and includes the extracted position in the encrypted data.

Terminal according to claim 1 or 2, comprising a non-volatile memory (36) storing a symmetric encryption key, the processor generating the encrypted data using this symmetric encryption key.

Terminal according to any one of the preceding claims, comprising:

a storage memory (35) accessible via the communication interface (37); a control interface through which a user can control the end of a session of use of the terminal; the processor (38) controlling the erasure of the storage memory at the end of each use session.

5. Terminal according to claim 4, storing interpretation applications of different types of files stored in the storage memory (35), the processor (38) being able to execute these applications, able to generate an image of the content of an interpreted file capable of transmitting this image via the communication interface.

Terminal according to one of the preceding claims, wherein the authentication parameter reader is a fingerprint reader.

The terminal of any one of the preceding claims, wherein the authentication parameter reader is a retinal fingerprint reader.

8. Terminal according to any one of the preceding claims, wherein the authentication parameter reader is a keyboard, the terminal further comprising a smart card reader.

Terminal according to any of the preceding claims, wherein the communication interface is a wireless communication interface.

Terminal according to any one of the preceding claims, wherein the receiver is configured to receive a GPS signal.