WO2007012782A2

WO2007012782A2 - Procedure and system for secure management of data between a server and a client

Info

Publication number: WO2007012782A2
Application number: PCT/FR2006/050745
Authority: WO
Inventors: Aurélien ROUSSEAU; Emmanuel Attali
Original assignee: France Telecom
Priority date: 2005-07-26
Filing date: 2006-07-25
Publication date: 2007-02-01
Also published as: FR2889388A1; WO2007012782A3

Abstract

The invention concerns system and a procedure for secure management of data between a server (1) and a client (3) mutually connected by a communication network (7) including the following steps: creation by the server (1) of an account for a user (5) associated with said client; communicating to said user (5) an identifier of said account and means for authentication with said account; and creating a key pair comprising a public key and a private key, the public key being kept by the server (1) in association with the user account.

Description

Method and system for secure data management between a server and a client

TECHNICAL FIELD OF THE INVENTION The invention relates to the field of secure data management between a server and a client. More particularly, the invention relates to the field of secure storage and access control to documents in client / server mode as well as to the identity federation domain associated with an identity provider.

Background of the invention

Computer storage and information-sharing systems (eg document storage, collaborative spaces, etc.) all need to limit the risk of confidential data being disclosed to unauthorized persons. Such systems use a number of concepts to model access rights (notion of owner of a document, definition of user groups sharing certain rights, etc.). Among these rights, we can distinguish rights on the document as an archived object (right to know the existence and name of the document, right of cancellation, etc.) and rights relating to the content itself. same document (reading rights, writing, etc.).

These information-sharing systems are inherently "distributed" between "client" subsets and "server" subsets. For example, in "web" type architectures, there are subsystems "servers" (HTTP servers, application servers, databases), and sub-sets "clients" (web browsers, visualization programs ).

However, the current systems usually manage all access rights through rights calculation mechanisms, that is to say are access programs to stored documents that "decide", depending on the identity of the connected user, the nature and extent of possible interactions. For example, collaborative web-based systems dynamically compute (server-side) the list of documents that can be displayed on an authenticated user's Internet browser.

Current document storage services in principle preserve the confidentiality of stored data through user authentication mechanisms that restrict legitimate access to documents only for legitimate owners. Nevertheless, the underlying infrastructure software (in the case of services in "web" mode, we can mention HTTP servers and operating systems) are not exempt from security vulnerabilities. This is due to the still imperfect quality of these software. Therefore, it is not yet possible to give complete confidence to these access control mechanisms. In addition, a third party having physical access to the storage servers (or backup media) has no hardware difficulty accessing the stored contents. This is completely independent of application authentication and access control mechanisms. Therefore, it is desirable to add to the storage services of confidential documents additional security of encrypting the stored documents.

This encryption of the stored documents is a complementary means to guarantee the confidentiality of the sensitive data. Currently, document encryption can be achieved by shared directories encrypted and managed by networked operating systems. Another document encryption technique concerns Digital Rights Management (DRM) type digital rights management systems. These current encryption techniques combine one or more of the following disadvantages:

some of these techniques are based on public key infrastructure (PKI), the deployment of which is a prerequisite, and in particular the publication of encryption certificates and the distribution of decryption keys;

-the existing encryption tools do not integrate with Internet browsers, and are therefore not suitable for use in web mode; and some of these techniques imply an adherence or correspondence with the workstation (this is the case of DRM solutions), which is detrimental to nomadism, that is to say to a greater mobility of the workstation. job.

This explains that the existing document storage services, especially in "thin client" mode, do not include this additional security that would be the encryption of data.

Another example of secure data management is the "federation of identities" between an "identity provider" and a "personalized service". Indeed, there are currently a large number of services offered on the Web that can be grouped under the concept of "personalized services". This type of service must always know the user with whom it communicates. For this, the user must have previously registered. Following this registration, the user obtains "identifiers" which are asked for at each new access. These services exist in a wide variety of fields (eg e-mail, online banking, merchant sites, corporate portals, etc.).

