Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
  • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
  • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
  • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
  • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
• • 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/3218—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 proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
• • 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

Definitions

• the present invention relates to an interface method and device for the secure exchange of online content data.
• data transport networks make it possible to design and use numerous services accessible online, that is to say accessible remotely via a data transport network.
• Examples of such services are electronic commerce, broadcasting audio-visual programs, electronic mail, online banking and financial management services, access to databases and mobile access to a virtual office, among other.
• This type of service is generally made accessible by the service provider by means of one or more data server (s) connected to the data transport network.
• the use of such services involves exchanging content data, that is to say data which convey the content of the service, between a user interface device and at least one server of the service provider, via the data transport networks.
• this content data is generally personal or reserved for the user and / or for the service provider.
• recipient and sender should be understood here to mean computers or similar devices connected to a data transport network or the users or operators of such computers or devices.
• Various cryptographic methods are known for ensuring such protection. For example, electronic signature methods allow any recipient of a message to verify the identity of the sender and to verify that the content of the message has not has been altered during transport.
• the authentication methods make it possible to verify the identity of the correspondent with whom the data exchange is carried out.
• the encryption methods symmetrical or asymmetrical, allow the data to be put into a form unusable by any third party other than their legitimate recipient.
• the implementation of these cryptographic methods requires the use of an interface device capable of performing complex calculations, that is to say of a device comparable to a computer in the broad sense of the term, such as a workstation, cell phone, personal digital assistant, microcomputer, television decoder or smart card.
• This implementation is generally possible using a software implementation of the method on the interface device, software implementation which may possibly be public.
• the software or hardware implementation of the cryptographic method can only be used by a person to protect content data when this implementation is configured by means of personal cryptographic data, i.e. - say specific to this person.
• personal cryptographic data that are for public use, such as a public key allowing any third party to verify electronic signatures issued by this person
• personal cryptographic data that are for private use such as a private key allowing the person to '' issue its own signature. It is imperative to keep secret these personal cryptographic data, at least those which are for private use. Indeed, if a person other than the authentic owner of personal cryptographic data takes possession of it, this person can use all online services on behalf of the authentic owner and without being easily unmasked.
• a first solution consists in using personal cryptographic data which is intrinsic to its owner and therefore does not require any physical storage means.
• This kind of Personal cryptographic data includes passwords stored by their owner and biometric data, such as fingerprints and retinal images.
• biometric data requires the use of a specific reader, the cost of which is high and the use of which is not very widespread.
• biometric data has a fixed configuration which it is not possible to adapt to all useful formats, for example for their use in standard authentication and encryption methods such as OpenPGP (acronym for English: Open Pretty Good Privacy), S / MIME (acronym in English: Secure Multipurpose Internet Mail Extensions), SSL (acronym in English: Secure Socket Layer).
• a second known solution consists in storing personal cryptographic data locally on the device which implements the cryptographic method in which said data is used.
• This solution consists, for example, of storing this data on the hard disk of a microcomputer serving as an interface device for using online services or in the non-volatile memory of a cellular telephone.
• a smart card is easy to carry and can be shielded. However, the strength of the shield depends on the cost and format of the Smartcard. It is known that that of the usual smart cards can be successfully pierced with a budget of the order of 10 4 Euros.
• the workstation transforms the password into a symmetric encryption key by applying a hashing algorithm
• the workstation requests from the remote server the user's private key, which is stored on the remote server in encrypted form using the symmetric key derived from the password; - the remote server sends this private key in encrypted form to the workstation, which decrypts it with the symmetric key.
• this third party may attempt what is called an offline dictionary attack, that is to say, may try a large number of usual passwords (all words existing in all languages for example) without interaction with the server.
• US-A-5,491,752 proposes to authenticate the user having the password before sending him his encrypted keys.
• the proposed techniques essentially consist in sending the hash value of the password to the server in order for it prove knowledge of the password. This value must be sent encrypted so that it can only be read by the remote server.
• This authentication of the user could be done in a more or less complex manner, but in any case it requires that verification data is initially stored on the remote server. It is indeed impossible to identify a user from scratch.
• the remote server can perform an offline dictionary attack. The only data characterizing a user is his username (a priori public) and his password. The remote server can therefore try a large number of passwords since it has direct access to the verification data.
• this prior art assumes that the server's public encryption key is known. In other words, it is assumed that there is already a channel to guarantee that the data sent will be received by the remote server and by him alone.
• the object of the invention is to remedy at least some of the abovementioned drawbacks, by providing a method and an interface device for exchanging content data online which ensures good protection of the content data, which is easy to use and accessible as widely as possible.
• the invention provides a method for the protected exchange of online content data comprising the steps of: receiving a code entered by a user in an interface device connected to a first server device by at least one network transporting data, sending a read request from said interface device to said first server device in which are stored respective personal cryptographic data of a plurality of users, said personal cryptographic data of each user being encrypted by means of a respective authentic code of said user, receiving the encrypted personal cryptographic data of said user in said interface device, decrypting said personal cryptographic data by means of said code entered when said entered code corresponds to said authentic code of the user, characterized in that 'he composes all the steps consisting in: using said personal cryptographic data to protect an exchange of content data between said interface device and said at least one second server device connected to said interface device by at
• a data transport network designates any link means capable of transporting data, whether in optical, radioelectric or electric form, and can consist of optical fibers, electric cables, coaxial cables , radio or microwave or infrared transmit / receive stations, routers, repeaters, and any combination of these elements known to those skilled in the art.
• Several networks having at least one crossing point from one to the other also constitute a data transport network within the meaning of the invention.
• the storage of users' personal data in the first server device makes it possible to make this data accessible remotely from an interface device connected to the first server device.
• the personal cryptographic data of the user is therefore kept at his disposal without requiring the transport of a mobile device or a smart card.
• Personal cryptographic data is stored on the first server device in an encrypted form using an authentic code known only to their legitimate user, so that their confidentiality is preserved, including vis-à-vis the first server device.
• the authentic code and the encrypted or decrypted personal cryptographic data are only kept on the interface device for the duration of a session, i.e. the time necessary for their use, respectively to decrypt the personal cryptographic data received. from the first server and to protect by a cryptographic method an exchange of content data between the interface device and the second server device, after which they are deleted from the interface device.
• the user does not need to control access to the interface device between two sessions, which can therefore be used by a multitude of users, for example according to a self-service rule.
• said interface device and said first server device establish a confidential communication channel between them by pooling at least one encryption key having a large entropy relative to said authentic code of the user, said personal data. encrypted cryptographic being transmitted to said interface device by said confidential communication channel.
• This provides a first level of protection against dictionary attacks from a third party intercepting communications between the interface device and the first server device. For this, you can use a key exchange protocol or Key-Exchange which allows two parties who have no prior common secret data to calculate such data and then use it, for example, as a symmetric encryption key, then called session key.
• At least one personal code verification data item which derives from said authentic user code according to a deterministic function is stored in said first server device and said first server device explicitly or implicitly authenticates said interface device using of said personal code verification data.
• Implicit authentication of the interface device means that the first server device, without having any guarantee on the identity of its interlocutor in this case, is assured that only an interface device having the authentic code will be able to interpret its response.
• the deterministic function can be the identity function, in which case the first server device stores the authentic code itself.
• said deterministic function is a non-invertible function resistant to collisions, in particular a cryptographic hash function.
• said interface device and said first server device simultaneously perform the pooling of said at least one encryption key and the explicit or implicit authentication of said interface device by said first server device using a password-based-key-exchange protocol PBKE.
• the PBKE type protocol designates a family of protocols also known by the name of Password Authenticated Key Agreement (PAKA). These protocols verify at least the following conditions:
• the two parties use only a low entropy code in the sense of the number of possible realizations, for example a password or its derivative, as certain common data, - from this common data, the two parties establish a secure communication channel, i.e. based on at least one key of greater entropy, without allowing offline dictionary attacks by third parties seeking to obtain this common data,
• PBKEs include a subfamily of protocols called the Encrypted Key Exchange (EKE).
• EKE is a general concept, theoretically applicable to any key exchange protocol; but, for the moment, research in cryptography has only developed the technical details in the case of Diffie-Hellman and its variants on other groups (such as for example on elliptic curves).
• Such a protocol provides protection of said at least one encryption key against interception by a third party which would intercept all communications between the interface device and the first server device without knowing said authentic code or its derivatives.
• said Password-Based-Key-Exchange type protocol includes a single communication in each direction between said interface device and said first server device.
• said communication from the first server device to the interface device includes the transmission of encrypted personal cryptographic data.
• said interface device chooses a first integer corresponding to a first element of a predefined group and said first server device chooses a second integer corresponding to a second element of said group, for example of the form g x mod p, then said interface device and said first server device transmit said first and second elements to each other, said interface device and said first server device each producing said at least one encryption key by combination of the integer chosen by itself and of the element received by itself, said first element of the group being transmitted to said first server device in an encrypted form by means of a discriminating trace which derives from said code entered by the user in the interface device according to said deterministic function , said first element of the group being decrypted by said first server device by means of said personal code verification data, said second element of the group being transmitted to said interface device in a symmetrically encrypted form by means of said personal code verification data, said second element of the group being deciphered by said interface device to the by means of said discriminating trace.
• a PBKE protocol on the Diffie-Hellman protocol makes it possible to recover encrypted personal cryptographic data on the remote server with authentication by password and resistance to attacks by offline dictionary.
• said first and second elements of the group are encrypted with a symmetric encryption protocol which is chosen so that an attempt to decrypt one of said elements of the group according to said protocol always produces an element of said group, whatever the key used in said attempt.
• said first and second elements of the group are encrypted with a symmetric encryption protocol which is chosen so that said integer cannot be obtained from the element of the corresponding encrypted group.
• said first element of the group is encrypted with a symmetric encryption protocol which comprises the step consisting in composing said element by a composition law of said group with the image of said discriminating trace, respectively the image of said personal code verification data, by a function with values in said group.
• said step of using comprises the step of authenticating said user with said at least one second server device by means of authentication data of said user included in said personal cryptographic data.
• the authentication data includes a digital certificate of the user.
• said step of use comprises the steps consisting in: receiving content data entered by said user in said interface device, encrypting said content data by means of at least one an encryption key included in said personal cryptographic data, sending said encrypted content data to said at least one second server device to store said encrypted content data in said second server device and / or transmitting it to a recipient.
• the encryption key is a strong cryptographic key, for example greater than or equal to 128 bits, for symmetrically encrypting said content data.
• said step of use comprises the steps consisting in: sending a second read request designating content data from said interface device to said at least one second server device, receiving said encrypted content data from said at least one second server device in said interface device, decrypting said content data by means of at least one decryption key included in said personal cryptographic data.
• This embodiment can be applied to the reception of encrypted electronic mail, to the reception of audio and / or video content data, and to the read access to a personal database, said content data being personal data. which have been previously encrypted using said personal cryptographic data and stored by said user in said second server device.
• This embodiment also makes it possible, in the case where the second server is also a key server similar to the first, to access the user's private keys stored in encrypted form on the second server. The connection to the second server is then made using personal cryptographic data retrieved from the first server.
• the protection of private keys is increased by making their recovery dependent on the success of a series of prior connections to several successive key servers.
• said first read request includes a discriminating trace of said code entered and said personal data of each user includes personal code verification data to verify that said code entered corresponds to said authentic code of the user, said said encrypted personal cryptographic data of said user being received in said interface device only if said code entered corresponds to said authentic code of the user.
• a discriminating trace of the code is a trace which makes it possible to differentiate two different codes. It can be the code itself - but this embodiment is not recommended for security reasons - or an image of the code by a deterministic and collision-resistant cryptographic function, that is to say a function which has a property injectivity in the computational sense of the term, insofar as it is technically impossible to construct two antecedents of the same image.
• the discriminating trace is used to prove that the user knows the authentic code, as much as possible without disclosing the authentic code.
• the code entered by the user of the interface device is used to authenticate it with the first server and the personal cryptographic data is only sent to the user when he has demonstrated that he knows the code.
• authentic which prevents a third party from receiving encrypted personal cryptographic data in an attempt to break their encryption by systematic tests.
• personal code verification data may include a user identifier and the authentic password or data derived from it.
• the method according to the invention comprises the steps consisting in: calculating said discriminating trace as a non-invertible transform of the code entered in said interface device, said personal code verification data stored in the first server device comprising a transform similar to said authentic code.
• the personal code verification data stored in the first server device results from a non-invertible transformation of the authentic code, so that the authentic code of the user cannot be found from the personal code verification data stored in the first server device. This prevents even the first server device and its operators from being able to easily find the authentic code.
• the method according to the invention comprises the step consisting in imposing a predetermined minimum time between the processing of two successive occurrences of said first read request at the level of the first server device, under penalty of not taking account of the latest occurrence.
• each test requires interaction with an entity that legitimately knows the password (for example a computer server on a network);
• - offline attacks the attacker has all the data necessary to "try" each password on his own computers and check its validity.
• Offline attacks are fatal because only the power of the attacker's computer limits the number of attempts he can make every second; a realistic speed is around 10,000 tests per second, which means that the password will be found in a few minutes.
• Online attacks can be easily countered: it is enough for the contacted server to limit the number of attempts by the attacker, for example by imposing a delay on each response, or by refusing to respond after a certain number unsuccessful attempts.
• the method according to the invention comprises a step consisting in systematically monitoring the communications involving said first server device.
• the read requests received by the first server device and the cryptographic data sent in response by the first server device are few and not very large, which makes such control possible without excessive cost.
• the first server device is exclusively dedicated to storing the personal data of the users and making these available to their owners when the latter so require, at the start of a session, which contributes to limiting the volume of said communications.
• the method according to the invention comprises the step of: controlling the integrity of the personal cryptographic data received from said first server device by means of integrity control data appended to said personal cryptographic data received from said first server device.
• the method according to the invention comprises the step consisting in authenticating said first server device with said interface device before sending said first read request.
• a false first server device is prevented from receiving the request, which may contain the discriminating trace of the authentic code of the user, and therefore from being able to mount an attack "by dictionary" relating to the authentic code.
• the method according to the invention includes the step of establishing confidential communication with the first server device before sending said first read request from the interface device.
• This prevents any third party intercepting communications between the first server device and the interface device from reading the first request, which may contain the discriminating trace of the user's authentic code, and therefore from being able to mount a “dictionary” attack relating to the authentic code.
• the authentication of the first server device and / or the establishment of a confidential communication are carried out using a digital certificate of the first server device and the SSL protocol.
• the method according to the invention comprises a registration step consisting in: making personal cryptographic data available in said interface device, receiving an authentic code entered by said user in said interface device, encrypting said personal cryptographic data using said authentic code, sending said encrypted personal cryptographic data from said interface device to said first server device for storing said cryptographic personal data encrypted in said first server device, deleting said personal cryptographic data and said authentic code from said interface device.
• the registration step also comprises the steps consisting in: forming personal code verification data from said authentic code, sending said personal code verification data from said interface device to said first server device for storing said code personal code verification data in said first server device.
• Personal cryptographic data can be made available by reading said data on a medium such as a smart card or by generating said data in the interface device from a random number generator.
• the authentic code is a password memorized by the user which is transformed into a cryptographic key in the interface device to symmetrically encrypt at least some of the personal cryptographic data.
• the method according to the invention comprises a step consisting in rejecting said authentic code entered by the user when said code meets predefined obviousness criteria.
• the authentic code cannot be an obvious code, which reinforces the security of the data stored on the first server device against “dictionary” attacks fomented to fraudulently obtain the authentic code and personal cryptographic data, including by those having control of the first server device.
• the criteria predefined evidence can impose a minimum number of characters, a minimum number of non-alphanumeric characters, and exclude common character strings, such as dates, first names, etc.
• the method according to the invention comprises the step consisting in authenticating said first server device with said interface device before sending said encrypted personal cryptographic data.
• the method according to the invention comprises the step consisting in establishing confidential communication between the interface device and the first server device before sending said encrypted encrypted cryptographic personal data. Therefore, any third party posing as the first server device or spying on exchanges between the first server device and the interface device is prevented from receiving the encrypted cryptographic personal data, and therefore from being able to mount a “dictionary” attack relating to the authentic code for decrypting said personal cryptographic data.
• the invention also provides an interface device for the protected exchange of online content data, comprising means for receiving a code entered by a user, means for sending a first read request from said interface device to a first server device in which are stored respective personal cryptographic data of a plurality of users, said personal cryptographic data of each user being encrypted by means of a respective authentic code of said user, means for receiving the encrypted personal cryptographic data said user from said first server device, means for decrypting said personal cryptographic data using said entered code, when said entered code corresponds to said authentic user code, characterized in that it comprises: means for using said data personal cryptographic in order to protect an exchange of content data between said interface device and at least one second server device, means for deleting said code and said personal cryptographic data from said interface device.
• the interface device according to the invention can be produced as a device whose hardware design is specific for this purpose, or as a device of conventional hardware design, for example a generic microcomputer, programmed by means of 'a specific computer program for this purpose, or as a combination of the two.
• the interface device according to the invention can also be produced as a computer program.
• a computer program comprises instruction codes capable of being read or stored on a medium and executable by a computer or similar device.
• the device consists of an electronic mail management program, said means of using personal cryptographic data comprising a cryptographic module for signing, encrypting and / or decrypting electronic mails by using at least some of said personal cryptographic data.
• the device consists of an extension module suitable for an electronic mail management program comprising a cryptographic module for signing, encrypting and decrypting electronic mails, said means of using the personal cryptographic data comprising means for providing said cryptographic module with at least some of said personal cryptographic data.
• the invention also provides a registration interface device, characterized in that it comprises: a means for making personal cryptographic data available in said interface device, means for receiving an authentic code entered by said user in said interface device, means for encrypting said personal cryptographic data using said authentic code, means for sending said personal cryptographic data encrypted from said interface device to a first server device for storing said encrypted personal cryptographic data in said first server device, in which are stored respective cryptographic personal data of a plurality of users, said personal cryptographic data of each user being encrypted by means of a respective authentic code of said user, means for deleting said personal cryptographic data and said authentic code from said interface device.
• FIG. 1 is a block diagram of a system for implementing the data exchange method according to the invention
• FIG. 2 is a diagram representing a step of registering the data exchange method according to the invention
• FIG. 3 is a diagram representing a session for using the data exchange method according to the invention.
• FIG. 4 represents an application of the method according to the invention to a personal database
• FIG. 5 represents an application of the method according to the invention to the management of secure electronic mail
• FIG. 6 represents an application of the method according to the invention to audiovisual broadcasting
• FIG. 7 shows another embodiment of the usage session.
• a data transport network links together content servers 2a and 2b offering online services, a key server 3 and devices interface 4a, 4b, 4c to use the services offered by the content servers 2a and 2b.
• the interface devices 4a, 4b are conventional computers comprising a memory, a data processing unit and I / O and storage peripherals. They are connected to network 1 by wire links 5a and 5b.
• the interface device 4c is a cell phone also comprising a memory, a data processing unit, a keyboard 6 and a screen 7. It is connected to the network 1 via a radio link 5c with a radio station. transmission / reception integrated into the network 1.
• the system may include a very large number of each.
• the invention is not limited in this regard.
• the same computer can simultaneously constitute several servers, these being implemented in software form and each having a specific address on the network 1.
• the key server 3 can be implemented by the same computer as a content server.
• the content servers 2a and 2b serve to provide the users of the interface devices 4a, 4b, 4c with services involving content data.
• the content servers 2a and 2b may include web site servers, e-mail servers, audio / video data servers, fax servers, FTP file transfer servers, mailing list servers, IRC real-time discussion servers, information servers, e-commerce servers, etc.
• the key server 3 is a server exclusively dedicated to store personal cryptographic data and personal code verification data of a plurality of users registered with the key server 3 or its operator, and to transmit to any device d interface from which a registered user requests the personal cryptographic data of this user.
• the latter is preferably located in a place protected by shielding and / or access restrictions.
• the key server 3 is physically closed as much as possible, in particular by closure of communication ports which are not essential. Due to the restricted functions performed by the key server 3, the number of accesses to it and the volume of data which it exchanges are quite limited.
• the content data is generally large and can be the subject of a multitude of simultaneous accesses, so that the volume of exchanges between each content server 2a or 2b and the network 1 is generally much greater than 'between the key server 3 and the network 1, which is symbolized by the thickness of the connection lines between the respective servers and the network 1.
• the smallness of the incoming and outgoing data flows from the key server 3 allows a monitoring system 8, symbolically represented in FIG. 1, monitors in real time the communications between the key server 3 and the network 1, for example by monitoring the log book of the key server 3.
• a user performs a registration step from an interface device 4a-c which will now be described with reference to FIG. 2.
• step 10 the user launches a registration application on an interface device, for example a microcomputer connected to the network 1.
• an interface device for example a microcomputer connected to the network 1.
• the interface device In step 11, the interface device generates personal cryptographic data for the user.
• a private key KS is generated by means of a secure pseudo-random generator embedded in the interface device and using random initialization data originating from a physical measurement. .
• Several methods exist for obtaining such initialization data for example by asking the user to randomly strike keys on a keyboard of the interface device and by precisely timing the time intervals between two successive keystrokes.
• a key pair formed by a public key KB and a corresponding private key KR is generated. All these keys are chosen to be long enough, for example 128 bits or more, to ensure high cryptographic security.
• step 12 the user has his public key KB certified by a certification authority, which may be an independent entity which is not represented or the key server 3, according to a known technique. Such certification is used to prove that a public key KB belongs to this given person, who alone has the corresponding private key KR.
• the user thus obtains a digital certificate A which contains the public key KB and various identifying data of its owner, such as the name of the user, his address, his age, etc.
• digital certificate A is in the standardized X.509 format that can be used in an SSL encryption protocol.
• the private key KR, the digital certificate A and the symmetric key KS constitute the user's personal cryptographic data.
• Steps 11 and 12 are only an example of making available the user's personal cryptographic data in the memory of the interface device.
• the user could have obtained such keys beforehand, for example on a medium such as a smart card, and load this data into the memory of the interface device using a suitable reader.
• This provisioning step having to be carried out only once, the smart card could then be put in safety in a safe to serve as a backup copy.
• Personal cryptographic data within the meaning of the invention is not limited to the aforementioned combination of keys. This data could also be limited to a single private key or, on the contrary, be more numerous. However, it is preferable to provide separate keys for each function.
• the pair formed by the certificate A and the private key KR is used for the user authentication function and the private key KS for the encryption / decryption function of the content data.
• the user is invited to enter a personal identifier N, such as his name or a pseudonym, and a personal password in the interface device. This password is chosen by the user. If the password entered is less than eight characters or less than two non-alphanumeric characters, it is automatically rejected and the invitation is reiterated.
• the authentic password P is non-invertibly transformed into a symmetric encryption key KP by applying a hash function to the concatenation of the identifier N and the authentic password P of l 'user.
• the hash function used is the SHA function defined by the FIPS 180 standard.
• a personal password verification key VP is calculated by a non-invertible injective transformation of the authentic password P.
• VP results from the application of a hash function to the key of symmetric KP encryption.
• the private key KR and the digital certificate A are symmetrically encrypted using the symmetric key KS.
• the symmetric key KS is encrypted symmetrically using the encryption key KP resulting from the authentic password P.
• the user's personal cryptographic data is considered to be encrypted by the authentic password P, i.e. it is encrypted in such a way that the authentic password P is necessary to decipher them.
• the interface device establishes a secure communication with the key server 3 via the network 1.
• the standard SSL protocol can be used which ensures the confidentiality and integrity of the data exchanged between the device interface and the key server 3, as well as the authentication of the key server 3 with the interface device.
• the SSL protocol has several variations, one of which is described below.
• the interface device contacts the key server 3 and signals its intention to communicate with it.
• the key server 3 randomly chooses a pair of keys formed by a public key PA and a private key KV, corresponding to the standard Diffie-Hellman algorithm.
• the key server 3 has a public certificate CA which contains another public key SP of the key server 3, to which corresponds a respective private key SR of the key server 3.
• the key server 3 transmits to the interface device the public certificate CA, the public key PA and an electronic signature of the public key PA by the private key SR.
• the interface device verifies the signature of the certificate CA using the public key of the certification authority which signed it, and verifies the signature of the public key PA using the public key SP.
• the interface device randomly chooses a pair of keys formed by a public key PB and a private key KW, according to the Diffie-Hellman algorithm, and transmits the public key PB to the key server 3.
• the key server 3 calculates a session key KT as a function of the public key PB and its private key KV.
• the interface device calculates a session key KT as a function of the public key PA and of its private key KW.
• the Diffie-Hellman algorithm ensures that the interface device and the key server 3 calculate the same session key KT, that is to say that they obtain the same calculation result differently. This result cannot be calculated without the knowledge of at least one of the private keys KV and KW.
• a large prime number for example 1024 bits
• the Diffie-Hellman protocol is as follows:
• - A calculates g a mod p and sends the result to B.
• - B randomly chooses an integer b modulo q; this choice is made uniformly between 0 and q - 1 (inclusive).
• - B calculates g b mod p and sends the result to A.
• the security of the Diffie-Hellman protocol rests on the difficulty of finding the integer a, because a is chosen randomly, from g a mod p. This problem is known as the discrete logarithm. If p is large enough (e.g. 1024 bits) and a is chosen from a sufficiently large set (i.e. q is large enough - at least 160 bits), then the discrete logarithm is beyond of existing technology.
• an elliptical curve is a set of points, each point having two coordinates in a finite body.
• the Diffie-Hellman protocol assumes that the exchanges are intact, that is to say that the data sent by A and by B are not modified on the way by an attacker.
• the Diffie-Hellman protocol does not authenticate both parties. This is why it is necessary to have the public CA certificate of the key server in the aforementioned SSL protocol.
• the two interlocutors have pooled a temporary KT key that only they know.
• the key server 3 is authenticated with the interface device by means of the proof of identity constituted by the certificate CA. All their subsequent exchanges are carried out, at the transmitter, by encrypting symmetrically with the session key KT the data to be sent and, at the receiver, by decrypting with the session key KT the data received.
• the content of the data thus exchanged is perfectly secret vis-à-vis any intermediate transport device.
• the client that is to say the interface device or its user, is not yet authenticated with the key server 3.
• This authentication can be carried out by any known method making it possible to identify the client with the registration authority having control of the key server 3.
• the registration authority may require a physical meeting with a future user before registration to find out your identity by presenting official documents at a registration desk.
• the registration authority can assign and confidentially communicate to the future user a password, which must be entered by the user on the interface device to establish the aforementioned SSL connection.
• the SSL protocol can also be used in a bi-authenticated manner: for this, the interface device makes use of its certificate numeric A containing the public key KB.
• the interface device signs the public key PB using the private key KR and sends to the key server 3 the signed public key PB and the certificate A.
• the key server 3 verifies the signature of the certificate A at using the public key of the certifying authority that signed it, and verifying the signature of the public key PB using the public key KB.
• the user of the interface device is authenticated with the key server 3 thanks to the proof of identity constituted by the certificate A.
• all the data packets M exchanged between the interface device and the key server 3 are provided with integrity control means allowing the recipient to verify that the data have not been altered between their transmission and their reception.
• An example of such control means which applies in particular when the encryption of the exchanged data is carried out using a symmetric block encryption function, consists in concatenating with the data packet M itself, before its encryption with the session key KT, the result of applying a hash function to the data packet, for example SHA (M).
• M hash function
• the recipient of the data packet can thus verify that the data it has received does indeed have an M // SHA (M) type structure, which allows the recipient to detect any data corruption during the communication and report it to the sender to repeat the shipment or take other security measures.
• the interface device securely sends to the key server 3 a request to create a personal user account containing: the identifier N, the personal cryptographic data A, KR, KS encrypted by the authentic password P and the password verification key VP.
• the key server 3 stores this data in an account, that is to say a storage space, reserved for the user, for example on a hard disk.
• the key server 3 sends a message confirming the creation of the account. The exchanges between the interface device and the key server 3 are now finished with regard to the registration and the temporary session key KT can be erased by the two interlocutors.
• step 28 the user closes the registration application, which erases the authentic password P and all the cryptographic personal data A, KB, KR, KS encrypted or not from the memory of the interface device. No confidential user data remains in the memory of the interface device, so that the user is not linked to this particular device and that no access control to the latter is necessary thereafter.
• the interface device can be of public access, for example in an internet cafe.
• the registration step thus allows the user to store on the key server 3, which is accessible from any interface device connected to the network 1, cryptographic personal data in an encrypted form which he is the only one to be able to decipher.
• the encryption obtained using the KS key is a strong encryption which is considered inviolable, because of the length of this key.
• the encryption obtained using the KP key is generally weaker since it derives directly from the password P which must be of reasonable length to be memorized by the user.
• the password P is not stored on no support. It cannot be found directly from the VP verification key, except by a systematic search. In addition, such a systematic search would only be possible by the key server 3 which is the only one to store the verification key VP. It never travels in clear over network 1.
• step 10 above an online registration procedure has been described ensuring the authentication of the key server 3 and possibly the authentication of the user, as well as the confidentiality of the exchanges between the user and the key server 3.
• Other registration procedures ensuring the same guarantees are nevertheless possible.
• the user can be led by the registration authority into an armored room containing the key server 3, in which case the authentication of the server and the confidentiality of communications are ensured by non-cryptographic means, by the simple fact the absence of an intermediate communication device and the physical isolation of the interlocutors from the outside.
• step 30 the user launches the session application.
• step 32 the user is invited to enter his identifier N and his authentic password P.
• the user enters an identifier N 'and a password P' using the keyboard.
• step 34 a symmetric encryption key KP 'is calculated from the password P' and the identifier N 'in the same way as the symmetric encryption key KP in step 16. Then a key VP 'is calculated from the symmetric encryption key KP' in the same way as the verification key VP in step 18.
• step 36 the interface device establishes a secure communication with the key server 3 via the network 1, for example by using the standard SSL protocol in a similar manner to step 22.
• the interface device does not have the user's certificate A at this stage. It generates a pair of public / private keys specially to establish this communication, which implies that the key server 3 cannot authenticate the user at this stage.
• the interface device sends the key server 3 a read request containing the identifier N 'and the key VP'.
• step 38 the key server 3 processes this request by identifying the account corresponding to the identifier N ', if there is one, and by comparing the verification key VP stored in this account with the key VP 'received in the request.
• the account does not exist, or if the comparison is negative, this indicates that the user has not entered the authentic username / password pair of a registered user. Indeed, due to the collision resistance of the hash function, as long as P 'differs from P, VP' differs from VP.
• the key server 3 then sends in response a refusal of access message, as indicated by the arrow 40. This ensures that the encrypted personal cryptographic data will only be sent to a user who has demonstrated that he knew the couple authentic username / password.
• Steps 32 to 38 are then repeated, until the key server 3 receives a second occurrence of the read request.
• the key server 3 performs the comparison provided for in step 38 only after a delay greater than ten seconds since the reception of the first occurrence of the read request. Therefore, for an 8-character password, automatically trying all possible passwords by automatically sending successive requests would take unreasonable time, on the order of a million years.
• step 42 the key server 3 sends the personal cryptographic data to the interface device A, KR, KS encrypted stored in the corresponding account.
• the interface device sends an acknowledgment to the key server 3, then the communication between them is ended.
• step 44 the interface device decrypts the key KS using the key KP 'calculated in step 34, then decrypts the certificate A and the corresponding private key KR using the key KS thus obtained.
• step 46 the user accesses services offered by one or more of the content servers 2a, 2b from the interface device. In this step, the communications between the content server or servers 2a, 2b and the interface device are protected by encryption, electronic signature and / or authentication methods using the personal cryptographic data A, KR, KS . Several detailed examples of this step are described below.
• step 48 the use of the services having ended, the user closes the session application, which leads to the erasure of the password P ', of the keys KP' and VP 'and of all the personal data cryptographic A, KR, KS, encrypted or not from the memory of the interface device. No confidential user data remains in the memory of the interface device, so that the user is not linked to this particular device and that no access control to the latter is necessary thereafter.
• the interface device for the session stage can also be of public access, for example in an internet cafe.
• Storing personal cryptographic data on the key server 3 is safer, from a privacy and durability point of view, than local storage on the interface device or storage on a smart card, because the server of keys 3 is better physically protected and can be carefully monitored.
• the interface device is designated by A and the key server 3 by B.
• a and B share an infrastructure for public data I comprising numbers p, q and g suitable for the Diffie-Hellman protocol, at least one hash function h, for example SHA-1, and encryption protocols E and F.
• the user (assumed to be authentic in the example shown) initially only enters his identity N and a password P.
• B has on his internal storage system the personal cryptographic data of user D A encrypted symmetrically with the KP key deduced from password P; we denote by F the encryption function used, that is to say that B stores F ⁇ p (D A ). Ok recover this data D A.
• the protocol is as follows: - A calculates KP and VP using data N and P entered by the user.
• V A g a mod p.
• V B g b mod p.
• the encryption system F is a simple symmetric encryption system, using for example the standard AES algorithm.
• MAC integrity control system
• the symmetric encryption system E used must be such that:
• E VP (V A ) must give another valid element of the group generated by g; in other words, the use of a password other than the voucher must give a valid instance of the problem (but of course this does not lead to the correct session key).
• the second condition prevents an attacker from later using a failed session as a test for a dictionary attack.
• One possibility for attacker C is to arbitrarily choose a password P "during key negotiation and to send Eyp " (g b mod p). Then, A uses the session key K s (which C does not know, unless he accidentally chose the right password) to encrypt a message intended for C. The purpose of C is to use this message to try passwords; for each, denoted P ', C wants to reconstitute the b' such that Evp (g b mod p) is equal to the value that it actually sent to A.
• C can, for each word of password P ', calculate the corresponding session key K', and check if it correctly decrypts the message sent then by A. If this is the case, then C a, afterwards, retrieves the password P used by A during execution of the protocol. This constitutes an offline dictionary attack. Condition 2 on encryption E precisely prevents this attack from being possible.
• This embodiment is based on a general technique called encrypted key exchange (EKE) which was described for the first time in an article entitled “Encrypted Key Exchange: Password-Based Protocols Secure against Dictionary Attacks", Steven M. Bellovin and Michael Merritt, in Proceedings of the IEEE Symposium on Security and Privacy, Oakland, California, May, 1992, pp. 72-84. It prevents any attack by offline dictionary, even in the case of an adversary who can intercept and modify the communications, and it only requires one network round trip.
• EKE encrypted key exchange
• the negotiated session key K is then used to confidentially transmit the data packet containing D A from the server to the client.
• the protocol offers a guarantee of anonymity to the customer and therefore protection desirable when the user's connections to the key server 3 are private.
• KP) instead of h (KP) is intended to prevent B (in the event that its storage system is compromised by an attacker) from carrying out an offline dictionary attack on several passwords belonging to separate users.
• the registration application and the session application can be produced in the form of independent software or in the form of functionalities distinct from a single software. It is particularly advantageous to program the session application and the registration application using the Java® programming system of Sun Microsystems® because it makes it possible to obtain software, in binary and compiled form, which can function whatever or the architecture of the interface device that executes it. Portable session and registration applications are therefore obtained, which are particularly suitable for downloading by downloading.
• this programming system is available for all major architectures and very often already installed in browsing programs. It contains the necessary semantic verifiers which allow the interface device which executes it to ensure that no prohibited operation is carried out, so that the execution of the applications thus obtained is safe.
• the session application and the registration application can be executed by any interface device having generic and standard access to the network 1, without requiring particular access to the resources of the interface device, apart from what the Java® programming system provides, such as the graphical interface and network access 1.
• the session application can also be implemented in a specific hardware and / or software form in a particular type of interface device, for example in a model of cellular telephone which leaves the factory with the application of preinstalled session.
• step 46 will now be described with reference to FIGS. 4 to 6.
• the link 54 represents both the connection of the interface device 50 to the network 1 and the network 1 itself or a part of the network 1. Only a content server 2a, 2b or 2c is represented each time because the key server 3 no longer intervenes. However, it is always assumed that there can be several content servers and that the interface device 50 is able to communicate with the key server 3, in order to be able to perform steps 30 to 44, which will not be described again. .
• the content server 2a offers a personal data bank service to the user.
• a database can be created with software known under the trade names Apache® or Tomcat®.
• a user account 52 is reserved in the storage means of the content server 2a, for example on a hard disk or an optical disk.
• This account contains user 56 personal files, which are organized in a hierarchical structure. Each file has been deposited by the user in an encrypted form by means of the symmetric key KS, and this encryption comprises a means of checking the integrity of the files derived from this same key.
• the content server 2a treats these files as meaningless sequences of bytes, except with regard to the associated metadata (names and organization of the files).
• the content server 2a provides an access interface in the form of a web site executable from the interface device 50, which here takes the form of a generic microcomputer provided with a browsing program or classic navigation, such as those offered by the Netscape® or Microsoft® companies.
• the session application puts the personal cryptographic data A, KR, KS in a format and in a memory location suitable for the browsing program to read and use them.
• the navigation program uses the navigation program to display the interface for accessing the content server 2a on the screen.
• a communication in standard HTTP format is then established between the interface device 50 and the content server 2a, using the certificate A and the corresponding private key KR of the user to secure this communication by an SSL protocol, such as it was described in step 22.
• the SSL protocol is used in a bi-authenticated manner, as described in step 22.
• the interface device 50 and the content server 2a have mutually authenticated , their subsequent exchanges are confidential, and the integrity of the transferred data can be checked.
• the access interface to the content server 2a allows the user to know the content and structure of his account 52, to read a file from account 52, to write a file to account 52, and to move or delete a file.
• the interface device 50 sends corresponding requests 58, according to the known technique. These requests are only processed by the content server 2a after authentication of the user by means of the certificate A, so that the files 56 cannot be read or altered by a third party. A third party cannot not even know about the existence of these files or the associated metadata, such as file names.
• the user To store a file in the account 52, the user enters this file in the interface device 50, for example by creating the file from a word processing software, or by reading the file from an optical or other magnetic medium.
• the browsing program then performs symmetric encryption of the file using the key KS, and sends the file thus encrypted in the write request 58.
• the file is stored in the desired location by the content server 2a. Since the content server 2a does not have the key KS, the content of the files 56 thus stored is perfectly secret vis-à-vis the content server 2a.
• the browsing program sends a read request 58 comprising this name to the content server 2a.
• the content server 2a sends to the interface device 50 a response 60 containing the corresponding file encrypted by the key KS.
• the browsing program then performs a symmetric decryption of the file using the KS key. Due to the encryption by the KS key, the over-encryption ensured by the SSL protocol using a temporary KT key is not essential to guarantee the confidentiality of the files 56. However, this over-encryption guarantees the authenticity of the server and user throughout the exchanges, which prevents a false server deceiving the user as to the content of his account or a false user altering the content of the account 52.
• the user can store on the account 52 all kinds of personal data, in graphic, audio, video, text, etc. formats.
• account 52 contains the user's email address book and their archived email folders.
• Account 52 can also contain other cryptographic keys of the user. All this data is kept confidential because of its encryption and remains accessible from any interface device provided with the session application and a suitable access application, i.e. for example a foraging program.
• the server 2a can very securely ensure the durability of the files 56, by making copies of backup which, due to the strong encryption of files 56, does not entail any intrinsic risk.
• the session application and the registration application can be produced in the form of one or more extension software modules, also called plug-ins, for a browsing program, for example for Netscape Communicator® software.
• the session application or the registration application may be launched by an instruction from the browsing program interface and will be automatically closed when the browsing program is closed.
• the session application and the registration application can be integrated into a specific program providing the access functions to the server 2a.
• step 46 in which the service offered is a secure electronic mail service.
• the server 2b is an electronic mail server which can communicate with the interface device 50 in a manner known per se, for example according to the SMTP protocols (acronym for English: Simple Mail Transfer Protocol) IMAP (acronym for English: Internet Message Access Protocol) or POP (acronym for English: Post Office Protocol).
• the session application puts the personal cryptographic data A, KR, KS in a format and in a suitable memory location so that a client program for managing secure electronic mail can read them and use them.
• client programs for managing electronic mail which are secure, that is to say that they include a cryptographic module for fulfilling protection functions, and for which the storage of the cryptographic elements is configurable by means of software modules. extension.
• client programs for managing electronic mail which are secure, that is to say that they include a cryptographic module for fulfilling protection functions, and for which the storage of the cryptographic elements is configurable by means of software modules. extension.
• Known examples are Outlook Express® from Microsoft® and Netscape Communicator® from Netscape®, in which encryption and electronic signature operations are performed in S / MIME format.
• the session application and / or the registration application may take the form of an extension module for such a program.
• the session application allows you to quickly reconfigure the cryptographic module of the client program with the data user's personal cryptographic data.
• extension software modules for these widely distributed programs is that they add the characteristics of the registration application and / or the session application without requiring users to learn the operation of new software.
• the secure email management client program performs several functions.
• An encrypted mail sending function includes the operations of receiving a message entered by the user on the interface device 50, designating a recipient of the message, selecting the public key of this recipient to encrypt the message and / or signing the message with the private key KR and send the encrypted and / or signed message to the server 2b, as indicated by the arrow 66.
• the message will then be transmitted via the network 1 to the recipient's electronic mail server 62 and the recipient will be able to consult the message from its own microcomputer 64 equipped with an appropriate client program.
• An encrypted electronic mail reception function comprises the operations of receiving an encrypted message from the server 2b, as indicated by the arrow 68, decrypting the message with the private key KR and / or verifying the signature of the message with the public key of the sender, and present the content of the message to the user.
• step 46 in which the service offered is a digital television broadcasting service.
• the server 2c is a digital television server of a supplier with which the user is subscribed.
• the user uses an interface device 50 which takes the form of a television decoder 70 provided with a remote control 72.
• step 46 the session application is executed by the decoder 70 to perform mutual authentication between the user and the server 2c using the certificate A, as explained with reference to step 22 Then the user selects a television program by means of the remote control 72.
• the decoder 70 transmits a corresponding read request 74 to the server 2c.
• the server 2c After verifying that the requested television program is authorized by the user's subscription, the server 2c sends to the decoder 70 a corresponding audio-video data stream 76, symmetrically encrypted so as to be decrypted by the decoder 70 by means of the key KS or a temporary key KT.
• the key KS may have been assigned confidentially to the user by the supplier during the subscription formalities or may have been transmitted by the decoder 70 to the server 2c after mutual authentication.

Applications Claiming Priority (3)

Publications (1)

Family

ID=29595286

Family Applications (1)

Country Status (5)

Families Citing this family (14)

Family Cites Families (21)

• 2002
  • 2002-06-17 FR FR0207413A patent/FR2841070B1/fr not_active Expired - Fee Related
• 2003
  • 2003-06-17 US US10/518,301 patent/US20060053288A1/en not_active Abandoned
  • 2003-06-17 WO PCT/FR2003/001841 patent/WO2003107587A1/fr not_active Application Discontinuation
  • 2003-06-17 AU AU2003267489A patent/AU2003267489A1/en not_active Abandoned
  • 2003-06-17 EP EP03748176A patent/EP1514377A1/de not_active Withdrawn

Non-Patent Citations (2)

Also Published As

Similar Documents

Legal Events