WO2009136030A1 - Procede de sauvegarde/restauration de fichiers dans un reseau pair a pair - Google Patents

Procede de sauvegarde/restauration de fichiers dans un reseau pair a pair Download PDF

Info

Publication number
WO2009136030A1
WO2009136030A1 PCT/FR2009/050560 FR2009050560W WO2009136030A1 WO 2009136030 A1 WO2009136030 A1 WO 2009136030A1 FR 2009050560 W FR2009050560 W FR 2009050560W WO 2009136030 A1 WO2009136030 A1 WO 2009136030A1
Authority
WO
WIPO (PCT)
Prior art keywords
fragment
peer
file
network
fragments
Prior art date
Application number
PCT/FR2009/050560
Other languages
English (en)
Inventor
Houssem Jarraya
Maryline Maknavicius-Laurent
Original Assignee
Groupe Des Ecoles Des Telecommunications (Get) Institut National Des Telecommunications (Int)
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 Groupe Des Ecoles Des Telecommunications (Get) Institut National Des Telecommunications (Int) filed Critical Groupe Des Ecoles Des Telecommunications (Get) Institut National Des Telecommunications (Int)
Publication of WO2009136030A1 publication Critical patent/WO2009136030A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • 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
    • 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/1469—Backup restoration techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G06F16/1834—Distributed file systems implemented based on peer-to-peer networks, e.g. gnutella
    • G06F16/1837—Management specially adapted to peer-to-peer storage networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1061—Peer-to-peer [P2P] networks using node-based peer discovery mechanisms
    • H04L67/1065—Discovery involving distributed pre-established resource-based relationships among peers, e.g. based on distributed hash tables [DHT] 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H04L67/1078—Resource delivery mechanisms
    • H04L67/108—Resource delivery mechanisms characterised by resources being split in blocks or fragments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]

