EP3266148A1

EP3266148A1 - Device and method for administering a digital escrow server

Info

Publication number: EP3266148A1
Application number: EP16710269.8A
Authority: EP
Inventors: Bertrand WALLRICH
Original assignee: Institut National de Recherche en Informatique et en Automatique INRIA
Current assignee: Institut National de Recherche en Informatique et en Automatique INRIA
Priority date: 2015-03-04
Filing date: 2016-03-04
Publication date: 2018-01-10
Anticipated expiration: 2036-03-04
Also published as: US10439810B2; EP3266148B1; FR3033466B1; WO2016139435A1; FR3033466A1; US20180131513A1

Abstract

An administration machine (32) for a digital escrow server (10) stores integer values each corresponding to a machine (32;34;36) of a group of administration machines (30). An initialisation function calls a polynomial function, unique to the administration machine, of a degree less than or equal to the number of administration machines, with each integer value, in order to obtain first secret values. The function constructs a message comprising, for each administration machine, the first secret value corresponding to the integer value of said machine. In response to a message comprising, for each administration machine, a second secret value obtained on calling the polynomial function of said machine on the integer value of the administration machine (32), the function constructs a resulting secret value from the first and second secret values. An overlay function processes a digital escrow using the resulting secret value unique to the administration machine (32) and resulting secret values unique to similar administration machines (34;36).

Description

Device and method for administering a digital receiver server

The invention relates to computer security in general, and more particularly the confidentiality of digital data.

To ensure the confidentiality of digital data, it is customary to encrypt them. The encrypted digital data is unusable as it is: it must be previously decrypted. Encryption involves applying a cryptographic function to numeric, block, or message data, using a particular value as a parameter. This particular value corresponds to what is called an encryption key in the art. Subject to knowing the cryptographic function used, which is generally the case when the algorithms are public, it is necessary and sufficient to know the value of a decryption key to decrypt the digital data.

The value of this decryption key is such that it can not be easily found. Generally a key of significant value is used, which makes it practically impossible to recover the encrypted data without knowing the value of the key, in particular by successive attempts.

In the case of an asymmetric cryptographic function, the decryption key, which is generally referred to as "private key", differs from the encryption key, which is then called "public key". It is sometimes said that these keys are asymmetrical. In the case of a symmetric cryptographic function, the encryption key also allows decryption. It is said that the key is symmetrical. The confidentiality of encrypted digital data relies on the ability to keep the secret decryption key. The value of the decryption key is kept secretly by the recipient of the digital data, or disseminated in a strictly limited way to third parties authorized to access this data.

The decryption keys, and more generally all confidential digital data, can be securely stored by a trusted third party which limits access to them. It is in particular a digital receiver server, a receiver corresponding to an encrypted form of the confidential digital data.

The key to decrypt a digital escrow can be secretly kept by a single person. Generally, it is a recipient of the receiver, especially the owner, or the administrator of the server. In this case, however, the sequestered data may be lost if the person in question is no longer able to indicate the value of the decryption key.

This is usually quite critical as the encrypted data is sensitive and important. Their availability for their owner, individual or company, is essential. As a result, the administrator of the receiver server must show a flawless availability.

The administrator function of an escrow server is sometimes provided by several people, each of these people having knowledge of the value of the decryption key. This affects the confidentiality of the data: each administrator can decipher a receiver. The risks to the confidentiality of receivers are increased: the administrators of the receiver server are more frequently the target of computer attacks since a successful attack can provide access to the data of several receivers.

Another practice is to establish a convention for the generation of the decryption key, to reconstruct it in case of loss. In fact, the knowledge of the convention and the data necessary for its application is equivalent to knowing the key itself. A flaw is introduced in the data security, in that knowledge of the convention makes it possible to determine all the encryption keys conforming to the convention. Another practice is to provide a recovery key for the encrypted data. An encryption algorithm is used such that the encrypted data can be decrypted either by the encryption key, kept by the user, or by the recovery key, entrusted to a trusted third party.

In this case, however, each third party can recover the encrypted data alone. And we multiply the security vulnerabilities due to a wider distribution of key values for decryption of data In addition, the same value of recovery key is often used for encryption keys corresponding to different users. And the validity period of a recovery key is generally much greater than that of the user encryption keys.

An alternative is to distribute the decryption key between several trusted third parties: it is necessary to gather all the key parts of third parties to obtain the recovery key. The security is greatly improved insofar as it is necessary to know and attack each of the third parties to hope to recover the encryption key. However, we are reduced to a situation where the default of a single person, in this case a trusted third party, prevents the recovery of the receiver.

One variant is to share this recovery key between trusted third parties, according to a secret sharing algorithm, such as Shamir type or equivalent. The recovery key can be rebuilt by all third parties, or by a subset, also called "quorum" of these third parties. However, a vulnerability persists: once the recovery key is rebuilt, it can be disclosed. There is no longer a quorum of administrators to access all the encrypted data.

The invention improves the situation.

There is provided an administration machine for a digital receiver server including at least one communication interface, memory storing a list integer values each corresponding to a respective machine of a group of administrative machines of the digital receiver server, and a set of parameters relating to an encryption function to perform a sequestration. The machine further comprises a computer capable of executing a polynomial function of degree less than or equal to the number of machines of the group of administration machines, the polynomial function being specific to the administration machine, an initialization function arranged for call the polynomial function with each integer value of the list to obtain a row list of first secret values, construct at least one message comprising, for each administration machine homologous machine of the administration machine group, at least the first corresponding secret value to the integer value of this peer administration machine, in response to at least one message comprising, for each administration machine peer machine, at least one second secret value obtained from the call of the function polynomial of this counterpart administration machine on the entire value of the administration machine, cons truce a resultant secret value specific to the administration machine from the first and second secret values. The calculator is further capable of performing a collection function arranged to process at least a portion of a digital receiver using the resulting secret value specific to the administration machine and resulting secret values specific to the counterpart administration machines. the administration machine group.

The proposed machine is capable of recovering a receiver by cooperating with the homologous machines of the group of administration machines, if necessary with only a subset of the machines of this group. By "recovering a receiver" is meant the process of deciphering the receiver without knowledge of the decryption key.

Recovery of the sequestrator is done without reconstruction of a possible decryption key. Each administration machine can recover the receiver if it has cooperated with a sufficient number of counterpart administration machines. The number of machines that must cooperate to recover a receiver is configurable.

When recovering a sequestrator, the machines of the group of administration machines operate in a similar manner to one another. The proposed machine and the homologous machines do not need to know each other. No master key is used, which greatly improves the security of the receivers.

Certain sequester decryption parameters may be stored on the receiver server itself, for example encrypted with a key specific to each administration machine. In case of server corruption, the confidentiality of the receivers remains assured, as well as the identity of the administrators and the means of deciphering the receivers. A user can deposit a receiver. This user can not recover his escrow himself. This avoids any attack based on identity theft for the receiver. The escrow server does not have to maintain a partial or temporary key, neither on disk nor in RAM. All decryption operations are executed on the administration machine.

The secret value used for recovery is specific to the administration machine. It is partly defined by secret values relating to the other administration machines.

There is also provided a digital escrow exchange and processing infrastructure comprising an escrow server and a group of administration machines comprising at least two administration machines of the type proposed above for the escrow server, two administration machines being homologous to each other. A method for administering a digital receiver server is proposed, comprising the steps of: on each machine of a group of administration machines, calling a respective polynomial function of degree less than or equal to the number of machines in the group of administration machines with each value of a list of integer values each corresponding to a respective machine of the administration machine group to obtain a list of secret values; on each machine of the administration machine group, constructing at least one message comprising at least one secret value corresponding to the integer value of a destination administration machine; on each machine in the administration machine group, construct a resultant secret value specific to this machine from the calculated secret values, by the other machines in the administration machine group, for the integer value corresponding to the administration machine ; on at least some of the machines in the administration machine group, decrypting a digital receiver using this resulting secret value and the resulting secret values of peer administration machines.