Given the multiplicity and diversity of these personalized services, we can see that a user is often registered on several services requiring it to memorize a large number of different identifiers and associate each with a given service (e-mail account, account on the online bank, etc.).

In addition, during the same navigation session, that is to say during the continuous use of the same communication interface (radio, browser, PC connected to the Internet, etc.), a user can access several services requiring identification.

As a result, personalized services make navigating difficult and jerky by repeated identifications. Moreover, a user can not easily obtain an overall view of the various services on which he has registered.

One of the ways to solve this problem is the identity federation that can be implemented through different products and specifications (MS Passport ™, Liberty Alliance, SAML, etc.) and is based on the following principles:

-confidence relationships can be established between personalized services which defines "circles of trust"; and within each circle of trust, one or more services considered central can fulfill the function of "identity provider".

In general, identity providers are servers that are likely to know the majority of users reported on all services in the circle of trust. In addition, they have sufficient audience, influence, or authority for personalized services to be easily accessible from identity providers.

The federation of identities then consists in weaving links between the different identities of the same user, each being defined on a different personalized service and its unique identity on the identity provider. These links are materialized by sharing an alias (also called the federation key) between the identity provider and the custom service. This alias is then attached to the identity provider and the corresponding user's personalized service. Once this alias is exchanged, it can be used by the identity provider or the custom service to communicate about a known known user of both systems.

The direct use of this alias then makes it possible to implement a single connection protocol (or Single Sign On in English) within a circle of trust. Once the user is identified with the identity provider, the personalized services can call him to ask for his alias on their service. This alias can then be used directly to identify the user and the user no longer has to enter their identifiers on each service.

Each identity provider then has a federation base. This federation database contains, for each user, the list of corresponding aliases on the different personalized services of the circle of trust.

Thus, identity federation, in the context of a relationship between an identity provider and a personalized service makes it possible to associate a common alias with two identities on two different systems. More broadly, it allows for a reconciliation between the data related to each of these identities.

To make this match, you need to have access to the identity provider's physical data and at least one custom service in the same trust circle, and cross-reference based on the aliases. Two identities sharing the same alias correspond to the same real user. It is then possible to compare the data and even to aggregate the data concerning a user. This possibility can be perceived as a real invasion of privacy by the user. As part of a wider circle of trust, it is It is likely that the same identity provider offers access to completely different types of services (banking, insurance, tax, medical follow-up, etc.). The possibility of cross-referencing the information contained on these different personalized services is particularly critical and must be made as difficult as possible; in particular, it must not be automatable.

Admittedly, for an external actor, access to the physical data of a system is quite difficult. Access to physical data from two systems by an external actor is therefore unlikely. Nevertheless, the stakes and the possibilities offered by the cross-checking of information are such that it is also necessary to be able to be sheltered from access initiated by internal actors in the system (for example operating staff).

OBJECT AND SUMMARY OF THE INVENTION The object of the invention is to remedy these drawbacks and to secure the management of data between a server and a client.

These goals are achieved by a method of secure data management between a server and a client connected to each other by means of a communication network, comprising the following steps: -creation by the server of an account for a user associated with the audit customer,

communication to said user of an identifier of said account and of an authentication means with this account, and

drawing a biclef comprising a public key and a private key, the public key being kept by the server in association with the user account.

Thus, this method allows permanent encryption of the data that can be stored on the server. This is a very good protection against both remote attacks and access to data by an actor who has physical access to server and possible implementation defects of a software access control mechanism.

According to one embodiment of the invention, the private key is stored by the server in encrypted form by means of a word or passphrase in association with the user account.

Thus, by encrypting the private key with for example a "passphrase" which is a password with more characters, the secure management of the data can be performed in thin client mode.

According to another embodiment of the invention, the private key is stored securely by the user.

Thus, secure data management can be done in rich client mode to increase the confidentiality of data stored on the server.

The method according to the invention further comprises the following steps:

-download by the user of a set of data on the server, -automatic encryption of said data set by the server to form a set of encrypted data, and

