EP3360034A1 - Procédé et système de sauvegarde répartie dynamique - Google Patents

Procédé et système de sauvegarde répartie dynamique

Info

Publication number
EP3360034A1
EP3360034A1 EP16778810.8A EP16778810A EP3360034A1 EP 3360034 A1 EP3360034 A1 EP 3360034A1 EP 16778810 A EP16778810 A EP 16778810A EP 3360034 A1 EP3360034 A1 EP 3360034A1
Authority
EP
European Patent Office
Prior art keywords
data
server
storage
blocks
servers
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP16778810.8A
Other languages
German (de)
English (en)
Inventor
Francis Pinault
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ROBERTO GIORI CO Ltd
Original Assignee
ROBERTO GIORI CO Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ROBERTO GIORI CO Ltd filed Critical ROBERTO GIORI CO Ltd
Publication of EP3360034A1 publication Critical patent/EP3360034A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0646—Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
    • G06F3/065—Replication mechanisms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1464—Management of the backup or restore process for networked environments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0614—Improving the reliability of storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/062—Securing storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0629—Configuration or reconfiguration of storage systems
    • G06F3/0631—Configuration or reconfiguration of storage systems by allocating resources to storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/064—Management of blocks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]

Definitions

  • the present invention relates to the computer field, and more particularly to a system and method for storing data associated with a user in a computer network comprising a plurality of storage servers. In other words, it is distributed or distributed storage or backup of data over a network.
  • An object of the present invention is thus to improve the security of a personal data during its storage distributed over a plurality of servers.
  • a first aspect of the present invention relates to a method of storing data associated with a user in a computer network comprising a plurality of storage servers, the method comprising the following steps:
  • the determination of the respective server is a function of a current time instant.
  • the determination of the respective server as a function of a current time instant can be carried out for each block of data, so that the storage server used to store each respective block of data varies periodically in time.
  • the invention relates, according to a second aspect, to a system (which can be integrated into a simple user terminal) for storing data associated with a user in a computer network comprising a plurality of storage servers, the system comprising at least one microprocessor configured to execute, in a system execution environment, the following steps:
  • the determination of the respective server is a function of a current time instant.
  • the method or system according to the invention thus makes it possible to increase the security of personal data, for example confidential data, encrypted or not, or personal programs.
  • the storage server used for storing a particular data block may vary in time, i.e., it is determined according to one or more dynamic distribution laws. The task of locating and retrieving the blocks of data is thus greatly complexified for a malicious person.
  • a new respective storage server is determined, at each new time instant, for each data block, so as to store the data block at a new storage server at each new time instant.
  • This provision specifies the dependence, at the time, of the determination of the server to use.
  • the method further comprises the following steps in response to a request for access to the data associated with the user:
  • This arrangement makes it possible to process the storage discontinuity of the data blocks during a change of time instant. Indeed, depending on whether the request for access to the data received in the vicinity of this change in time is processed more or less quickly, the data blocks may have been moved from one server to another, according to the new distributed storage scheme applicable at time T + 1.
  • the data is reconstituted using the scheme applicable at time T, and if this data is erroneous (lack of coherence, error on an identification criterion such as a user identity in the reconstituted data, etc.), a reconstruction is performed using the scheme applicable at time T + 1.
  • the determination of the respective server is further dependent on a private binary key associated with the user. It can be any cryptographic key associated with the user, which is used in its binary form.
  • This arrangement makes it possible to encrypt the distribution scheme of the storage servers according to each user, and thus makes it more difficult for an attacker to carry out the operations to be implemented to identify the storage location of each of the data blocks.
  • the step of determining the storage servers includes a step of applying the binary key as a mask to a first server distribution table to identify storage servers to be used for a portion of the data blocks. respective server distribution table associating a server with each block of data.
  • the step of determining the storage servers further comprises a step of applying a complementary bit key as a mask to a second server distribution table to identify storage servers to be used for the other blocks. respective data.
  • said second server distribution table can associate a server with each data block and can be formed from the same elementary table as the first server distribution table.
  • Distribution tables are generated by repeating (and concatenating) the elementary table, the second distribution table being the continuity of the first distribution table with regard to the repetition of the elementary table.
  • the mask formed by the binary key is shifted relative to the first or second distribution table of the servers by a number of positions depending on the current time instant, before being applied to the first or second second server distribution table.
  • the current time instant is thus used as disturbing reference in the application of the mask (user's binary key), increasing the security of the distributed storage of the personal data.
  • the mask is formed of a repetition (possibly partial) of the binary key so as to reach the size of the first or second distribution table servers, that is to say the number blocks of data to store.
  • the method further comprises a step of determining a server distribution basic table by duplication of which the server distribution table or tables are obtained,
  • the step of determining the elementary table is a function of a performance index associated with each storage server and a confidence index associated with the geographical location of each storage server.
  • a strategy for prioritizing the use of certain servers can be implemented, for example to favor efficient servers and / or located in areas with low geographical risk (eg seismic risk or geopolitical risk).
  • the length of the elementary table is a function of the sum of weights associated with the storage servers, the weight associated with a storage server being determined from the performance and trust indices of the storage server considered.
  • the step of determining the elementary table comprises the following steps:
  • the elementary table thus makes it possible to obtain a complex and interlaced distribution of the servers, in proportions equal to their respective weights, that is to say to their confidence and performance indices. Also, such an elementary table is complex to recreate for a malicious person, while ensuring equity between the servers given their characteristics.
  • the step of dividing the data comprises the following steps:
  • FIG. 1 illustrates an example of a hardware architecture in which the present invention can be implemented, notably in the form of computer programs;
  • FIG. 2 illustrates an example of a computer network comprising a plurality of storage servers in which the invention can be implemented
  • FIG. 3 illustrates, using a flow chart, the general steps of a method of distributed backup of a piece of data according to embodiments of the invention
  • FIG. 4 illustrates, in the form of a flow chart, steps for the determination of storage servers of the method of FIG. 3;
  • FIG. 5 illustrates an example of implementation of the steps of FIG. 4
  • FIG. 6 illustrates, in the form of a flow chart, steps for determining an elementary table of the method of FIG. 3;
  • FIG. 7 illustrates an example of implementation of the steps of FIG. 6.
  • FIG. 8 illustrates, in the form of a flow chart, an example of general steps of a method of accessing a data item saved according to the method of FIG. 3.
  • FIG. 1 illustrates an example of a hardware architecture in which the present invention may be implemented, notably in the form of computer programs.
  • this hardware architecture can be part of a device or user terminal, such as an onboard computer or not, laptop, mobile terminal, a mobile tablet, or from a server offering services. distributed backup of data and access to this data.
  • the hardware architecture 10 comprises in particular a communication bus 100 to which are connected:
  • CPU Central Processing Unit
  • non-volatile memory 120 for example ROM (for Read Only Memory), EEPROM (for Electrically Erasable Read Only Memory) or Flash, for storing computer programs for the implementation of the invention and possible parameters used for this one;
  • a random access memory 130 or cache memory or volatile memory for example RAM (for Random Access Memory), configured to store the executable code of methods according to embodiments of the invention, and to store registers adapted to memorize, at least temporarily, variables and parameters necessary for the implementation of the invention according to embodiments;
  • an interface 140 of input / output I / O for Input / Outpuf
  • I / O for Input / Outpuf
  • a screen for example a screen, a keyboard, a mouse or other pointing device such as a touch screen or a remote control enabling a user to interact with the system via a graphical interface
  • a communication interface COM 150 adapted to exchange data for example with storage servers via a computer or communication network.
  • the instruction codes of the program stored in non-volatile memory 120 are loaded into RAM 130 for execution by the processing unit CPU 1 10.
  • the non-volatile memory 120 also stores confidential information of the user, for example a private key in binary form.
  • confidential information of the user for example a private key in binary form.
  • SE Secure Element
  • HSM Hardware Security Module
  • the present invention is part of the backup (or storage) distributed data on storage servers of a communication network, typically an extended computer network, such as the Internet.
  • FIG. 2 illustrates an example of a computer network 20 comprising a plurality of M storage servers S x .
  • M storage servers
  • Si storage servers
  • S 2 storage servers
  • S 3 storage servers
  • S 4 storage servers
  • the servers are synchronized on the same reference clock.
  • a user terminal 21, presenting the hardware architecture of FIG. 1, enables a user to request the safeguarding of personal data, sometimes confidential, encrypted or not, and access this personal data once it stored distributed in the network 20.
  • the user terminal 21 can implement the present invention to manage the distributed storage of such personal data and its subsequent access.
  • the user terminal 21 can access a distributed data backup service and subsequent access to this data, proposed by a server S of the network 20.
  • all the parameters (indices of confidence and performance, user keys, etc.) discussed subsequently can be stored on such a server S, and be retrieved, if necessary, by the user terminals.
  • the general principles of distributed data backup include dividing the data to obtain a plurality of data blocks; determining, for each data block, a respective one of the plurality of storage servers; and storing each block of data at the respective storage server.
  • the present invention provides for increasing the protection, and therefore the security, of the data thus stored according to these solutions, by making a determination of each respective server according to a current time instant, that is to say say according to time.
  • FIG. 3 illustrates, using a flow chart, general steps of an exemplary method according to embodiments of the invention. These steps are implemented in a system according to the invention, which may be the user terminal 21 or the server S of FIG.
  • step 30 a request for storing a personal data DATA is received from the user (via the user terminal 21 if necessary).
  • This data is personal in that it is attached to a user or group of users. It may consist of a plurality of elementary data, for example confidential. Typically, the personal data is encrypted.
  • the personal data DATA forms a file of size LENGTH.
  • step 31 the DATA data is divided to obtain a plurality of data blocks.
  • This step is broken down into three sub-steps: dividing the data DATA into elementary blocks of data DD N ; duplicate the elementary blocks into duplicate DVD blocks to provide a sufficient level of redundancy; and interleaving the duplicate blocks to improve the reliability of the storage mechanism.
  • the data DATA can be divided into a plurality of blocks of the same size Lvar, this block size being variable in that it can depend on one or more parameters, for example chosen from the following parameters: the size LENGTH of the DATA data, the user, the operator of the distributed backup and data access service, etc.
  • the number of blocks obtained is then:
  • Nb T LENGTH / Lvar 1.
  • variable lengths further improves the security of the data to be backed up.
  • the variability of the size of the block as a function of the LENGTH size of the data DATA can follow one of the following formulas:
  • Nbmax is a predefined parameter and Lmin is a predefined minimum integer size.
  • Nb of data blocks obtained tends to Nbmax plus the data DATA is large;
  • Nb of data blocks obtained is min (rV (LENGTH) 1, Nbmax), and therefore tends to Nbmax plus the DATA data is large.
  • the variability of the block size according to the user may consist of using a unique identifier ID of the user (for example a social security number, a passport number or identity card, etc.) that one normalizes in a predefined interval [0; Nbmax], to calculate this length:
  • a unique identifier ID of the user for example a social security number, a passport number or identity card, etc.
  • Nb ID - Nbmax.LlD / NbmaxJ, where L J is the function returning the integer part by default, and thus:
  • an integer of the interval [0; Nbmax] can be randomly assigned to each user and used to define the value Nb.
  • the variability of the size of the block according to an operator may consist in providing different levels (value Nb) of dividing the data according to subscription options or performance.
  • Value Nb the number of bits assigned to the data according to subscription options or performance.
  • the use of a division into one large number of blocks is safer, but requires more calculations as described later. Also, such a level of division can be reserved for premium subscribers.
  • these blocks of data can be duplicated to provide data redundancy, making the reconstitution of DATA data more reliable.
  • the redundancy law can be fixed, defining the number of duplications RD by a fixed number, for example 3.
  • the applied redundancy law may be variable in that it may depend on one or more parameters, for example according to CS confidence indices, assigned to the M servers S ,.
  • the whole number of duplications can be:
  • Nb ' RD.Nb D'-iD blocks are obtained from n elementary blocks DD N.
  • the m DVD blocks can be interleaved to improve the reliability of the backup system with regard to errors occurring in the processing of DVD blocks.
  • step 32 a basic table of distribution servers S , denoted TABLE E, is obtained in step 32 .
  • the elementary table TABLE E consists of an ordered plurality of L TAB LE entries, each identifying one of the servers S ,.
  • This table elementary TABLE E can be a predefined table recovered in non-volatile memory of the system. As a variant, it can be determined according to the method of FIG. 6 described below in order, in particular, to favor trusted and / or efficient servers.
  • a private key of the user is obtained in step 33. It is preferably a cryptographic key obtained from an elliptic curve.
  • This key, noted K, is securely stored in the system embodying the invention, for example using a secure element type smart card.
  • the private key K is used to determine the servers to be used to store each D 'block.
  • a respective storage server is determined, for each data block D ', among the plurality of storage servers, according to a current time instant Tu.
  • the current time instant is defined with an accuracy directly dependent on a chosen time unit.
  • the time instant can be defined by the current time if a time unit of the order of the hour is chosen.
  • a time unit of the agenda can be used, so as to modify the storage location of the blocks D ', thirty or thirty-one times a month.
  • Step 34 an embodiment of which is described in greater detail hereinafter with reference to FIG. 4, thus makes it possible to identify a storage server for each data block D ', resulting from the division of the initial data. DATA, and this according to the current time instant Tu.
  • step 35 the proper storage of each block of data at the respective storage server and determined.
  • Conventional secure communication techniques with the storage servers S are preferably implemented.
  • step 36 the system waits for the next time instant, for example the beginning of the next hour or the next day.
  • steps 31 to 35 are reiterated to determine a new respective storage server for each data block D'i, and thus store the data block at the new storage server during this new time. time instant.
  • the data blocks are erased from the old storage servers on which they were stored during the old time instant just ended.
  • steps 31, 32 and 33 may simply consist in recovering the result of a previous execution of these steps, when these do not involve the current time instant as a parameter (for example the elementary table distribution can change over time).
  • Step 35 is itself dependent on the current time instant, ensuring that the storage servers identified for each block of data to backup evolve over time.
  • FIG. 4 illustrates an embodiment of the step 34 of determining the storage servers for saving the data blocks D 'at the current time instant Tu. This determination takes into account, besides the current time instant Tu, the private key K, the elementary distribution table TABLE E and the size LENGTH of the data DATA to be saved.
  • a first step 40 consists in obtaining a first distribution table TABLE1 from the elementary table TABLE E , by duplication of the latter in order to obtain a table TABLE1 of length equal to Nb '(that is to say a table TABLE1 of the same length as the number of data blocks D ', to be saved).
  • the next step 41 is to obtain a MASK bit mask from the private key K and the current time instant Tu. Since this mask MASK will be applied to the first distribution table TABLE1, it has the same size Nb 'as this one.
  • the private key K is used in its binary form (continuation of and ⁇ '), here a 32-bit key. Then, the mask MASK is formed by the repetition of the binary key K, until reaching the size Nb 'of the first server distribution table. In the figure, the nine bolded bits are from a K key repetition.
  • step 42 the mask MASK is applied to the first distribution table TABLE1 servers to identify storage servers to use for a portion of the respective data blocks D ',. According to embodiments, it is at this stage that the current time instant Tu is taken into account to disturb the identification of the storage servers to be used.
  • it may be provided to shift the mask MASK relative to the beginning of the first distribution table servers TABLE1 a number of positions according to the current time instant Tu, before being applied to this server distribution table .
  • the mask MASK is shifted from Tu positions before application to the TABLE1 (offset indicated by K "Tu); and the result RESULT1 of this masking operation (those of the mask identify the servers of the table TABLE1 to keep) identifies only a portion of the storage servers to use.
  • step 43 a second server distribution table is obtained
  • the second distribution table can simply be the continuity of the first distribution table with regard to the repetition of the elementary table, as illustrated in FIG.
  • step 44 a second MASK2 mask formed, for example, of the binary (bit-to-bit) complement of the first mask MASK is obtained.
  • the second mask also has a size equal to Nb '.
  • step 45 the second mask MASK2 is applied to the second distribution table TABLE2 in the same way as in step 42, so as to identify the storage servers to be used for the other data blocks D ', (those for which step 42 could not identify such servers). Indeed, the use of the complementary of the first mask ensures that ultimately each of the blocks D ', is associated with a respective storage server.
  • the process of FIG. 4 ends at step 46 by merging the results RESULT1 and RESULT2 of the masking operations, so as to obtain a RESULT grid for locating the Nb 'storage servers.
  • This grid thus identifies the storage server S to be used for each of the Nb 'data blocks D'.
  • the step of determining the elementary table is a function of a performance index associated with each storage server and a confidence index associated with the geographical location of each storage server.
  • Each server S is associated with a geographical location
  • Two servers can have the same location LS j , hence N ⁇ M.
  • a confidence index CS is associated with each location LS j .
  • This confidence index is representative of a local stability with regard to the accessibility of servers located there.
  • 0 low confidence
  • other ranges of values are possible.
  • Each storage server S is thus indirectly associated with a CS index of confidence, linked to its geographical location.
  • a performance index PS is associated with each storage server S, depending for example on the performance of access to this server and / or the performance of the server itself.
  • server performance There are a large number of techniques to scale server performance, including storage performance, memory performance, processor performance, network performance, and process performance. Also they will not be described in detail here.
  • PS performance index can vary over time:
  • step 32 f (Tu), in which case for example step 32 is re-executed entirely at each new time instant (after step 36).
  • the step of determining the elementary distribution table of TABLE E servers begins with a step 60 of obtaining a weight WS, associated with each storage server S 1.
  • This weight can in particular be representative of the associated confidence and performance.
  • the weight WS, associated with a storage server S can be determined from the performance and confidence indices of the storage server in question, for example by combining the indices CS, and PS, associated with S ,.
  • WS (CSi.PSi) / (CS max .PS max) for a weight ranging from 0 to 1.
  • a repetition frequency F x is determined for each storage server according to the weight WS X associated with the storage server S x considered.
  • F x is representative of a frequency of occurrence of the storage server S x in the elementary distribution table TABLE E , when it will be necessary to create it.
  • 1 / F X L (L T ABLE / WS X ) _
  • TABLE table E is formed by repeating WS x times each server S x with a frequency F x .
  • the first position in the elementary table TABLE E therefore informs the server Si.
  • the position of the input entered is stored in a variable 'z'.
  • a counter of the number of NBOCC occurrences is initialized to 1.
  • step 66 provides for populating the next occurrence of the server S x in the TABLE E.
  • the method then loops back to step 65 making it possible to fill all the occurrences of the server S x in the elementary table TABLE E.
  • the elementary table TABLE E is filled by repeating, for each server S, iteratively considered and according to its determined repetition frequency (F,), an occurrence of the server within the elementary table until reaching a number of repetition NBOCC equal to the weight WS, associated with the considered server.
  • TABLE E (9) is already filled in (for the server S 2 )
  • TABLE E (10) 3.
  • TABLE E (12) 3
  • TABLE E (14) 3.
  • TABLE E (16) 3
  • TABLE E (18) 3.
  • this algorithm includes a mechanism for managing the risks of ambiguity relating to the passage of a message. transition from one time instant to the next, upon receipt of a request to access the data DATA.
  • the algorithm starts at step 80 by receiving a request to access the data DATA by a user U. If necessary, the division, redundancy and interleaving mechanisms (step 31) of the data DATA are set to particularly for the purpose of knowing the number Nb 'of data blocks D' to be recovered.
  • a variable ⁇ ' is initialized to 0, to serve as a mechanism for managing temporal transitions.
  • the temporal instant Tu of reception of the request is memorized.
  • the following steps identify the storage servers storing, at this time, the data blocks forming the data DATA to access.
  • step 81 the elementary table TABLE E is obtained in a manner similar to step 32.
  • step 82 the private key K of the user is obtained in a manner similar to step 33.
  • step 83 the data block storage servers D 'are determined similarly to step 34, for the time slot Tu.
  • step 84 the data blocks D 'are recovered from these determined storage servers by conventional mechanisms (for example, requests secure). Then, during step 85, the data DATA is reformed from the blocks D ', thus recovered.
  • the next step, 86 is to check the consistency of the result of step 85.
  • the verification may relate to the identification of the user U which must be identical to that indicated in the data reformed DATA (for example if the DATA data is encrypted, the use of a public key of the user U can verify the authenticity).
  • checksum verification may be carried out (for example if the end of the data DATA consists of a checksum of the rest of the data).
  • Other checks can be carried out such as the dating of the last storage stored compared to a traceability stored operations performed for this user.
  • loop 1 (test 88)
  • an error message is returned to the user in response to his request (step 90).
  • the reformed data is returned to the user in response to his request (step 91).

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Hardware Redundancy (AREA)

Abstract

L'invention concerne le domaine informatique, et notamment le stockage réparti d'une donnée sur plusieurs serveurs de stockage. Un procédé de sauvegarde répartie comprend les étapes suivantes : diviser la donnée pour obtenir des blocs de données; déterminer, pour chaque bloc, un serveur respectif parmi la pluralité de serveurs de stockage; et mémoriser chaque bloc au niveau du serveur déterminé. Selon l'invention, la détermination du serveur respectif est fonction d'un instant temporel courant. Elle peut être, en outre, fonction d'une clé privée de l'utilisateur. La clé est utilisée pour former un masque. Ce dernier est décalé en fonction de l'instant temporel courant. Puis le masque décalé et son complémentaire sont appliqués respectivement à deux tables de répartition de serveurs afin d'identifier les serveurs à utiliser pour chacun des blocs de données. Les blocs peuvent être changés de serveurs à chaque nouvel instant temporel.

Description

PROCEDE ET SYSTEME DE SAUVEGARDE REPARTIE DYNAMIQUE
DOMAINE DE L'INVENTION
La présente invention concerne le domaine informatique, et plus particulièrement un système et un procédé de stockage d'une donnée associée à un utilisateur dans un réseau informatique comprenant une pluralité de serveurs de stockage. En d'autres termes, il s'agit d'un stockage ou d'une sauvegarde distribuée ou répartie de données sur un réseau.
CONTEXTE DE L'INVENTION
L'idée d'utiliser un réseau informatique étendu, tel l'Internet, pour sécuriser le stockage de données n'est pas nouvelle. Dans l'article journalistique « Utiliser Internet comme système de stockage réparti » (http://www.lemondeinformatique.fr/ actualites/lire-utiliser-internet-comme-systeme-de-stockage-reparti-22932.html), il était déjà indiqué que l'idée, aussi simple qu'ambitieuse d'une certaine société, consiste à découper en tranches un volume de données à archiver et de répartir leur stockage sur l'ensemble des ressources disponibles sur Internet. Cette approche, baptisée DSG (pour « dispersed storage grid ») repose sur un algorithme mis au point au MIT à la fin des années 70. Il permet de découper les données en tranche, et confère à chacune d'entre elle la possibilité de régénérer des segments perdus. La fiabilité du système lui conférerait une disponibilité record : moins d'une heure d'indisponibilité sur un million d'années.
Aujourd'hui, le stockage ou la sauvegarde de données sur le nuage (ou
« Cloud » selon la terminologie anglo-saxonne) est largement répandu.
Pour autant, malgré de nombreuses techniques de chiffrement des données, le niveau de sécurité, en terme de confidentialité des données propres à un utilisateur, proposé par les solutions existantes peut s'avérer insatisfaisant. En particulier, une personne malveillante peut tenter de récupérer, sur les serveurs de stockage utilisés, les blocs de données formant une donnée secrète initiale, sans que des contremesures efficaces soient prises notamment parce que la récursivité d'accès à cette donnée peut permettre avec le temps et des dispositifs espions sophistiqués de déjouer les chiffrements de données. Le document US 2007/073990 décrit un stockage distribué de blocs formant un fichier, sur des serveurs. Une liste de serveurs est déterminée à partir d'une graine associée au fichier. Lorsqu'un serveur est ajouté ou retiré, une nouvelle affectation des blocs aux serveurs disponibles est effectuée, en limitant une redistribution des blocs aux seuls blocs concernés par le serveur ajouté ou retiré selon cette nouvelle affectation.
RESUME DE L'INVENTION
Un objectif de la présente invention est ainsi d'améliorer la sécurisation d'une donnée personnelle lors de son stockage réparti sur une pluralité de serveurs.
Dans ce dessein, un premier aspect de la présente invention concerne un procédé de stockage d'une donnée associée à un utilisateur dans un réseau informatique comprenant une pluralité de serveurs de stockage, le procédé comprenant les étapes suivantes :
diviser la donnée pour obtenir une pluralité de blocs de données ; déterminer, pour chaque bloc de données, un serveur respectif parmi la pluralité de serveurs de stockage ; et
mémoriser chaque bloc de données au niveau du serveur de stockage respectif,
caractérisé en ce que la détermination du serveur respectif est fonction d'un instant temporel courant.
Notamment, la détermination du serveur respectif en fonction d'un instant temporel courant peut être réalisée pour chaque bloc de données, de sorte que le serveur de stockage utilisé pour mémoriser chaque bloc respectif de données varie périodiquement dans le temps.
Corrélativement, l'invention concerne, selon un deuxième aspect, un système (qui peut être intégré dans un simple terminal utilisateur) de stockage d'une donnée associée à un utilisateur dans un réseau informatique comprenant une pluralité de serveurs de stockage, le système comprenant au moins un microprocesseur configuré pour exécuter, dans un environnement d'exécution du système, les étapes suivantes :
diviser la donnée pour obtenir une pluralité de blocs de données ; déterminer, pour chaque bloc de données, un serveur respectif parmi la pluralité de serveurs de stockage ; et mémoriser chaque bloc de données au niveau du serveur de stockage respectif,
caractérisé en ce que la détermination du serveur respectif est fonction d'un instant temporel courant.
Le procédé ou le système selon l'invention permet ainsi d'accroître la sécurisation de données personnelles, par exemple une donnée confidentielle, chiffrée ou non, ou des programmes personnels.
Cette sécurisation accrue est obtenue par la dépendance au temps du serveur de stockage utilisé pour stocker chaque bloc de donnée résultant de la division de la donnée personnelle. Il en résulte que le serveur de stockage utilisé pour mémoriser un bloc de données particulier peut varier dans le temps, c'est-à-dire qu'il est déterminé selon une ou plusieurs lois de répartition dynamique. La tâche de localisation et de récupération des blocs de données est ainsi largement complexifiée pour une personne malintentionnée.
Des caractéristiques optionnelles du procédé selon l'invention sont par ailleurs définies dans les revendications dépendantes. Le système selon l'invention peut également comprendre des moyens configurés pour mettre en œuvre ces caractéristiques optionnelles.
Dans un mode de réalisation, un nouveau serveur de stockage respectif est déterminé, à chaque nouvel instant temporel, pour chaque bloc de données, de sorte à mémoriser le bloc de données au niveau d'un nouveau serveur de stockage à chaque nouvel instant temporel.
Cette disposition précise la dépendance, au temps, de la détermination du serveur à utiliser.
Dans un mode de réalisation particulier, le procédé comprend, en outre, les étapes suivantes en réponse à une requête d'accès à la donnée associée à l'utilisateur :
identifier des serveurs de stockage mémorisant, à un instant temporel donné, les blocs de données ;
récupérer les blocs de données depuis les serveurs de stockage respectifs ainsi identifiés, pour reformer ladite donnée ; et
en cas de détection d'une erreur sur la donnée reformée à partir des blocs de données récupérés, identifier de nouveaux serveurs de stockage mémorisant, à un instant temporel suivant (celle suivant immédiatement l'instant temporel donné), les blocs de données, puis récupérer les blocs de données depuis les nouveaux serveurs de stockage respectifs ainsi identifiés, pour reformer ladite donnée.
Cette disposition permet de traiter la discontinuité de stockage des blocs de données lors d'un changement d'instant temporel. En effet, selon que la requête d'accès à la donnée reçue aux environs de ce changement d'instant temporel soit traitée plus ou moins vite, les blocs de données peuvent avoir été déplacés d'un serveur à l'autre, selon le nouveau schéma de stockage réparti applicable à l'instant T+1 .
Ainsi, la donnée est reconstituée en utilisant le schéma applicable à l'instant T, et si cette donnée est erronée (défaut de cohérence, erreur sur un critère d'identification comme par exemple une identité utilisateur dans la donnée reconstituée, etc.), on procède à une reconstitution en utilisant le schéma applicable à l'instant T+1.
Dans un autre mode de réalisation, la détermination du serveur respectif est en outre fonction d'une clé binaire privée associée à l'utilisateur. Il peut s'agir de n'importe quelle clé cryptographique associée à l'utilisateur, qui est utilisée dans sa forme binaire.
Cette disposition permet de crypter le schéma de répartition des serveurs de stockage en fonction de chaque utilisateur, et ainsi complexifie, pour une personne malveillante, les opérations à mettre en œuvre pour identifier la localisation de stockage de chacun des blocs de données.
Selon un mode de réalisation particulier, l'étape de détermination des serveurs de stockage comprend une étape consistant à appliquer la clé binaire comme masque à une première table de répartition des serveurs pour identifier des serveurs de stockage à utiliser pour une partie des blocs de données respectifs, ladite première table de répartition des serveurs associant un serveur à chaque bloc de données.
La connaissance de la clé devient ainsi indispensable à l'identification de chaque serveur de stockage utilisé.
Selon une caractéristique particulière, l'étape de détermination des serveurs de stockage comprend en outre une étape consistant à appliquer un complémentaire de la clé binaire comme masque à une deuxième table de répartition des serveurs pour identifier des serveurs de stockage à utiliser pour les autres blocs de données respectifs. Notamment, ladite deuxième table de répartition des serveurs peut associer un serveur à chaque bloc de données et peut être formée à partir d'une même table élémentaire que la première table de répartition des serveurs. Par exemple, les tables de répartition sont générées par répétition (et concaténation) de la table élémentaire, la deuxième table de répartition étant la continuité de la première table de répartition eu égard à la répétition de la table élémentaire.
Ces dispositions permettent de déterminer les serveurs de stockage à utiliser de façon très sécurisée.
Selon un mode de réalisation particulier, le masque formé de la clé binaire est décalé relativement à la première ou deuxième table de répartition des serveurs d'un nombre de positions fonction de l'instant temporel courant, avant d'être appliqué à la première ou deuxième table de répartition des serveurs. L'instant temporel courant est ainsi utilisé comme référence perturbatrice dans l'application du masque (clé binaire de l'utilisateur), augmentant la sécurisation du stockage réparti de la donnée personnelle.
Selon un autre mode de réalisation particulier, le masque est formé d'une répétition (éventuellement partielle) de la clé binaire de sorte à atteindre la taille de la première ou deuxième table de répartition des serveurs, c'est-à-dire le nombre de blocs de données à stocker.
Une personne malveillante devra donc connaître la clé de l'utilisateur pour tenter de localiser les serveurs où sont stockés chacun des blocs de données.
Selon encore un autre mode de réalisation particulier, le procédé comprend en outre une étape de détermination d'une table élémentaire de répartition des serveurs par duplication de laquelle la ou les tables de répartition des serveurs sont obtenues,
procédé dans lequel l'étape de détermination de la table élémentaire est fonction d'un indice de performance associé à chaque serveur de stockage et d'un indice de confiance associé à la localisation géographique de chaque serveur de stockage.
Ainsi, une stratégie de priorisation de l'utilisation de certains serveurs peut être mise en œuvre, afin par exemple de favoriser les serveurs performants et/ou localisés dans des zones à faible risque géographique (par exemple risque sismique ou risque géopolitique).
Selon une caractéristique particulière, la longueur de la table élémentaire est fonction de la somme de poids associés aux serveurs de stockage, le poids associé à un serveur de stockage étant déterminé à partir des indices de performance et de confiance du serveur de stockage considéré. Selon une autre caractéristique particulière, l'étape de détermination de la table élémentaire comprend les étapes suivantes :
déterminer, pour chaque serveur de stockage, une fréquence de répétition d'une occurrence (par exemple via un identifiant) du serveur de stockage dans la table élémentaire en fonction du poids associé audit serveur de stockage considéré ;
remplir la table élémentaire en répétant, pour chaque serveur itérativement considéré et en fonction de sa fréquence de répétition déterminée, une occurrence du serveur au sein de la table élémentaire jusqu'à atteindre un nombre de répétition égal au poids associé au serveur considéré.
La table élémentaire permet ainsi d'obtenir une répartition complexe et entrelacée des serveurs, dans des proportions égales à leurs poids respectifs, c'est-à- dire à leurs indices de confiance et de performance. Aussi, une telle table élémentaire est complexe à recréer pour une personne malveillante, tout en garantissant une équité entre les serveurs compte tenu de leurs caractéristiques.
A noter que lors de la formation de la table élémentaire, si une position
(dans la table élémentaire) est déjà occupée par une occurrence d'un serveur de stockage lors d'une nouvelle répétition d'un autre serveur de stockage, on peut décider de décaler l'occurrence de cet autre serveur de stockage à la prochaine position libre, puis de recommencer la répétition à partir de cette nouvelle position. Pour atteindre le nombre de répétitions/occurrences souhaité alors que la fin de la table élémentaire est atteinte, il peut être prévu de poursuivre la répétition en bouclant à nouveau sur le début de la table élémentaire. Par exemple, si la longueur de la table élémentaire équivaut la somme des poids, il est nécessaire, pour remplir toute la table élémentaire, que chacun des serveurs soit présent dans un nombre d'occurrences égal à son propre poids.
Dans un mode de réalisation de l'invention, l'étape de division de la donnée comprend les étapes suivantes :
diviser la donnée en des blocs élémentaires de données ;
dupliquer les blocs élémentaires en des blocs dupliqués ;
entrelacer les blocs dupliqués de sorte à obtenir ladite pluralité de blocs de données.
Cette disposition permet d'introduire une redondance des blocs élémentaires formant la donnée personnelle initiale, et par voie de conséquence permet d'améliorer la fiabilité de stockage dans le système. BREVE PRESENTATION DES FIGURES
D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les dessins ci-joints, dans lesquels :
- la figure 1 illustre un exemple d'architecture matérielle dans laquelle la présente invention peut être mise en œuvre, notamment sous forme de programmes informatiques ;
- la figure 2 illustre un exemple de réseau informatique comprenant une pluralité de serveurs de stockage dans lequel l'invention peut être mise en œuvre ;
- la figure 3 illustre, à l'aide d'un ordinogramme, des étapes générales d'un procédé de sauvegarde répartie d'une donnée selon des modes de réalisation de l'invention ;
- la figure 4 illustre, sous forme d'ordinogramme, des étapes pour la détermination de serveurs de stockage du procédé de la figure 3 ;
- la figure 5 illustre un exemple de mise en œuvre des étapes de la figure 4 ;
- la figure 6 illustre, sous forme d'ordinogramme, des étapes pour la détermination d'une table élémentaire du procédé de la figure 3 ;
- la figure 7 illustre un exemple de mise en œuvre des étapes de la figure 6 ; et
- la figure 8 illustre, sous forme d'ordinogramme, un exemple d'étapes générales d'un procédé d'accès à une donnée sauvegardée selon le procédé de la figure 3.
DESCRIPTION DETAILLEE DE MODES DE REALISATION DE L'INVENTION La figure 1 illustre un exemple d'architecture matérielle dans laquelle la présente invention peut être mise en œuvre, notamment sous forme de programmes informatiques. A titre d'exemple, cette architecture matérielle peut faire partie d'un dispositif ou terminal utilisateur, tel qu'un ordinateur embarqué ou non, ordinateur portable, terminal mobile, une tablette mobile, ou faire partir d'un serveur offrant des services de sauvegarde répartie de données et d'accès à ces données.
L'architecture matérielle 10 comprend notamment un bus de communication 100 auquel sont reliées :
- une unité de traitement 1 10, notée CPU (pour Central Processing Unit), pouvant comporter un ou plusieurs processeurs ; - au moins une mémoire non volatile 120 par exemple ROM (pour Read Only Memory), EEPROM (pour Electrically Erasable Read Only Memory) ou encore Flash, pour stocker des programmes informatiques pour la mise en œuvre de l'invention et d'éventuels paramètres utilisé pour celle-ci ;
- une mémoire vive 130 ou mémoire cache ou mémoire volatile par exemple RAM (pour Random Access Memory), configurée pour stocker le code exécutable de procédés selon des modes de réalisation de l'invention, et pour stocker des registres adaptés à mémoriser, au moins temporairement, des variables et paramètres nécessaires à la mise en œuvre de l'invention selon des modes de réalisation ;
- une interface 140 d'entrées/sorties I/O (pour Input/Outpuf), par exemple un écran, un clavier, une souris ou un autre dispositif de pointage tel qu'un écran tactile ou une télécommande permettant à un utilisateur d'interagir avec le système via une interface graphique ; et
- une interface de communication COM 150 adaptée à échanger des données par exemple avec des serveurs de stockage via un réseau informatique ou de communication.
Les codes d'instructions du programme stocké en mémoire non-volatile 120 sont chargés en mémoire RAM 130 en vue d'être exécutés par l'unité de traitement CPU 1 10.
La mémoire non-volatile 120 stocke également des informations confidentielles de l'utilisateur, par exemple une clé privée sous forme binaire. Bien entendu, afin d'améliorer la protection d'une telle clé privée, celle-ci peut être stockée dans un élément sécurisé (SE pour Secure Elément) type carte à puce, équipant le système selon cette architecture matérielle ou encore sur un HSM (Hardware Security Module).
La présente invention s'inscrit dans le cadre de la sauvegarde (ou stockage) répartis de données sur des serveurs de stockage d'un réseau de communication, typiquement un réseau informatique étendu, tel que l'Internet.
La figure 2 illustre un exemple de réseau informatique 20 comprenant une pluralité de M serveurs de stockage Sx. Dans l'exemple non limitatif de la figure, quatre (M=4) serveurs de stockage Si , S2, S3 et S4 sont représentés. Les serveurs sont synchronisés sur une même horloge de référence.
Un terminal utilisateur 21 , présentant l'architecture matérielle de la figure 1 , permet à un utilisateur de solliciter la sauvegarde d'une donnée personnelle, parfois confidentielle, cryptée ou non, et d'accéder à cette donnée personnelle une fois celle-ci stockée de façon répartie dans le réseau 20.
Le terminal utilisateur 21 peut mettre en œuvre la présente invention pour gérer le stockage réparti d'une telle donnée personnelle et son accès ultérieur. En variante, le terminal utilisateur 21 peut accéder à un service de sauvegarde distribuée d'une donnée et d'accès ultérieur à cette donnée, proposé par un serveur S du réseau 20. Dans les deux cas, l'ensemble des paramètres (indices de confiance et de performance, clés utilisateur, etc.) discutés par la suite peuvent être stockés sur un tel serveur S, et être récupérés, si nécessaire, par les terminaux utilisateurs.
Les principes généraux de sauvegarde répartie d'une donnée incluent de diviser la donnée pour obtenir une pluralité de blocs de données ; de déterminer, pour chaque bloc de données, un serveur respectif parmi la pluralité de serveurs de stockage ; et de mémoriser chaque bloc de données au niveau du serveur de stockage respectif.
Dans ce contexte, la présente invention prévoit d'accroître la protection, et donc la sécurité, de la donnée ainsi stockée selon ces solutions, en effectuant une détermination de chaque serveur respectif en fonction d'un instant temporel courant, c'est-à-dire en fonction du temps.
Il en résulte une localisation de chaque bloc de données qui peut varier dans le temps, rendant leur récupération par une personne malveillante plus difficile.
La figure 3 illustre, à l'aide d'un ordinogramme, des étapes générales d'un procédé exemplaire selon des modes de réalisation de l'invention. Ces étapes sont mises en œuvre dans un système selon l'invention, lequel peut être le terminal utilisateur 21 ou le serveur S de la figure 2.
A l'étape 30, une requête de stockage d'une donnée personnelle DATA est reçue de l'utilisateur (via le terminal utilisateur 21 le cas échéant).
Cette donnée est personnelle en ce qu'elle est attachée à un utilisateur ou groupe d'utilisateurs. Elle peut être constituée d'une pluralité de données élémentaires, par exemples confidentielles. Typiquement, la donnée personnelle est chiffrée.
La donnée personnelle DATA forme un fichier de taille LENGTH.
A l'étape 31 , la donnée DATA est divisée pour obtenir une pluralité de blocs de données. Cette étape se décompose en trois sous-étapes : diviser la donnée DATA en des blocs élémentaires de données D DN ; dupliquer les blocs élémentaires en des blocs dupliqués DVD pour procurer un niveau de redondance suffisant ; et entrelacer les blocs dupliqués pour améliorer la fiabilité du mécanisme de stockage. La donnée DATA peut être divisée en Nb blocs de taille constante Lfixe, applicable à toute donnée DATA dans le temps : Nb= Γ LENGTH / Lfixe 1, où Γ Ί est la fonction retournant la partie entière par excès.
En variante, la donnée DATA peut être divisée en une pluralité de blocs de même taille Lvar, cette taille de bloc étant variable en ce qu'elle peut dépendre de un ou plusieurs paramètres, par exemple choisis parmi les paramètres suivants : la taille LENGTH de la donnée DATA, l'utilisateur, l'opérateur du service de sauvegarde répartie et d'accès aux données, etc. Le nombre de blocs obtenus est alors :
Nb= T LENGTH / Lvar 1.
L'utilisateur de longueurs variables améliore encore la sécurisation de la donnée à sauvegarder.
A titre d'exemple, la variabilité de la taille du bloc en fonction de la taille LENGTH de la donnée DATA peut suivre l'une des formules suivantes :
Lvar = TLmin + (LENGTH/Nbmax)],
où Nbmax est une paramètre prédéfini et Lmin est une taille entière minimale prédéfinie. Dans ce cas, le nombre Nb de blocs de données obtenus tend vers Nbmax plus la donnée DATA est de grande taille ;
Lvar = V(LENGTH) pour LENGTH < Nbmax2
Lvar = LENGTH/Nbmax pour LENGTH≥ Nbmax2,
auquel cas le nombre Nb de blocs de données obtenus vaut min(rV(LENGTH)1, Nbmax), et tend donc vers Nbmax plus la donnée DATA est de grande taille.
A titre d'exemple, la variabilité de la taille du bloc en fonction de l'utilisateur peut consister à utiliser un identifiant unique ID de l'utilisateur (par exemple un numéro de sécurité sociale, un numéro de passeport ou carte d'identité, etc.) que l'on normalise dans un intervalle prédéfini [0 ;Nbmax], pour calculer cette longueur :
Nb = ID - Nbmax.LlD/NbmaxJ, où L J est la fonction retournant la partie entière par défaut, et du coup :
Lvar = TLENGTH/Nbl = rLENGTH/(ID-Nbmax.|_ID/Nbmax_|)1.
En variante, un nombre entier de l'intervalle [0 ;Nbmax] peut être attribué de façon aléatoire à chaque utilisateur et servir à définir la valeur Nb. La taille variable découle alors directement : Lvar = TLENGTH/Nbl.
A titre d'exemple, la variabilité de la taille du bloc en fonction d'un opérateur peut consister à prévoir différents niveaux (valeur Nb) de division de la donnée en fonction d'options d'abonnement ou de performance. Le recours à une division en un grand nombre de blocs s'avère plus sécuritaire, mais nécessite plus de calculs comme décrits par la suite. Aussi, un tel niveau de division peut être réservé aux abonnés premium.
Bien entendu ces différents exemples peuvent être combinés entre eux pour produire des longueurs variables de découpage de la donnée DATA en blocs de données DrDMt,.
De façon optionnelle, ces blocs de données peuvent être dupliqués pour fournir une redondance des données, fiabilisant la reconstitution de la donnée DATA. Dans un mode de réalisation, la loi de redondance peut être fixe, définissant le nombre de duplications RD par un nombre fixe, par exemple 3.
Selon un autre mode de réalisation, la loi de redondance appliquée peut être variable en ce qu'elle peut dépendre de un ou plusieurs paramètres, par exemple fonction d'indices de confiance CS, attribués aux M serveurs S,. A titre d'exemple, le nombre entier de duplications peut valoir :
RD = RDmax + - L(∑CSi)/M + 1 J
avec RDmin<RD≤RDmax# RDmin et RDmax étant deux valeurs prédéfinies ; et moy() étant la fonction qui retourne la valeur médiane ou moyenne.
Compte tenu du nombre RD de duplications, Nb'=RD.Nb blocs D'-i-D sont obtenus à partir des n blocs élémentaires D DN .
De façon optionnelle également, les m blocs DVD peuvent être entrelacés afin d'améliorer la fiabilité du système de sauvegarde eu égard à des erreurs se produisant dans le traitement des blocs DVD -
A titre d'exemple, l'entrelacement des blocs de données DVD produits peut être monotone de profondeur P, signifiant que chaque groupe de P blocs élémentaire D, est dupliqué RD fois. Par exemple, pour RD=3 et P=4, on considère chaque groupe de 4 blocs successivement comme suit :
D1 D2D3D4 D1 D2D3D4 D1 D2D3D4 D5D6D7D8 D5D6D7D8 D5D6...
En variante, un entrelacement complexe de profondeur P peut être mis en œuvre, signifiant que pour chaque groupe de P blocs élémentaires, leurs duplications sont mélangées. Par exemple pour RD=3 et P=6 :
D1 D4D2D5D3D6 D5D2D4D1 D6D3 D6D1 D3D4D2D5 D8D10D7D9D11 D12... Suite à l'étape 31 , une table élémentaire de répartition des serveurs S,, notée TABLEE, est obtenue à l'étape 32.
La table élémentaire TABLEE consiste en une pluralité ordonnée de LTABLE entrées, chacune identifiant un des serveurs S,. Cette table élémentaire TABLEE peut être une table prédéfinie récupérée en mémoire non volatile du système. En variante, elle peut être déterminée selon le procédé de la figure 6 décrite ci-après afin de notamment favoriser des serveurs de confiance et/ou performants.
Un exemple de table élémentaire de longueur est reproduit ici aux seules fins d'illustration, où seul est reporté l'indice i du serveur S, lorsque M=4 :
Suite à l'étape 32, une clé privée de l'utilisateur est obtenue à l'étape 33. Il s'agit de préférence d'une clé cryptographique obtenue à partir d'une courbe elliptique. Cette clé, notée K, est mémorisée de façon sécurisée dans le système mettant en œuvre l'invention, par exemple à l'aide d'un élément sécurisé type carte à puce.
Comme exposé par la suite, la clé privée K est utilisée pour déterminer les serveurs à utiliser pour mémoriser chaque bloc D',.
Puis à l'étape 34, un serveur de stockage respectif est déterminé, pour chaque bloc de données D',, parmi la pluralité de serveurs de stockage, en fonction d'un instant temporel courant Tu. L'instant temporel courant est défini avec une précision directement dépendante d'une unité temporelle choisie.
Par exemple, l'instant temporel peut être défini par l'heure courante s'il est choisi une unité temporelle de l'ordre de l'heure. Dans ce cas, la journée est découpée en 24 instants successifs, identifiés par leurs heures respectives Tu = 0 à 23. Comme le stockage selon l'invention dépend du temps, une telle unité temporelle permet de modifier la localisation de stockage des blocs D', vingt-quatre fois par jour.
En variante, on peut utiliser une unité temporelle de l'ordre du jour, de sorte à modifier la localisation de stockage des blocs D', trente ou trente et une fois par mois.
Ces unités temporelles proposées offrent l'avantage d'être très longues par rapport au temps de traitement des étapes 31 à 35 permettant de déterminer de nouvelles localisations pour le stockage des blocs de données. En effet, un ratio supérieur à 1000 (un tel traitement par des moyens informatiques prenant généralement moins de quelques secondes) est ainsi obtenu, permettant de réduire les risques d'ambiguïté relatifs au passage d'une transition d'un instant temporel au suivant, lors de la réception d'une requête d'accès à la donnée DATA.
Toutefois, des mécanismes permettant de gérer ces risques peuvent être mis en œuvre comme décrits par la suite en référence à la figure 8. L'étape 34, dont un mode de réalisation est décrit plus en détails ci-après en référence à la figure 4, permet ainsi d'identifier un serveur de stockage pour chaque bloc de données D', issue de la division de la donnée initiale DATA, et ce en fonction de l'instant temporel courant Tu.
II s'ensuit, à l'étape 35, le stockage proprement dit de chaque bloc de données au niveau du serveur de stockage respectif ainsi déterminé. Des techniques classiques de communications sécurisées avec les serveurs de stockage S, sont préférentiellement mises en œuvre.
Le procédé se poursuit à l'étape 36 où le système attend le prochain instant temporel, par exemple le début de l'heure suivante ou du jour suivant. Lorsqu'un nouvel instant temporel est atteint, les étapes 31 à 35 sont réitérées pour déterminer un nouveau serveur de stockage respectif pour chaque bloc de données D'i, et ainsi mémoriser le bloc de données au niveau du nouveau serveur de stockage pendant ce nouvel instant temporel. De préférence, les blocs de données sont effacés des anciens serveurs de stockage sur lesquels ils étaient stockés pendant l'ancien instant temporel qui vient de se terminer.
On voit ainsi que la sauvegarde répartie de la donnée DATA par blocs évolue dynamiquement, rendant la tâche de localisation des blocs de données D', difficile pour une personne malintentionnée.
A noter que la nouvelle exécution des étapes 31 , 32 et 33 peut simplement consister à récupérer le résultat d'une exécution précédente de ces étapes, lorsque celles-ci ne font pas intervenir l'instant temporel courant comme paramètre (par exemple la table élémentaire de répartition peut évoluer dans le temps).
L'étape 35 est, elle, dépendante de l'instant temporel courant, garantissant que les serveurs de stockage identifiés pour chaque bloc de données à sauvegarder évoluent dans le temps.
La figure 4 illustre une réalisation de l'étape 34 de détermination des serveurs de stockage pour sauvegarder les blocs de données D', à l'instant temporel courant Tu. Cette détermination tient compte, outre de l'instant temporel courant Tu, de la clé privée K, de la table élémentaire de répartition TABLEE et de la taille LENGTH de la donnée DATA à sauvegarder.
Une première étape 40 consiste à obtenir une première table de répartition TABLE1 à partir de la table élémentaire TABLEE, par duplication de cette dernière afin d'obtenir une table TABLE1 de longueur égale à Nb' (c'est-à-dire une table TABLE1 de même longueur que le nombre de blocs de données D', à sauvegarder). La figure 5 illustre un exemple de table élémentaire TABLEE et de la première table de répartition TABLE1 ainsi obtenue, pour M=4 (quatre serveurs), avec 41 blocs D
Puis, l'étape suivante 41 consiste à obtenir un masque binaire MASK à partir de la clé privée K et de l'instant temporel courant Tu. Comme ce masque MASK sera appliqué à la première table de répartition TABLE1 , il présente la même taille Nb' que celle-ci.
Dans l'exemple de la figure 5, la clé privée K est utilisée sous sa forme binaire (suite de et de Ό'), ici une clé de 32 bits. Puis, le masque MASK est formé par la répétition de la clé binaire K, jusqu'à atteindre la taille Nb' de la première table de répartition des serveurs. Sur la figure, les neuf bits en gras sont issus d'une répétition de la clé K.
Puis, à l'étape 42, le masque MASK est appliqué à la première table de répartition des serveurs TABLE1 pour identifier des serveurs de stockage à utiliser pour une partie des blocs de données respectifs D',. Selon des modes de réalisation, c'est à cette étape que l'instant temporel courant Tu est pris en compte pour perturber l'identification des serveurs de stockage à utiliser.
Notamment, il peut être prévu de décaler le masque MASK relativement au début de la première table de répartition des serveurs TABLE1 d'un nombre de positions fonction de l'instant temporel courant Tu, avant d'être appliqué à cette table de répartition des serveurs.
Comme montré sur la figure 5, le masque MASK est décalé de Tu positions avant application à la table TABLE1 (décalage indiqué par K«Tu) ; et le résultat RESULT1 de cette opération de masquage (les du masque identifient les serveurs de la table TABLE1 à conserver) identifie seulement une partie des serveurs de stockage à utiliser.
A l'étape 43, on obtient une deuxième table de répartition des serveurs
TABLE2 de taille Nb' à partir de la table élémentaire TABLEE par duplication de cette dernière. Afin d'obtenir une table TABLE2 différente de la première table TABLE1 , la deuxième table de répartition peut simplement être la continuité de la première table de répartition eu égard à la répétition de la table élémentaire, comme illustré sur la figure
5.
Puis, à l'étape 44, un second masque MASK2 formé par exemple du complémentaire binaire (bit à bit) du premier masque MASK est obtenu. Le second masque a également une taille égale à Nb'. A l'étape 45, le second masque MASK2 est appliqué à la deuxième table de répartition TABLE2 de la même façon qu'à l'étape 42, de sorte à identifier les serveurs de stockage à utiliser pour les autres blocs de données D', (ceux pour lesquels l'étape 42 n'a pas pu identifier de tels serveurs). En effet, l'utilisation du complémentaire du premier masque garantit qu'au final chacun des blocs D', se voit associé un serveur de stockage respectif.
La figure 5 identifie le résultat de cette opération par la référence
RESULT2.
Bien entendu, d'autres approches peuvent être mises en œuvre comme l'utilisation d'autres masques générés à partir de la clé privée K et de l'instant Tu, et la répétition d'opérations de masquage tant que l'ensemble des blocs de données D', ne s'est pas vu attribué des serveurs de stockage respectifs.
Le processus de la figure 4 se termine à l'étape 46 par la fusion des résultats RESULT1 et RESULT2 des opérations de masquage, de sorte à obtenir une grille RESULT de localisation des Nb' serveurs de stockage.
Cette grille identifie donc le serveur de stockage S, à utiliser pour chacun des Nb' blocs de données D',.
On décrit maintenant, en référence à la figure 6, une réalisation de l'étape 32 de détermination de la table élémentaire de répartition des serveurs TABLEE par duplication de laquelle les tables de répartition des serveurs TABLE1 et TABLE2 sont obtenues.
Dans ce procédé, l'étape de détermination de la table élémentaire est fonction d'un indice de performance associé à chaque serveur de stockage et d'un indice de confiance associé à la localisation géographique de chaque serveur de stockage.
Aussi, on suppose un ensemble de propriétés rattachées aux serveurs S, de la figure 2.
Chaque serveur S, est associé à une localisation géographique Deux serveurs peuvent avoir la même localisation LSj, d'où N < M.
Un indice de confiance CS, est associé à chaque localisation LSj. Cette indice de confiance est représentatif d'une stabilité locale eu égard à l'accessibilité de serveurs qui y sont localisés. Par exemple, cet indice de confiance peut être établi comme dans le brevet EP 2 433 216, par exemple sur une échelle de 0 (confiance faible) à CSmax=10 (confiance forte), tenant compte de risques sismiques, d'inondation, géopolitiques, etc. pour la localisation considérée. Bien entendu, d'autres plages de valeurs sont possibles.
Chaque serveur de stockage S, se voit donc associé indirectement un indice de confiance CS, lié à sa localisation géographique.
De plus, un indice de performance PS, est associé à chaque serveur de stockage S, en fonction par exemple de la performance d'accès à ce serveur et/ou de la performance du serveur lui-même.
Il existe un grand nombre de techniques permettant d'évoluer les performances d'un serveur, notamment en termes de performances de stockage, performances de mémoire, performances de processeur, performances de réseau et performances de processus. Aussi elles ne seront pas décrites en détails par ici.
L'indice de performance PS, est de préférence établi sur une échelle allant de 0 (peu performant) à PSmax=10 (très performant). Bien entendu, d'autres valeurs sont possibles.
A noter que l'indice de performance PS, peut varier dans le temps :
PSi=f(Tu), auquel cas par exemple l'étape 32 est re-exécutée entièrement à chaque nouvel instant temporel (après l'étape 36).
Comme illustré sur la figure 6, l'étape de détermination de la table élémentaire de répartition des serveurs TABLEE débute par une étape 60 d'obtention d'un poids WS, associé à chaque serveur de stockage S,. Ce poids peut notamment être représentatif des confiance et performance associées. Aussi, le poids WS, associé à un serveur de stockage S, peut être déterminé à partir des indices de performance et de confiance du serveur de stockage considéré, par exemple par combinaison des indices CS, et PS, associés à S,.
Par exemple : WS, = (CSi.PSi)/(CSmax.PSmax) pour un poids variant de 0 à 1.
En variante, pour obtenir un poids variant entre 0 et CSmax ou entre 0 et PSmax, on peut utiliser une des formules suivantes :
WS; = (CSi.PSi)/PSmax,
WS; = (CSi.PSi)/CSmax.
En outre, si CSmax = PSmax, la formule suivante peut être utilisée pour définir une valeur moyenne entre performance et confiance des serveurs de stockage :
Disposant des poids WS,, l'étape 61 consiste à déterminer la longueur LTABLE de la table élémentaire en fonction de la somme de poids associés aux serveurs de stockage. Par exemple, LTABLE = ∑i=i..M(WSi). Si WS, prend valeur entre 0 et 10 (CSmax = Smax = 10), alors la longueur de table vaut au plus 10.M.
Puis, à l'étape 62 un index 'x' est initialisé à 1 . Cet index est utilisé dans la boucle de l'algorithme décrite après, pour traiter l'ensemble des serveurs de stockage : x=1 ...M.
Puis à l'étape 63, une fréquence de répétition Fx est déterminée pour chaque serveur de stockage en fonction du poids WSX associé au serveur de stockage Sx considéré. Comme utilisée par la suite, Fx est représentative d'une fréquence d'occurrence du serveur de stockage Sx dans la table élémentaire de répartition TABLEE, lorsqu'il s'agira de la créer.
Ainsi, plus le poids WSX est élevé (serveur de confiance et/ou performant), plus la fréquence de répétition peut être choisie élevée afin de favoriser les serveurs de confiance et/ou performants.
Par exemple, 1/FX = L(LTABLE / WSX)_|. En d'autres termes, on envisage de répéter le serveur S, toutes les L(LTABLE / WSX)J positions à l'intérieur de la table TABLEE.
Puis aux étapes suivantes, la table TABLEE est formée en répétant WSX fois chaque serveur Sx avec une fréquence Fx.
Par exemple à l'étape 64, on initialisé le remplissage de TABLEE pour le serveur Sx par TABLEE(x) = x. La première position dans la table élémentaire TABLEE renseigne donc le serveur Si.
Si cette entrée de la table est déjà utilisée, on prend la première entrée disponible suivant TABLEE(x).
La position de l'entrée renseignée est mémorisée dans une variable 'z'. En outre, on initialisé un compteur du nombre d'occurrences NBOCC à 1.
Puis on vérifie à l'étape 65 si toutes les occurrences du serveur Sx ont été ajoutées à la table TABLEE : « NBOCC = WSX ? ».
Dans la négative, l'étape 66 prévoit de renseigner l'occurrence suivante du serveur Sx dans la table TABLEE.
Pour ce faire, la position de l'entrée suivante est déterminée :
z <- (z + 1/FX) mod(LTABLE).
Si l'entrée correspondante TABLEE(z) est déjà renseignée, à nouveau on prend la première entrée disponible suivante (en rebouclant au début de la table si nécessaire), auquel cas on mémorise son index dans la variable z. Puis, l'entrée TABLEE(z) est renseignée pour indiquer le serveur de stockage Sx : TABLEE(z) = x, et la variable NBOCC est incrémentée.
Le procédé reboucle alors sur l'étape 65 permettant de remplir toutes les occurrences du serveur Sx dans la table élémentaire TABLEE.
Lorsque toutes ces occurrences ont été renseignées (sortie 'oui' du test
65), l'étape 67 détermine si tous les serveurs ont été traitées : « x=M ? », auquel cas le procédé de la figure 6 prend fin. Dans la négative, le serveur de stockage suivant est considéré en incrémentant l'index x (étape 68) avant de reboucler sur l'étape 63.
Compte tenu de la définition de LTABLE, toutes les entrées de la table TABLEE renseignent au final un serveur de stockage.
La figure 7 illustre le processus de la figure 6 pour M=4 serveurs, avec les poids suivants WSi=4, WS2=3, WS3=8 et WS4=6. La table élémentaire TABLEE est remplie en répétant, pour chaque serveur S, itérativement considéré et en fonction de sa fréquence de répétition déterminée (F,), une occurrence du serveur au sein de la table élémentaire jusqu'à atteindre un nombre de répétition NBOCC égal au poids WS, associé au serveur considéré.
L'étape 61 permet d'obtenir LTABLE = 4+3+8+6 = 21
La première boucle (x=1 ) des étapes 63 à 66 permet d'obtenir
1/Fi = L(L TABLE / WSi)J = L21/4j = 5
Puis d'avoir TABLEE(1 )=1 , TABLEE(1 +5=6)=1 , TABLEE(6+5=1 1 )=1 et
TABLEE(1 1 +5=16)=1 . Comme à ce stade NBOCC=4=WSi, aucune autre occurrence du serveur Si n'est ajoutée à la table élémentaire de répartition TABLEE, et notamment au niveau de l'entrée TABLEE(16+5=21 ) identifiée, sur la figure, par le sigle '♦ '.
Lors de la deuxième boucle (x=2), 1/F2 = L21/3J = 7, puis TABLEE(2)=2, TABLEE(2+7=9)=2. Comme l'entrée TABLEE(16) est déjà renseignée (pour le serveur Si), cette entrée est passée (puce '·' sur la figure) et l'entrée disponible suivante est choisie TABLEE(17)=3. A ce stade NBOCC atteint WS2=3, ce qui finit la boucle pour le serveur S2. On voit ici qu'il y a moins d'occurrences du serveur S2 comparé au serveur Si, en raison du fait que ce dernier présente un plus fort poids (4 contre 3).
Lors de la troisième boucle (x=3), 1/F3 = L21/8J = 2, puis TABLEE(3)=3,
TABLEE(5)=3, TABLEE(7)=3. Comme l'entrée TABLEE(9) est déjà renseignée (pour le serveur S2), l'entrée disponible suivante est choisie TABLEE(10)=3. Puis les occurrences selon 1/F3 sont reprises : TABLEE(12)=3, TABLEE(14)=3. Comme les entrées TABLEE(16) et TABLEE(17) sont déjà renseignées, l'entrée disponible suivante est choisie TABLEE(18)=3. La dernière occurrence pour atteindre NBOCC=WS2=3 est renseignée : TABLEE(20)=3.
Enfin, lors de la quatrième boucle (x=4), 1/F4 = |_21/6j = 3, puis TABLEE(4)=4, TABLEE(8)=4 (puisque TABLEE(7) est déjà renseignée), TABLEE(13)=4 (puisque TABLEE(1 1 ) et TABLEE(12) sont déjà renseignées), TABLEE(19)=4 (puisque TABLEE(16) à TABLEE(18) sont déjà renseignées). Comme z+1/F4=22 est supérieur à ABLE, on reboucle sur le début de la table élémentaire TABLEE où l'on trouve la première entrée disponible TABLEE(15) pour y renseigner le serveur S4. Enfin, la dernière occurrence du serveur S4 est renseignée dans la dernière entrée disponible TABLEE(21 ).
On obtient ainsi la table élémentaire TABLEE entièrement remplie, laquelle peut être utilisée à l'étape 32 décrite ci-dessus.
Le procédé d'accès à une donnée sauvegardée selon l'algorithme de la figure 3 est maintenant décrit en référence à la figure 8. Comme évoqué précédemment, cet algorithme comporte un mécanisme permettant de gérer les risques d'ambiguïté relatifs au passage d'une transition d'un instant temporel au suivant, lors de la réception d'une requête d'accès à la donnée DATA.
L'algorithme commence à l'étape 80 par la réception d'une requête d'accès à la donnée DATA par un utilisateur U. Si nécessaire, les mécanismes de division, redondance et entrelacement (étape 31 ) de la donnée DATA sont mis en œuvre aux fins notamment de connaître le nombre Nb' de blocs de données D', à récupérer.
Une variable Ίοορ' est initialisée à 0, pour servir de mécanisme de gestion des transitions temporelles.
L'instant temporel Tu de réception de la requête est mémorisé. Les étapes suivantes permettent d'identifier les serveurs de stockage mémorisant, à cet instant temporel, les blocs de données formant la donnée DATA à accéder.
Notamment, à l'étape 81 , la table élémentaire TABLEE est obtenue de façon similaire à l'étape 32. Puis à l'étape 82, la clé privée K de l'utilisateur est obtenue de façon similaire à l'étape 33. Puis à l'étape 83, les serveurs de stockage des blocs de données D', sont déterminés de façon similaire à l'étape 34, pour l'instant temporel Tu.
A l'étape 84, les blocs de données D', sont récupérés de ces serveurs de stockage déterminés, par des mécanismes classiques (par exemple des requêtes sécurisées). Puis, lors de l'étape 85, la donnée DATA est reformée à partir des blocs D', ainsi récupérés.
L'étape suivante, 86, consiste à vérifier la cohérence du résultat de l'étape 85. Plusieurs éléments peuvent être vérifiés afin d'identifier une éventuelle erreur. Par exemple, la vérification peut porter sur l'indentification de l'utilisateur U qui doit être identique à celle indiquée dans la donnée DATA reformée (par exemple si la donnée DATA est cryptée, l'utilisation d'une clé publique de l'utilisateur U permet de vérifier l'authenticité). Selon un autre exemple, une vérification de sommes de contrôle peut être menées (par exemple si la fin de la donnée DATA consiste en une somme de contrôle du reste de la donnée). D'autres vérifications peuvent être menées comme la datation du dernier stockage mémorisée par rapport à une traçabilité mémorisées des opérations effectuées pour cet utilisateur.
En cas d'incohérence ou d'erreur constatée sur la donnée reformée à partir des blocs de données récupérés (test 87), le procédé se poursuit au test 88 pour vérifier si l'on vient de tester les données à l'instant temporel Tu (loop=0) ou à l'instant temporel suivant Tu+1 (loop=1 ). Si loop=0, on incrémente l'instant temporel Tu : Tu -Tu+1 à l'étape 89 et on reboucle sur l'étape 83 de sorte à identifier de nouveaux serveurs de stockage mémorisant, à l'instant temporel suivant (celle suivant immédiatement l'instant temporel de réception de la requête d'accès), les blocs de données, puis à récupérer (étape 84) les blocs de données depuis les nouveaux serveurs de stockage respectifs ainsi identifiés, pour reformer (étape 85) ladite donnée.
Si loop=1 (test 88), alors un message d'erreur est retourné à l'utilisateur en réponse à sa requête (étape 90).
En l'absence d'erreur au test 87, la donnée reformée est retournée à l'utilisateur en réponse à sa requête (étape 91 ).
On voit que si la donnée DATA ne peut être correctement reconstituée à l'aide du schéma de répartition des blocs D', à l'instant temporel Tu, on la reconstitue à l'aide du schéma de répartition valable pour l'instant temporel suivant Tu+1 . Ainsi, même si la requête d'accès est reçue proche d'une transition temporelle par laquelle les blocs de données D', sont déplacés de serveurs, le procédé permet de récupérer de façon sécurisée ladite donnée DATA.
Les modes de réalisation de l'invention qui viennent d'être décrits permettent de déterminer, dans un réseau étendu, des localisations virtuelles de sauvegarde répartie selon une ou plusieurs lois de répartition dynamiques. Cette approche offre un haut niveau de sécurisation d'une donnée sauvegardée de façon répartie. Divers mécanismes permettent d'améliorer cette sécurisation, tels que la redondance de blocs de données, l'utilisation de l'identité de l'utilisateur pour faire varier certains paramètres.
Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas.