Finally, a computer program product capable of cooperating with a central computer unit is proposed to constitute an administration machine of the type proposed above.

Other features and advantages of the invention will appear on examining the detailed description below, and the attached drawings, in which:

FIG. 1 represents a block diagram illustrating an area of receivers;

FIG. 2 represents a block diagram which illustrates a server module for a receiver domain;

FIG. 3 is a block diagram illustrating a higher level administrator module for an escrow domain; FIG. 4 is a block diagram illustrating an administrator module for a receiver domain;

FIG. 5 represents a block diagram which illustrates a client module for a receiver domain;

FIG. 6 represents a flowchart illustrating successive operational modes of an escrow domain; FIG. 7 represents a flowchart illustrating the establishment of an escrow domain;

FIG. 8 represents the domain of FIG. 1 in a first operational mode; FIG. 9 represents a flowchart that illustrates the operation of a higher level administration machine corresponding to a first operational mode of an escrow domain;

FIG. 10 represents a flowchart that illustrates the operation of a receiver server corresponding to the first operational mode of an escrow domain;

FIG. 11 represents a flowchart that illustrates the operation of an administration machine corresponding to the first operational mode of an escrow domain;

- Figure 12 is similar to Figure 10;

- Figure 13 is similar to Figure 11; Fig. 14 is a flow chart that details a step of Fig. 13; FIG. 15 represents a flowchart that illustrates the operation of a receiver server corresponding to a second operational mode of a receiver domain;

FIG. 16 is a block diagram illustrating the domain of FIG. 1 in a second operational mode;

FIG. 17 represents a flow chart that illustrates the operation of a client machine corresponding to the second operational mode of a sequester domain; Fig. 18 is a block diagram illustrating the sequester domain of Fig. 1 in a third operational mode;

FIG. 19 represents a flowchart illustrating the third operational mode of an escrow domain;

FIG. 20 is a flowchart illustrating the operation of an administration machine corresponding to the third operational mode of an escrow domain; - Figure 21 is similar to Figure 20;

FIG. 22 represents a flowchart that illustrates the operation of a receiver server corresponding to the third operational mode of an escrow domain; and

FIG. 23 represents a flowchart that illustrates the operation of an administration machine corresponding to the third operational mode of an escrow domain.

The attached drawings contain elements of a certain character and may therefore not only serve to complete the invention, but also contribute to its definition, if necessary. Figure 1 shows a computing infrastructure of exchange and processing of digital receivers organized in a domain 1. Here, the domain 1 is further organized to store digital receivers.

In general, a "digital sequestration" or "sequestration" in short, corresponds to an encrypted form of a sequence of bytes of any size stored, or intended to be, securely on a third-party machine. The original sequence of bytes is sometimes referred to as "secret" in the art. A secret can for example correspond to a string of characters, a number, a sequence of numbers, a computer file or a list of files.

The domame 1 is organized on an infrastructure, hardware and software, computer network. The base network comprises machines, hardware and software of the network, capable of communicating with each other according to any network protocol, for example on the basis of socket, hypertext transfer protocol, or http protocol, possibly in the version secure (https protocol) or RPC protocol, for "Remote Procedure Call" or remote procedure call in French, or more generally any structured data exchange protocol.

The machines of domain 1 communicate with each other according to a protocol allowing the exchange of data between the machines of domain 1. The protocol can be encoded in any way so long as the machines of domain 1 can exchange data with each other the others, for example in ASN. l, JSON or XML.

The receiver area 1 comprises a receiver server 10 which, on the one hand, stores the digital receivers, and, on the other hand, partially controls at least the domain 1. The server 10 can be distributed over several machines, hardware and / or software. In particular, the server 10 may comprise a first machine dedicated to the storage of the digital receivers and a second, different machine, dedicated to the control of the domain 1. Domain 1 further comprises a higher level administration machine, or higher administration machine 20, capable of communicating with the server 10. The upper administration machine 20 controls the server 10.

Domain 1 further comprises a group of administration machines 30, here comprising a first administration machine 32, a second administration machine 34 and a third administration machine 36. Each machine of the group 30 is able to communicate. Group 30 machines operate on digital receivers.

Domain 1 finally comprises one or more client machines 40 which are each capable of communicating with the server 10, in particular in order to deposit one or more digital receivers therein.

FIG. 2 shows a server module 100 for use for example for the server 10 of FIG. 1.

The server module 100 comprises a main controller 110 and a data storage structure 120. The controller 1 10 is able to read, write and process data in the storage structure 120. The structure of this storage 120 maintains in particular a set management data relating to the escrow domain, including data related to the escrow setting.

The server module 100 further comprises at least a first communication interface 130 which can be controlled by the controller 1 10 to communicate with the machines of an escrow domain, for example the domain 1 of FIG. 1.

Here, the server module 100 further comprises a second communication interface 140 that can be controlled by the controller 1 to exchange data exclusively with a digital receivers storage machine. In particular, the controller 1 10 is able to send to the second interface 140 one or more messages including digital receivers for storage on the machine in question

The escrow storage machine may be arranged to periodically connect to the controller 110 via the second communication interface 140 in order to retrieve requests from the waiting server module 100 and to transmit to this module responses to requests relating to the previous connection. In this configuration, the escrow storage machine corresponds to what is sometimes called a "cold server", usually designated by the equivalent English equivalent of "cold server".

The server module 100 can be implemented in the form of a web-based software server equipped with JSON type libraries (for "Java Script Object Notation" or Javascript object notation in French) executed by a central computer unit. The storage structure 120 may be organized in the storage memory of the computer in question.

FIG. 3 shows a super administrator module 200 for use, for example, in the super-administrator machine 20 of FIG. 1.

The super administrator module comprises a main controller 210 and a storage structure 220 which stores the data relating to the super administrator function. The controller 210 can read, write and process the data in the storage structure 220.

The super administrator module 200 further comprises a user interface 230, for example of graphical type, which interacts with the main controller 210. The administrator module further comprises a communication interface 220 which can be controlled by the main controller 210 to transmit and receive data through a sequestering domain, for example the domain 1 of FIG. 1.

The super administrator module 200 can take the form of a Java application that runs on a central computer unit. The storage structure 220 may be organized in the storage memory of the computer in question.

FIG. 4 shows an administrator module that can be used in an administration machine, for example each of the first machine 32, the second machine 34 and the third machine 36 of the administration group 30 of FIG.

The administration module 300 comprises a main controller 310 and a data storage structure 320 with which the controller can interact, in particular, to read, write and process data.

The administrator module includes a user interface capable of interacting with the main controller 310. For example, the user interface is of graphic type.

The administration module 300 further comprises a communication interface 340 which can be controlled by the controller 310 for exchanging data through an infrastructure of receivers, for example the domain 1 of FIG. 1.

The administrator module can be made as a Java application that runs on a central computer unit. The storage structure 320 may be organized in a storage memory of this central unit.

FIG. 5 shows a client module 400 used for example in the client machine 40 of the domain 1 of FIG. 1. The client module 400 includes a controller 430 and a data storage structure 440 with which the main controller 410 can interact to read, write, and store data. The client module 400 further comprises a user interface 430 which interacts with the main controller 410. The user interface 430 may be of graphic type.