storing said set of encrypted data in a mass memory of the server.

Thus, the encryption is transparent to the user who deposits the data set and this encryption is performed automatically by the server itself. Therefore, the repository of the dataset can be done from a standard Internet browser.

Advantageously, the automatic encryption of said data set comprises the following steps; generation of an encryption session key, encryption of said data set with the session key, and encryption of the session key with the public key, the encrypted session key being stored with the encrypted data set in the server's mass memory.

Thus, the encryption of the data set is performed in a secure and fast manner by the server without imposing any ergonomic constraint on the client computers. As a result, the security provided by encryption does not require special client-side adherence and fits seamlessly into thin client and mobile mode.

According to one embodiment of the invention, the reading of said set of data is performed according to the following steps:

-authentication of the user to the server,

-communication to the server by the user of a means of decryption of the private key associated with the user account,

-deciphering by the server of said private key, -deciphering by the server of the encryption session key of said data set by means of said private key, and

the server decrypts said set of encrypted data by means of the session key enabling said set of data to be read. Thus, the encrypted data can only be decrypted by the user who deposited the data set. Furthermore, according to this embodiment, the decryption process is entirely performed at the server allowing access to these data in thin client mode. According to another embodiment of the invention, the reading of said set of data is performed according to the following steps:

-authentication of the user to the server,

sending the user of the encryption session key of said set of data, said session key being encrypted, decryption by local means of the user of said session key by means of the private key held by the user,

sending back to the server the decrypted session key, and

the server decrypts said set of encrypted data by means of the session key.

Thus, the encrypted data can only be decrypted by the user and, moreover, the private key of the user is known only to the client. This further increases the security of data access. According to yet another embodiment of the invention, the reading of said data set is carried out according to the following steps:

-authentication of the user to the server,

sending the user of the encryption session key of said set of data, said session key being encrypted, as well as said set of encrypted data,

decryption by local means of the user of said session key by means of the private key held by the user, and

-deciphering by the local means of the user of said set of encrypted data by means of the session key.

Thus, the private key of the user is known only to the client and moreover the encrypted data is only decrypted on the client machine.

This further increases the security of data access. Advantageously, the method of the invention further comprises the following steps;

displaying a list of documents stored in the mass memory of the server and available to the user and / or rights holders of reading, and -selection by the user and / or a holder of the right to read a document from said list of documents with a view to its decryption.

Thus, the user or the right holder can access and manage in a simple and secure way the documents stored on the server. The documents can thus be decrypted only by a user-defined reading rights holder list.

According to another feature of the present invention, said data set being a federation base and the server being an identity provider, requests for changes related to the user account are recorded by the identity provider in a log in order to propose to the user when the latter decrypts the federation base.

Thus, the management method makes it possible to make a method based on federation of identities more reliable by increasing the protection of the privacy of its users and the modification of the federation base is always under the control of the user.

The invention also aims at a system for the secure management of data between a server and a client connected to each other by means of a communication network, the server comprising: a first means of production intended to create an account, an identifier of said account , and a means of authentication with this account for a user associated with said client,

a means of communication intended to communicate to said user the identifier of said account and the means of authentication with this account, and

a second means of production intended for the drawing of a bundle comprising a public key and a private key, the public key being kept by the server in association with the user account.

Thus, this system offers very good protection against both remote attacks and data access by an actor having physical access to the server as well as possible defects in the implementation of a software access control mechanism.

The server further comprises: a processing means for automatically performing the encryption / decryption of a set of data deposited by the user by means of a session key to form a set of encrypted data, and

a mass memory for storing said set of encrypted data.

Thus, the management system server itself securely and automatically encrypts the set of data deposited by the user.

According to one particularity of the invention, the session key is stored with the set of encrypted data in the mass memory of the server, said session key being encrypted by means of the public key associated with the user account.

Thus, the system is compatible with thin clients when the private key is for example encrypted with a "passphrase". The invention also aims at a secure data management server, comprising:

a first means of production intended to create an account, an identifier of said account and a means of authentication with this account for a user, a means of communication intended to communicate to said user the identifier of said account and the means of authentication with this account,

a second means of production intended for drawing a message comprising a public key and a private key, the public key being kept by the server in association with the user account, a processing means for automatically performing the encryption / decryption of a data set, and a mass memory for storing the set of encrypted data. Thus, this server makes it possible to perform data encryption / decryption in a simple, efficient and secure manner.

The invention also relates to a secure data management client connected to a server by means of a communication network, characterized in that it comprises:

decryption means for decrypting a session key and / or a set of encrypted data, and

storage means for storing a private key produced by the server. Thus, the private key is known only to the client and possibly the decryption of the set of encrypted data can be entirely realized on the client station itself then offering optimal security of access to the data.

The invention also relates to a computer program comprising instructions for implementing the secure management method according to the above characteristics when it is executed on the server. More particularly, said program is designed to allow the creation of an account for a user associated with said client, the communication to said user of an identifier of said account and a means of authentication with this account, the drawing of a biclef comprising a public key and a private key, the public key being kept in association with the user account, the automatic realization of the encryption / decryption of a set of data, and the storage of this set of data. The invention also relates to a computer program comprising instructions for implementing the secure management method according to the above characteristics when it is executed on the client. More particularly, said program is designed to perform a decryption of a session key and / or a set of encrypted data and to store a private key produced by the server.

The invention also aims at making available by downloading a computer program that can be executed on the client.

Brief description of the drawings

Other features and advantages of the invention will become apparent from reading the description given below, by way of indication but not limitation, with reference to the accompanying drawings, in which; FIG. 1 diagrammatically illustrates a system for the secure management of data between a server and a client, according to the invention;

FIG. 2 schematically illustrates a server according to FIG.

1;

FIG. 3 diagrammatically illustrates the creation of a user account in the system of FIG. 1, according to the invention;

FIG. 4 schematically illustrates the filing and encryption of a set of data, according to the invention;

FIGS. 5A to 5C schematically illustrate variants of the reading of the data set, according to the invention; FIG 6 schematically illustrates a client according to Figure 1; and

FIGS. 7 to 9 schematically illustrate an example of a secure management of a set of data according to the invention.

Detailed description of embodiments According to the invention, FIG. 1 illustrates a schematic example of a system for the secure management of data between a server 1 and a client 3 driven by a user 5. The client can be a thin client or a rich client and is connected to the server by means of a communication network 7. A thin client means the use of a workstation that does not require little or no administration and is generally limited to performing posting and typing tasks and rich client means the meeting of client and Web architectures at the workstation level. According to a first example, this system can be used for storage and secure access control to documents in client / server mode. In another example, the system can be used for storage and secure access control to a federation base as part of a federation of identities. FIG. 2 illustrates a schematic example of a server 1 according to the invention comprising a first production means 11, a communication means 13, a second production means 15, a processing means 17, and a mass memory 19. The processing means 17 controls all the other elements 11, 13, 15 and 19 of the server 1.

In addition, FIG. 3 illustrates steps of creating an account for the user 5 in the secure data management system between the server 1 and a client 3.

In step El, the user 5 asks the server 1 to create a new account. Then, in steps E2 to E6, the server 1 performs the coupling of an account PKI public key infrastructure.

Indeed, in step E2, the server 1 creates an account for the user 5. In particular, this account and an identifier of this account and an authentication means (for example a password) with this account are created by the first means of production 11 of the server 1. For example, the first production means 11 reserves a first storage area 19a in the mass memory 19 of the server 1 to concretize the account associated with the user 5.

In step E3, the communication means 13 of the server 1 communicates to the user 5 the identifier and the authentication means concerning this account.

Step E4 concerns the drawing of a message comprising a public key and a private key to perform asymmetric encryption / decryption. More particularly, the second production means generates the article. In addition, the second production means 15 in connection with the processing means 17, hold (step E5) the public key for example in the first storage area 19a of the mass memory 19 of the server 1 in association with the account of the user.