Claims

REVENDICATIONS
1. Procédé de stockage d'une donnée (DATA) associée à un utilisateur dans un réseau informatique (20) comprenant une pluralité de serveurs de stockage (S,), le procédé comprenant les étapes suivantes :
diviser (31 ) la donnée pour obtenir une pluralité de blocs de données (D,, déterminer (34), pour chaque bloc de données, un serveur respectif parmi la pluralité de serveurs de stockage ; et
mémoriser (35) chaque bloc de données au niveau du serveur de stockage respectif,
caractérisé en ce que la détermination, pour chaque bloc de données, du serveur respectif est fonction d'un instant temporel courant (Tu), de sorte que le serveur de stockage utilisé pour mémoriser chaque bloc respectif de données varie périodiquement dans le temps.
2. Procédé selon la revendication 1 , dans lequel un nouveau serveur de stockage respectif est déterminé, à chaque nouvel instant temporel, pour chaque bloc de données divisant ladite donnée, de sorte à mémoriser le bloc de données au niveau d'un nouveau serveur de stockage à chaque nouvel instant temporel.
3. Procédé selon la revendication 2, comprenant, en outre, les étapes suivantes en réponse à une requête d'accès à la donnée associée à l'utilisateur :
identifier (83) des serveurs de stockage mémorisant, à un instant temporel donné (Tu), les blocs de données ;
récupérer (84) les blocs de données (D,, D',) depuis les serveurs de stockage respectifs ainsi identifiés, pour reformer ladite donnée (DATA) ; et
en cas de détection d'une erreur sur la donnée reformée à partir des blocs de données récupérés, identifier de nouveaux serveurs de stockage mémorisant, à un instant temporel suivant, les blocs de données, puis récupérer les blocs de données depuis les nouveaux serveurs de stockage respectifs ainsi identifiés, pour reformer ladite donnée.
4. Procédé selon l'une des revendications 1 à 3, dans lequel la détermination du serveur respectif est en outre fonction d'une clé binaire privée (K) associée à l'utilisateur.
5. Procédé selon la revendication 4, dans lequel l'étape de détermination des serveurs de stockage comprend une étape (42) consistant à appliquer la clé binaire comme masque (MASK) à une première table de répartition des serveurs (TABLE1 ) pour identifier des serveurs de stockage à utiliser pour une partie des blocs de données respectifs, ladite première table de répartition des serveurs associant un serveur à chaque bloc de données.
6. Procédé selon la revendication 5, dans lequel l'étape de détermination des serveurs de stockage comprend en outre une étape (45) consistant à appliquer un complémentaire de la clé binaire comme masque (MASK2) à une deuxième table de répartition des serveurs (TABLE2) pour identifier des serveurs de stockage à utiliser pour les autres blocs de données respectifs, ladite deuxième table de répartition des serveurs associant un serveur à chaque bloc de données et étant formée à partir d'une même table élémentaire (TABLEE) que la première table de répartition des serveurs.
7. Procédé selon la revendication 5 ou 6, dans lequel le masque formé de la clé binaire est décalé relativement à la première ou deuxième table de répartition des serveurs d'un nombre de positions fonction de l'instant temporel courant, avant d'être appliqué à la première ou deuxième table de répartition des serveurs.
8. Procédé selon l'une des revendications 5 à 7, dans lequel le masque est formé d'une répétition de la clé binaire de sorte à atteindre la taille (Nb') de la première ou deuxième table de répartition des serveurs.
9. Procédé selon l'une des revendications 5 à 8, dans comprenant en outre une étape de détermination (32) d'une table élémentaire de répartition des serveurs (TABLEE) par duplication de laquelle la ou les tables de répartition des serveurs sont obtenues,
procédé dans lequel l'étape de détermination de la table élémentaire est fonction d'un indice de performance (PS,) associé à chaque serveur de stockage et d'un indice de confiance (CS,) associé à la localisation géographique (LS,) de chaque serveur de stockage.
10. Procédé selon la revendication 9, dans lequel la longueur (LTABLE) de la table élémentaire est fonction de la somme de poids (WS,) associés aux serveurs de stockage, le poids associé à un serveur de stockage étant déterminé à partir des indices de performance et de confiance du serveur de stockage considéré.
1 1 . Procédé selon la revendication 9 ou 10, dans lequel l'étape de détermination de la table élémentaire comprend les étapes suivantes : déterminer (63), pour chaque serveur de stockage, une fréquence (F,) de répétition d'une occurrence du serveur de stockage dans la table élémentaire en fonction du poids associé audit serveur de stockage considéré ;
remplir (64, 66) la table élémentaire en répétant, pour chaque serveur itérativement considéré et en fonction de sa fréquence de répétition déterminée, une occurrence du serveur au sein de la table élémentaire jusqu'à atteindre (65) un nombre de répétition (NBOCC) égal au poids associé au serveur considéré.
12. Procédé selon l'une des revendications 1 à 1 1 , dans lequel l'étape de division de la donnée comprend les étapes suivantes :
diviser la donnée (DATA) en des blocs élémentaires de données (D,) ; dupliquer les blocs élémentaires en des blocs dupliqués ;
entrelacer les blocs dupliqués de sorte à obtenir ladite pluralité de blocs de données (D',).
13. Système de stockage d'une donnée (DATA) associée à un utilisateur dans un réseau informatique (20) comprenant une pluralité de serveurs de stockage
(S,), le système comprenant au moins un microprocesseur (1 10) configuré pour exécuter, dans un environnement d'exécution du système, les étapes suivantes :
diviser la donnée pour obtenir une pluralité de blocs de données (D,, D',) ; déterminer, pour chaque bloc de données, un serveur respectif parmi la pluralité de serveurs de stockage ; et
mémoriser chaque bloc de données au niveau du serveur de stockage respectif,
caractérisé en ce que la détermination, pour chaque bloc de données, du serveur respectif est fonction d'un instant temporel courant (Tu), de sorte que le serveur de stockage utilisé pour mémoriser chaque bloc respectif de données varie périodiquement dans le temps.
14. Système selon la revendication 13, dans lequel le microprocesseur est en outre configuré pour déterminer un nouveau serveur de stockage respectif à chaque nouvel instant temporel et pour chaque bloc de données divisant ladite donnée, de sorte à mémoriser le bloc de données au niveau d'un nouveau serveur de stockage à chaque nouvel instant temporel.
15. Système selon la revendication 13 ou 14, dans lequel la détermination du serveur respectif est en outre fonction d'une clé binaire privée (K) associée à l'utilisateur.
EP16778810.8A 2015-10-08 2016-10-07 Procédé et système de sauvegarde répartie dynamique Withdrawn EP3360034A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP15306582.6A EP3153961A1 (fr) 2015-10-08 2015-10-08 Procédé et système de sauvegarde répartie dynamique
PCT/EP2016/074104 WO2017060495A1 (fr) 2015-10-08 2016-10-07 Procédé et système de sauvegarde répartie dynamique

Publications (1)

Publication Number Publication Date
EP3360034A1 true EP3360034A1 (fr) 2018-08-15

Family

ID=55027646

Family Applications (2)

Application Number Title Priority Date Filing Date
EP15306582.6A Withdrawn EP3153961A1 (fr) 2015-10-08 2015-10-08 Procédé et système de sauvegarde répartie dynamique
EP16778810.8A Withdrawn EP3360034A1 (fr) 2015-10-08 2016-10-07 Procédé et système de sauvegarde répartie dynamique

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP15306582.6A Withdrawn EP3153961A1 (fr) 2015-10-08 2015-10-08 Procédé et système de sauvegarde répartie dynamique

Country Status (5)

Country Link
US (1) US10678468B2 (fr)
EP (2) EP3153961A1 (fr)
CN (1) CN108139869A (fr)
BR (1) BR112018006134A2 (fr)
WO (1) WO2017060495A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111309528A (zh) * 2020-03-23 2020-06-19 重庆忽米网络科技有限公司 一种基于云计算及分布式存储的数据协同备份系统及方法

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003063423A1 (fr) * 2002-01-24 2003-07-31 University Of Southern California Stockage de donnees pseudo-aleatoires
US7096328B2 (en) * 2002-01-25 2006-08-22 University Of Southern California Pseudorandom data storage
US20060020569A1 (en) * 2004-07-22 2006-01-26 Goodman Brian G Apparatus, system, and method for time-based library scheduling
US7844775B2 (en) * 2005-09-23 2010-11-30 Avid Technology, Inc. Distribution of data in a distributed shared storage system
US9178693B2 (en) * 2006-08-04 2015-11-03 The Directv Group, Inc. Distributed media-protection systems and methods to operate the same
FR2945644A1 (fr) 2009-05-18 2010-11-19 Alcatel Lucent Systeme de sauvegarde de donnees
KR101483127B1 (ko) * 2011-03-31 2015-01-22 주식회사 케이티 클라우드 스토리지 시스템에서 리소스를 고려한 자료분배방법 및 장치
US8732421B2 (en) * 2011-08-26 2014-05-20 Hitachi, Ltd. Storage system and method for reallocating data
KR101632817B1 (ko) * 2012-03-09 2016-06-22 엠파이어 테크놀로지 디벨롭먼트 엘엘씨 클라우드 컴퓨팅 보안 데이터 저장
WO2014010016A1 (fr) 2012-07-09 2014-01-16 富士通株式会社 Programme, procédé de gestion de données et dispositif de traitement d'informations
CN203149553U (zh) * 2013-03-28 2013-08-21 中国大唐集团财务有限公司 一种带有数据安全校验的异地灾备系统
US20160147838A1 (en) * 2013-06-14 2016-05-26 Nec Corporation Receiving node, data management system, data management method and strage medium
CN103916477A (zh) * 2014-04-09 2014-07-09 曙光云计算技术有限公司 用于云环境的数据存储方法和装置、及下载方法和装置

Also Published As

Publication number Publication date
BR112018006134A2 (pt) 2018-10-23
US10678468B2 (en) 2020-06-09
CN108139869A (zh) 2018-06-08
WO2017060495A1 (fr) 2017-04-13
US20180284991A1 (en) 2018-10-04
EP3153961A1 (fr) 2017-04-12

Similar Documents

Publication Publication Date Title
EP1570648B1 (fr) Méthode de sécurisation des mises à jour de logiciels
EP0402210B1 (fr) Procédé pour vérifier l&#39;intégrité d&#39;un logiciel ou de données, et système pour la mise en oeuvre de ce procédé
EP0810506B1 (fr) Procédé et dispositif d&#39;identification sécurisée entre deux terminaux
EP1055203B1 (fr) Protocole de controle d&#39;acces entre une cle et une serrure electronique
EP1761835B1 (fr) Module de sécurité et méthode de personnalisation d&#39;un tel module de sécurité
CN111680013A (zh) 基于区块链的数据共享方法、电子设备和装置
EP3360034A1 (fr) Procédé et système de sauvegarde répartie dynamique
FR2792141A1 (fr) Procede de securisation d&#39;un ou plusieurs ensembles electroniques mettant en oeuvre un meme algorithme cryptographique avec cle secrete, une utilisation du procede et l&#39;ensemble electronique
FR3052894A1 (fr) Procede d&#39;authentification
EP1609326B1 (fr) Procede de protection d&#39;un terminal de telecommunication de type telephone mobile
EP1436792B1 (fr) Protocole d&#39;authentification a verification d&#39;integrite de memoire
EP3394812A1 (fr) Procédé d&#39;authentification
FR3107416A1 (fr) Tokenisation aléatoire efficace dans un environnement dématérialisé
WO2020065185A1 (fr) Procédé cryptographique de comparaison sécurisée de deux données secrètes x et y
WO2019175482A1 (fr) Traitement sécurisé de données
FR3121240A1 (fr) Procédé permettant de garantir l’intégrité des données informatiques gérées par une application tout en préservant leur confidentialité
EP3284209B1 (fr) Procédés de génération et de vérification d&#39;une clé de sécurité d&#39;une unité monétaire virtuelle
FR3111037A1 (fr) Procédé de dérivation d’une signature partielle avec vérification partielle
FR3122753A1 (fr) Procédé d&#39;exécution d&#39;un code binaire par un microprocesseur
FR3083344A1 (fr) Support amovible de stockage de donnees
FR3003058A1 (fr) Systeme et procede de gestion d’au moins une application en ligne, objet portable utilisateur usb et dispositif distant du systeme
FR2987711A1 (fr) Delegation de calculs cryptographiques
FR2912529A1 (fr) Couplage d&#39;un programme informatique ou de donnees a un systeme de reference et verification associee.
FR2856815A1 (fr) Procede d&#39;authentification de donnees contenues dans un objet a memoire
FR3041196A1 (fr) Procede de gestion d&#39;une liste d&#39;au moins un mot de passe

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20180504

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20211115

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20220326