The client module 400 further comprises a communication interface 440 which can be controlled by the main controller 410 to exchange data through a sequestration infrastructure, in particular, the domain 1 of FIG. 1.

Client module 400 can be implemented as a Java application running on a central computer unit. The storage structure 420 can be organized in the storage memory of this calculation unit.

In one embodiment, at least some of the server modules 100, super administrator 200, administrator 300 and client 400 are integrated in the same application, for example Java, which runs on a machine as a particular module according to the associated rights in the domain to an identifier of the user of the machine in question.

FIG. 6 generally illustrates various operational modes of a digital receiver infrastructure, in particular domain 1 of FIG. 1. According to a first operational mode, illustrated by block 5, at least some of the software and hardware elements of an infrastructure computer network cooperate to establish an escrow domain.

According to a second operational mode, illustrated by block 7, at least some of the hardware and software elements of the infrastructure cooperate to allow registering a receiver on a server of the infrastructure, for example the server 10 of FIG.

According to a third operational mode, illustrated by block 9, at least some hardware and software elements of the infrastructure cooperate to recover at least one of the receivers stored on the infrastructure server, that is to say to allow the decryption of the digital receiver in the absence of at least some of the data used for the encryption of the digital receiver in question. Figures 7 and 8 detail the establishment of a sequestering infrastructure such as the domain 1 of Figure 1 for example.

The establishment of the infrastructure begins with a configuration phase, represented here by block 50. In particular, it involves setting at least some of the parameters necessary for the operation of the infrastructure, at least in an initial phase. This involves at least defining, among the hardware and software elements of a network infrastructure, an infrastructure controller, an escrow storage server, possibly assembled in a single machine, and a group of administration machines for the receivers. . This definition may involve user intervention.

The configuration of the receiver infrastructure can be performed from a particular machine in the network infrastructure, such as a higher level administration machine, for example the machine 20 of FIG. 8. Configuration data infrastructure are maintained on the controller, to which the administration machines can access. In the example of FIG. 8, these data are maintained on the sequester server 10, for example in a structure similar to the storage structure 120 of FIG. 2. The configuration data of the receiver infrastructure can be transmitted to the escrow controller by the highest level administration machine in a specific domain creation message, or CREATJDOM message, as shown in FIG. 8.

The establishment of the sequestrator infrastructure is continued by the generation of cryptographic parameters for use in the infrastructure, which corresponds to block 52 of FIG. 7, and by the sharing of these parameters between at least some of the machines of the sequestration infrastructure. infrastructure, which corresponds to block 53 of Figure 7.

Each administration machine, for example each machine in the group 30 of FIG. 1, generates a first set of cryptographic parameters of its own. Then the cryptographic parameters of the first set of administration machines are shared between the peer machines of the administration machine group. The sharing of these parameters can be done through the infrastructure controller, which prevents the administration machines from having to communicate directly with each other. For example, each administration machine transmits data from its first set of cryptographic parameters to the controller, using an initialization message. In FIG. 8, for example, each of a first administrator station 32, a second administrator station 34 and a third administrator station 36 sends the server 10 an administrator initialization message, or ADMJNIT message.

The controller of the escrow infrastructure stores the cryptographic parameters received from the administration machines in a collection of first cryptographic parameters relating to the group of the administration machines, then makes this collection available to these administration machines.

In the embodiment illustrated in FIG. 8, each of the first administration machine 32, the second administration machine 34 and the third administration machine 36 receives from the server 10 a message containing administrative configuration data. Domain 1, or DOM_CFG_ADM message. This data includes a collection of first cryptographic parameters. Each administration machine stores the collection of first cryptographic parameters. Each administration machine generates a second set of cryptographic parameters from the collection of first cryptographic parameters. This corresponds to block 54 of FIG. 7. The second set of cryptographic parameters comprises cryptographic data specific to the administration machine that generated it and cryptographic data for use more generally by other machines of the infrastructure. in particular other administration machines. The parameters of the second set are then shared between the administration machines. This corresponds to block 55 of FIG. 7. Sharing can be done through the receiver controller. In FIG. 8, for example, each administration machine transmits to the server 10 a data sharing message, or ADM_SHAR message, which contains the data of its second set of parameters.

The establishment of the receiver infrastructure ends with the calculation of cryptographic parameters for use in this infrastructure, in particular for the deposit of a receiver, from the collection of cryptographic parameters. This corresponds to block 56 in FIG. 7. The cryptographic parameters in question comprise in particular a public key valid for the receiver infrastructure. This public key can be made available to the infrastructure machines on a server of the infrastructure, typically the receiver server or the controller. This public key can be used to encrypt digital data for sequestration purposes. FIG. 9 illustrates a first main function for a higher level administration machine, for example the machine 20 of FIG. 8, for use in the first operational mode of an escrow infrastructure. This may be, for example, the operation of the main controller 210 of Figure 3. The function starts in a step 5000. In the next step 5002, the function receives an identifier for the receiver infrastructure, or identifier Domld, for example in the form of a character string, a total number of administration machines for the infrastructure, or number DomAdmMax, a minimum number of administrative machines necessary for the recovery of a receiver, or DomAdmMin number, and an identifier for each infrastructure administration machine, noted generically DomAdm_i for an i-th machine, for example under the form of a string of characters. These data are stored in memory, for example in a structure similar to the storage structure 220 of FIG. 3. The identifiers DomAdm_i can be stored in an array of dimension n, where the number n corresponds to the number DomAdmMax. Here it is the DomAdm board. These values can be entered from the higher level administration machine, in particular through an interface similar to the interface 230 of FIG. 3. In the next step 5004, the function constructs an infrastructure creation message. , for example a CREAT DOM message, comprising an identifier of the host machine, here the identifier SAdmld, as issuer, and the identifier of a controller of the infrastructure as a recipient, or identifier SRVRId. The message contains as data the Domld string, the DomAdmMax number and the DomAdmMin number, and a table of the type of the DomAdm array, each element of which corresponds to the identifier of an infrastructure administration machine. or the like.

The function then stops at step 5006.

FIG. 10 illustrates a first main function for a controller, for example the server 10 of FIG. 8, in the first operational mode of an escrow infrastructure. This is for example the operation of the controller 110 of Figure 2. The function starts in 5100. In the next step 5102, the function receives a domain creation message from a higher level administration machine, for example a CREATJDOM message. The message includes a domain identifier, for example the Domld string, a number of administration machines, for example the DomAdmMax number, a minimum number of administration machines, for example the DomAdmMin number, and a list of machine identifiers. administration, for example the DomAdm board.

In the next step 5104, the function stores the received data locally. The function stores the identifier of each administration machine, noted generically DomAdm_i, in relation to a respective integer value (non-zero), noted generically value DomAdmRk_i.

For example, the function fills an array relating to the group of administration machines, here a table DomAdmGr, each element includes a DomAdm_i identifier, in relation to a value DomAdmRk_i. The DomAdmRkJ value can be an index value of the DomAdm_i ID in the DomAdmGr array. This index may correspond to the order in which the administration machine received the user identifiers. Random scheduling can also be implemented. In addition or in replacement, integer values can be generated randomly.

The function then ends in a step 5106. FIG. 11 illustrates a first function for an administration machine, for example the main function 310 of the administration module 300 of FIG. 4, corresponding to the first operational mode of a Domain infrastructure. This first function is intended for generating a first set of cryptographic data.

The function starts in 5200. In the next step 5202, the function receives the identifier DomAdmId_i of an administration machine i. Here, the function also receives a code whose value conditions access to this machine i. The code is for example a password, which is generically noted DomAdmPwd_, for example in the form of a character string, where appropriate chosen by or for a user of the machine i.