Definitions

  • P2P network refers to a network composed of a set of entities called peers, interconnected with one another. Each of these entities can play both the role of server and client and it participates in the P2P service offered by the supply of some of its resources (hard disk, processor, ...) to the system.
  • the invention applies more particularly to information backup systems in P2P networks based on the use of a distributed hash table (DHT) and fragmentation of files.
  • DHT distributed hash table
  • distributed hash table denotes a data structure that associates for each peer a unique identifier that is the result of a hash function applied for example to its IP address or its machine name.
  • a unique key of the same length as the peer identifiers. This key designated below by "DHT key” or “CDHT” is calculated by applying a hash function on an element of the resource, such as its name or content. Subsequently, each resource is saved in the peer whose identifier is closest to its key, according to a fixed distance function.
  • C. Batten, K. Barr, A.Saraf and S.Trepetin are known from publications
  • PStore a secure peer-to-peer backup system
  • Mr. Landers, H. Zhang and K.L. Tan PeerStore: better performance by relaxing in peer-to-peer backup” examples of such backup systems.
  • a peer fragments each file into several pieces of data called FB (File Block), and generates, for each of these files, an additional fragment called FBL (File Block List) that describes the list of FB fragments that make up the file. file and their location in the P2P network.
  • FBL Fra Block List
  • the FBL fragment also contains additional information for recovering any version of the file. This FBL fragment is also saved in the P2P network and its location is identified by a DHT key.
  • each file saved in the P2P network consists of a set of fragments FB and a single fragment FBL 10, as shown in Figure 1.
  • the fragment FBL defines for each version of the file and for each fragment FB a key for locating the fragment FB, in the example considered a DHT key (CDHT), and a key for decrypting the fragment FB (CC) and the length of the FB fragment.
  • CDHT DHT key
  • CC a key for decrypting the fragment FB
  • FIG. 2 shows a method of restoring a file saved in the P2P network with the known backup systems.
  • the user must, from a terminal 3, specify the name and the path of the desired file in order to have access to the fragment FBL 10, this fragment FBL 10 allowing access to fragments FB 11 making it possible to reconstitute the searched file 13.
  • restoring N files assumes N identical and repeated FBL fragment extraction operations.
  • the publication L.P. Cox, CD is still known. Muray and B.D. Noble
  • the invention aims to meet this need.
  • the subject of the invention is a method for saving at least one file recorded by a peer in the terminal memories of a plurality of nodes of a peer-to-peer network, in which:
  • this peer is allowed to select one or more files to save
  • the source fragment is stored in the memory of at least one terminal of the network.
  • Terminal means for example a camera, a camera, a mobile phone, a smartphone, set-top box (for example of the "box” type connected to ADSL and providing telephone, internet and television), a computer, a laptop, a refrigerator, an oven, an alarm, a video recorder, an FTP server, a database server, an email server, a workstation or a digital personal assistant.
  • set-top box for example of the "box” type connected to ADSL and providing telephone, internet and television
  • computer a laptop, a refrigerator, an oven, an alarm, a video recorder, an FTP server, a database server, an email server, a workstation or a digital personal assistant.
  • the invention makes it possible, thanks to the source fragment, to add a level in the hierarchy of the fragments FBL and FB of the prior art.
  • the source fragment by making it possible to locate and decrypt at least a portion of the description fragments of several files, enables the par to locate and decrypt fragments of these files saved in a single operation.
  • the peer no longer needs to memorize for each FBL fragment the key for locating the latter in the network and / or its decryption key.
  • the invention makes it possible, as soon as the source fragment is accessed, to be able to extract at one time files it automatically backs up in the P2P network, without having to request one by one the files it wishes to extract, which can be particularly useful in case of loss, either by crash or by theft, of the hard disk of the peer terminal.
  • the restoration of the backed up files depends only on the access to the source fragment, it can be done from any terminal of the network, and not only since the one from which the files to be restored have been saved.
  • a key for encrypting the source fragment and a key for locating the source fragment can be computed.
  • the source fragment can be saved in the memory of one or more nodes of the network, or even in the memory of a secure element of the network, such as a backup server set up by an operator.
  • the source fragment may directly contain the keys for locating and decrypting the FBL fragment (s), which may further simplify the decryption and localization of this fragment or fragments from the source fragment.
  • the key for locating the source fragment can be calculated by hashing at least one peer associated with the peer.
  • This key is for example a DHT key.
  • This key being dependent on a secret of the user, for example a password, a private key or a secret code associated with a terminal of the peer, for example a PIN code of a mobile phone , the invention may make it possible to prevent any node that does not know this secret from accessing the source fragment, thus making it possible to restrict access to the source fragment at the peer that has saved the files.
  • the key for encrypting the source fragment can be calculated according to at least one secret associated with the peer, for example according to a password, a private key or a secret code.
  • the calculation function makes it possible, for example, to construct a symmetric encryption key from a string of characters by redistributing bits, deleting or adding other bits.
  • the use of such a key to encrypt the source fragment may make it possible to prevent another node, for example by a network backup server scanning technique, from reading and interpreting the source fragment to determine the list. backed up files and / or know who owns them.
  • the secret from which is calculated the key for encrypting the source fragment is for example the same as that from which is calculated the key to locate this source fragment.
  • the invention by using keys to locate and encrypt the source fragment as mentioned above, makes it possible to condition the access to the source fragment and consequently the determination of the list of files that have been saved in the P2P network and / or their recovery to the knowledge by a node of the key for decrypting the source fragment and the key to locate it.
  • the invention can thus make it possible to respect the privacy of the holders of the nodes of the network.
  • the method may comprise a step allowing the peer to select at least one property to be saved by file stored in the memory of a terminal of the network.
  • properties to be backed up are, for example, the access rights of local users, the creation date of the file or the path to this file.
  • the checksum of the file (checksum) to check the integrity of the file after it has been restored can also be saved, which can detect errors during the file restore, these errors can be caused by a collision between FB fragments.
  • the method may comprise the step of allowing the peer to modify a source fragment already generated to take into account: the backup of a new file saved in the memory of a network terminal and / or the deletion of a saved file
  • the source fragment makes it possible to locate and to decipher all the generated FBL fragments, which can allow a peer to have only one source fragment from which it can, if he wishes, restore all the files he has saved.
  • each source fragment can be generated, each source fragment making it possible to locate and to decipher part of the FBL fragments associated with the files saved, which can make it possible to associate a source fragment with group of files saved.
  • a key for locating or encrypting a source fragment can be calculated in the same way as previously defined.
  • the keys for locating and encrypting the source fragments may be different from one source fragment to another, which may prevent a node that knows the keys of a source fragment from gaining access to the other fragments. sources, but also collisions between source fragments.
  • Files can be grouped into a particular source fragment depending on their type, content, or access rights.
  • File types according to the invention are, for example, photos, videos, sound recordings or texts.
  • a root fragment for locating and decrypting the source fragments can be generated, this root fragment can be saved in the memory of at least one P2P network terminal.
  • Another object of the invention is, according to another of its aspects, a method of restoring at least one file saved in the terminal memories of a peer-to-peer network in the form of data fragments (FB) to which is associated a fragment of description (FBL) listing the fragments of data, this fragment FBL being localizable and decryptable by a protected access source fragment saved in the memory of a terminal of the network, in which process: a peer accesses the source fragment from any terminal in the network to determine the list of files backed up in the network, the peer selects at least one file to be restored from the list, the peer initiates the process of automatically restoring the selected file (s) from this terminal.
  • FB data fragments
  • FBL fragment of description
  • the method may comprise a step of updating the list of the files saved, for example to take into account the peer backup of a new file in the network or the deletion of a file in the network.
  • the method may include a step of testing availability and integrity on files in the list. These tests can be performed periodically to ensure that the restoration process is operational and may concern only one file, or even more or even all of the files in the list.
  • Another aspect of the invention is a method of selective broadcasting of at least one file recorded in the terminal memories of a peer-to-peer network, this file being fragmented into several pieces of data ( FB) associated with a description fragment (FBL) listing the FB fragments, this FBL fragment being localizable and decryptable by a protected access source fragment saved in the memory of a terminal of the network, a method in which a client is allowed of the network searching for the recorded file and having satisfied a predefined condition the access to the source fragment and the recovery of the searched file.
  • FB pieces of data
  • FBL description fragment
  • Access to the searched file may be enabled by providing the network client with a key for locating the source fragment and / or a key for decrypting the source fragment.
  • the key to locate and / or the key to decrypt the source fragment is for example specific to each client, which can allow by assigning personal keys to each client to limit the risk of fraudulent access to the file.
  • the method may include a step of testing availability and integrity on the file. This test can be performed periodically to ensure that the broadcast process is operational.
  • Another subject of the invention is, according to another of its aspects, a method for saving at least one file recorded by a peer in the terminal memories of a plurality of nodes of a peer-to-peer network, each file being fragmented into a plurality of data fragments (FB) to which is associated a description fragment (FBL) listing the data fragments, in which process: least one source fragment for locating and decrypting at least a portion of the FBL fragments,
  • the source fragment is stored in the memory of at least one terminal of the network.
  • the P2P network can be a home automation private network.
  • the P2P network is an enterprise private network, distributed or not on several geographically distant sites.
  • the P2P network uses the Internet network.
  • FIGS. 1 and 2 illustrate an example of a method for backing up and restoring already known files
  • FIGS. 3 and 4 illustrate files backup and restoration systems according to the invention
  • FIG. 5 schematically represents an example of source fragment according to the invention
  • FIGS. 6 and 7 illustrate an example of a file saving method and an example of file restoration according to the invention
  • FIGS. 8 to 16 show examples of application of the invention.
  • FIGS. 3 and 4 show an example of backup by a pair of 13 X files according to the invention.
  • each X file is fragmented into several data fragments (FB) 11 to which is associated a description fragment (FBL) listing the FB fragments, similar to the known systems described above.
  • the fragments FBL 1O 1 and FB 1 I j can be recorded in the memories of terminals 3 constituting a peer-to-peer network 1, these terminals possibly being different from that of the peer having recorded the files.
  • the terminals 3 are represented in the form of computers in FIG. 4, the invention is of course not limited to the use of such terminals, as will be seen later.
  • At least one source fragment 9 is stored in the memory of a terminal 3 of the network 1, this terminal being in the example described different from the terminal of the peer having recorded the files 13 ⁇
  • the source fragment 9 may be stored in the memory of several distinct nodes and / or be recorded in a not shown backup server.
  • a backup server can be set up by an operator or other trusted entity.
  • the invention makes it possible to add a level of hierarchy to the fragments FBL 1O 1 and FB H j thanks to the source fragment 9 which allows the localization and the decryption of all the fragments FBL 1O 1 and, via the latter, the location of all fragments FB 1 I j constituting a file 13 ⁇ the invention allows, in this example, the user no longer necessarily have to memorize an element of information allowing him to find the DHT key and / or the encryption key of one of its fragments FBL.
  • FIG. 5 shows an example of source fragment 9. This fragment contains different fields.
  • a first field 30 assigns an identifier / number to the file 13i.
  • a second field 31 lists the name of the recorded X file.
  • a third field 32 corresponds to a key, for example a DHT key, making it possible to locate the fragment FBL 1O 1 associated with the file 13 X
  • a fourth field 33 corresponds to a key making it possible to decrypt the fragment FBL 1O 1 associated with the file 13 ⁇
  • Access to the source fragment 9 is protected by two keys, a key to allow the location of the source fragment 9 in the network 1, by example a DHT key, and a key to allow its encryption in the case of file backup or decryption in the case of file restoration or file distribution.
  • keys are determined in the example described from a secret only known to the user and which can take the form of a password, a private key, a secret code such as a code PIN of a terminal, for example a mobile phone or a personal digital assistant belonging to the peer.
  • the DHT key is for example determined by hashing the password or the private key or the PIN code.
  • the key for encrypting or decrypting the source fragment 9 is for example calculated according to the password, the private key or a secret code. This calculation function makes it possible, for example, to construct a symmetric encryption or decryption key from a string of characters by redistributing these bits, deleting or adding other bits.
  • the various fragments saved in the network 1 relating to the backup of a file 13 X are therefore encrypted: the data fragments FB 11 using, for example, the method "Convergent Encryption” as disclosed in the publication JR Sweetness, A. Adya, WJ. Bolosky, D. Simon and M.
  • Theimer "Reclaiming space from duplicate files in a serverless distributed file system", the fragments FBL 1O 1 using the symmetric encryption key saved in the source fragment 9, and the source fragment 9 using a key calculated from of the peer's secret.
  • a node wants to access, without permission, a saved file
  • the source fragment 9 may further comprise, as shown in FIG. 5, other fields 34 containing properties of the saved file 13 X. These properties concern for example the access rights of local users, the creation date of the file or the file path.
  • Field 34 may also contain a checksum to check the integrity of the entire file after it is restored. This check detects errors due to a collision between FB fragments, these errors being considered negligible.
  • PeerStore consists of separately checking the integrity of each FB fragment. This parcel checking of the integrity of a file can be problematic when a collision between fragments occurs, that is, if another different FB fragment but having the same DHT key value is stored instead a fragment of this file. Collision detection is not possible in the case of parcel control, but the collision problem can be detected if the global integrity check on the entire file is performed through the source fragment 9.
  • the invention enables the peer to access the source fragment 9 provided that it has communicated its secret, namely its password, its private key, its secret code or its PIN code, on the basis of which the keys allowing locate and decrypt the source fragment 9 will be determined, then recover all the files that have been saved in the P2P network.
  • FIG. 6 represents an exemplary method of saving files in a network 1 as represented in FIGS. 3 and 4.
  • the peer selects the list of files it wishes to save in the network 1.
  • the peer selects one or more properties to be saved, these properties corresponding to those mentioned in relation to the field 34 of the source fragment 9.
  • step 120 the peer specifies the importance level of the saved information.
  • step 130 the fragments FB H j are created by applying the necessary security processing and saved in the network 1, and a fragment FBL 1O 1 is associated for each 13 X file saved.
  • step 140 the peer generates for each fragment FBL 1O 1 a location key and an encryption key, decrypts the fragment and the backup in the network 1.
  • a source fragment 9 is generated with calculation of keys for locating and encrypting this source fragment 9.
  • the peer saves this source fragment 9 in the network 1 in the memory of one or more computer terminals 3 of the network and / or in the memory of a backup server.
  • FIG. 7 shows an example of a method for restoring by a peer one or more files saved according to the invention, this restoration method being able to be performed from any terminal 3 of the network and not only from the terminal with which the For example, par has performed the process shown in FIG.
  • step 200 the user presents the secret he used to associate an encryption key and a location key with his source fragment 9.
  • step 210 the peer retrieves and decrypts the source fragment 9.
  • step 220 the peer determines the list of 13 X files it has saved in the network 1.
  • the viewing of these files can be in the form of a flat list of file names, or a tree highlighting the path originally occupied by each saved file.
  • step 230 the peer selects the number of files it wishes to restore, namely one, several or all of the files 13 ⁇
  • step 240 the automatic restoration of this or these files begins with the recovery of its fragment FBL 1O 1 and its data fragments FB 1 I j .
  • a peer can also recover its source fragment 9 to take into account the saving of a new file in the network 1 and / or the deletion of a file from the network 1 and / or to perform availability and integrity tests on one or more files saved 13 15 so as to ensure, periodically or in a controlled manner by the user, that the backup method is operational.
  • FIG. 8 shows an example of application of the invention to a home automation private network 1.
  • This network 1 comprises for example a plurality of appliances
  • Intelligent and / or electronic devices such as a camera, a camera, a mobile phone, a set-top box, a computer, a refrigerator, an oven, an alarm, a video recorder, these devices each having a memory and corresponding to computer terminals 3i within the meaning of the invention. All or part of these devices can communicate by carrier or non-wireless link, for example Bluetooth or Wifi type.
  • a user can create his own distributed file recovery system. Indeed, it can keep a copy of the important files of a node, for example the computer 3i or 3 2 , on the other nodes of the network P2P in order to recover them in case of loss of the original files due to the loss of the disk hard terminal 3i or 3 2 .
  • the invention makes it possible to benefit from a new free and normally reliable restoration system, the nodes being under the entire control of the user.
  • FIG. 9 shows another example of application of the invention to produce a system for restoring files in a corporate private network 1, including servers, for example FTP servers, database servers. or email servers, and workstations that correspond to terminals within the meaning of the invention, constitute a peer-to-peer network.
  • servers for example FTP servers, database servers. or email servers, and workstations that correspond to terminals within the meaning of the invention, constitute a peer-to-peer network.
  • the free disk spaces of the memories of the various terminals 3 are used to record files, making it possible to duplicate the important data of a node on the other nodes of the network 1 in order to restore them in case of loss of the initial files.
  • the invention allows the company to benefit from a file restoration system: free, the company does not need to reserve a particular server to duplicate the important data of its various terminals 3, reliable, all the nodes being under the entire control of the company and, of course, the terminals 3 being in this example servers and workstations of the company, these different machines being always available in the network, so that the backup and the Restoring a file in Network 1 can be done at any time.
  • the example of FIG. 10 differs from that of FIG. 9 in that the enterprise is distributed on several geographically distant sites in which local intranets I 1 , I 2 and I 3 similar to the network described with reference to FIG. 9 exist.
  • communication between local intranet networks of two remote geographical sites is secured by establishing a VPN tunnel 2 created by one of the following protocols: Layer Two Tunneling Protocol (L2TP), IPsec (Internet Protocol) Security) or MPLS VPN.
  • L2TP Layer Two Tunneling Protocol
  • IPsec Internet Protocol
  • the invention by making it possible to save node files of a geographical site in memory of nodes of other geographical sites, allows the restoration of these files even in the case where the geographical site in which the terminal of the node is located having saved the files would disappear in its entirety due for example to a fire, a natural disaster or an attack.
  • the company assigns, according to a first embodiment, to each geographic site a single source fragment 9 enabling the automatic restoration of all the important data of a site.
  • the secret allowing access to this source fragment is preferably known only by the site manager.
  • the company allocates for each service of each geographical site, for example the financial or commercial service of each geographical site, a single source fragment.
  • the source fragment allows the automatic restoration of all the important data of a service and its secret is advantageously known only by the director of the service.
  • the company assigns each terminal 3 a source fragment 9.
  • the source fragment 9 only allows the automatic restoration of important data of a particular terminal and its secret is advantageously known. than the owner of this terminal.
  • FIG. 11 shows another example of application of the invention.
  • the peer-to-peer network 1 is formed by nodes that are terminals 3 connected to the Internet.
  • the terminals 3 are in this example chosen from computers, mobile phones, set-top boxes (for example of the "box" type connected to ADSL and providing telephone, internet and television) and PDAs.
  • a peer keeps a copy of its important data in the disk spaces of the memory terminals of the other nodes of the network 1, in order to recover them in case of loss of its local data.
  • a mobile or fixed operator, an access provider, or a new P2P service provider may charge the proposed backup and restore service to the peer.
  • the automatic recovery process can include all files already backed up in network 1 or be restricted to files of only one node;
  • the network 1 may comprise, as represented in FIG. 12, a central trusted entity 5 in periodic communication with all the nodes 3 of the network 1 and arranged to:
  • a credit or debit billing system can be provided depending on whether the resources provided are more or less important than the resources consumed;
  • Access to the source file may be controlled by a mobile or fixed operator, an access provider or a P2P service provider.
  • the access control may consist, for example, of an AAA control device (Authentication, Authorization,
  • This particular node can then be responsible for controlling the good behavior of the nodes during the various backup operations but also in the duration.
  • the invention is not limited to backing up and / or restoring files backed up in a peer-to-peer network.
  • a peer-to-peer network of at least one file, for example a multimedia or musical content, for example one or more films or music files, game software, professional or other, stored in the memory of at least one terminal of the network.
  • FIG. 13 shows such an example of application of the invention.
  • a node 6 of the network 1, hereinafter called server node acts as a server distributing films, multimedia content for example, other nodes 8 of the network 1, hereinafter called clients.
  • clients nodes 8 of the network 1, hereinafter called clients.
  • Unlike a centralized video on demand server it is not thanks to the invention not necessary to use a DNS name or a large storage space.
  • the server node 6 firstly stores in the memories of the terminals 3 of the network all the films 13 X to be shared with the clients of the network 1.
  • the server node 6 calculates from a secret the location key and the encryption key allowing access to the source fragment 9 listing all the 13i films saved then creates and saves its source fragment in the memory of n ' Any terminal of the network 1.
  • the server node 6 then transmits the secret allowing access to the source fragment to any client 8 of the network 1 having satisfied a predefined condition being for example the subscription to a subscription.
  • the dissemination of the secret allowing access to the source fragment can take several forms.
  • a client 8 can retrieve and decrypt the source fragment 9 of the server node 6 and thus determine the list of films that are available. Moreover, from the information contained in this source fragment, it can recover any movie H 1 already saved by the server node in the network 1.
  • the server-node 6 can save it in the network 1 and then update its source fragment 9. By recovering the new version of this source fragment, a client 8 can determine the new list of films offered by the server node 6.
  • the server node 6 can, at any time, remove films from the network 1, for example in order to free disk space in the memories of the terminals 3 to save new movies.
  • the invention makes it possible to have an accessible service even if the server node 6 is inaccessible since all the necessary information is saved and distributed on the various nodes of the P2P network.
  • the secret allowing access to the source fragment 9 can be distributed to the clients 8 in several forms:
  • the same character string is communicated to the customers. This string is to be entered in the access software to the data distribution application.
  • a secret such as a private key
  • a protected physical medium for example an electronic chip or a USB key.
  • a custom client-dependent secret being determined according to certain characteristics of this client, for example the MAC address of the terminal that it uses.
  • the user downloads a client software to which he must enter the personalized secret.
  • the software can then calculate the secret allowing access to the source fragment according to this personalized secret.
  • the custom secret can still be determined using other characteristics of the customer, such as his subscriber number when he has subscribed to an operator.
  • the communication of the secret allowing access to the source fragment or, where appropriate, the personalized secret can take the following forms:
  • the client software can provide a serial number or a client name so that the server controls the dissemination and personalization of the secret
  • the file to be broadcast is a file relating to an advertisement or of an informative nature and the server node 6 can broadcast the secret to all the clients 8 of the network 1 having made the request.
  • the modification rights of the source fragment can be reserved to the server node 6 to prevent a client to whom the secret was revealed can not modify the saved contents.
  • This control of these rights of modification of the source fragment can be ensured by a centralized server in which are memorized all the source fragments of the network, and which grants the rights of modification only to the node-server 6 and gives the right only to clients 8.
  • the invention enables the sharing of files between the nodes of the network 1 by the knowledge of a source fragment 9.
  • the principle is identical to the principle of broadcasting a file by a server node 6 to a client 8 described above, except that the modification rights of the source fragment are open to all the nodes of the network.
  • the same services are possible, namely the secret access control of the source fragment 9, the updates of the source fragment 9, and the management of the different versions of the saved files 13 L
  • the invention can also allow the creation of a root fragment for locating and decrypting a plurality of source fragments 9 saved in the network 1.
  • the root fragment 7 makes it possible to locate and decrypting first source fragments 9a, the latter making it possible to locate and to decipher second source fragments 9b which are similar to the source fragments described with reference to the preceding figures.
  • access to each source fragment 9a or 9b is conditioned by the knowledge of a secret according to the examples described above. The secret is different from a first source fragment 9a to another, as well as from a second source fragment 9b to the other.
  • access to a single source fragment only allows the recovery of a subset of files. Only the access to the root fragment 7, conditioned for example by the knowledge of a secret making it possible to calculate keys to locate and decipher the root fragment, can allow the access to all the source fragments and the complete recovery of the files saved in the network 1.
  • the first source fragment 9ai contains keys for locating and decrypting the second source fragments 9bi, 9b 2 and 9b3, which allows to locate and decrypt the fragments FBL 1Oi to IO5 and IO7, and therefore access to the files 13i to 13s and 13 7 .
  • the invention can allow the peer having saved the files whose restoration is allowed through the access to the root fragment 7 to broadcast only a subset of files to a client of the network. If this client can, according to the example of FIG. 14, access only the second source fragment 9bi, it can only recover the fragments FBL 1O1 to IO3 and consequently only recover the files 13i to 133-
  • the peer may decide to share only a subset of files that it has backed up with other nodes in the network.
  • the peer can choose to share only the 13s and 13 7 files with one or more nodes of the network by sending them the secret allowing them to access only the second source fragment% 3 .
  • the invention also makes it possible to optimize the disk space volume of the memory of the terminals 3i by allowing several first source fragments 9a to point to one and the same second source fragment 9b, or even to several same second source fragments. 9b. In the same way, several second source fragments 9b can point to the same FBL fragment 10, or even to several same FBL fragments.
  • FIG. 15 shows an example of application of the invention in which two root fragments 1 1 and 7 2 associated with two different pairs point to the same source fragment 9 0 .
  • This source fragment 9o makes it possible, for example, to access all the files shared between the two peers.
  • each of the peer having access to the root fragment 1 ⁇ and the one having access to the root fragment 7 2 can be considered as the owner of the source fragment% and the files to which access is thus allowed, although these files are not saved. only once in the network.
  • the peer having saved the files whose access is allowed by the root file does not need to retain the secrets allowing access to the different source fragments or, when the source fragments are hierarchized into first and second source fragments, the secrets allowing access to these different source fragments, but only that of the root fragment, the latter advantageously containing the secrets allowing access to the source fragments.
  • a server node 6 wishes to allow a client to access all the files it has saved in the network, it is sufficient to communicate to it the secret permitting access to the root fragment 7, in this way it will be able to obtain the list of the first source fragments 9a, allowing themselves access to the second source fragments 9b.
  • FIG. 16 shows an example of a method for distributing files saved within different source fragments 9.
  • a source fragment 9 is associated for each type of backup file.
  • the source fragment 9 is for example only related to files containing photos, which enables the peer to restrict its automatic restoration to all of his photos that have been saved in the network 1.
  • the files saved are grouped according to their contents.
  • a server node offering video films can associate each category of films (cultural, sport, ...) with a source fragment 9. Subsequently, a customer can subscribe to a particular category of films by asking the secret allowing access to the source fragment 9.
  • the files saved are grouped according to the access rights by the nodes of the network to the files saved. For example, private files are associated with a source fragment whose secret may never be transmitted to the other nodes of the network, and we associate with the public files another source fragment whose secret can be transmitted to all the nodes of the network.
  • the invention can make it possible to group the files saved in a database of multi-criteria source fragments, the number of source fragments and hierarchy of source fragments, ie first, second ... nth source fragments increasing with the number of criteria.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Computer Hardware Design (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)

Abstract

La présente invention concerne un procédé de sauvegarde d'au moins un fichier enregistré par un pair dans les mémoires de terminaux d'une pluralité de nœuds d'un réseau pair à pair (1), dans lequel : on permet à ce pair de sélectionner une liste de fichiers à sauvegarder; on crée pour chaque fichier plusieurs fragments de données (FB) et un fragment de description (FBL) répertoriant les fragments FB; on génère pour chaque fragment FBL de description une clé de localisation du fragment et une clé de chiffrement de ce fragment FBL; on sauvegarde les fragments FB et les fragments FBL dans les terminaux d'un réseau pair à pair; on génère au moins un fragment source (9) à accès protégé permettant de localiser et de déchiffrer au moins une partie des fragments FBL; et on sauvegarde le fragment source (9) dans la mémoire d'au moins un terminal du réseau.

Description

Procédé de sauvegarde/restauration de fichiers dans un réseau pair à pair
La présente invention a pour objet un procédé de sauvegarde/restauration de fichiers dans un réseau pair à pair (désigné par « P2P » par la suite). On désigne par « réseau P2P » un réseau composé d'un ensemble d'entités appelées pairs, interconnectées entre elles. Chacune de ces entités peut jouer à la fois le rôle de serveur et de client et elle participe au service P2P proposé par l'offre d'une partie de ses ressources (disque dur, processeur, ...) au système.
L'invention s'applique plus particulièrement aux systèmes de sauvegarde d'informations dans des réseaux P2P reposant sur l'utilisation d'une table de hachage distribuée (DHT) et la fragmentation de fichiers.
On désigne par « table de hachage distribuée » une structure de données qui associe pour chaque pair un identifiant unique qui est le résultat d'une fonction de hachage appliquée par exemple sur son adresse IP ou son nom de machine. De même, pour chaque ressource sauvegardée dans le réseau P2P, se trouve associée une clé unique de même longueur que les identifiants des pairs. Cette clé désignée dans la suite par « clé DHT » ou « CDHT » est calculée en appliquant une fonction de hachage sur un élément de la ressource, comme par exemples son nom ou son contenu. Par la suite, chaque ressource est sauvegardée dans le pair dont l'identifiant est le plus proche de sa clé, d'après une fonction de distance fixée. On connaît par les publications C. Batten, K. Barr, A.Saraf et S.Trepetin
« pStore : a secure peer-to-peer backup System » et M. Landers, H. Zhang et K.L. Tan « PeerStore : better performance by relaxing in peer-to-peer backup » des exemples de tels systèmes de sauvegarde.
Dans de tels systèmes, un pair fragmente chaque fichier en plusieurs fragments de données appelés FB (File Block), et génère, pour chacun de ces fichiers, un fragment supplémentaire appelé FBL (File Block List) qui décrit la liste des fragments FB composant le fichier et leur localisation dans le réseau P2P. Le fragment FBL contient aussi des informations supplémentaires permettant la récupération de n'importe quelle version du fichier. Ce fragment FBL est également sauvegardé dans le réseau P2P et sa localisation est identifiée par une clé DHT.
Avec les systèmes pStore et PeerStore, il suffit de stocker pour chaque fichier son nom et son chemin pour pouvoir déterminer la clé DHT et la clé de déchiffrement du fragment FBL associées au fichier. A partir d'un fragment FBL, le système P2P en déduit toutes les clés DHT et les clés de chiffrement associées aux fragments FB du fichier ; il extrait alors les fragments de données d'un fichier du réseau P2P et reconstitue la totalité du fichier. On connaît également par le site internet www.dispairse.point6.net un autre système de sauvegarde dans un réseau P2P.
Dans cet exemple, chaque fichier sauvegardé dans le réseau P2P est constitué d'un ensemble de fragments FB et d'un seul fragment FBL 10, comme illustré à la figure 1. Sur cette dernière, on a supposé que deux versions 20 et 21 d'un même fichier sont sauvegardées. Le fragment FBL 10 définit pour chaque version du fichier et pour chaque fragment FB une clé permettant de localiser le fragment FB, dans l'exemple considéré une clé DHT (CDHT), et une clé permettant de déchiffrer le fragment FB (CC) et la longueur du fragment FB.
Avec les systèmes de sauvegarde connus, il est nécessaire pour restaurer un fichier de connaître la clé DHT permettant de localiser le fragment FBL, la clé permettant de déchiffrer ce fragment FBL afin de pouvoir récupérer n'importe quelle version du fichier. Ces deux clés sont retrouvées à partir du nom du fichier, son chemin et un secret relatif à l'utilisateur (mot de passe ou clé privée).
On a représenté à la figure 2 un procédé de restauration d'un fichier sauvegardé dans le réseau P2P avec les systèmes de sauvegarde connus. L'utilisateur doit, depuis un terminal 3, spécifier le nom et le chemin du fichier souhaité afin d'avoir accès au fragment FBL 10, ce fragment FBL 10 permettant l'accès à des fragments FB 11 permettant de reconstituer le fichier recherché 13. Avec de tels systèmes de sauvegarde, la restauration de N fichiers suppose N opérations identiques et répétées d'extraction de fragments FBL. On connaît encore par la publication L.P. Cox, CD. Muray et B.D. Noble
« Pastiche : making backup cheap and easy » un autre système de sauvegarde définissant son propre système de fichiers et permettant la sauvegarde et la restauration automatique que d'une arborescence de fichiers. Ce système associe pour chaque fichier ou répertoire un fichier de métadonnées décrivant son contenu. Lors de la phase de restauration, il suffit de récupérer la métadonnée du dossier racine pour pouvoir par la suite récupérer toute l'arborescence du fichier. On connaît encore par la publication J. Cooley, C. Taylor et A. Peacock « ABS : the apportioned backup System » un système comportant une base de données locale, dupliquée elle même dans le réseau P2P, pour garder les informations nécessaires à la restauration des fichiers. Ainsi, lors de la phase de restauration, l'utilisateur accède à sa base de données locale ou la récupère entièrement à partir du réseau P2P afin de déterminer la liste des fragments de données nécessaires à la restauration d'un fichier.
Il existe un besoin pour perfectionner encore les procédés de sauvegarde et/ou de restauration sécurisée et automatique de fichiers personnels sauvegardés dans un réseau P2P. L'invention vise à répondre à ce besoin.
Selon l'un de ses aspects, l'invention a pour objet un procédé de sauvegarde d'au moins un fichier enregistré par un pair dans les mémoires de terminaux d'une pluralité de nœuds d'un réseau pair à pair, dans lequel :
- on permet à ce pair de sélectionner un ou plusieurs fichiers à sauvegarder,
- on crée pour chaque fichier plusieurs fragments de données (FB) et un fragment de description (FBL) répertoriant les fragments de données,
- on génère pour chaque fragment FBL une clé permettant de localiser le fragment FBL dans le réseau et une clé permettant de déchiffrer ce fragment, - on sauvegarde les fragments (FB) et les fragments (FBL) dans les mémoires de terminaux d'un réseau pair à pair
- on génère au moins un fragment source à accès protégé permettant de localiser et de déchiffrer au moins une partie des fragments FBL et,
- on sauvegarde le fragment source dans la mémoire d'au moins un terminal du réseau.
Par « mémoire », il faut comprendre tout type de dispositif de stockage de données, par exemple disque dur, bande magnétique, disque optique, mémoires électroniques du type FLASH, entre autres.
Par « terminal », on désigne par exemple un appareil photo, une caméra, un téléphone portable, un smartphone, boîtier décodeur (par exemple de type « box » relié à l'ADSL et fournissant téléphone, internet et télévision), un ordinateur, un ordinateur portable, un réfrigérateur, un four, une alarme, un enregistreur vidéo, un serveur FTP, un serveur de base de données, un serveur de courrier électronique, une station de travail ou encore un assistant personnel numérique.
L'invention permet, grâce au fragment source, d'ajouter un niveau dans la hiérarchie des fragments FBL et FB de l'art antérieur. Le fragment source, en permettant de localiser et de déchiffrer au moins une partie des fragments de description de plusieurs fichiers, permet au pair la localisation et le déchiffrement de fragments de ces fichiers sauvegardés en une seule opération.
Contrairement aux systèmes de l'art antérieur, le pair n'a plus besoin de mémoriser pour chaque fragment FBL la clé permettant de localiser ce dernier dans le réseau et/ou sa clé de déchiffrement.
L'invention permet, dès l'accès au fragment source, de pouvoir extraire en une seule fois des fichiers sauvegardés par lui dans le réseau P2P de façon automatique, sans avoir à demander un à un les fichiers qu'il souhaite extraire, ce qui peut s'avérer particulièrement pratique en cas de perte, soit par crash, soit par vol, du disque dur du terminal du pair.
La restauration des fichiers sauvegardés ne dépendant que de l'accès au fragment source, elle peut être effectuée depuis n'importe quel terminal du réseau, et non seulement depuis celui depuis lequel les fichiers à restaurer ont été sauvegardés.
Lors de la génération du fragment source, une clé permettant de chiffrer le fragment source et une clé permettant de localiser le fragment source peuvent être calculées.
Le fragment source peut être sauvegardé dans la mémoire d'un ou plusieurs nœuds du réseau, voire dans la mémoire d'un élément sûr du réseau, comme un serveur de sauvegarde mis en place par un opérateur. Le fragment source peut contenir directement les clés permettant de localiser et de déchiffrer le ou les fragments FBL, ce qui peut permettre de simplifier encore le déchiffrement et la localisation de ce ou ces fragments à partir du fragment source.
La clé permettant de localiser le fragment source peut être calculée par hachage d'au moins un secret associé au pair. Cette clé est par exemple une clé DHT. Cette clé étant dépendante d'un secret de l'utilisateur, par exemple d'un mot de passe, d'une clé privée ou d'un code secret associé à un terminal du pair, par exemple un code PIN d'un téléphone portable, l'invention peut permettre d'empêcher tout nœud qui ne connaîtrait pas ce secret d'accéder au fragment source, permettant ainsi de restreindre l'accès au fragment source au pair ayant sauvegardé les fichiers.
La clé permettant de chiffrer le fragment source peut être calculée en fonction d'au moins un secret associé au pair, par exemple en fonction d'un mot de passe, d'une clé privée ou d'un code secret. La fonction de calcul permet par exemple la construction d'une clé de chiffrement symétrique à partir d'une chaîne de caractères par redistribution de bits, suppression ou ajout d'autres bits.
L'emploi d'une telle clé pour chiffrer le fragment source peut permettre d'empêcher qu'un autre nœud, par exemple par une technique de scanning de serveurs de sauvegarde du réseau, ne puisse lire et interpréter le fragment source pour déterminer la liste des fichiers sauvegardés et/ou savoir quel en est le propriétaire.
Le secret à partir duquel est calculée la clé permettant de chiffrer le fragment source est par exemple le même que celui à partir duquel est calculée la clé permettant de localiser ce fragment source.
L'invention, grâce à l'emploi de clés pour localiser et chiffrer le fragment source telles qu'évoquées ci-dessus, permet de conditionner l'accès au fragment source et par conséquent la détermination de la liste des fichiers qui ont été sauvegardés dans le réseau P2P et/ou leur récupération à la connaissance par un nœud de la clé permettant de déchiffrer le fragment source et de la clé permettant de le localiser. L'invention peut permettre ainsi de respecter la vie privée des titulaires des nœuds du réseau.
Le procédé peut comporter une étape permettant au pair de sélectionner au moins une propriété à sauvegarder par fichier enregistré dans la mémoire d'un terminal du réseau. Ces propriétés à sauvegarder sont par exemple les droits d'accès d'utilisateurs locaux, la date de création du fichier ou le chemin d'accès à ce fichier.
La somme de contrôle du fichier (checksum) permettant de vérifier l'intégrité du fichier après qu'il a été restauré peut également être sauvegardée, ce qui peut permettre de détecter des erreurs lors de la restauration du fichier, ces erreurs pouvant être causées par une collision entre des fragments FB. Le procédé peut comporter l'étape selon laquelle on permet au pair de modifier un fragment source déjà généré pour prendre en compte : la sauvegarde d'un nouveau fichier enregistré dans la mémoire d'un terminal du réseau et/ou la suppression d'un fichier sauvegardé
Selon un exemple de mise en œuvre de l'invention, le fragment source permet de localiser et de déchiffrer tous les fragments FBL générés, ce qui peut permettre à un pair de n'avoir qu'un seul fragment source à partir duquel il peut, s'il le souhaite, procéder à la restauration de tous les fichiers qu'il a sauvegardés.
Selon un autre exemple de mise en œuvre de l'invention, plusieurs fragments sources peuvent être générés, chaque fragment source permettant de localiser et de déchiffrer une partie des fragments FBL associés aux fichiers sauvegardés, ce qui peut permettre d'associer un fragment source par groupe de fichiers sauvegardés.
Une clé permettant de localiser ou de chiffrer un fragment source peut être calculée de la même façon que définie précédemment.
Les clés permettant de localiser et de chiffrer les fragments source peuvent être différentes d'un fragment source à l'autre, ce qui peut permettre d'éviter qu'un nœud ayant connaissance des clés relatives à un fragment source puisse avoir accès aux autres fragments sources, mais aussi les collisions entre fragments source.
Les fichiers peuvent être regroupés dans un fragment source particulier selon leur type, leur contenu ou les droits d'accès y étant associés.
Des types de fichiers selon l'invention sont par exemple les photos, les vidéos, les enregistrements sonores ou encore les textes.
Toujours selon cet exemple de mise en œuvre de l'invention, un fragment racine permettant de localiser et de déchiffrer les fragments sources peut être généré, ce fragment racine pouvant être sauvegardé dans la mémoire d'au moins un terminal du réseau P2P. L'invention a encore pour objet, selon un autre de ses aspects un procédé de restauration d'au moins un fichier sauvegardé dans les mémoires de terminaux d'un réseau pair à pair sous la forme de fragments de données (FB) auxquels est associé un fragment de description (FBL) répertoriant les fragments de données, ce fragment FBL étant localisable et déchiffrable par un fragment source à accès protégé sauvegardé dans la mémoire d'un terminal du réseau, procédé dans lequel : un pair accède au fragment source depuis un terminal quelconque du réseau pour déterminer la liste des fichiers sauvegardés dans le réseau, le pair sélectionne au moins un fichier à restaurer dans la liste, le pair lance le processus de restauration automatique du ou des fichiers sélectionnés depuis ce terminal.
Le procédé peut comporter une étape de mise à jour de la liste des fichiers sauvegardés, pour prendre par exemple en compte la sauvegarde par le pair d'un nouveau fichier dans le réseau ou la suppression d'un fichier dans le réseau
Le procédé peut comporter une étape de test de disponibilité et d'intégrité sur des fichiers de la liste. Ces tests peuvent être effectués de manière périodique pour s'assurer que le procédé de restauration est opérationnel et peuvent ne concerner seulement qu'un fichier, voire plusieurs, voire encore la totalité des fichiers de la liste.
L'invention a encore pour objet, selon un autre de ses aspects, un procédé de diffusion sélective d'au moins un fichier enregistré dans les mémoires de terminaux d'un réseau pair à pair, ce fichier étant fragmenté en plusieurs fragments de données (FB) auxquels est associé un fragment de description (FBL) répertoriant les fragments FB, ce fragment FBL étant localisable et déchiffrable par un fragment source à accès protégé sauvegardé dans la mémoire d'un terminal du réseau, procédé dans lequel on permet à un client du réseau recherchant le fichier enregistré et ayant satisfait une condition prédéfinie l'accès au fragment source et la récupération du fichier recherché.
L'accès au fichier recherché peut être permis en fournissant au client du réseau une clé permettant de localiser le fragment source et/ou une clé permettant de déchiffrer le fragment source. La clé permettant de localiser et/ou la clé permettant de déchiffrer le fragment source est par exemple propre à chaque client, ce qui peut permettre en attribuant des clés personnelles à chaque client de limiter les risques d'accès frauduleux au fichier.
Le procédé peut comporter une étape de test de disponibilité et d'intégrité sur le fichier. Ce test peut être effectué de manière périodique pour s'assurer que le procédé de diffusion est opérationnel.
L'invention a encore pour objet, selon un autre de ses aspects un procédé de sauvegarde d'au moins un fichier enregistré par un pair dans les mémoires de terminaux d'une pluralité de nœuds d'un réseau pair à pair, chaque fichier étant fragmenté en plusieurs fragments de données (FB) auxquels est associé un fragment de description (FBL) répertoriant les fragments de données, procédé dans lequel : - on génère au moins un fragment source permettant de localiser et de déchiffrer au moins une partie des fragments FBL,
- on génère, pour ce fragment source, une clé permettant de localiser et une clé permettant de chiffrer le fragment source en fonction d'un secret de l'utilisateur, et
- on sauvegarde le fragment source dans la mémoire d'au moins un terminal du réseau.
Le réseau P2P peut être un réseau privé domotique.
En variante, le réseau P2P est un réseau privé d'entreprise, distribué ou non sur plusieurs sites géo graphiquement distants.
Dans une autre variante, le réseau P2P utilise le réseau internet. L'invention pourra être mieux comprise à la lecture de la description qui va suivre, d'exemples non limitatifs de celle-ci, et à l'examen du dessin annexé, sur lequel :
- les figures 1 et 2 illustrent un exemple de procédé de sauvegarde et de restauration de fichiers déjà connu,
- les figures 3 et 4 illustrent des systèmes de sauvegarde et de restauration de fichiers selon l'invention,
- la figure 5 représente de façon schématique un exemple de fragment source selon l'invention,
- les figures 6 et 7 illustrent un exemple de procédé de sauvegarde de fichier et un exemple de restauration de fichier selon l'invention, et - les figures 8 à 16 représentent des exemples d'application de l'invention.
On a représenté aux figures 3 et 4 un exemple de sauvegarde par un pair de fichiers 13X selon l'invention. Chaque fichier 13X est par exemple fragmenté en plusieurs fragments de données (FB) 11 auxquels est associé un fragment de description (FBL) 10 répertoriant les fragments FB, similairement aux systèmes connus décrits ci-dessus. Comme on peut le voir sur la figure 4, les fragments FBL 1O1 et FB 1 Ij peuvent être enregistrés dans les mémoires de terminaux 3 constituant un réseau pair à pair 1 , ces terminaux pouvant être différents de celui du pair ayant enregistré les fichiers 13^ Bien que les terminaux 3 soient représentés sous la forme d'ordinateurs à la figure 4, l'invention n'est bien sûr pas limitée à l'emploi de tels terminaux, comme on le verra par la suite.
Selon l'invention, au moins un fragment source 9 est enregistré dans la mémoire d'un terminal 3 du réseau 1, ce terminal étant dans l'exemple décrit différent du terminal du pair ayant enregistré les fichiers 13^
Pour des raisons de sécurité, le fragment source 9 peut être enregistré dans la mémoire de plusieurs nœuds distincts et/ou être enregistré dans un serveur de sauvegarde non représenté. Un tel serveur de sauvegarde peut être mis en place par un opérateur ou une autre entité de confiance.
Comme on peut le voir à la figure 3, l'invention permet d'ajouter un niveau de hiérarchie aux fragments FBL 1O1 et FB Hj grâce au fragment source 9 qui permet la localisation et le déchiffrement de l'ensemble des fragments FBL 1O1 et, par l'intermédiaire de ce dernier, la localisation de tous les fragments FB 1 Ij constituant un fichier 13^ L'invention permet, selon cet exemple, à l'utilisateur de ne plus nécessairement avoir à mémoriser un élément d'information lui permettant de retrouver la clé DHT et/ou la clé de chiffrement de l'un de ses fragments FBL.
On a représenté à la figure 5 un exemple de fragment source 9. Ce fragment contient différents champs. Un premier champ 30 attribue un identifiant/numéro au fichier 13i. Un deuxième champ 31 répertorie le nom du fichier 13X enregistré. Un troisième champ 32 correspond à une clé, par exemple une clé DHT, permettant de localiser le fragment FBL 1O1 associé au fichier 13X
Un quatrième champ 33 correspond à une clé permettant de déchiffrer le fragment FBL 1O1 associé au fichier 13^ L'accès au fragment source 9 est protégé par deux clés, une clé pour permettre la localisation du fragment source 9 dans le réseau 1 , par exemple une clé DHT, et une clé pour permettre son chiffrement dans le cas de la sauvegarde de fichier ou son déchiffrement dans le cas de la restauration de fichier ou de la diffusion de fichier.
Ces clés sont déterminées dans l'exemple décrit à partir d'un secret uniquement connu de l'utilisateur et qui peut prendre la forme d'un mot de passe, d'une clé privée, d'un code secret comme par exemple un code PIN d'un terminal, par exemple un téléphone portable ou un assistant personnel numérique appartenant au pair. La clé DHT est par exemple déterminée par hachage du mot de passe ou de la clé privée ou du code PIN.
La clé permettant chiffrer ou de déchiffrer le fragment source 9 est par exemple calculée en fonction du mot de passe, de la clé privée ou encore d'un code secret. Cette fonction de calcul permet par exemple la construction d'une clé de chiffrement ou de déchiffrement symétrique à partir d'une chaîne de caractères par redistribution des ces bits, suppression ou ajout d'autres bits.
Les différents fragments sauvegardés dans le réseau 1 relatifs à la sauvegarde d'un fichier 13X sont par conséquent chiffrés : les fragments de données FB 11 en utilisant, par exemple, la méthode « Convergent Encryption » telle que divulguée dans la publication J.R. Douceur, A. Adya, WJ. Bolosky,D. Simon et M. Theimer « Reclaiming space from duplicate files in a serverless distributed file System », les fragments FBL 1O1 en utilisant la clé de chiffrement symétrique sauvegardée dans le fragment source 9, et le fragment source 9 en utilisant une clé calculée à partir du secret du pair. Dans le cas où un nœud veut accéder, sans permission, à un fichier sauvegardé
13l5 il doit tout d'abord déterminer les clés permettant l'accès au fragment source 9. Ces clés étant, comme mentionné ci-dessus, déterminées à partir d'un secret de l'utilisateur, aucun nœud non autorisé ne peut accéder au fragment source 9 et par conséquent aux fichiers sauvegardés 13X Ainsi, aucun nœud non autorisé ne peut ni accéder à un fichier sans l'autorisation de son propriétaire, ni déterminer la liste des fichiers sauvegardés dans le réseau 1.
La sauvegarde de toutes les données associées au pair, aussi bien les données utiles que les métadonnées, dans le réseau 1, permet de garantir que le processus de restauration de ces fichiers peut démarrer, même sans disque dur ou en cas de crash du disque dur tout entier, à partir de n'importe quel terminal 3 connecté au réseau 1.
Le fragment source 9 peut encore comporter, comme représenté à la figure 5, d'autres champs 34 contenant des propriétés du fichier 13X sauvegardé. Ces propriétés concernent par exemple les droits d'accès d'utilisateurs locaux, la date de création du fichier ou encore le chemin du fichier.
Le champ 34 peut également contenir un checksum permettant de vérifier l'intégrité du fichier entier après sa restauration. Ce contrôle permet de détecter les erreurs dues à une collision entre fragments FB, ces erreurs pouvant être considérées comme négligeables.
La méthode utilisée dans les systèmes de sauvegarde tels que pStore ou
PeerStore consiste à vérifier séparément l'intégrité de chaque fragment FB. Cette vérification parcellaire de l'intégrité d'un fichier peut poser problème lorsqu'une collision entre fragments se produit, c'est-à-dire, si un autre fragment FB différent mais ayant la même valeur de clé DHT est stocké à la place d'un fragment de ce fichier. Aucune détection de la collision n'est possible dans le cas d'un contrôle parcellaire, mais le problème de collision peut être détecté si le contrôle d'intégrité global sur tout le fichier est réalisé par l'intermédiaire du fragment source 9.
L'invention permet au pair d'accéder au fragment source 9 à condition d'avoir communiqué son secret, à savoir son mot de passe, sa clé privée, son code secret ou encore son code PIN, sur la base duquel les clés permettant de localiser et de déchiffrer le fragment source 9 seront déterminées, puis de récupérer tous les fichiers qui ont été sauvegardés dans le réseau P2P.
La figure 6 représente un exemple de procédé de sauvegarde de fichiers dans un réseau 1 tel que représenté aux figures 3 et 4.
A une première étape 100, le pair sélectionne la liste des fichiers qu'il souhaite sauvegarder dans le réseau 1. A l'étape 110, le pair sélectionne une ou plusieurs propriétés à sauvegarder, ces propriétés correspondant à celles mentionnées en rapport avec le champ 34 du fragment source 9.
A l'étape 120, le pair spécifie le niveau d'importance des informations sauvegardées. A l'étape 130, les fragments FB Hj sont créés en appliquant les traitements de sécurité nécessaires et sauvegardés dans le réseau 1, et un fragment FBL 1O1 est associé pour chaque fichier 13X sauvegardé.
A l'étape 140, le pair génère pour chaque fragment FBL 1O1 une clé de localisation et une clé de chiffrement, déchiffre le fragment et le sauvegarde dans le réseau 1.
A l'étape 150, un fragment source 9 est généré avec calcul des clés permettant de localiser et de chiffrer ce fragment source 9. A l'étape 160, le pair sauvegarde ce fragment source 9 dans le réseau 1 dans la mémoire d'un ou plusieurs terminaux informatique 3 du réseau et/ou dans la mémoire d'un serveur de sauvegarde.
On a représenté à la figure 7 un exemple de procédé de restauration par un pair d'un ou plusieurs fichiers sauvegardés selon l'invention, ce procédé de restauration pouvant être effectué depuis tout terminal 3 du réseau et non uniquement depuis le terminal avec lequel le pair a, par exemple, effectué le procédé représenté à la figure 6.
A l'étape 200, l'utilisateur présente le secret qu'il a utilisé pour associer une clé de chiffrement et une clé de localisation à son fragment source 9. A l'étape 210, le pair récupère et déchiffre le fragment source 9.
A l'étape 220, le pair détermine la liste des fichiers 13X qu'il a sauvegardés dans le réseau 1. La visualisation de ces fichiers peut se faire sous la forme d'une liste plate de noms de fichiers, ou bien d'une arborescence mettant en évidence le chemin occupé à l'origine par chaque fichier sauvegardé. A l'étape 230, le pair sélectionne le nombre de fichiers qu'il souhaite restaurer, à savoir un, plusieurs ou la totalité des fichiers 13^
A l'étape 240, la restauration automatique de ce ou de ces fichiers commence par la récupération de son fragment FBL 1O1 puis de ses fragments de données FB 1 Ij.
Un pair peut aussi récupérer son fragment source 9 pour prendre en compte la sauvegarde d'un nouveau fichier dans le réseau 1 et/ou la suppression d'un fichier du réseau 1 et/ou pour effectuer des tests de disponibilité et d'intégrité sur un ou plusieurs fichiers sauvegardés 13l5 de manière à s'assurer, périodiquement ou de façon contrôlée par l'utilisateur, que le procédé de sauvegarde est opérationnel.
On va maintenant décrire en référence aux figures 8 à 16 plusieurs exemples d'applications de l'invention.
On a représenté à la figure 8 un exemple d'application de l'invention à un réseau privé domotique 1.
Ce réseau 1 comporte par exemple une pluralité d'appareils d'électroménager
« intelligents » et/ou d'appareils électroniques tels qu'un appareil photo, une caméra, un téléphone portable, un boîtier décodeur, un ordinateur, un réfrigérateur, un four, une alarme, un enregistreur vidéo, ces appareils comportant chacun une mémoire et correspondant à des terminaux informatique 3i au sens de l'invention. Tout ou partie de ces appareils peut communiquer par courants porteurs ou liaison non fïlaire, par exemple de type Bluetooth ou Wifï.
En créant un réseau pair à pair 1 dont les nœuds sont constitués par ces différents appareils, un utilisateur peut créer son propre système de restauration de fichiers distribué. En effet, il peut garder une copie des fichiers importants d'un nœud, par exemple l'ordinateur 3i ou 32, sur les autres nœuds du réseau P2P afin de les récupérer en cas de perte des fichiers originaux due à la perte du disque dur du terminal 3i ou 32.
L'invention permet, selon cet exemple, de bénéficier d'un nouveau système de restauration gratuit, et normalement fiable, les nœuds étant sous l'entier contrôle de l'utilisateur.
Dans l'exemple décrit, les différents nœuds du réseau 1 peuvent partager le même fragment source, ce qui permet de récupérer grâce au fragment source n'importe quel fichier à partir de n'importe quel nœud, indépendamment du nœud depuis lequel le fichier a été enregistré. On a représenté à la figure 9 un autre exemple d'application de l'invention pour réaliser un système de restauration de fichiers dans un réseau privé d'entreprise 1, dont les serveurs, par exemple des serveurs FTP, des serveurs de base de données ou des serveurs de courrier électronique, et les stations de travail qui correspondent à des terminaux au sens de l'invention, constituent un réseau pair à pair. Dans cet exemple, les espaces disques libres des mémoires des différents terminaux 3 sont utilisés pour enregistrer des fichiers, permettant de dupliquer les données importantes d'un nœud sur les autres nœuds du réseau 1 afin de les restaurer en cas de perte des fichiers initiaux.
L'invention permet à l'entreprise de bénéficier d'un système de restauration de fichiers : gratuit, l'entreprise n'ayant pas besoin de réserver un serveur particulier pour dupliquer les données importantes de ses différents terminaux 3, fiable, tous les nœuds étant sous l'entier contrôle de l'entreprise et, sûr, les terminaux 3 étant dans cet exemple des serveurs et les stations de travail de l'entreprise, ces différentes machines étant toujours disponibles dans le réseau, de sorte que la sauvegarde et la restauration d'un fichier dans le réseau 1 peuvent être effectuées à tout moment. L'exemple de la figure 10 diffère de celui de la figure 9 par le fait que l'entreprise est distribuée sur plusieurs sites géographiquement distants dans lesquels des réseaux intranets locaux I1, I2 et I3 similaires au réseau décrit en référence à la figure 9 existent. Dans l'exemple de la figure 10, la communication entre des réseaux intranet locaux de deux sites géographiques distants est sécurisée en établissant un tunnel VPN 2 créé par l'un des protocoles suivants : L2TP (Layer Two Tunneling Protocol), IPsec (Internet Protocol Security) ou encore MPLS VPN.
L'invention, en permettant la sauvegarde de fichiers de nœuds d'un site géographique dans des mémoires de nœuds d'autres sites géographiques, permet la restauration de ces fichiers même pour le cas où le site géographique dans lequel est situé le terminal du nœud ayant sauvegardé les fichiers viendrait à disparaître dans sa totalité en raison par exemple d'un incendie, d'une catastrophe naturelle ou d'un attentat.
Dans l'exemple de la figure 10, l'entreprise attribue, selon un premier mode de réalisation, à chaque site géographique un unique fragment source 9 permettant la restauration automatique de toutes les données importantes d'un site. Le secret permettant l'accès à ce fragment source n'est de préférence connu que par le responsable du site.
Selon un deuxième mode de réalisation, l'entreprise attribue pour chaque service de chaque site géographique, par exemple le service financier ou commercial de chaque site géographique, un seul fragment source. Dans cet exemple, le fragment source permet la restauration automatique de toutes les données importantes d'un service et son secret n'est avantageusement connu que par le directeur du service.
Selon un troisième mode de réalisation, l'entreprise attribue à chaque terminal 3 un fragment source 9. Dans cet exemple, le fragment source 9 ne permet la restauration automatique que des données importantes d'un terminal particulier et son secret n'est avantageusement connu que du propriétaire de ce terminal.
On a représenté à la figure 11 un autre exemple d'application de l'invention.
Dans cet exemple le réseau pair à pair 1 est formé par des nœuds qui sont des terminaux 3 connectés à internet.
Les terminaux 3 sont dans cet exemple choisis parmi les ordinateurs, les téléphones portables, les boîtiers décodeurs (par exemple de type « box » reliés à l'ADSL et fournissant téléphone, internet et télévision) et les assistants personnels numériques. Dans cet exemple, un pair garde une copie de ses données importantes dans les espaces disques des mémoires des terminaux des autres nœuds du réseau 1, afin de les récupérer en cas de perte de ses données locales.
Le cas échéant, un opérateur mobile ou fixe, un fournisseur d'accès, ou un nouveau fournisseur de services P2P peut facturer le service de sauvegarde et de restauration proposé au pair.
Dans cet exemple d'application, si l'utilisateur est le propriétaire d'un seul nœud, un seul fragment source lui permettant de restaurer de façon automatique et à partir de n'importe quel nœud, l'ensemble de ses données déjà sauvegardées dans le réseau 1 pourra être attribué.
Toujours dans cet exemple d'application, si l'utilisateur est le propriétaire de plusieurs nœuds, il peut choisir entre :
- partager un seul fragment source entre ses différents nœuds. Ainsi, il lui est possible de restaurer automatiquement tous ses fichiers déjà sauvegardés dans le réseau 1 indépendamment du nœud à partir duquel la sauvegarde de fichier a eu lieu ;
- attribuer à chacun de ses nœuds un fragment source différent. Dans ce cas, le processus de restauration automatique sera restreint sur les fichiers d'un seul nœud,
- attribuer à chacun de ses nœuds un fragment source différent et créer un fragment racine permettant de localiser et de déchiffrer les fragments sources propres à chacun de ses nœuds. Dans ce cas, le processus de restauration automatique peut porter sur tous les fichiers déjà sauvegardés dans le réseau 1 ou être restreint aux fichiers d'un seul nœud ;
Pour assurer le bon fonctionnement du procédé de sauvegarde et/ou de restauration, le réseau 1 peut comporter, comme représenté à la figure 12 une entité centrale de confiance 5 en communication périodique avec tous les nœuds 3 du réseau 1 et agencée pour :
- éviter les comportements égoïstes des nœuds en comptabilisant, par exemple, les ressources fournies et consommées par chaque nœud. On peut prévoir un système de facturation créditrice ou débitrice selon que les ressources fournies sont plus ou moins importantes que les ressources consommées ;
- contrôler l'accès au service P2P proposé ; - contrôler le comportement des différents nœuds au cours du fonctionnement du système, en vérifiant périodiquement que chaque nœud effectue bien le travail assigné, qu'il est disponible, que les fragments auparavant sauvegardés sont toujours bien sauvegardés et intègres. Cela permet par exemple d'évaluer le niveau de fiabilité d'un nœud, sur lequel pourrait être basée la facturation associée à un nœud ;
- assurer une bonne qualité du service aux usagers.
Pour permettre l'autorisation à un pair d'effectuer un procédé de sauvegarde et/ou de restauration selon l'invention, plusieurs solutions sont possibles :
- utilisation d'un boitier domotique spécifique pour que tous les équipements en réseau de la maison puissent en bénéficier ;
- logiciel dans le mobile spécifique permettant de sauvegarder uniquement les données de ce mobile ;
- passage par un proxy du fournisseur de service, permettant au pair d'accéder et de restaurer ses données quelle que soit la machine d'accueil (mobile, PC...) ; - obligation d'avoir un jeton d'accès signé par un nœud de confiance qui se charge de contrôler l'accès au service proposé ;
- obligation d'avoir accès à un nœud particulier du réseau, l'accès étant restreint aux seules entités autorisées à faire du service P2P.
L'accès au fichier source peut être contrôlé par un opérateur mobile ou fixe, un fournisseur d'accès ou un fournisseur de services P2P. Le contrôle d'accès peut consister par exemple en un dispositif de contrôle AAA (Authentication, Authorisation,
Accounting). Ce nœud particulier peut alors être chargé de contrôler le bon comportement des nœuds lors des différentes opérations de sauvegarde mais aussi dans la durée.
L'invention n'est pas limitée à la sauvegarde et/ou à la restauration de fichiers sauvegardés dans un réseau pair à pair.
Selon d'autres applications, elle permet la diffusion sélective dans un réseau pair à pair d'au moins un fichier, par exemple un contenu multimédia ou musical, par exemple un ou plusieurs films ou fichiers musicaux, logiciels de jeux, professionnels ou autres, enregistré dans la mémoire d'au moins un terminal du réseau. Par diffusion du secret permettant le calcul des clés DHT et de déchiffrement associées au fragment source 9 à un groupe d'utilisateurs, il est possible, grâce à l'invention, de distribuer des données à ce groupe d'utilisateurs, ce qui peut permettre d'obtenir l'équivalent d'un serveur « virtuel », dans la mesure où les fichiers à distribuer sont sauvegardés dans les mémoires de terminaux s différents.
On a représenté à la figure 13 un tel exemple d'application de l'invention. Un nœud 6 du réseau 1, appelé par la suite nœud-serveur joue le rôle d'un serveur distribuant des films, du contenu multimédia par exemple, d'autres nœuds 8 du réseau 1, appelés par la suite clients. Contrairement à un serveur de vidéo à la demande centralisé, il n'est grâce à l'invention pas nécessaire d'avoir recours à un nom DNS ou un gros espace de stockage.
Selon l'exemple représenté à la figure 13, le nœud-serveur 6 sauvegarde dans un premier temps dans les mémoires des terminaux 3 du réseau l'ensemble des films 13X à partager avec les clients du réseau 1.
Le nœud serveur 6 calcule ensuite à partir d'un secret la clé de localisation et la clé de chiffrement permettant l'accès au fragment source 9 répertoriant l'ensemble des films 13i sauvegardés puis crée et sauvegarde son fragment source dans la mémoire de n'importe quel terminal du réseau 1. Le nœud-serveur 6 transmet ensuite le secret permettant l'accès au fragment source à tout client 8 du réseau 1 ayant satisfait une condition prédéfinie étant par exemple la souscription à un abonnement.
La diffusion du secret permettant l'accès au fragment source peut prendre plusieurs formes. Par la connaissance du secret, un client 8 peut récupérer et déchiffrer le fragment source 9 du nœud-serveur 6 et donc déterminer la liste des films qui sont disponibles. De plus, à partir des informations contenues dans ce fragment source, il peut récupérer n'importe quel film H1 déjà sauvegardé par le nœud-serveur dans le réseau 1.
Bien que les données du nœud-serveur 6 soient sauvegardées dans les mémoires de terminaux 3 de différents nœuds du réseau, seuls les nœuds ayant accès au fragment source 9 peuvent accéder aux films 13^
Pour partager un nouveau film, le nœud-serveur 6 peut le sauvegarder dans le réseau 1 puis mettre à jour son fragment source 9. En récupérant la nouvelle version de ce fragment source, un client 8 pourra déterminer la nouvelle liste des films offerts par le nœud-serveur 6. Le nœud-serveur 6 peut, à tout moment, supprimer des films du réseau 1, par exemple afin de libérer de l'espace disque dans les mémoires des terminaux 3 pour sauvegarder de nouveaux films.
L'invention permet, selon cet exemple, de disposer d'un service accessible même en cas d'inaccessibilité du nœud-serveur 6 puisque toutes les informations nécessaires sont sauvegardées et distribuées sur les différents nœuds du réseau P2P.
Le secret permettant l'accès au fragment source 9 peut être diffusé auprès des clients 8 sous plusieurs formes :
- un mot de passe ou code PIN : une même chaîne de caractères est communiquée aux clients. Cette chaîne est à rentrer dans le logiciel d'accès à l'application de distribution de données.
- un secret, comme une clé privée, communiquée aux clients sur un support physique protégé, par exemple une puce électronique ou une clé USB.
- un secret personnalisé dépendant du client, étant déterminé en fonction de certaines caractéristiques de ce client, par exemple l'adresse MAC du terminal qu'il utilise. L'utilisateur télécharge un logiciel client auquel il devra rentrer le secret personnalisé. Le logiciel pourra alors calculer le secret permettant l'accès au fragment source en fonction de ce secret personnalisé. Le secret personnalisé peut encore être déterminé à l'aide d'autres caractéristiques du client, comme par exemple son numéro d'abonné lorsqu'il a souscrit un abonnement auprès d'un opérateur.
La communication du secret permettant l'accès au fragment source ou, le cas échéant du secret personnalisé peut prendre les formes suivantes :
- communication du secret par courrier email ou postal,
- téléchargement par le logiciel client du secret auprès d'un serveur en ligne. Le téléchargement auprès du serveur peut être considéré comme quasi transparent pour l'utilisateur. De plus, le logiciel client peut fournir un numéro de série ou un nom de client de manière à ce que le serveur contrôle la diffusion et la personnalisation du secret,
- téléchargement par l'utilisateur du secret auprès d'un serveur en ligne. Après s'être authentifié auprès de ce serveur l'utilisateur télécharge par exemple le secret, et configure en conséquence son logiciel client. En variante, le fichier à diffuser est un fichier relatif à une publicité ou à caractère informatif et le nœud-serveur 6 peut diffuser le secret à tous les clients 8 du réseau 1 en ayant fait la demande.
Les droits de modification du fragment source, pour ajouter ou supprimer un nouveau fichier sauvegardé, peuvent être réservés au nœud-serveur 6 afin d'éviter qu'un client auquel le secret a été révélé ne puisse modifier les contenus sauvegardés. Ce contrôle de ces droits de modification du fragment source peut être assuré par un serveur centralisé dans lequel sont mémorisés tous les fragments sources du réseau, et qui n'accorde les droits de modification qu'au seul nœud- serveur 6 et ne donne le droit de lecture qu'aux seuls clients 8.
Dans un autre exemple d'application, l'invention permet le partage de fichiers entre les nœuds du réseau 1 par la connaissance d'un fragment source 9. Le principe est identique au principe de diffusion d'un fichier par un nœud serveur 6 à un client 8 décrit ci-dessus, excepté le fait que les droits de modification du fragment source sont ouverts à tous les nœuds du réseau. Les mêmes services sont possibles, à savoir le contrôle d'accès au secret du fragment source 9, les mises à jour du fragment source 9, et les gestions des différentes versions des fichiers sauvegardés 13L
L'invention peut aussi permettre la création d'un fragment racine permettant de localiser et de déchiffrer une pluralité de fragments sources 9 sauvegardés dans le réseau 1. Dans l'exemple représenté à la figure 14, le fragment racine 7 permet de localiser et de déchiffrer des premiers fragments sources 9a, ces derniers permettant de localiser et de déchiffrer des deuxièmes fragments sources 9b qui sont similaires aux fragments sources décrits en référence aux figures précédentes. Dans cet exemple, l'accès à chaque fragment source 9a ou 9b est conditionné par la connaissance d'un secret selon les exemples décrits précédemment. Le secret est différent d'un premier fragment source 9a à l'autre, ainsi que d'un deuxième fragment source 9b à l'autre. Ainsi, l'accès à un seul fragment source ne permet la récupération que d'un sous ensemble de fichiers. Seul l'accès au fragment racine 7, conditionné par exemple par la connaissance d'un secret permettant de calculer des clés pour localiser et déchiffrer le fragment racine, peut permettre l'accès à tous les fragments sources et la récupération intégrale des fichiers sauvegardés dans le réseau 1.
Dans cet exemple, le premier fragment source 9ai contient des clés permettant de localiser et de déchiffrer les deuxièmes fragments sources 9bi, 9b2 et 9b3, ce qui permet de localiser et de déchiffrer les fragments FBL 1Oi à IO5 et IO7, et par conséquent l'accès aux fichiers 13i à 13s et 137.
Selon cet exemple, l'invention peut permettre au pair ayant sauvegardé les fichiers dont la restauration est permise grâce à l'accès au fragment racine 7 de ne diffuser qu'un sous ensemble de fichiers à un client du réseau. Si ce client ne peut, selon l'exemple de la figure 14, accéder qu'au deuxième fragment source 9bi, il ne peut récupérer que les fragments FBL 1Oi à IO3 et par conséquent ne récupérer que les fichiers 13i à 133-
Selon cet exemple, le pair peut ne décider de ne partager qu'un sous-ensemble de fichiers qu'il a sauvegardés avec d'autres nœuds du réseau. Le pair peut choisir de ne partager que les fichiers 13s et 137 avec un ou plusieurs nœuds du réseau en leur envoyant le secret ne leur permettant d'accéder qu'au deuxième fragment source %3.
Toujours selon cet exemple, l'invention permet également d'optimiser le volume d'espace disque de la mémoire des terminaux 3i en permettant à plusieurs premiers fragments sources 9a de pointer vers un même deuxième fragment source 9b, voire vers plusieurs mêmes deuxièmes fragments sources 9b. De la même façon, plusieurs deuxièmes fragments sources 9b peuvent pointer vers un même fragment FBL 10, voire vers plusieurs mêmes fragments FBL.
On a représenté à la figure 15 un exemple d'application de l'invention dans lequel deux fragments racines 1\ et 72 associés à deux pairs différents pointent vers un même fragment source 90. Ce fragment source 9o permet, par exemple, l'accès à l'ensemble des fichiers partagés entre les deux pairs.
Ainsi, chacun du pair ayant accès au fragment racine 1\ et de celui ayant accès au fragment racine 72 peut être considéré comme le propriétaire du fragment source % et des fichiers auxquels l'accès est ainsi permis, bien que ces fichiers ne soient sauvegardés qu'une seule fois dans le réseau.
Le pair ayant sauvegardé les fichiers dont l'accès est permis par le fichier racine n'a pas besoin de retenir les secrets permettant l'accès aux différents fragments sources ou, lorsque les fragments sources sont hiérarchisés en premiers et deuxièmes fragments sources, les secrets permettant l'accès à ces différents fragments sources, mais uniquement celui du fragment racine, ce dernier contenant avantageusement les secrets permettant l'accès aux fragments sources. Dans le cas de l'exemple de la figure 14, si un nœud-serveur 6 souhaite permettre à un client d'accéder à l'intégralité des fichiers qu'il a sauvegardés dans le réseau, il suffit de lui communiquer le secret permettant l'accès au fragment racine 7, de cette façon il pourra obtenir la liste des premiers fragments sources 9a, permettant eux- mêmes l'accès aux deuxièmes fragments sources 9b.
On a représenté à la figure 16 un exemple de procédé de répartition des fichiers sauvegardés au sein de différents fragments sources 9.
Dans l'exemple représenté, on associe pour chaque type de fichier sauvegardé un fragment source 9. Le fragment source 9\ n'est par exemple relatif qu'à des fichiers contenant des photos, ce qui permet au pair de restreindre sa restauration automatique à l'ensemble de ses photos qui ont été sauvegardées dans le réseau 1.
Dans un autre exemple, on regroupe les fichiers sauvegardés selon leurs contenus. Par exemple, un nœud-serveur offrant des films vidéo peut associer à chaque catégorie de films (culturel, sport, ...) un fragment source 9. Par la suite, un client peut s'abonner à une catégorie particulière de films en demandant le secret permettant l'accès audit fragment source 9.
Dans un autre exemple, on regroupe les fichiers sauvegardés selon les droits d'accès par les nœuds du réseau aux fichiers sauvegardés. On associe par exemple aux fichiers privés un fragment source dont le secret peut n'être jamais transmis aux autres nœuds du réseau, et on associe aux fichiers publics un autre fragment source dont le secret peut être transmis à tous les nœuds du réseau.
Du fait de la propriété d'optimisation du volume d'espace disque mémoire précédemment décrit, l'invention peut permettre de regrouper les fichiers sauvegardés dans une base de fragments sources à critères multiples, le nombre de fragments sources et de hiérarchisation de fragments sources, à savoir premiers, deuxièmes... niemes fragments sources augmentant avec le nombre de critères.
L'invention n'est bien entendu pas limitée aux exemples qui viennent d'être décrits.
On peut par exemple combiner des caractéristiques décrites en référence à différents modes de réalisation de l'invention.

Claims

REVENDICATIONS
1. Procédé de sauvegarde d'au moins un fichier (IS1) enregistré par un pair dans les mémoires de terminaux (S1) d'une pluralité de nœuds d'un réseau pair à pair (1), dans lequel :
- on permet à ce pair de sélectionner une liste de fichiers à sauvegarder,
- on crée pour chaque fichier (IS1) plusieurs fragments de données (FB) (1 Ij) et un fragment de description (FBL) (1O1) répertoriant les fragments FB,
- on génère pour chaque fragment FBL (1O1) de description une clé de localisation du fragment et une clé de chiffrement de ce fragment FBL (1O1),
- on sauvegarde les fragments FB (1 Ij) et les fragments FBL (1O1) dans les terminaux (S1) d'un réseau pair à pair
- on génère au moins un fragment source (9) à accès protégé permettant de localiser et de déchiffrer au moins une partie des fragments FBL (1O1) et, - on sauvegarde le fragment source (9) dans la mémoire d'au moins un terminal (S1) du réseau.
2. Procédé selon la revendication 1, dans lequel lors de la génération du fragment source, on calcule une clé permettant de localiser le fragment source et une clé permettant de chiffrer le fragment source.
3. Procédé selon la revendication précédente, dans lequel on calcule la clé permettant de localiser le fragment source (9) par hachage d'au moins un secret associé au pair.
4. Procédé selon la revendication 2 ou 3, dans lequel on calcule la clé permettant de chiffrer le fragment source (9) en fonction d'au moins un secret associé au pair.
5. Procédé selon l'une des deux revendications immédiatement précédentes, dans lequel un secret associé au pair est choisi parmi un mot de passe, une clé privée, et un code secret associé à un terminal du pair.
6. Procédé selon l'une quelconque des revendications précédentes, dans lequel on permet au pair de sélectionner au moins une propriété à sauvegarder par fichier enregistré dans les mémoires de terminaux du réseau.
7. Procédé selon la revendication précédente, dans lequel ladite au moins une propriété est choisie parmi la somme de contrôle du fichier (checksum) et/ou la date de création du fichier et/ou les droits d'accès au fichier et/ou le chemin du fichier et/ou la version du fichier.
8. Procédé selon l'une quelconque des revendications précédentes, dans lequel on permet au pair de spécifier le niveau d'importance du fichier sauvegardé.
9. Procédé selon l'une quelconque des revendications précédentes, dans lequel on permet au pair de modifier un fragment source (9) déjà généré pour prendre en compte : la sauvegarde d'un nouveau fichier (IS1) dans les mémoires de terminaux (S1) du réseau et/ou la suppression d'un fichier sauvegardé.
10. Procédé selon l'une quelconque des revendications précédentes dans lequel le fragment source (9) permet de localiser et de déchiffrer tous les fragments FBL (1O1) générés.
11. Procédé selon l'une quelconque des revendications 1 à 9, dans lequel on génère plusieurs fragments sources (9), chaque fragment source (9) permettant de localiser et de déchiffrer une partie des fragments FBL (1O1) générés.
12. Procédé selon la revendication précédente, dans lequel on calcule pour chaque fragment source (9) deux clés, l'une permettant de localiser et l'autre de chiffrer le fragment source (9).
13. Procédé selon la revendication précédente, dans lequel les clés permettant de localiser et de chiffrer le fragment source (9) diffèrent d'un fragment source à l'autre.
14. Procédé selon l'une des deux revendications immédiatement précédentes, dans lequel on regroupe les fichiers (13^ sauvegardés dans un fragment source (9) particulier selon leur type, leur contenu ou les droits d'accès y étant associés.
15. Procédé selon l'une quelconque des revendications 11 à 14, dans lequel on génère un fragment racine (7) permettant de localiser et de déchiffrer les fragments sources (9) et dans lequel on sauvegarde ce fragment racine (7) dans la mémoire d'au moins un terminal (3i) du réseau.
16. Procédé de diffusion sélective d'au moins un fichier (13^ enregistré dans la mémoire d'au moins un terminal (3i) d'un réseau pair à pair (1), ce fichier (13^ étant fragmenté en plusieurs fragments de données FBI (Hj), auxquels est associé un fragment de description (FBL) (1O1) répertoriant les fragments (FBL) (Hj), ces fragments FBL (1O1) étant localisables et déchiffrables par un fragment source (9) à accès protégé sauvegardé dans la mémoire d'un terminal du réseau, procédé dans lequel on permet à un client (8) du réseau recherchant le fichier enregistré (IS1) et ayant satisfait une condition prédéfinie l'accès au fragment source (9) et la récupération du fichier recherché.
17. Procédé selon la revendication précédente, dans lequel on permet l'accès au fichier recherché (IS1) en fournissant au client (8) du réseau une clé permettant de localiser le fragment source (9) et/ou une clé permettant de déchiffrer le fragment source
(9).
18. Procédé selon la revendication précédente, dans lequel la clé permettant de localiser et/ou la clé permettant de déchiffrer le fragment source est propre au client (8).
19. Procédé selon l'une quelconque des revendications 16 à 18, comportant une étape de test de disponibilité et d'intégrité du fichier recherché.
20. Procédé de restauration d'au moins un fichier sauvegardé (IS1) dans les mémoires de terminaux (S1) d'un réseau pair à pair sous la forme de fragments de données
(l lj) auxquels est associé un fragment de description (1O1) répertoriant les fragments de données, ce fragment de description étant localisable et déchiffrable par un fragment source (9) à accès protégé sauvegardé dans la mémoire d'un terminal du réseau, procédé dans lequel : - un pair accède au fragment source (9) pour, depuis un terminal quelconque du réseau, déterminer la liste des fichiers sauvegardés dans le réseau
- le pair sélectionne au moins un fichier à restaurer (IS1) dans la liste,
- le pair lance le processus de restauration automatique du ou des fichiers sélectionnés depuis ce terminal.
21. Procédé selon la revendication précédente, comportant une étape de mise à jour de la liste des fichiers sauvegardés.
22. Procédé selon l'une des deux revendications immédiatement précédentes, comportant une étape de test de disponibilité et d'intégrité sur des fichiers répertoriés dans le fragment source.
23. Procédé de sauvegarde d'au moins un fichier (13i) enregistré par un pair dans les mémoires de terminaux (3^ d'une pluralité de nœuds d'un réseau pair à pair, chaque fichier étant fragmenté en plusieurs fragments de données (Hj) auxquels est associé un fragment de description (1O1) répertoriant les fragments de données, procédé dans lequel :
- on génère au moins un fragment source permettant de localiser et de déchiffrer au moins une partie des fragments de description, - on génère pour ce fragment source (9) une clé permettant de localiser et une clé permettant de chiffrer le fragment source (9) en fonction d'un secret de l'utilisateur, et
- on sauvegarde le fragment source dans la mémoire d'au moins un terminal du réseau.
PCT/FR2009/050560 2008-04-02 2009-04-01 Procede de sauvegarde/restauration de fichiers dans un reseau pair a pair WO2009136030A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0852170 2008-04-02
FR0852170A FR2929792B1 (fr) 2008-04-02 2008-04-02 Procede de sauvegarde/restauration de fichiers dans un reseau pair a pair.

Publications (1)

Publication Number Publication Date
WO2009136030A1 true WO2009136030A1 (fr) 2009-11-12

Family

ID=40091287

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2009/050560 WO2009136030A1 (fr) 2008-04-02 2009-04-01 Procede de sauvegarde/restauration de fichiers dans un reseau pair a pair

Country Status (2)

Country Link
FR (1) FR2929792B1 (fr)
WO (1) WO2009136030A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220283678A1 (en) * 2019-09-06 2022-09-08 Dropbox, Inc. Generating a customized organizational structure for uploading content to a cloud-based storage system

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040153458A1 (en) * 2002-11-08 2004-08-05 Noble Brian D. Peer-to-peer method and system for performing and managing backups in a network of nodes
WO2008017505A1 (fr) * 2006-08-11 2008-02-14 Velocix Limited Amélioration des performances de stockage

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040153458A1 (en) * 2002-11-08 2004-08-05 Noble Brian D. Peer-to-peer method and system for performing and managing backups in a network of nodes
WO2008017505A1 (fr) * 2006-08-11 2008-02-14 Velocix Limited Amélioration des performances de stockage

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BATTEN C ET AL: "pStore: A Secure Peer-to-Peer Backup System (MIT-LCS-TM-632)", INTERNET CITATION, XP002233336, Retrieved from the Internet <URL:http://www.cag.lcs.mit.edu/~kbarr/pstore/pStore.pdf> [retrieved on 20030304] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220283678A1 (en) * 2019-09-06 2022-09-08 Dropbox, Inc. Generating a customized organizational structure for uploading content to a cloud-based storage system
US11775140B2 (en) * 2019-09-06 2023-10-03 Dropbox, Inc. Generating a customized organizational structure for uploading content to a cloud-based storage system

Also Published As

Publication number Publication date
FR2929792B1 (fr) 2010-05-21
FR2929792A1 (fr) 2009-10-09

Similar Documents

Publication Publication Date Title
US11863380B2 (en) Community internet drive
US8843637B2 (en) Managed peer-to-peer content backup service system and method using dynamic content dispersal to plural storage nodes
US9824230B2 (en) Remote data access techniques for portable devices
US9858397B1 (en) Distributing digital-works and usage-rights to user-devices
US10693839B2 (en) Digital media content distribution blocking
US20020152262A1 (en) Method and system for preventing the infringement of intellectual property rights
US20060173974A1 (en) System and method for providing mobile access to personal media
US20020152261A1 (en) Method and system for preventing the infringement of intellectual property rights
US20100235878A1 (en) Method and system for file distribution
US20130305385A1 (en) Streaming audio playback service and methodology
FR2868896A1 (fr) Procede et dispositif de controle d&#39;acces a un document numerique partage dans un reseau de communication de type poste a poste
FR2860935A1 (fr) Procede et dispositif de traitement de donnees numeriques
EP1637989A1 (fr) Procédé et système de séparation de comptes de données personnelles
WO2006016085A1 (fr) Procede de sauvegarde distribuee sur des postes clients dans un reseau informatique
WO2021043599A1 (fr) Migration d&#39;une chaîne de blocs de données
WO2009136030A1 (fr) Procede de sauvegarde/restauration de fichiers dans un reseau pair a pair
WO2015197930A1 (fr) Procédé de partage de fichiers numériques entre plusieurs ordinateurs, et ordinateur, ensemble de stockage de données et système de partage de fichiers numériques associés
FR2901381A1 (fr) Systeme informatique a gestion universelle et collaborative de fichiers utilisateurs
Suthar et al. PMS-Sharing: Framework for Automatically Authenticating users in a Group to Allow Sharing Storage
FR2994003A1 (fr) Dispositif informatique de stockage de donnees privees totalement distribue en environnement hostile
FR2901386A1 (fr) Support personnel de memoire de masse portatif et systeme informatique d&#39;acces securise a un reseau par des utilisateurs.
FR2988250A1 (fr) Procede de validation d&#39;une transaction
FR2810756A1 (fr) Systeme et procede d&#39;acces etendu a une plurialite de ressources internet a partir d&#39;un terminal d&#39;acces internet

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09742228

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09742228

Country of ref document: EP

Kind code of ref document: A1