According to a first variant, in step E6 (represented in dashed line), the private key is stored by the server 1 in encrypted form, for example in the first storage area 19 a of the mass memory

19 in association with the user's account. The private key can be encrypted using a password (or a passphrase that is no more than a password with more characters, typically several tens or more) that will not be known only by the user, for example by using an algorithm of the 3DES type.

According to this first variant, the secure management of the data can be performed in thin client mode. The client computer 3 may in this case include a simple graphical interface software allowing it to display only the result of the processing performed by the server 1.

According to a second variant, the private key is not kept on the server 1. On the other hand, it is stored securely by the user 5, for example in the form of a cryptographic support of the smart card type. Thus, secure data management can be performed in rich client mode to increase the confidentiality of data stored on the server 1.

It should be noted that the coupling of a user account with a PKI can accommodate any form of PKI. In its simplest form, the management of the PKI is reduced to the draw of a biclef per account made by the server 1 itself. Indeed, this option is the most natural in a "thin client" mode It is also possible to combine a more traditional PKI with a system of accounts (X.509 certificates, registration of the certified identity of certificate holders. ..). Figure 4 illustrates steps for depositing and encrypting a data set.

Indeed, in step E7, the user 5 deposits a set of data on the server 1. For example, the set of data can be transmitted to the server 1 by using an HTTPS request. Optionally, the data set can be transmitted to the server 1 by using an SMTP request, in which case the deposit of this set of data is similar to the sending of an email.

In step E8, the processing means 17 of the server 1 proceeds to an automatic encryption of this set of data by means of the public key associated with the user's account thereby forming a set of encrypted data.

More specifically, the encryption of the data set may include generating an encryption session key, symmetric encryption of the data set with the session key, and asymmetric encryption of the session key with the session key. public key.

In step E9, the processing means 17 stores this set of encrypted data on the server 1. For example, the set of encrypted data can be stored in a second storage area 19b of the memory of mass 19 of the server 1. It will be noted that the encrypted session key is also stored with the set of encrypted data in the mass memory 19 of the server 1.

Figs. 5A-5C illustrate variations of the reading of the set of encrypted data stored on the server. According to the first variant, the step ElO of FIG. 5A concerns the authentication of the user 5 with the server 1.

Step EI1 concerns the communication to server 1 by the user 5 of a decryption means of his private key. For example, the user 5 communicates to the server 1, through an HTML form, the password (or passphrase) associated with the private key.

In step E12, the processing means 17 realizes the decryption of this private key by the decryption means communicated by the user.

Then, in step E13, the processing means 17 decrypts the encryption session key of the data set by means of the private key decrypted by the user 5.

Finally, in step E14, the processing means 17 decrypts the set of encrypted data by means of the decrypted session key, thereby allowing the user 5 to read the set of data.

In this way, the private key of the user 5 is known by the server 1. On the other hand, the server 1 completely performs the decryption process allowing the user 5 to access the data set in thin client mode. . On the other hand, according to the second variant (FIG. 5B), the private key of the user is known only to the client 3.

In fact, after the authentication step ElO of the user 5, the server 1 sends (step E13) to the user 5 the encryption session key of the set of data. In step E14 the user decrypts this session key by local means. These local means are for example a software extension in the form of a complementary program or plug-in ("plug-in" in English) in a browser capable of using the private key stored in the cryptographic support (smart card) of the user 5.

In step E15 the user 5 returns to the server 1, the decrypted session key, which allows the processing means 17 of the server 1 to decrypt the step E16 the set of encrypted data.

Figure 5C illustrates a third variant of the reading of the data set.

As before, after the user authentication step ElO, the server 1 sends (step E13) to the user 5 the encryption session key of the encrypted data set.

In addition, in step E17 the server 1 sends the user 5 the set of encrypted data.

In step E14, the user 5 decrypts by these local means the session key.

Finally, in step E18, the user decrypts by local decryption means (see FIG. 6) the set of data encrypted by means of the session key. This increases the security of data access. Of course, in this case, the customer is a rich customer.