In the next step 5204, the function generates a pair of values corresponding to a public key, or key PubKy, and a private key, or key PvtKy, of an asymmetric type of encryption function. The key PvtKy and the key PubKy are generated randomly on the machine i and are specific to this machine i. The asymmetric encryption function can be of the RSA or El Gamal type, for example. For example, the function randomly generates an integer in an interval [1 .. pO-2], where pO is an integer value that corresponds to a parameter common to machines in the receiver infrastructure. The generated value is used as the PvtKy key. The function then calculates the key PubKy using a generating value gO, in the interval [1 .. pO-2], raised to the power PvtKy and brought back to the interval [1 ... p0_2] (modulo pO). The generating value gO may be common to the receiver infrastructure. For example, the values of the parameters p0 and g0 can be coded in the function to avoid exchanging these values between machines of the infrastructure. This improves the security of the sequestration infrastructure. Alternatively, the values of the parameters p0 and g0 may be specific to each administration machine. In this case, these values are communicated to the peer machine in the group of administrative machines.

In the next step 5206, the key PvtKy is encrypted by means of a symmetrical type function, for example of the AES type, with a code specific to the machine i as a parameter, for example the string DomAdmPwd_i. We obtain an encrypted value of the key PvtKy, or EncPvtKy value. The key PvtKy, the key PubKy and the value EncPvtKy are specific to the machine i. In the next step 5208, the function constructs a message destined for a controller of the infrastructure, for example the server 10 of FIG. 8, indicating the identifier of the administration machine DomAdm_i as issuer. The message includes data corresponding to the key PubKy_i generated on the machine i and the value EncPvtKy_i encrypted for the machine i. This is for example an ADM_INIT message in Figure 8. The function then stops in 5210.

FIG. 12 illustrates a second function for a controller, for example the server 10 of FIG. 8, for use in the first operational mode of an escrow infrastructure. This is for example the operation of the main controller 210 of Figure 3.

The function starts at 5300. At the next step 5302, the function starts a loop structure by initializing a counter j.

In the next step 5304, the function receives a message from an administration machine i of the infrastructure. The message comprises two values respectively corresponding to a public key value specific to the machine i, here the key PubKyJ, and an encrypted value for this machine i a private key specific to the machine i, here the value EncPvt y_i. This is for example an ADM_INIT message.

In the next step 5306, the function stores the data from the previous step. Here the data is gathered as an index element j of a GrpDomAdm array. The function adds to the received data the integer value DomAdmRk i of the administration machine i.

In the next step 5308, the counter j is incremented.

In the next step 5310, the function verifies that the counter ja reaches its final value. This value is the DomAdmMax number. The function checks that it has received and processed an initialization message from each of the sequestration infrastructure administration machines.

If so, then the function ends in the next step 5312. Otherwise, the function returns to step 5304 where it waits for an initialization message from another administration machine.

Steps 5300 to 5312 correspond to the storage, on the controller of the receiver infrastructure, of cryptographic data for the secure exchange of data between management machines, directly or through the controller. This cryptographic data comprises, for each administration machine, a respective value for use as a public key. Here, this cryptographic data further comprises an encrypted value, for the machine in question, of the private key corresponding to the public key The latter can become optional, insofar as at least some of the administration machines can keep their private key without addressing it to the controller or counterpart machines.

Fig. 13 illustrates a second main function for an administration machine, for example one of the first 32, second 34 and third 36 administration machines of Fig. 8, corresponding to the first operational mode of a sequestration infrastructure. This second function corresponds to the exchange of parameters of a first set of cryptographic parameters between administration machines. This is for example the operation of the main controller 310 of Figure 4. The function starts in a step 5400.

In the next step 5402, the function receives a message from a controller of the infrastructure comprising data relating to each administration machine i of the receiver infrastructure. In particular, the data comprises, for each administration machine i, a machine identifier, for example the identifier DomAdmId_i, a public key value specific to this machine i, for example the key PubKyJ, an encrypted value for this machine i of a private key generated by this machine i, by example the key value EncPvtKyJ, and a rank DomAdmRk_i of this machine. The data can be collected in a table similar to the GrpDomAdm table.

In the next step 5404, the function receives a code which conditions access to the machine, for example the string DomAdmPwd.

This allows, in the next step 5406, to decipher the value EncPvtKyJ corresponding to the machine i. We obtain the key PvtKy_i relating to this machine i. Steps 5400 to 5406 correspond to the recovery, by a particular administration machine, of the data of its first set of cryptographic parameters, in particular its public key value and an encrypted version of its private key value. This makes it possible to use physically different equipment as an administration machine i between steps 52 and 54. This also prevents the machine from storing cryptographic data on equipment, which greatly improves security. However, these steps are optional in that this cryptographic data can be securely stored on a particular piece of equipment. In the following steps, the function generates data defining a polynomial of degree corresponding to the number DomAdmMin minus one. The coefficients of the polynomial are generated randomly in a discrete integer space whose dimension, represented here by the integer q, is common to the administration machines of the sequestrator infrastructure. The polynomial is specific to the machine that generated it. The peer machines in the administration machine group do not necessarily use the same polynomial.

This is done by first initializing a loop counter j to a null value in a step 5408. In the next step 5410, the function stores as an index element j of an array Poly_i the result of a random generation function with values in an interval [1 .. q-2]. The counter j is incremented in the next step 5412. In the next step 5414, the function verifies that the counter ja reaches its final value, that is to say the number DomAdmMin. The function verifies that a coefficient has been generated for each term of the polynomial. If so, then the function continues to the next step 5416. Otherwise, the function returns to step 5410 where it generates a value for the higher degree coefficient and then stores it in the Poly_i table.

In step 5416, a local public key value specific to the administration machine i, or key LocKy L, is calculated from the data of the table Poly_i. Here we use an El Gamal type encryption function. The key LocKy_i is computed with the generator value g of the infrastructure, in the interval [1 .. p-2], by using the term of the polynomial of degree zero, here the integer of zero index of the table Poly_i. The value LocKy_i is specific to the administration machine i considered.

In the next step 5418, the function calculates a collection of secret values relating to the other domain administration machines. A secret value for a generic administration machine k is encrypted with the key PubKy_k of this administration machine, for example as received in step 5402. The encrypted secret values are gathered here in an array EncRemKy_i . For example, the secret value for the administration machine k is stored as an index item k-1 in this table.

In the next step 5420, the function constructs a message to the server for cryptographic data sharing, or message ADM_ SHAR. The message in question includes the value of the local key LocKy_i of the host machine i and an array of secret values, where appropriate encrypted, corresponding to the table EncRemKy_i.

The function stops at the next step 5422.

The encryption of secret values makes it possible to ensure their confidentiality. In other words, only the administration machine can access the secret calculated for it by the administration machine i. This makes it possible to confidentially gather the secret values on a server of the infrastructure. However, the encryption can become optional in the case where it is possible to ensure in another way the confidentiality of the secret, for example in the context of an exchange of secret values directly between the administration machines.

FIG. 14 details step 5418 of FIG. 13. In a step 54180, the function starts a loop structure by initializing a first counter j to the value 0 (zero).

In the next step 54181, the function creates a calculation table RemKy_i and initializes the index element j of this array to 0 (zero).

In the next step 54182, the function starts a second loop structure, nested in the first, by setting a second counter k to 0 (zero).