Indeed, FIG. 6 illustrates a client 3 for secure data management comprising decryption means 21 and storage means 23.

The decryption means 21 (for example a processing means) are intended to perform the decryption of the session key generated by the server and / or the set of encrypted data stored on the server 1. In addition, the storage means 23 may be intended to store the private key produced by the server 1. This storage means 23 can also store the set of encrypted data sent by the server 1 and possibly the set of data decrypted by the client 3. It will be noted that the secure management method according to the invention can be implemented by computer programs comprising instructions executed on the server 1 and / or the client 3.

In addition, the executable program on the client 3 can be made available to a user 5 by downloading from, for example, the server 1.

FIGS. 7 to 9 schematically illustrate an example of a secure management of a set of data forming a digital document in relation to a document manager of the server 1.

This example is adapted to the particular case of a "web" architecture for storing and sharing documents.

Figure 7 illustrates the creation for a user of a briefcase account in the document manager of server 1.

The ElOl step concerns the request by the user 5 of a creation of an account and possibly the choice of the means of authentication with this account.

Step E102 concerns the creation and reservation of storage resources embodying a new document holder belonging to the account holder.

Step E103 concerns the communication to the user 5 of an account identifier and the authentication means with this account.

Step E104 relates to the drawing of a biclef for an asymmetric encryption / decryption algorithm (example: RSA). The public key is kept by the server (step E106), in association with the user account. On the other hand, the treatment of the private key differs according to the variant chosen.

Indeed, in a variant of thin client, the private key is encrypted (step E105) and is stored (step E106) with the public key on the server 1 in encrypted form. For example, the private key is encrypted using a password that will be known only to the user, using an algorithm such as 3DES.

On the other hand, in a rich client variant, the private key is stored securely by the user 5. FIG. 8 illustrates the filing and encryption of a document by the server 1. According to this example, any authorized actor can file new documents in the briefcase.

Thus, in step ElI1, a user issuing a document obtains the account identifier of a client 3 recipient. In step E112, the transmitter 35 transmits documents

(initially in clear) to the server 1, for example using an HTTPS request or a request of the SMTP type. In the latter case, it suffices that the account identifier of the client 3 recipient is linked to an email address.

The steps El 13 to El 15 relate to the encryption of documents by the server 1, using the public key associated with the account. A conventional encryption scheme, such as "PKCS # 7 enveloped data" can be used.

Thus, step E113 concerns the generation of an encryption session key. Step El 14 concerns the encryption of documents with the session key, using a symmetric algorithm. Finally, the step El 15 concerns the encryption of the session key with the public key, using the asymmetric algorithm provided for the latter.

Moreover, step El 16 concerns the storage and indexing of the documents and the session key thus encrypted in the mass memory 19 of the server 1. Finally, in step El17, the account user 5 is notified of the filing of the documents.

Note that a user issuing a document can define one or more rights holders for reading the document at the time of filing this document. For this, it is sufficient to designate several recipients, and trigger the encryption of the session key in multiple copies, one per recipient, using the public key of each recipient.

Figure 9 illustrates the access of a user 5 holder of a briefcase account to his documents.

Step E121 concerns the establishment of a session with the server 1 of briefcase, for example via the HTTPS protocol, using the authentication means that were allocated when the account was opened. By way of example, this consists in the user entering his account identifier and a password in a web form and then obtaining a session token by the Internet browser (for example a cookie) that will be reused for each subsequent HTTPS request.

Step E122 concerns a display of a list of documents available in the briefcase. This list of documents is stored in the mass memory 19 of the server 1 and is available to the user 5 and possibly to rights holders.

Step E123 concerns the selection by the user 5 (possibly a holder of the right to read) of a document among those in the list of documents available for decryption.

Steps E124 to E127 relate to the decryption of the document in a thin client mode. Indeed, in step E125, the user 5 allows the server 1 to decrypt its private key by communicating (step E124) to the server 1, through an HTML form, the password encryption required. Then, in step E126, the server 1 decrypts, thanks to the private key, the encryption session key of the document.