In the next step 54184, the function stores in the calculation table RemKy_i, as index element j, the value corresponding to this index j, to which the degree coefficient k of the signature polynomial is added, it is ie the integer value of index k in the table Poly_i, that multiplies the rank of the administration machine j + 1, or DomAdmRkJ + 1 to the power k. In the next step 54186, the function increments the loop counter k, before checking, in a step 54188, that this loop counter ka reaches its final value, corresponding to the number DomAdmMin. If yes, then the function continues to the next step 54190. Otherwise, the function returns to step 54184. The steps 54182 to 54188 correspond to the calculation of a result-value of the polynomial function which serves as a signature function to the administration machine i for a particular value. This particular value corresponds to the integer value DomAdmRkj of an administration machine j of the infrastructure. The result value is generated on a particular administration machine, based on a function specific to that machine. This value can be seen as a signature value. The result value is also a secret value. This result value is calculated on the basis of an integer value uniquely corresponding to a peer machine in the administration machine group. It can be seen as part of a secret value unique to this peer machine.

In step 54190, the function encrypts the secret value corresponding to an administration machine j, for example the index value j in the key table Rem y_i, with the key PubKy_j of this machine j. The encryption here uses a function of the El Gamal type, the parameters of which are common to the administration machines of the sequestrator infrastructure, for example the parameters g_u and p_0 described in connection with step 5204. Preferably, the values these parameters are coded in the function.

In the next step 54192, the first loop counter j is incremented, and it is verified in a step 54194 that the loop counter j has reached the value DomAdmMax.

If so, then the function stops, which corresponds to the end of step 5418 of FIG. 13. Otherwise, we return to step 54181. FIG. 15 illustrates a third main function for a controller, for example the server 10 of FIG. 8, in the first operational mode of an infrastructure of receivers. This third function corresponds to a phase of exchange of encryption parameters.

The function starts in step 5500.

In the next step 5502, the function initiates a loop structure initializing a first counter j to 0 (zero).

In the next step 5504, the controller receives a message from an administration machine i, for example an ADM_SHAR message. The message contains a signature value of the administration machine i, for example a value LocKy_i, and an encrypted value EncRemKy_i J of a secret value RemKy_iJ of the machme i calculated for each other administration machine j, from the integer value corresponding to the latter. Here, the encryption was done with the PubKyJ key of each machine j. For example, these values are collected in an indexed array EncRemKy_i.

In the next step 5506, a value corresponding to the integer value of the machine i is stored as an index element j of an array GrpDomAdm, for example the value DomAdmRkJ, an identifier of this machine, for example the an identifier DomAdmId_i, a public key value specific to this machine, or key PubKy_i, an encrypted value of a private key value generated by this machine, for example the value EncPvtKy_i, the signature of this machine, or value LocKy_i, and encrypted values EncRemK J of signatures generated by the machine i for each other administration machine j of the infrastructure.

In the next step 5508, the function increments the loop counter j. In the next step 5510, the function verifies that the loop counter ja reaches its final value, which corresponds to the number DomAdmMax. If so, then the server has received a message from each of the domain's administration machines. Otherwise, the function returns to step 5504 and waits for one or more messages from other administration machines. Once the server has received and processed the messages from all infrastructure management machines, i.e. the test in step 5510 is positive, the server starts a second structure of loop initiating a second counter k to the value 0 (zero) in a step 12.

In the next step 5514, the server creates a DomPubKy calculation variable. The variable DomPubKy is initialized to the value 1 (one).

In a step 5516, the new value of the variable DomPubKy is calculated as the old value of this variable DomPubKy multiplied by the local public key of the administration machine k, or key LocKy_k.

The next step 5518 is to increment the second loop counter k. In the next step 5520 it is verified that the loop counter k has reached its final value, which corresponds to the number DomAdmMax.

If so, then the function stops at the next step 5522. Otherwise, the function returns at 5516. The result of steps 5514 to 5520 is a final value of the variable DomPubKy which corresponds to the product of the respective local key values LocKy_k of each administration machine of the sequestration infrastructure.

FIG. 16 illustrates the sequester domain 1 in the second operational mode, which corresponds to the deposit of a receiver on the server 10 from a client machine 40.

The client machine 40 receives from the server a message comprising cryptographic parameters for use in the domain, or message DOM_CFG_CLT. This data includes a public key value for use in the domain 1, that is to say, to use to encrypt a receiver for this infrastructure. This is the final value of the DomPubKy variable. The client machine 40 processes a series of bytes of any size to be sequestered using the received cryptographic parameters and local parameters, and then sends a message containing the sequester to be stored to the server 10, or message ADD_ESCRW.

The encrypted byte sequence corresponds to what is sometimes called a "secret" in the art. The secret can be a string, a number or a sequence of numbers, a file or a list of files. Fig. 17 illustrates a main function for a client machine of a sequestration infrastructure, for example the machine 40 of Fig. 16, in the second operational mode of the infrastructure.

The function starts in a step 700.

In the next step 702, the function receives the secret to be processed, for example a string of characters CltScrtStrg.

In the next step 704, the function randomly generates an integer value CltSesKy, here using a subfunction kygnrtr ().

In the next step 706, the function encrypts the string CltScrtStrg with the integer value CltSesky. The function uses a symmetric type encryption algorithm, for example of the AES type. We get an encrypted string, or string EncCltScrtStrg. The integer value CltSesky is a session key for the client machine, i.e., this integer value is used only for encrypting a CltScrtStrg string or a limited number of analog strings. This CltSesKy value is unique to the client machine. In the next step 707, the function randomly generates a value r in the range [1 .. p-2]. In the next step 708, the function encrypts the session key CltSesky with the value DomPubky, which corresponds to a public key for the escrow domain. The function uses an El Gamal type encryption function with, as parameters, the p-dimension and g-generator values of the infrastructure. These values may have been received from the server as cryptographic parameters or integrated directly into the function.

Encryption uses as parameter the integer value r generated randomly as a private key.

The escrow includes the encrypted form of the session key. The sequester includes a first digit Alpha which is equal to the generating value g of the domain raised to the power r modulo p, and a second digit Beta which corresponds more particularly to the encrypted form of the session key, calculated as the public key to the power. r that multiplies the CltSesky session key, all modulo p.

In the next step 710, the client machine sends a message to an infrastructure controller, for example an ADD_ESCRW message. The message contains an identifier of the client machine, or identifier DomCltld, a sequester identifier, for example in the form of a string CltEscwid, and the sequester comprising the values Alpha and Beta corresponding to the encrypted value EncCltSesKy of the session key CltSesKy. Optionally, the message may further contain the encrypted form EncCltScrtStrg of the string CltScrtStrg, i.e., the secret of the user of the client machine. In a way, this encrypted form can be seen as part of the sequestration.

The client machine is identified with the infrastructure controller to receive the operating parameters of the infrastructure, in particular the values of the parameters p and g and the public key. The client machine, or its user, is not necessarily authenticated. In other words, the controller does not keep any authentication data relating to the client machine or its user. The function then stops at step 712.

Upon receipt of the ADDJ3SCRW message, the infrastructure controller may issue an acknowledgment to the client machine. The server stores the receiver, in particular in a cold storage type server, and the data relating to the client machine.

Fig. 18 illustrates the third operational mode of a receiver infrastructure such as domain 1 of Fig. 1.

In this operational mode, only a subset of the domain 1 administration machine group cooperates to recover a digital receiver, for example the Alpha and Beta values corresponding to the encrypted form of the CltSesKy key. In the example of FIG. 18, this is the second administration machine 34 and the third administration machine 36. Each of the administration machines receives a message containing the cryptographic configuration data of the domain, or DOM_CFG_ADM message.

The escrow recovery consists of four main transactions. In a first operation, illustrated by block 90 of FIG. 19, at least some of the machines of the group of administration machines, here the second machine 32 and the third machine 36, each calculate a respective additional value from the cryptographic data. calculated for them by all the other administration machines of the sequestration infrastructure. This additional value is secret since it is calculated for the first time on the administration machine concerned, from secret values calculated and encrypted for this administration machine.

At the next operation, represented by block 92, the sequester is recovered, or at least the value of Alpha.

In a next operation, represented by block 94, the administration machines that calculated their additional secret value re-encrypt the value Alpha. The Alpha value corresponds to a part of the escrow, in particular a part of the encrypted value EncCltSes y of the key CltSes y. This step of encrypting the Alpha value can be seen as over-encryption. In a next operation, represented by block 96, each administration machine having calculated an additional secret value decrypts the receiver. In other words, each of these administration machines retrieves the value of the session key CltSesKy. As an option, at least some of these machines can decrypt the EncCltScrtStrg secret.

FIG. 20 illustrates a second main function for an administration machine of a sequestration infrastructure and intended for the calculation of a secret value specific to this machine, generically denoted as the administration machine j, or DomAdmJ machine. The function starts in a step 9000.

In the next step 9002, the function receives from an infrastructure controller a message containing a public key value for use in the infrastructure, for example the key DomPubKy, and the data relating to cryptographic parameters of the infrastructure. , for example grouped in an array of the GrpDomAdm table type. This is for example a DOM_CFG_ADM message. The cryptographic parameters include in particular the set of secret values calculated by each administration machine i for the other administration machines j of the group of administration machines. Here, each secret value is encrypted with the public key of the administration machine for which it is intended, that is to say whose integer value was used for the calculation.

In the next step 9004, the function receives a code which conditions the access to the administration machine j, for example a chain analogous to the chain DomAdmPwdJ. In the next step 9006, the function searches in the cryptographic parameters of the infrastructure for the entire value DomAdmRkJ corresponding to an administration machine j. In the next step 9008, the function decrypts the EncPvt yJ value of the machine j with the password DomAdmPwdJ entered in step 9004. This results in a private key value corresponding to the administration machine j, or key PvtKyJ.

Steps 9004 to 9008 are optional. They aim to find the key value PvtKy_i of the machine i, as it was calculated at the initialization of the domain of receivers.

In the next step 9010, the function starts a loop structure by initializing a counter k to the value 0 (zero).

In the next step 9012, the function creates a calculation variable AdmScrtJ for the administration machine that it sets to zero.

In the next step 9014, the function assigns the calculation variable AdmScrtJ the previous value of this variable to which it adds the decrypted version of the secret value computed by the administration machine k for the administration machine j. Here, this value corresponds to the index element j-1 of the EncRemky_k + 1 array.

In the next step 9016, the function increments the counter k.

In the next step 9018, the function verifies that the counter ka reaches its final value, which corresponds to the number DomAdmMax. If so, then the function ends in the next step 9020. Otherwise, the function returns to step 9014. The resulting value AdmScrtJ corresponds to an additional secret value of the administration machine j calculated from the secret values calculated for this machine by the other infrastructure administration machines. In a non-detailed phase, at least some of the administration machines send a message with identifiers corresponding to the receivers, for example a username and a receiver name. This is for example a GET_ESCRW message. In return, a receiver controller is arranged to return the value Alpha to these administration machines.

FIG. 22 illustrates a second main function for a sequestration infrastructure administration machine in the third operational mode of this infrastructure, for example one of the second machine 34 and the third machine 36 of FIG. 18. This is to re-encrypt part of the sequestrum, the Alpha value, with a secret value specific to the administration machine and established from secret values computed for it by the homologous machines of the group of administration machines. .

The function starts in a step 9400.

In the next step 9402, the function receives a message comprising the value Alpha corresponding to a portion of a digital receiver. Typically, this is a portion of the EncCltSesKy encrypted value of the CltSesKy session key.

In the next step 9404, the function calculates an encrypted value EncCalpha_i of the value Alpha with an additional secret value AdmScrtJ of the machine i. The function raises the Alpha value to a power corresponding to the additional secret value AdmScrtJ of the machine i, all modulo p.

In the next step 9406, the function initiates a loop structure by initializing a counter k to the value 0 (zero).

In the next step 9408, the function calculates an encrypted value of the value EncCalphaJ using the key PubKy_k + 1 corresponding to the administration machine k + 1. The result is for example stored as index element k of a table, noted here EncCalphaJ table. In the next step 9410, the function increments the loop counter k.

In the next step 9412, the function checks that the loop counter k has reached its final value, which corresponds to the number DomAdmMax.

If so, then the function proceeds to the next step 9414. Otherwise, the function returns to step 9408. At the end of steps 9406 to 9412, the function has established a collection of encrypted values each corresponding to the value EncAlpha_i of Alpha encrypted with the additional secret value of the machine i encrypted again with the pubKy_k public key of another k administration machine of the infrastructure. These steps are intended to encrypt the exchange of EncAlpha_j values each specific to a respective administrative machine of the infrastructure between the administration machines i through the infrastructure. These steps are optional.

In step 9414, the administration machine i constructs a message intended for the infrastructure controller, for example an ADM_SCRYPT_ESCRW message. The message comprises the collection of EncCalpha_i_k values, for example in the form of an indexed EncAlpha_i list of values of which a generic index element k comprises a value of EneAlpha_i encrypted with the key PubKyJk corresponding to the index value. The function then stops at step 9416.

Fig. 22 illustrates a third function for a receiver infrastructure controller such as server 10 of Fig. 18 in the third operational mode of this infrastructure.

The function starts with step 9500. In the next step 9502, the function initiates a loop structure by initializing a counter j to 0 (zero).

In the next step 9504, the server receives a message from an administration machine i. The message includes the collection of encrypted values of Alpha by the machine i encrypted for each other administration machine of the receiver infrastructure. Here these values are gathered in a table of the type of the table EncCalpha_i [..]

In the next step 9506, the function creates a table to hold the encrypted values of Alpha for the domain, or DomCalpha array. The function stores therein the collection of values computed by the administration machine i, or table EnCalphaJ as an index element j, here in relation with an identifier of this machine, for example the identifier Admld__i At step following 9508, the function increments the loop counter j.

In the next step 9510, the function verifies that the loop counter j has reached its final value, which corresponds to the number DomAdmMin. If so, then the function has received and processed as many messages as the minimum number of administration machines to recover a receiver. The function then continues with step 9512. Otherwise, the function returns to step 9504.

In step 9512, the function initiates a loop structure by initializing a second counter k to the value 0 (zero).

In the next step 9513, the function retrieves an identifier of the machine whose calculated data is stored as an index element k in the DomCalpha array. This identifier is that of the administration machine i, generically noted Admld_i. In the next step 9514, the function controls the transmission of a message to the administration machine k. The message contains the DomCalpha array and the Beta value.

In the next step 9516, the function increments the second loop counter k.

In the next step 9518, the function verifies that the counter k has reached its final value, namely the number DomAdmMin.

If so, then the function has issued a message to each administration machine involved in the collection of a receiver. And the function stops at the next step 9520. Otherwise, the function returns to step 9513 to issue a message to another receiving machine of the receiver.

Fig. 23 illustrates a second function for an administration machine for use in decrypting the sequester.

The function starts with a step 9600.

In the next step 9602, the function receives a message from a controller of an escrow infrastructure, for example the server 10 of FIG. 18, containing a set of alpha values encoded with the secret values of the machines. administration of the escrow, each value itself being encrypted with a public key value of an administration machine. Here, these values are contained in an array of the type of the DomCalpha array. The message may further include the Beta portion of the digital receiver.