Finally, in step E127, the server 1 decrypts the document itself before sending it thus decrypted (step E128) to the user 5. In a rich client mode, the user 5 receives from the server 1 the key session of encryption of the document and decrypts it by local means. Then, the user 5 sends back to the server 1 the decrypted session key, which allows the server 1 to decrypt the document itself. This optimizes the computing load for the user's computer 5, to the detriment of that of the server 1.

It is also conceivable that the server 1 directly communicates the encrypted document to the user 5 so that the latter itself decrypts the document.

In addition, it should be noted that it is possible to extend the list of rights holders on an encrypted document.

Thus, in a thin client mode, the user 5, who belongs to the holders of reading rights, selects a list of users to whom he also wishes to confer the right to read on the document. In this case, the user 5 communicates his decryption password to the server 1. This allows the server 1 to decrypt the session key. Then, the server 1 encrypts the session key with the public key of each of the new users of the document.

In addition, to revoke the right to read a document for a given user, simply delete the session key as encrypted for this user.

According to another example of secure data management, the data set is a federation base and the server is an identity provider. Thus, the creation of a new user account on the server 1 identity provider results in the steps of Figure 3 explained above.

Furthermore, when the user 1 authenticates on the server 1 identity provider or when it requires, for the first time to access the federation base, the user is asked to decrypt his database federation so that it can be used in the context of its session according to the steps of Figures 6A to 6C explained above. In addition, when the user's session on the identity provider server 1 terminates as a result of his request or because of a long period of inactivity, the federation database is encrypted and the decrypted form is erased. The encryption of the federation base is done according to the steps of Figure 4 explained above. On the other hand, when the user 5 modifies, destroys, or creates new federations, the federation database must be updated.

Indeed, when the user is identified on the server 1 identity provider and the federation base is decrypted, the change of the federation base can be done conventionally. Indeed, the federation base is in clear, in the server's RAM. In order to make the changes more reliable, it may be interesting to renew the storage in encrypted form with each modification, without waiting for the end of the session.

On the other hand, when the federation database is not decrypted and the user does not intervene, then, in order to update the federation database, the identity provider server 1 can log the requests for the federation database. modification and offer them to the user when deciphering his federation base.

Thus, the secure management of data (digital documents or federation base) according to the invention allows encryption in permanence of the data stored in the mass memory of the server. This provides very good protection against remote attacks by taking advantage of software security vulnerabilities.

In addition, this method is a very good protection so that people who have physical access to the server (or backup media) do not breach their duty of confidentiality vis-à-vis the stored data.

In addition, this secure data management provides an excellent compromise between ergonomics and security, since it provides an encryption service, without imposing an ergonomic constraint on the client computers. Indeed, an Internet browser is enough. As for the withdrawal of data, in the thin client mode, it only requires as a prerequisite knowledge of a word or passphrase.

Claims

1. A method of secure data management between a server (1) and a client (3) connected to each other by means of a communication network (7), characterized in that it comprises the following steps: - creation by the server (1) of an account for a user (5) associated with said client (3),

- communication to said user (5) of an identifier of said account and an authentication means with this account, and

- Drawing of a biclef comprising a public key and a private key, the public key being kept by the server (1) in association with the user account.

2. Management method according to claim 1, characterized in that the private key is stored by the server (1) in encrypted form by means of a word or passphrase in association with the user account.

3. Management method according to claim 1, characterized in that the private key is stored securely by the user (5).

4. Management method according to any one of claims 1 to 3, characterized in that it further comprises the following steps:

- deposit by the user (5) of a set of data on the server (1), - automatic encryption of said set of data by the server (1) to form a set of encrypted data, and

storage of said set of encrypted data in a mass memory of the server (19).

5. Management method according to claim 4, characterized in that the automatic encryption of said data set comprises the following steps:

- generation of an encryption session key, encrypting said set of data with the session key, and