In the next step 9604, the function initiates a loop structure by initializing a first counter j to the value 1 (one). In the next step 9606, the function creates a SummC calculation variable that it initializes to zero. In the next step 9608, the function starts a second loop structure, nested in the first, by setting a second counter k to 0 (zero).

In the next step 9609, the function initializes a second calculation variable, or Lambda variable J, to the value 1 (one).

In the next step 9610, the function checks that the integer value DomAdmRk k of the machine k differs from that DomAdmRkJ of the administration machine DomAdm J. If yes, then the function calculates a LambdaJ value by multiplying the previous value of the variable LambdaJ by the integer value DomAdmRk_k corresponding to the machine DomAdm_k and dividing the result by the value of the difference of the integer value DomAdmRkJ corresponding to the administration machine k and that DomAdmRk J corresponding to the machine DomAdm J, the whole modulo p. In the next step 9614, the function increments the second loop counter k.

In the next step 9616, the function verifies that the loop counter k has reached its final value, which corresponds to the number DomAdmMin. If so, then the function continues with step 9618. Otherwise, the function returns to step 9610.

Steps 9608 to 9616 correspond to calculating a Lagrange coefficient value from the DomAdmRk integer values corresponding to the administration machine k and to the counterpart administration machines of at least a subset of the group 'administration.

In step 9618, the function computes SummC as the previous value of the SummC variable to which it adds the EncCalpha value of Alpha encrypted for the administration machine i to the LambdaJ power. In the next step 9620, the function increments the loop counter j. In the next step 9622, the function checks that the loop counter ja reaches its final value, which corresponds to the number DomAdmMin. If so, then the function continues with step 9626. Otherwise, the function returns to step 9608. In the next step 9626, the function calculates a decrypted version DcphKy_i of Beta for the administration machine i. This value is calculated by multiplying the value Beta by the last calculated value of the SummC variable to the power minus one (-1).

In the next step 9628, the function finds the secret value of the user CltScrtStrg by decrypting the encrypted version EncCltScrtStrg using the decryption key DcphKy_i. This decryption key DcphKy_i corresponds to the integer value used for the symmetric encryption of the secret to be processed, for example the value CltSesKy described in connection with FIG. 17. Then the function stops at the next step 9630.

Steps 9600 to 9630 can be executed on each of the quorum sequestration administration machines, i.e., machines having calculated an over-encrypted version of Alpha.

Decryption involves a subset of domain administration machines whose cardinal is the DomAdmMin number. The DomAdmMin number is defined as a parameter. It is similar to what could be called a "quorum" of administration machines.

In this decryption process, the escrow's storage server mainly acts to provide the quorum administration machines with the different Alpha and Beta parts of the escrow. In an alternative embodiment, the administration machines are arranged to recover only the session key of the client machine, and to communicate this value to the client machine. A sequestration infrastructure has just been described in which the administration machines take care of the recovery of digital receivers and part of the initialization of this infrastructure. A machine comprises the hardware and software elements necessary for the described operation. In particular, the software elements may be common to at least some of the administration machines. The administration machines are essentially distinguished from each other by their DomAdmld identifier in the infrastructure. The identifier of an administration machine may be replaced by a user identifier insofar as the controller is able to relate a user identifier to an address for the messages, or, to a similar extent, by a software identifier

The control of access to an administration machine is conditioned to the provision of a code. In practice, this code can be associated with an equivalent more easily memorized for the user. The equivalent in question can take various forms, such as a computer file, a certificate, a token, which is called "token" in the art, possibly stored on storage media such as a smart card for example . The equivalent can also correspond to a person's biometric parameters, such as fingerprints for example

The controller or the receiver server may provide the parameters of the cryptographic function for use in the domain.

The receiver server is arranged to store a receiver including the Alpha and Beta values of an El Gamal number corresponding to a symmetric encryption key and optionally the symmetrically encrypted form of a secret. Alternatively, the server may store only a portion of this receiver, for example the Alpha and Beta values. The described server performs a dual function, namely (i) keep encrypted user secrets, (ii) stores in encrypted form the encryption keys used on the user secrets with access. The user can decipher his secret if he knows the value of the encryption key. In the opposite case, it may require the recovery of this key from its asymmetrically encrypted form. Recovery implies that a predetermined number of administration machines, or quorum, accesses the encrypted form of the encryption key. It is the server that gives access to this encrypted form. Physically, the server may correspond to a machine dedicated to this function or a machine that also provides other functions within the infrastructure, for example one of the administration machines.

The exchange of cryptographic data between the administration machines, in particular the secret values, the secret keys or the sequestration, is done here by message exchanges which are centralized on the receiver controller. This centralized architecture of the infrastructure can be abandoned in favor of an architecture in which at least some of the messages are directly exchanged between machines in the group of administration machines. In the foregoing description, most of the messages addressed by the server to a respective administration machine contain data of interest only to other administration machines. The confidentiality of this data is ensured by the use of encryption using the public key of the administration machine interested by the data. In a variant, the server only sends to each administration machine the data of interest to this machine. Homologous administration machines have been described, that is to say which are able to function, in relation to the infrastructure, in a similar manner to one another. Homologous administration machines may differ materially from one another. In a presently preferred embodiment, each administration machine results from the execution on a central computer unit of a product of the same computer program. However, it can be envisaged that at least some of the administration machines are distinguished from each other by the product in question.

Administration or client machines in particular have been described which memorize a set of parameters relating to an encryption function for the operation of the infrastructure of a receiver. This storage is to be understood here in a broad sense, encompassing, for example, parameters integrated in the program corresponding to the product running on a central computer unit, or temporary storage, limited to the time required for encryption / decryption / recovery calculations.

The invention has been described in the form of an escrow infrastructure including in particular one or more administration machines. It can be expressed as a method of administering an escrow server.

The described infrastructure, or its variants, have the following particularities: - To recover the confidential data of the receiver, an evil person must corrupt the entire quorum of the administration machinery

- The infrastructure works without a master key. No decryption key is rebuilt. Each administration machine over-encrypts at least a portion of the escrow with a secret value of its own.

- In the event that the infrastructure is corrupt, there would be no disclosure of information concerning the administration machines or the users of these machines, nor on the secrets kept by the infrastructure in question.

- Only a subset of the admimstration machines can recover the sequestration. These machines or their users do not need to know the identity of one or the other. - The receiver server, or the controller, does not maintain any temporary or partial key useful for the recovery of a receiver. No secret key is available on the server, in memory, or in a file. The server maintains only encrypted digital data, without any element allowing their decryption. - All cryptographic operations, including the random generation of encryption parameters, are performed in a distributed manner on machines separate from the server / controller of receivers. The escrow is encrypted on the client machine.

- No infrastructure user can recover his or her secret alone, i.e. without the participation of a quorum of administration machines. This avoids any theft of secrecy by identity theft.

The client machines, the administration machines and / or the higher level administration machine can be implemented in the form of the same software, or computer program product, executed on one or more computer equipment, typically a central computer unit. The function of the resulting machine in the receiver infrastructure can be determined by user-related identification data, for example an identifier / password pair. In this case, the identification data is associated, for example in the receiver controller, with a function such as administrator or super administrator. This does not necessarily apply to the client machine, since its user, i.e. the infrastructure client does not have to be authenticated.

- The infrastructure works with a public key for encryption of receivers. No private key is associated with this public key. The recovery is based on over-encryption using a secret shared in Shamir's way.

- The messages exchanged between the machines of the infrastructure and the server / controller are encrypted. To do this, each machine initially generates a random encryption key in an asymmetric protocol. Each machine has the public key of the server / controller, in particular coded in the program whose executable product is used for the implementation of the machine.

The invention is not limited to the embodiments described above, but encompasses all the variants that may be considered by those skilled in the art. Optional, complementary or replacement characteristics of the administration machine according to the invention are set out below:

The overlay function is further arranged to, in response to a message comprising at least a portion of a digital receiver, calculate, with the resulting secret value specific to the administration machine, an encrypted version of this portion of the digital receiver. construct at least one message including this encrypted version of the digital receiver portion, and, in response to at least one message including encrypted versions of the portion of the digital receiver, computed with at least some of the resulting secret values specific to the sequestration machines. administration machine group, recover the receiver using at least some of these encrypted versions.

- At least one of the first secret values, corresponding to an integer value corresponding to a peer administration machine of the administration machine group, is included in the message or messages in encrypted form with a corresponding public key value to this counterpart administration machine.

- The overlay function is arranged to calculate, for each homologous administration machine of at least a subset of the group of administration machines, a Lagrange coefficient value from the integer values corresponding to the machine of administration and to the subassembly homologous administration machines, and to apply this Lagrange coefficient value to the encrypted version of the portion of the digital sequester calculated with the resultant secret value specific to this counterpart administration machine.

The recovery function is furthermore arranged to process the part of the digital receiver using a value corresponding to the sum of the encrypted versions of the portion of the digital receiver calculated respectively with the resulting secret values specific to the administration machines. counterparts of said subset, each time raised to a power corresponding to a respective value of Lagrange coefficient. The digital sequestration results from an El Gamal type encryption, the public key of which corresponds to a product of public keys each calculated with the aid of a corresponding integer value corresponding to the counterpart machine management machines of the group of machines. administration.

Claims

claims

An administration machine (32) for a digital receiver server (10) comprising:

at least one communication interface (340);

storing memory (320):

A list of integer values each corresponding to a respective machine (32; 34; 36) of a group of administration machines (30) of the digital receiver server (10),

A set of parameters relating to an encryption function for carrying out a sequestration;

a calculator capable of executing:

a polynomial function of degree less than or equal to the number of machines (32; 34; 36) of the group of administration machines (30), the polynomial function being specific to the administration machine,

An initialization function arranged for:

Call the polynomial function with each integer value of the list to obtain a row list of first secret values,

- constructing at least one message (ADM_SHAR) comprising, for each peer administration machine (34; 36) of the administration machine group (30), at least the first secret value corresponding to the integer value of that machine; peer administration (34; 36),

In response to at least one message (GET_DOM_CFG) comprising, for each peer administration machine (34; 36) of the administration machine group (30), at least one second secret value obtained from the call of the function polynomial of this peer administration machine (34; 36) on the integer value of the administration machine (32), constructing a resultant secret value specific to the administration machine (32) from the first and second secret values ,

A recovery function arranged to process at least a portion of a digital receiver using the resulting secret value specific to the machine (32) and resulting secret values specific to the peer administration machines (34; 36) of the administration machine group (30).

2. Machine according to claim 1, wherein the recovery function is further arranged for:

In response to a message comprising at least a portion of a digital receiver, calculating, with the resulting secret value specific to the administration machine (32), an encrypted version of this part of the digital receiver,

Constructing at least one message (ADM_SCRYPT_ESCRW) including this encrypted version of the portion of the digital receiver, and

In response to at least one message (DOM_CFG_ADM) comprising encrypted versions of the portion of the digital receiver, calculated with at least some of the resulting secret values specific to the peer administration machines (34; 36) of the administration machine group. (30), recover the receiver using at least some of those encrypted versions.

3. Machine according to one of claims 1 and 2, wherein the initialization function is arranged for:

Calculate a public key value from a constant value of the polynomial function, and

- construct at least one message (DOM_CFG_CLT) including this public key value.

4. Machine according to one of the preceding claims, wherein at least one of the first secret values, corresponding to an integer value corresponding to a homologous administration machine (34; 36) of the group of administration machines (30). ), is included in the message (s) (ADM_SHAR; GET_DOM_CFG) in an encrypted form with a public key value corresponding to that peer machine (34; 36).

5. Machine according to one of the preceding claims, wherein the recovery function is arranged to process the part of the digital receiver which corresponds to an alpha value of El Gamal type encryption.

6. Machine according to one of the preceding claims, wherein the overlap function is arranged to calculate, for each homologous administration machine (34; 36) of a subset (32; 34) at least of the group of administration machines (30), a Lagrange coefficient value from the integer values corresponding to the administration machine and the counterpart administration machines (34; 36) of the subassembly (32; 34), and for applying this Lagrange coefficient value to the encrypted version of the portion of the computed digital receiver with the resulting secret value specific to that peer machine (34; 36).

7. Machine according to claim 6, wherein the recovery function is further arranged to process the part of the digital receiver using a value corresponding to the sum of the numerical versions of the part of the digital receiver calculated respectively with the resulting secret values specific to the counterpart administration machines (34; 36) of said subset (32; 34), each raised to a power corresponding to a respective value of Lagrange coefficient.

8. Machine according to one of the preceding claims, wherein the digital sequester results from an El Gamal type of encryption, whose public key corresponds to a product of public keys each calculated using a corresponding respective integer value. to the counterpart administration machines (34; 36) of the administration machine group (30).

9. Machine according to one of the preceding claims, comprising a random number generation function, wherein the initialization function is arranged to repeatedly call the random number generation function to establish at least some of the coefficients of the polynomial function. , before the call of the latter.

10. Machine according to one of the preceding claims, wherein the polynomial function has a degree lower than the number of machines (32; 34; 36) of the group of administration machines (30).

A digital escrow exchange and processing infrastructure comprising an escrow server (10) and a group of administration machines (30) comprising at least two management machines according to one of the preceding claims for the server sequestra, the two administration machines (32; 34; 36) being homologous to one another.

The infrastructure of claim 11, wherein a public key value for the digital receivers deposit results from public key values each corresponding to an integer value corresponding to a respective administration machine (32; 34; 36) of the group. administration machines (30).

13. Infrastructure according to one of claims 1 1 and 12 comprising a client machine (40) comprising at least one communication interface (440), the memory (420) storing at least one secret digital data, and a computer capable of executing an encryption function arranged to randomly generate a local key and to symmetrically encrypt the secret digital data using the local key.

The infrastructure of claim 13, wherein the client machine (40) stores a set of parameters relating to an encryption algorithm to perform a sequester and wherein the encryption function of the client machine (40) is arranged to construct a message comprising the encrypted local key in accordance with said set of parameters.

15. A method of administering a digital receiver server comprising:

- on each machine (32; 34; 36) of a group of administration machines (30), to call a respective polynomial function of degree less than or equal to the number of machines of the administration machine group (30) with each value of a list of integer values each corresponding to a respective machine (32; 34; 36) of the administration machine group (30) to obtain a list of values secret,

- on each machine (32; 34; 36) of the administration machine group (30), constructing at least one message including at least one secret value corresponding to the integer value of a machine (32; 34; 36) d administration,

- on each machine (32; 34; 36) of the group of administration machines (30), constructing a resultant secret value specific to this machine (32; 34; 36) from the calculated secret values by the other machines ( 32; 34; 36) of the administration machine group (30) for the integer value corresponding to the administration machine (32; 34; 36),

~ on at least some of the machines (32; 34; 36) of the administration machine group (30). decrypting a digital sequester using this resulting secret value and the resulting secret values of peer administration machines (32; 34; 36).

16. Computer program product capable of cooperating with a central computer unit to constitute a delivery machine according to one of claims 1 to 10.