- encrypting the session key with the public key, the encrypted session key being stored with the set of encrypted data in the mass memory (19) of the server (1).

6. Management method according to claim 4 or claim 5, characterized in that the reading of said data set is performed according to the following steps:

- authentication of the user (5) with the server (1),

- communication to the server by the user of a means of decryption of the private key associated with the user account,

decryption by the server (1) of said private key,

decryption by the server (1) of the encryption session key of said data set by means of said private key, and

- Decrypting by the server (1) of said set of encrypted data by means of the session key for reading said set of data.

7. Management method according to claim 4 or claim 5, characterized in that the reading of said set of data is performed according to the following steps: - authentication of the user (5) with the server (1),

sending the user of the encryption session key of said data set, said session key being encrypted,

decryption by local means of the user of said session key by means of the private key held by the user, returning to the server (1) the decrypted session key, and

decryption by the server of said set of encrypted data by means of the session key.

8. Management method according to claim 4 or claim 5, characterized in that the reading of said data set is performed according to the following steps:

- authentication of the user (5) with the server (1), - sending the user of the encryption session key of said data set said session key being encrypted, and said set of encrypted data,

decryption by local means of the user of said session key by means of the private key held by the user, and decryption by the local means of the user of said set of encrypted data by means of the session key .

9. Management method according to any one of claims 4 to 8, characterized in that it further comprises the following steps:

displaying a list of documents stored in the mass memory (19) of the server (1) and available to the user and / or rights holders of reading, and

- selection by the user and / or a right holder to read a document from said list of documents for decryption.

10. Management method according to any one of claims 4 to 8, characterized in that said data set being a federation base and the server being an identity provider, requests for changes related to the user account are recorded by the identity provider in a log to offer them to the user when the user decrypts the federation database.

IT system for the secure management of data between a server (1) and a client (3) connected to each other by means of a communication network (7), characterized in that the server comprises: a first production means (11) intended to create an account, an identifier of said account, and a means of authentication with this account for a user associated with said client,

a communication means (13) for communicating to said user the identifier of said account and the means of authentication with this account, and

- A second production means (15) for drawing a biclef comprising a public key and a private key, the public key is kept by the server in association with the user account.

12. Management system according to claim 11, characterized in that the server further comprises:

processing means (17) for automatically performing the encryption / decryption of a set of data deposited by the user by means of a session key to form a set of encrypted data, and

a mass memory (19) for storing said set of encrypted data.

13. Management system according to any one of claims 11 and 12, characterized in that the session key is stored with the set of encrypted data in the mass memory (19) of the server (1), said key of session being encrypted using the public key associated with the user account.

14. Secure data management server, characterized in that it comprises: a first production means (11) intended to create an account, an identifier of said account and a means of authentication with this account for a user, a communication means (13) for communicating to said user the identifier of said account and the authentication means with this account,

- A second production means (15) for the draw of a biclef comprising a public key and a private key, the public key is kept by the server in association with the user account,

processing means (17) for automatically performing the encryption / decryption of a set of data, and

a mass memory (19) intended to store the set of encrypted data.

15. Secure data management client connected to a server by means of a communication network, characterized in that it comprises:

decryption means (21) for decrypting a session key and / or a set of encrypted data, and storage means (23) for storing a private key produced by the server.

16. Computer program comprising instructions for implementing the secure management method according to any one of claims 1 to 10 when said program is run on a server.

17. A computer program running on a secure data management server, said program being designed to allow the creation of an account for a user associated with said client, the communication to said user of an identifier of said account and a means authentication with this account, the drawing of a biclef comprising a public key and a private key, the public key being kept in association with the user account, the automatic realization of the encryption / decryption of a set of data, and storing this dataset.

18. Computer program comprising instructions for implementing the secure management method according to any one of claims 1 to 10 when said program is executed on a client.

19. Computer program running on a secure data management client connected to a server by means of a communication network, said program being designed to perform a decryption of a session key and / or a set of encrypted data and to store a private key produced by the server.

20. Downloading of a computer program according to claim 18.