WO2008065347A2 - Mssan - Google Patents

Mssan Download PDF

Info

Publication number
WO2008065347A2
WO2008065347A2 PCT/GB2007/004431 GB2007004431W WO2008065347A2 WO 2008065347 A2 WO2008065347 A2 WO 2008065347A2 GB 2007004431 W GB2007004431 W GB 2007004431W WO 2008065347 A2 WO2008065347 A2 WO 2008065347A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
access
users
network
allows
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/GB2007/004431
Other languages
English (en)
Other versions
WO2008065347A3 (fr
Inventor
David Irvine
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
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
Priority claimed from GB0624056A external-priority patent/GB2446169A/en
Application filed by Individual filed Critical Individual
Publication of WO2008065347A2 publication Critical patent/WO2008065347A2/fr
Publication of WO2008065347A3 publication Critical patent/WO2008065347A3/fr
Priority to US12/476,162 priority Critical patent/US20100058054A1/en
Anticipated expiration legal-status Critical
Priority to US13/569,962 priority patent/US20120311339A1/en
Ceased legal-status Critical Current

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
    • 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/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • 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
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • 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/1076—Resource dissemination mechanisms or network resource keeping policies for optimal resource availability in the overlay network
    • 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/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection

Definitions

  • US6859812 discloses a system and method for differentiating private and shared files, where clustered computers share a common storage resource, Network-Attached Storage (NAS) and Storage Area Network (SAN), therefore not distributed as in this present invention.
  • NAS Network-Attached Storage
  • SAN Storage Area Network
  • US5313646 has a system which provides a copy-on-write feature which protects the integrity of the shared files by automatically copying a shared file into user's private layer when the user attempts to modify a shared file in a back layer, this is a different technology again and relies on user knowledge - not anonymous.
  • WO02095545 discloses a system using a server for private file sharing which is not anonymous.
  • a computer system having plural nodes interconnected by a common broadcast bus is disclosed by US5117350.
  • US5423034 shows how each file and level in the directory structure has network access privileges.
  • the file directory structure generator and retrieval tool have a document locator module that maps the directory structure of the files stored in the memory to a real world hierarchical file structure of files. Therefore not distributed across public networks or anonymous or self encrypting, the present inventions does not use broadcasting in this manner.
  • Authentication servers are for user and data transaction authentication e.g. JP2005311545 which describe a system wherein the application of 'a digital seal 1 to electronic documents conforms to the Electronic Signature Act. This is similar to the case of signing paper documents but uses the application of an electronic signature through an electronic seal authentication system.
  • the system includes: client computers, to each of which a graphics tablet is connected; an electronic seal authentication server and a PKI authentication server, plus the electronic seal authentication server.
  • US2004254894 discloses an automated system for the confirmed efficient authentication of an anonymous subscriber's profile data in this case.
  • Self- verifying certificate for computer system uses private and public keys - no chunking but for trusted hardware subsystems (US2002080973) this is a mechanism of self signing certificates for authentication, again useful for effort based computing but not used in this present invention.
  • Other authentication modes are, device for exchanging packets of information (JP2001186186), open key certificate management data (JP10285156), and certification for authentication (WO96139210).
  • Authentication for Peer to Peer system is demonstrated by digital rights management (US2003120928). Digital rights management and CSC (part of that patent s a DRM container) issues which are based on ability to use rather than gaining access to network or resources and therefore not prior art.
  • Known self-healing techniques are divided broadly into two classes.
  • One is a centralized control system that provides overall rerouting control from the central location of a network.
  • the rerouting algorithm and the establishing of alarm collection times become increasingly complex as the number of failed channels increases, and a substantial amount of time will be taken to collect alarm signals and to transfer rerouting information should a large number of channels of a multiplexed transmission system fail.
  • the other is a distributed approach in which the rerouting functions are provided by distributed points of the network.
  • the following papers on distributed rerouting approach have been published: (these are all related to self healing but from a network pathway perspective and therefore are not prior art for this invention which deals with data or data chunks self healing mechanisms.
  • Patents W09637837, TW223167B, US6760756 and US7099898 describe methods of data replication and retention of data during failure.
  • Patent WO200505060625 discloses method of secure interconnection when failure occurs.
  • Network firewalls are typically based on packet filtering which is limited in principle, since the rules that judge which packets to accept or reject are based on subjective decisions.
  • VPNs Virtual Private Networks
  • other forms of data encryption, including digital signatures are not really safe because the information can be stolen before the encryption process, as default programs are allowed to do whatever they like to other programs or to their data files or to critical files of the operating system.
  • This is done by (CA247150) automatically creating an unlimited number of Virtual Environments (VEs) with virtual sharing of resources, so that the programs in each VE think that they are alone on the computer.
  • the present invention takes a totally different approach to security and obviates the requirement of much of the above particularly CA2471505.
  • a storage area network which is a shared, dedicated high-speed network for connecting storage resources to the servers. While the storage area networks are generally more flexible and scalable in terms of providing end user connectivity to different server-storage environments, the systems are also more complex. The systems require hardware, such as gateways, routers, switches, and are thus costly in terms of hardware and associated software acquisition. Yet another type of storage system is a network attached storage system in which one or more special-purpose servers handle file storage over the LAN.
  • Another file storage system utilizes distributed storage resources resident on various nodes, or computers, operating on the system, rather than a dedicated centralised storage system. These are distributed systems, with the clients communicating peer-to-peer to determine which storage resources to allocate to particular files, directories and so forth. These systems are organized as global file stores that are physically distributed over the computers on the system.
  • a global file store is a monolithic file system that is indexed over the system as, for example, a hierarchical directory.
  • the nodes in the systems use Byzantine agreements to manage file replications, which are used to promote file availability and/or reliability. The Byzantine agreements require rather lengthy exchanges of messages and thus are inefficient and even impractical for use in a system in which many modifications to files are anticipated.
  • US200211434 shows a peer-to- peer storage system which describes a storage coordinator that centrally manages distributed storage resources. The difference here is the requirement of a storage broker, making this not fully distributed.
  • the present invention also differs in that the present invention has no central resources for any of the system and we also encrypt data for security as well as the self healing aspect of our system which is again distributed.
  • US7010532 discloses improved access to information stored on a storage device.
  • a plurality of first nodes and a second node are coupled to one another over a communications pathway, the second node being coupled to the storage device for determining meta data including block address maps to file data in the storage device.
  • JP2003273860 discloses a method of enhancing the security level during access of an encrypted document including encrypted content.
  • a document access key for decrypting an encrypted content within an encrypted document is stored in a management device, and a user device wishing to access the encrypted document transmits its user ID and a document identification key for the encrypted document, which are encrypted by a private key, together with a public key to the management device to request transmission of the document access key. Differing from this invention in that it never transmit user id or login in the network at all. Also it does not require management devices of any form.
  • JP2002185444 discloses improves security in networks and the certainty for satisfying processing requests.
  • a print server forms a secret key and a public key, and delivers the public key to a user terminal, which forms a user ID, a secret key and a public key, encrypts the user ID and the public key by using the public key, and delivers them to the print server.
  • This is not linked at all to this invention and is a system for a PKI infrastructure for certificate access to network nodes.
  • the private and public keys of users are used in US6925182, and are encrypted with a symmetric algorithm by using individual user identifying keys and are stored on a network server making it a different proposition from a distributed network
  • US2005091234 describes data chunking system which divides data into predominantly fixed-sized chunks such that duplicate data may be identified. This is associated with storing and transmitting data for distributed network.
  • US2006206547 discloses a centralised storage system, whilst US2005004947 discloses a new PC based file system.
  • US2005256881 discloses data storage in a place defined by a path algorithm. This is a server based duplicate removal and not necessarily encrypting data, unlike the present invention which does both and requires no servers.
  • Hardware system which consists of a processor module, a redundant non-volatile memory system, such as dual disk drives, and multiple communications interfaces. This type of security system must be unlocked by a pass phrase to access data, and all data is transparently encrypted, stored, archived and available for encrypted backup.
  • a system for maintaining secure communications, file transfer and document signing with PKI, and a system for intrusion monitoring and system integrity checks are provided, logged and selectively alarmed in a tamper-proof, time-certain manner.
  • a system of sharing access to private files which has the functional elements of:
  • a product with simple granular accessibility to data in distributed network or corporate network A system with simple granular accessibility to data in distributed network or corporate network which is made of inter linkage all or some of the following elements:
  • a product for a simple granular accessibility to data in distributed network or corporate network which is made of inter linkage all or some of the following elements and sub-elements:
  • a method of above where granular system access to all data is created comprising of the following steps;
  • a Users log in with a created base ID; b. The ID is validated from a supervising node (this is a manager); c. Users provided a further key (manager's key) to allow access by manager.
  • a method of above where the corporate structure decided upon can be viewed as a tree and accessed as such, to provide access to all users' data beneath or equivalent in some cases to the current user level.
  • a method of providing file sharing via the implementation of the shared access to private files invention is a method of providing file sharing via the implementation of the shared access to private files invention.
  • a method where all or some copies of data can be stored on the Internet to allow users access from any internet location, removing the requirement for VPN.
  • a method of implementing granular security levels comprising the following options;
  • a method where the supervisor or maid ID can be replicated in an shared mechanism such as n + p key sharing, allowing a key to be split across many parties but require only a percentage to retrieve the main key.
  • MID - this is the base ID and is mainly used to store and forget files. Each of these operations will require a signed request. Restoring may simply require a request with an ID attached.
  • PMID - This is the proxy mid which is used to manage the receiving of instructions to the node from any network node such as get/ put / forget etc.
  • TMID - This is today's ID a one time ID as opposed to a one time password. This is to further disguise users and also ensure that their MID stays as secret as possible.
  • MAID - this is basically the hash of and actual public key of the MID. This ID is used to identify the user actions such as put / forget / get on the maidsafe.net network. This allows a distributed PKI infrastructure to exist and be automatically checked.
  • KID - Kademlia ID this can be randomly generated or derived from known and preferably anonymous information such as an anonymous public key hash as with the MAID.. In this case we use kademlia as the example overlay network although this can be almost any network environment at all.
  • MSID - maidsafe.net Share ID an ID and key pair specifically created for each share to allow users to interact with shares using a unique key not related to their MID which should always be anonymous and separate.
  • Anonymous authentication relates to system authentication and, in particular, authentication of users for accessing resources stored on a distributed or peer-to-peer file system. Its aim is to preserve the anonymity of the users and to provide secure and private storage of data and shared resources for users on a distributed system. It is a method of authenticating access to a distributed system comprising the steps of;
  • Receiving, retrieving and authenticating may be performed on a node in the distributed system preferably separate from a node performing the step of decrypting.
  • the method further comprises the step of generating the user identifier using a hash. Therefore, the user identifier may be considered unique (and altered if a collision occurs) and suitable for identifying unique validation records.
  • the step of authenticating access may preferably further comprise the step of digitally signing the user identifier. This provides authentication that can be validated against trusted authorities.
  • the method further comprises the step of using the signed user identifier as a session passport to authenticate a plurality of accesses to the distributed system. This allows persistence of the authentication for an extended session.
  • the step of decrypting preferably comprises decrypting an address in the distributed system of a first chunk of data and the step of authenticating access further comprises the step of determining the existence of the first chunk at the address, or providing the location and names of specific data elements in the network in the form of a data map as previously describe. This efficiently combines the tasks of authentication and starting to retrieve the data from the system.
  • the method preferably further comprises the step of using the content of the first chunk to obtain further chunks from the distributed system. Additionally the decrypted data from the additional chunks may contain a key pair allowing the user at that stage to sign a packet sent to the network to validate them or additionally may preferable self sign their own id.
  • a client node comprising a decryption module adapted to decrypt an encrypted validation record so as to provide decrypted information
  • a verifying node comprising: • a receiving module adapted to receive a user identifier;
  • a retrieving module adapted to retrieve from the storage module an encrypted validation record identified by the user identifier
  • an authentication module adapted to authenticate access to data in the distributed file system using the decrypted information from the client node.
  • the client node is further adapted to generate the user identifier using a hash.
  • the authentication module is further adapted to authenticate access by digitally sign the user identifier.
  • the signed user identifier is used as a session passport to authenticate a plurality of accesses by the client node to the distributed system.
  • the decryption module is further adapted to decrypt an address in the distributed system of a first chunk of data from the validation record and the authentication module is further adapted to authenticate access by determining the existence of the first chunk at the address.
  • the client node is further adapted to use the content of the first chunk to obtain further authentication chunks from the distributed system.
  • At least one computer program comprising program instructions for causing at least one computer to perform.
  • One computer program is embodied on a recording medium or read-only memory, stored in at least one computer memory, or carried on an electrical carrier signal.
  • the maidsafe.net product invention consists of 6 individual inventions, which collectively have 20 inter-linked functional elements, these are:.
  • the individual inventions are:
  • the inter-linked functional elements are:
  • maidsafe is a product and system (maidsafe.net) which works with linkage of numbers of elements which within themselves sub-elements.
  • Figure 1 illustrates the linkage of novel elements, perpetual data (PT1), self-encryption (PT2), data maps (PT3), anonymous authentication (PT4), shared access to private files (PT5), ms messenger (PT6), cyber cash (PT7) and world-wide voting system (PT8), which allows the maidsafe to exhibit attributes with all these novel elements and provides combined benefits such as anonymous secure communications, store and retrieve data, access data from any internet connected computing device & share resources, anonymous backup and restoring of data, share private, files & secure data without using any authentication server or file server, anonymous authentication of users (without user access lists or user-name password type devices as seen today), approve transaction based on signed serialised and anonymous digital currency and CPU sharing controlled via an anonymous voting system, added to this the anonymous voting system has vote validation and repudiation.
  • the perpetual data (PT1) itself is preferably made up from linkage of elements , peer ranking (P1), security availability (P2), self-healing (P3) and storage and retrieval (P4) which allows creation of perpetual data within distributed or peer-to-peer network. This allows data to be maintained in a manner which effectively guarantees availability barring a major global disaster.
  • Peer ranking element (P1) is preferably dependent upon another sub-element validation process (P14) to ensure data copies are both available and intact
  • security availability element (P2) is preferably dependent upon sub-element encryption/decryption (P8) to ensure data checking whilst remaining secure and anonymous
  • self-healing element (P3) preferably generates sub-element storing files (P6) which ensures data can be retrieved on hardware or software failure (such as loss of large network portions)
  • storage and retrieval element (P4) is preferably provided by sub-element revision control (P10) to allow historic data to be recovered and preferably generates sub-elements identify chunks (P9) and storing files (P6) to complete perpetual data.
  • the self-encryption (PT2) itself is made up from linkage of elements, storing file (P6), duplicate removal (P5), chunking (P7) and encryption / decryption (P8) which allows a self-encryption process to provide security and global duplicate data removal.
  • storing file element is preferably dependent upon sub-elements storage and retrieval (P4) and sub-element identify chunks (P9) and generate sub-element self-healing (P2)
  • duplicate removal element is preferably dependent on sub- element identify chunks (P9)
  • chunking element generate sub- element identify chunks (P9)
  • encryption / decryption element can be provided by sub-element provision of keys (P 13) to ensure validity of generating or requesting nodes anonymous identity (e.g. we don't know who it is but we know it was the node that put the chunk there).
  • the anonymous authentication (PT4) itself is made up from linkage of elements, logon (P12) preferably provision of key pairs (P13) and validation (P 14), to provide an anonymous authentication system for users requiring to be allowed access to resources stored on a distributed or peer-to-peer system and to preserve the anonymity of the user and to provide a mechanism for secure access to private storage of data and preferably other resources on a distributed file system.
  • logon provision of key pairs element provides a sub-element provision of public ID (P17) which allows sub-element document signing (P19), and sub-element encryption/decryption (P8) where required; element validation is dependent on sub-element anonymity (P25) and provides sub-element anonymous transaction (P24) and is provisioned by sub- element peer ranking (P1).
  • share maps element (P16)) is preferably dependent on sub-element provision of public ID (P17) and preferably sub-element encrypted communication (P18), and may make use of create map of maps element (P15) which is dependent on sub-element identify data with very small data element (P11).
  • the ms messenger (PT6) itself is made up from linkage of elements, provision of public ID (P17), preferably encrypted communication (P18) and preferably provides document signing (P19) and contract conversations (P20) to provide a system of messaging where identity is validated to prevent spam. The system further uses this identity and key pair to allow digitally validated document signing.
  • provision of public ID element (P17) is dependent on sub-element provision of key pairs (P13) and preferably generate sub-element share maps (P26), sub- element proven individual (P26) and sub-element interface with non- anonymous systems (P23).
  • the encrypted communication element (P18) generates sub-element share maps (P16) and initiates the validation process (P28) and document signing element (P19) is preferably dependent on sub-element provision of key pairs (P13)
  • a computer program consisting of a user interface and a chunk server (a system to process anonymous chunks of data) should be running, if not they are started when user selects an icon or other means of starting the program.
  • a user will input some data known to them such as a userid (random ID) and PIN number in this case. These pieces of information may be concatenated together and hashed to create a unique (which may be confirmed via a search) identifier. In this case this is called the MID (maidsafe.net ID)
  • TMID Today's MID
  • the TMID is a single use or single day ID that is constantly changed. This allows maidsafe.net to calculate the hash based on the user ID pin and another known variable which is calculable. For this variable we use a day variable for now and this is the number of days since epoch (01/01/1970). This allows for a new ID daily, which assists in maintaining the anonymity of the user.
  • This TMID will create a temporary key pair to sign the database chunks and accept a challenge response from the holder of these db chunks. After retrieval and generation of a new key pair the db is put again in new locations - rendering everything that was contained in the TMID chunk useless.
  • the TMID CANNOT be signed by anyone (therefore hackers can't BAN an unsigned user from retrieving this - in a DOS attack)- it is a special chunk where the data hash does NOT match the name of the chunk (as the name is a random number calculated by hashing other information (i.e. its a hash of the TMID as described below)
  • TMID hash of 613dav41e1267 and the MID is simply a hash of dave1267
  • the map of the user's database (or list of files maps) is identified.
  • the database is recovered from the net which includes the data maps for the user and any keys passwords etc..
  • the database chunks are stored in another location immediately and the old chunks forgotten. This can be done now as the MID key pair is also in the database and can now be used to manipulate user's data.
  • the maidsafe.net application can now authenticate itself as acting for this MID and put get or forget data chunks belonging to the user. 6.
  • the watcher process and Chunk server always have access to the PMID key pair as they are stored on the machine itself, so can start and receive and authenticate anonymous put / get / forget commands.
  • a DHT ID is required for a node in a DHT network this may be randomly generated or in fact we can use the hash of the PMID public key to identify the node.
  • This is a data element stored on net and preferably named with the hash of the MID public Key.
  • This mechanism also allows a user to add or remove PMIDS (or chunk servers acting on their behalf like a proxy) at will and replace PMID's at any time in case of the PMID machine becoming compromised. Therefore this can be seen as the PMID authentication element.
  • This is a data element stored on the network and preferably named with the hash of the PMID public key.
  • the key pair is stored on the machine itself and may be encoded or encrypted against a password that has to be entered upon start-up (optionally) in the case of a proxy provider who wishes to further enhance PMID security.
  • Figure 3 illustrates, in schematic form, a peer-to-peer network in accordance with an embodiment of the invention
  • Figure 4 illustrates a flow chart of the authentication, in accordance with a preferred embodiment of the present invention.
  • a peer-to-peer network 2 is shown with nodes 4 to 12 connected by a communication network 14.
  • the nodes may be Personal Computers (PCs) or any other device that can perform the processing, communication and/or storage operations required to operate the invention.
  • the file system will typically have many more nodes of all types than shown in Figure 3 and a PC may act as one or many types of node described herein.
  • Data nodes 4 and 6 store chunks 16 of files in the distributed system.
  • the validation record node 8 has a storage module 18 for storing encrypted validation records identified by a user identifier.
  • the client node 10 has a module 20 for input and generation of user identifiers. It also has a decryption module 22 for decrypting an encrypted validation record so as to provide decrypted information, a database or data map of chunk locations 24 and storage 26 for retrieved chunks and files assembled from the retrieved chunks.
  • the verifying node 12 has a receiving module 28 for receiving a user identifier from the client node.
  • the retrieving module 30 is configured to retrieve from the data node an encrypted validation record identified by the user identifier.
  • the validation record node 8 is the same node as the verifying node 12, i.e. the storage module 18 is part of the verifying node 12 (not as shown in Figure 3).
  • the transmitting module 32 sends the encrypted validation record to the client node.
  • the authentication module 34 authenticates access to chunks of data distributed across the data nodes using the decrypted information.
  • a login box is presented 46 that requires the user's name or other detail Preferably email address (the same one used in the client node software installation and registration process) or simply name (i.e. nickname) and the user's unique number, preferably PIN number. If the user is a 'main user' then some details may already be stored on the PC. If the user is a visitor, then the login box appears.
  • This 'hash' is now known as the 'User ID Key' (MID), which at this point is classed as 'unverified' within the system.
  • MID 'User ID Key
  • This is stored on the network as the MAID and is simply the hash of the public key containing an unencrypted version of the public key for later validation by any other node. This obviates the requirement for a validation authority
  • the hello.packet will be picked up by the first node (for this description, now called the 'verifying node') that recognises 54 the User ID Key element of the hello.packet as matching a stored, encrypted validation record file 56 that it has in its storage area.
  • a login attempt monitoring system ensures a maximum of three responses.
  • the verifying PC creates a 'black list' for transmission to peers.
  • an alert is returned to the user if a 'black list' entry is found and the user may be asked to proceed or perform a virus check.
  • the verifying node then returns this encrypted validation record file to the user via the internet.
  • the user's pass phrase 58 is requested by a dialog box 60, which then will allow decryption of this validation record file.
  • the validation record file is decrypted 62
  • the first data chunk details including a 'decrypted address'
  • the user PC sends back a request 66 to the verifying node for it to initiate a query for the first 'file-chunk ID 1 at the 'decrypted address' that it has extracted from the decrypted validation record file, or preferably the data map of the database chunks to recreate the database and provide access to the key pair associated with this MID.
  • the verifying node Given that some other node (for this embodiment, called the 'data node') has recognised 68 this request and has sent back a valid 'notification only' message 70 that a 'file-chunk ID' corresponding to the request sent by the verifying node does indeed exist, the verifying node then digitally signs 72 the initial User ID Key, which is then sent back to the user.
  • this verified User ID Key is used as the user's session passport.
  • the user's PC proceeds to construct 76 the database of the file system as backed up by the user onto the network. This database describes the location of all chunks that make up the user's file system.
  • the ID Key will contain irrefutable evidence such as a public/private key pair to allow signing onto the network as authorised users, preferably this is a case of self signing his or her own ID - in which case the ID Key is decrypted and user is valid - self validating.
  • a 'proxy- controlled' handshake routine is employed through an encrypted point-to- point channel, to ensure only authorised access by the legal owner to the system, then to the user's file storage database, then to the files therein.
  • the handshaking check is initiated from the PC that a user logs on to (the 'User PC), by generating the 'unverified encrypted hash' known as the 'User ID Key', this preferably being created from the user's information preferably email address and their PIN number.
  • This 'hash' is transmitted as a ' hello. packet" on the Internet, to be picked up by any system that recognises the User ID as being associated with specific data that it holds.
  • This PC then becomes the 'verifying PC and will initially act as the User PCs 'gateway' into the system during the authentication process.
  • the encrypted item of data held by the verifying PC will temporarily be used as a 'validation record', it being directly associated with the user's identity and holding the specific address of a number of data chunks belonging to the user and which are located elsewhere in the peer-to-peer distributed file system.
  • This 'validation record' is returned to the User PC for decryption, with the expectation that only the legal user can supply the specific information that will allow its accurate decryption.
  • this data may be a signed response being given back to the validating node which is possible as the id chunk when decrypted (preferably symmetrically) contains the users public and private keys allowing non refutable signing of data packets.
  • the machine will now have access to the data map of the database and public/private key pair allowing unfettered access to the system.
  • no communication is carried out via any nodes without an encrypted channel such as TLS (Transport Layer Security) or SSL (Secure Sockets Layer) being set up first.
  • a peer talks to another peer via an encrypted channel and the other peer (proxy) requests the information (e.g. for some space to save information on or for the retrieval of a file).
  • An encrypted link is formed between all peers at each end of communications and also through the proxy during the authentication process. This effectively bans snoopers from detecting who is talking to whom and also what is being sent or retrieved.
  • the initial handshake for self authentication is also over an encrypted link.
  • Secure connection is provided via certificate passing nodes, in a manner that does not require intervention, with each node being validated by another, where any invalid event or data, for whatever reason (fraud detection, snooping from node or any invalid algorithms that catch the node) will invalidate the chain created by the node. This is all transparent to the user.
  • Figure 5 illustrates a flow chart of data assurance event sequence in accordance with first embodiment of this invention
  • Figure 7 illustrates a schematic diagram of file chunking example
  • Figure 8 illustrates a flow chart of self healing event sequence
  • Figure 9 illustrates a flow chart of peer ranking event sequence
  • Figure 10 illustrates a flow chart of duplicate removal event sequence
  • the data is copied to at least three disparate locations at step (10).
  • the disparate locations store data with an appendix pointing to the other two locations by step (20) and is renamed with hash of contents.
  • this action is managed by another node i.e. super node acting as an intermediary by step (30).
  • step (40) Each local copy at user's PC is checked for validity by integrity test by step (40) and in addition validity checks by integrity test are made that the other 2 copies are also still ok by step (50).
  • any single node failure initiates a replacement copy of equivalent leaf node being made in another disparate location by step (60) and the other remaining copies are updated to reflect this change to reflect the newly added replacement leaf node by step (70).
  • the method further comprises the step of renaming all files with a hash of their contents.
  • each file can be checked for validity or tampering by running a content hashing algorithm such as (for example) MD5 or an SHA variant, the result of this being compared with the name of the file.
  • a content hashing algorithm such as (for example) MD5 or an SHA variant
  • step (100) provides a methodology to manageable sized data elements and to enable a complimentary data structure for and compression and encryption and the step is to file chunking.
  • the nominated data elements files are passed to chunking process.
  • Each data element (file) is split into small chunks by step (80) and the data chunks are encrypted by step (90) to provide security for the data.
  • the data chunks are stored locally at step (100) ready for network transfer of copies. Only the person or the group, to whom the overall data belongs, will know the location of these (100) or the other related but dissimilar chunks of data. All operations are conducted within the user's local system. No data is presented externally.
  • Each of the above chunks does not contain location information for any other dissimilar chunks. This provides for, security of data content, a basis for integrity checking and redundancy.
  • the method further comprises the step of only allowing the person (or group) to whom the data belongs, to have access to it, preferably via a shared encryption technique. This allows persistence of data.
  • the checking of data or chunks of data between machines is carried out via any presence type protocol such as a distributed hash table network.
  • a redirection record is created and stored in the super node network, (a three copy process - similar to data) therefore when a user requests a check, the redirection record is given to the user to update their database.
  • FIG. 7 illustrates flow chart example of file chunking.
  • User's normal file has 5Mb document, which is chunked into smaller variable sizes e.g. 135kb, 512kb, 768kb in any order. All chunks may be compressed and encrypted by using Pass phrase.
  • Next step is to individually hash chunks and given hashes as names.
  • database record as a file is made from names of hashed chunks brought together e.g. in empty version of original file (C1######,t1 ,t2,t3: C2########,t1 ,t2,t3 etc), this file is then sent to transmission queue in storage space allocated to client application.
  • Self healing is required to guarantee availability of accurate data.
  • the location of failing data chunks is assessed as unreliable and further data from the leaf node is ignored from that location by step (120).
  • a 'Good Copy' from the 'known good' data chunk is recreated in a new and equivalent leaf node.
  • Data or chunks are recreated in a new and safer location by step (130).
  • the leaf node with failing data chunks is marked as unreliable and the data therein as 'dirty' by step (140).
  • Peer leaf nodes become aware of this unreliable leaf node and add its location to watch list by step (150). All operations conducted within the user's local system. No data is presented externally.
  • the network will use SSL or TLS type encryption to prevent unauthorised access or snooping.
  • Peer Ranking id required to ensure consistent response and performance for the level of guaranteed interaction recorded for the user.
  • each node (leaf node) monitors its own peer node's resources and availability in a scaleable manner, each leaf node is constantly monitored.
  • Each data store (whether a network service, physical drive etc.) is monitored for availability.
  • a qualified availability ranking is appended to the (leaf) storage node address by consensus of a monitoring super node group by step (160).
  • a ranking figure will be appended by step (160) and signed by the supply of a key from the monitoring super node; this would preferably be agreed by more super nodes to establish a consensus for altering the ranking of the node.
  • the new rank will preferably be appended to the node address or by a similar mechanism to allow the node to be managed preferably in terms of what is stored there and how many copies there has to be of the data for it to be seen as perpetual.
  • Each piece of data is checked via a content hashing mechanism for data integrity, which is carried out by the storage node itself by step (170) or by its partner nodes via super nodes by step (180) or by instigating node via super nodes by step (190) by retrieval and running the hashing algorithm against that piece of data.
  • the data checking cycle repeats itself.
  • the super node querying the storage peer will respond with the result of the integrity check and update this status on the storage peer.
  • the instigating node or partner peer will decide to forget this data and will replicate it in a more suitable location.
  • step (200) If data fails the integrity check the node itself will be marked as 'dirty' by step (200) and 'dirty 1 status appended to leaf node address to mark it as requiring further checks on the integrity of the data it holds by step (210). Additional checks are carried out on data stored on the leaf node marked as 'dirty' by step (220). If pre-determined percentage of data found to be 'dirty' node is removed from the network except for message traffic by step (230). A certain percentage of dirty data being established may conclude that this node is compromised or otherwise damaged and the network would be informed of this. At that point the node will be removed from the network except for the purpose of sending it warning messages by step (230). This allows either having data stored on nodes of equivalent availability and efficiency or dictating the number of copies of data required to maintain reliability.
  • duplicate data is removed to maximise the efficient use of the disk space.
  • internally generated content hash may be checked for a match against hashes stored on the internet by step (250) or a list of previously backed up data (250). This will allow only one backed up copy of data to be kept. This reduces the network wide requirement to backup data which has the exact same contents.
  • Notification of shared key existence is passed back to instigating node by step (260) to access authority check requested, which has to pass for signed result is to be passed back to storage node.
  • the storage node passes shared key and database back to instigating node by step (270)
  • Such data is backed up via a shared key which after proof of the file existing (260) on the instigating node, the shared key (270) is shared with this instigating node. The location of the data is then passed to the node for later retrieval if required.
  • This data may be marked as protected or not protected by step (280) which has check carried out for protected or non-protected data content.
  • the protected data ignores sharing process.
  • the ability to seed or allow nodes to gain acceptance on a network will require that validation or approval is met somehow. This is carried out in this case by the addition of a seeding ID and associated key pair.
  • This key pair will allow the public key to be fed down the chain to authenticating nodes to validate themselves and consequently gain access to the network and then they themselves can become seeding nodes using their ID as the seeding ID for nodes further down the hierarchy.
  • a user looks for his manager's key locally or more likely in his database (retrieved via TMID chunk).
  • the user can then access his data / backup restore messaging systems etc.
  • a tab in the system shows the company structure, clicking on this a user (if he has rights) can look at all data available to that user including messenger messages etc. He can withdraw the service (if he has the particular authority to do so) at any time from this person by revoking his key.
  • This key is stored on the Authority Chunk on the net which is a chunk named the hash of the public key on the manager. This chunk includes all staff that can access the system with this public key as the authorisation mechanism. If a staff member cannot authenticate against any of the authority chunks he cannot use the system.
  • the manager (or preferably team) creates a maidsafe.net public ID (MPID) along with his usual MID PMID etc.
  • MPID maidsafe.net public ID
  • the initiator is not a manager, they may be an unauthorised user - to get authorised, a manager must give his MPID and get that user's MPID back to complete the challenge response.
  • the user can then authenticate staff organisationally below him or other staff that he is allowed to authenticate given company policy. Who can authenticate what users will be found on the company structure program tab.
  • a key sharing scheme such as:
  • n coordinate pairs (xi, yi) uniquely define a polynomial of degree n-1.
  • the dealer encodes the secret as the curve's y-intercept and gives each player the coordinates of a point on this curve. When the players pool together enough shares, they can interpolate to find the y-intercept and thus recover the secret.
  • a file is chunked or split into constituent parts (1) this process involves calculating the chunk size, preferably from known data such as the first few bytes of the hash of the file itself and preferably using a modulo division technique to resolve a figure between the optimum minimum and optimum maximum chunk sizes for network transmission and storage.
  • each chunk is then encrypted and obfuscated in some manner to protect the data.
  • a search of the network is carried out looking for values relating to the content hash of each of the chunks (2).
  • failure to identify all chunks may mean there is a collision on the network of file names or some other machine is in the process of backing up the same file.
  • a back-off time is calculated to check again for the other chunks. If all chunks are on the network the file is considered backed up and the user will add their MID signature to the file after preferably a challenge response to ensure there a valid user and have enough resources to do this.
  • the user preferably via another node (3) will request the saving of the first copy (preferably in distinct time zones or other geographically dispersing method).
  • the chunk will be stored (5) on a storage node allowing us to see the PMID of the storing node and store this.
  • the data is stored in multiple locations.
  • Each location stores the locations of its peers that hold identical chunks (at least identical in content) and they all communicate regularly to ascertain the health of the data.
  • the preferable method is as follows:
  • the data is copied to at least three disparate locations.
  • each copy is performed via many nodes to mask the initiator.
  • each local copy is checked for validity and checks are made that the preferably other 2 copies are also still valid.
  • any single node failure initiates a replacement copy being made in another disparate location and the other associated copies are updated to reflect this change.
  • steps of storing and retrieving are carried out via other network nodes to mask the initiator.
  • the method further comprises the step of renaming all files with a hash of their contents.
  • each chunk may alter its name by a known process such as a binary shift left of a section of the data. This allows the same content to exist but also allows the chunks to appear as three different bits of data for the sake of not colliding on the network.
  • each chunk has a counter attached to it that allows the network to understand easily just how many users are attached to the chunk - either by sharing or otherwise.
  • a user requesting a 'chunk forget 1 will initiate a system question if they are the only user using the chunk and if so the chunk will be deleted and the user's required disk space reduced accordingly. This allows users to remove files no longer required and free up local disk space. Any file also being shared is preferably removed from the user's quota and the user's database record or data map (see later) is deleted.
  • this counter is digitally signed by each node sharing the data and therefore will require a signed 'forget' or 'delete' command.
  • 'store', 'put', 'retrieve' and 'get' commands should also be either digitally signed or preferably go through a PKI challenge response mechanism.
  • this method will be monitored by a supernode or similar to ensure the user has not simply copied the data map for later use without giving up the disk space for it. Therefore the user's private ID public key will be used to request the forget chunk statement. This will be used to indicate the user's acceptance of the 'chunk forget' command and allow the user to recover the disk space. Any requests against the chunk will preferably be signed with this key and consequently rejected unless the user's system gives up the space required to access this file.
  • each user storing a chunk will append their signed request to the end of the chunk in an identifiable manner i.e. prefixed with 80 - or similar.
  • Forgetting the chunk means the signature is removed from the file. This again is done via a signed request from the storage node as with the original backup request.
  • this signed request is another small chunk stored at the same location as the data chunk with an appended postfix to the chunk identifier to show a private ID is storing this chunk. Any attempt by somebody else to download the file is rejected unless they first subscribe to it, i.e. a chunk is called 12345 so a file is saved called 12345 ⁇ signed store request>. This will allow files to be forgotten when all signatories to the chunk are gone.
  • a user will send a signed 'no store' or 'forget' and their ID chunk will be removed, and in addition if they are the last user storing that chunk, the chunk is removed. Preferably this will allow a private anonymous message to be sent upon chunk failure or damage allowing a proactive approach to maintaining clean data.
  • the other nodes can preferably send a message to all sharers of the chunk to identify the new location of the replacement chunk.
  • any node attaching to a file then downloading immediately should be considered an alert and the system may take steps to slow down this node's activity or even halt it to protect data theft.
  • Chunk Checks ( Figure 1 - P9 and Figure 13)
  • Storage node containing chunk 1 checks its peers. As each peer is checked it reciprocates the check. These checks are split into preferably 2 types:
  • Availability check i.e. simple network ping
  • Data integrity check in this instance the checking node takes a chunk and appends random data to it and takes a hash of the result. It then sends the random data to the node being checked and requests the hash of the chunk with the random data appended. The result is compared with a known result and the chunk will be assessed as either healthy or not. If not, further checks with other nodes occur to find the bad node.
  • the user who stored the chunk will check on a chunk from 1 storage node randomly selected. This check will ensure the integrity of the chunk and also ensure there are at least 10 other signatures existing already for the chunk. If there are not and the user's ID is not listed, the user signs the chunk. 4. This shows another example of another user checking the chunk. Note that the user checks X (40 days in this diagram) are always at least 75% of the forget time retention (Y) (i.e. when a chunk is forgotten by all signatories it is retained for a period of time Y). This is another algorithm that will continually develop.
  • Y forget time retention
  • the CID as shown in storing initial chunk contains the chunk name and any public keys that are sharing the chunk. In this instance it should only be our key as we are first ones storing the chunks (others would be in a back-off period to see if we back other chunks up). We shift the last bit (could be any function on any bit as long as we can replicate it)
  • the supernode network finds a storage location for us with the correct rank etc.
  • the CID is then updated with the second chunk name and the location it is stored at. This process is repeated for as many copies of a chunk that are required.
  • each file is split into small chunks and encrypted to provide security for the data. Only the person or the group, to whom the overall data belongs, will know the location of the other related but dissimilar chunks of data.
  • each of the above chunks does not contain location information for any other dissimilar chunks; which provides for security of data content, a basis for integrity checking and redundancy.
  • the method further comprises the step of only allowing the person (or group) to whom the data belongs to have access to it, preferably via a shared encryption technique which allows persistence of data.
  • the checking of data or chunks of data between machines is carried out via any presence type protocol such as a distributed hash table network.
  • a redirection record is created and stored in the super node network, (a three copy process - similar to data) therefore when a user requests a check, the redirection record is given to the user to update their database, which provides efficiency that in turn allows data resilience in cases where network churn is a problem as in peer to peer or distributed networks.
  • This system message can be preferably passed via the messenger system described herein.
  • the system may simply allow a user to search for his chunks and through a challenge response mechanism, locate and authenticate himself to have authority to get/forget this chunk.
  • a self healing network method is provided via the following process
  • the network layer will use SSL or TLS channel encryption to prevent unauthorised access or snooping.
  • Chunk ID A data element called a Chunk ID (CID) is created for each chunk. Added to this is the 'also stored at 1 MID for the other identical chunks.
  • the other chunk names are also here as they may be renamed slightly (i.e. by bit shifting a part of the name in a manner that calculable).
  • All storing nodes (related to this chunk) have a copy of this CID file or can access it at any stage from the DHT network, giving each node knowledge of all others.
  • Each of the storage nodes have their copy of the chunk.
  • Each node queries its partner's availability at frequent intervals. On less frequent intervals a chunk health check is requested. This involves a node creating some random data and appending this to it's chunk and taking the hash. The partner node will be requested to take the random data and do likewise and return the hash result. This result is checked against the result the initiator had and chunk is then deemed healthy or not. Further tests can be done as each node knows the hash their chunk should create and can self check n that manner on error and report a dirty node.
  • the first node to note this carries out a broadcast to other nodes to say it is requesting a move of the data.
  • a broadcast is sent to the supernode network closest to the storage node that failed, to state a re-storage requirement.
  • the supernode network picks up the request.
  • the request is to the supernode network to store x amount of data at a rank of y.
  • the storage node and new location carry out a challenge response request to validate each other.
  • each node (leaf node) monitors its own peer node's resources and availability in a scalable manner. Nodes constantly perform this monitoring function.
  • Each data store (whether a network service, physical drive etc.) is monitored for availability.
  • a ranking figure is appended and signed by the supply of a key from the monitoring super node, this being preferably agreed by more super nodes to establish a consensus before altering the ranking of the node.
  • the new rank will be appended to the node address or by a similar mechanism to allow the node to be managed in terms of what is stored there and how many copies there has to be of the data for it to be seen as perpetual.
  • Each piece of data is checked via a content hashing mechanism. This is preferably carried out by the storage node itself or by its partner nodes via super nodes or by an instigating node via super nodes by retrieving and running the hashing algorithm against that piece of data.
  • the super node querying the storage peer will respond with the result of the integrity check and update this status on the storage peer.
  • the instigating node or partner peer will decide to forget this data and will replicate it in a more suitable location.
  • the node itself will be marked as 'dirty' and this status will preferably be appended to the node's address for further checks on other data to take this into account.
  • a certain percentage of dirty data being established may conclude that this node is compromised or otherwise damaged and the network would be informed of this. At that point the node will be removed from the network except for the purpose of sending it warning messages.
  • the node ranking figure will take into account at least; availability of the network connection, availability of resources, time on the network with a rank (later useful for effort based trust model), amount of resource (including network resources) and also the connectivity capabilities of any node (i.e. directly or indirectly contactable)
  • the actual encrypting and decrypting is carried out via knowledge of the file's content and this is somehow maintained (see next).
  • Keys will be generated and preferably stored for decrypting.
  • Actually encrypting the file will preferably include a compression process and further obfuscation methods.
  • the chunk will be stored with a known hash preferably based on the contents of that chunk.
  • Decrypting the file will preferably require the collation of all chunks and rebuilding of the file itself.
  • the file may preferably have its content mixed up by an obfuscation technique rendering each chunk useless on its own.
  • every file will go through a process of byte (or preferably bit) swapping between its chunks to ensure the original file is rendered useless without all chunks.
  • This process will preferably involve running an algorithm which preferably takes the chunk size and then distributes the bytes in a pseudo random manner preferably taking the number of chunks and using this as an iteration count for the process. This will preferably protect data even in event of somebody getting hold of the encryption keys - as the chunks data is rendered useless even if transmitted in the open without encryption.
  • a chunk's original hash or other calculable unique identifier will be stored. This will be stored with preferably the final chunk name.
  • This aspect defines that each file will have a separate map preferably a file or database entry to identify the file and the name of its constituent parts. Preferably this will include local information to users such as original location and rights (such as a read only system etc.). Preferably some of this information can be considered shareable with others such as filename, content hash and chunks names.
  • these data maps may be very small in relation to the original data itself allowing transmission of files across networks such as the internet with extreme simplicity, security and bandwidth efficiency.
  • the transmission of maps will be carried out in a very secure manner, but failure to do this is akin to currently emailing a file in its entirety.
  • this will preferably not require the deletion or removal of existing chunks, but instead allow the existing chunks to remain and the map appended to with an indication of a new revision existing.
  • Preferably further access to the file will automatically open the last revision unless requested to open an earlier revision.
  • revisions of any file can be forgotten or deleted (preferably after checking the file counter or access list of sharers as above). This will allow users to recover space from no longer required revisions.
  • this map of maps will preferably identify the users connected to it via some public ID that is known to each other user, with the map itself will being passed to users who agree to join the share. This will preferably be via an encrypted channel such as ms messenger or similar. This map may then be accessed at whatever rank level users have been assigned. Preferably there will be access rights such as read / delete / add / edit as is typically used today. As a map is altered, the user instigating this is checked against the user list in the map to see if this is allowed. If not, the request is ignored but preferably the users may then save the data themselves to their own database or data maps as a private file or even copy the file to a share they have access rights for. These shares will preferably also exhibit the revision control mechanism described above.
  • joining the share will mean that the users subscribe to a shared amount of space and reduce the other subscription, i.e. a 10Gb share is created then the individual gives up 10Gb (or equivalent dependent on system requirements which may be a multiple or divisor of 10Gb).
  • Another user joining means they both have a 5Gb space to give up and 5 users would mean they all have a 2Gb or equivalent space to give up. So with more people sharing, requirements on all users reduce.
  • User 1 saves a file as normal (encrypted, obfuscated, chunked, and stored on the net via a signed and anonymous ID.
  • This ID is a special maidsafe.net Share ID (MSID) and is basically a new key pair created purely for interacting with the share users - to mask the user's MID (i.e. cannot be tied to MPID via a share). So again the MSID is a key pair and the ID is the hash of the public key - this public key is stored in a chunk called the hash and signed and put on the net for others to retrieve and confirm that the public key belongs to the hash.
  • MSID maidsafe.net Share ID
  • File data added to file map is created in the backup process, with one difference, this is a map of maps and may contain many files - see 14
  • User 2 has authentication details (i.e. their private MPID key) and can sign / decrypt with this MPID public key.
  • User 1 sends a share join request to user 2 (shares are invisible on the net - i.e. nobody except the sharers to know they are there). 9. User 1 signs the share request to state he will join share. He creates his MSID key pair at this time. The signed response includes User 2's MSID public key.
  • Share map is encrypted or sent encrypted (possibly by secure messenger) to User 1 along with the MSID public keys of any users of the share that exist. Note the transmittion of MSID public key may not be required as the MSID chunks are saved on the net as described in 3 so any user can check the public key at any time - this just saves the search operation on that chunk to speed the process up slightly.
  • Each user has details added to the share these include public name (MPID) and rights (read / write / delete / admin etc.)
  • Non-logged in users will have a message buffered for them - if the file is closed the buffered message is deleted (as there is no point in sending it to the user now) and logged in users are updated also.
  • a non public ID preferably one which is used in some other autonomous system is used as a sign in mechanism and creates a Public ID key pair.
  • the user selects or creates their public ID by entering a name that can easily be remembered (such as a nickname) the network is checked for a data element existing with a hash of this and if not there, this name is allowed. Otherwise the user is asked to choose again.
  • a name that can easily be remembered such as a nickname
  • MPID ‘maidsafe.net public ID)
  • MPID maidsafe.net public ID
  • These messages may go through a proxy system or additional nodes to mask the location of each user.
  • This system also allows document signing (digital signatures) and interestingly, contract conversations. This is where a contract is signed and shared between the users. Preferably this signed contract is equally available to all in a signed (non changeable manner) and retrievable by all. Therefore a distributed environment suits this method.
  • These contracts may be NDAs Tenders, Purchase Orders etc.
  • message 1 message 2 or simply be appended to the users MPID chunk, in both cases messages are signed by the sender. This allows messages to be buffered in cases where the user is offline. When the user comes on line he will check his ID chunk and look for appended messages as above ID.messagel etc. which is MPID. ⁇ message 1 data>. ⁇ message 2 data> etc
  • This system allows the ability for automatic system messages to be sent, i.e... in the case of sharing the share, data maps can exist on everyone's database and never be transmitted or stored in the open. File locks and changes to the maps can automatically be routed between users using the messenger system as described above. This is due to the distributed nature of maidsafe.net and is a great, positive differentiator from other messenger systems. These system commands will be strictly limited for security reasons and will initially be used to send alerts from trusted nodes and updates to share information by other shares of a private file share (whether they are speaking with them or not).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Selon cette invention les utilisateurs peuvent maximiser l'utilisation de la ressource de mémoire existante, de puissance de traitement et de largeur de bande de réseau, grâce à un niveau accru de sauvegarde et de restauration des données faisant appel au cryptage initial des données et au stockage des données d'un utilisateur sur les unités de disque dur d'un autre utilisateur par un processus anonyme. L'efficacité de ce processus est améliorée lorsque l'invention est utilisée conjointement à l'auto-authentification qui fournit ensuite la capacité d'ouvrir une session dans un réseau de manière anonyme, quel que soit l'endroit.
PCT/GB2007/004431 2006-12-01 2007-11-21 Mssan Ceased WO2008065347A2 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US12/476,162 US20100058054A1 (en) 2006-12-01 2009-06-01 Mssan
US13/569,962 US20120311339A1 (en) 2006-12-01 2012-08-08 Method for storing data on a peer-to-peer network

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
GB0624056.8 2006-12-01
GB0624056A GB2446169A (en) 2006-12-01 2006-12-01 Granular accessibility to data in a distributed and/or corporate network
GB0709751.2 2007-05-22
GB0709751.2A GB2444338B (en) 2006-12-01 2007-05-22 Secure anonymous storage of user data on a peer-to-peer network

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/476,162 Continuation US20100058054A1 (en) 2006-12-01 2009-06-01 Mssan

Publications (2)

Publication Number Publication Date
WO2008065347A2 true WO2008065347A2 (fr) 2008-06-05
WO2008065347A3 WO2008065347A3 (fr) 2008-11-13

Family

ID=39468306

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2007/004431 Ceased WO2008065347A2 (fr) 2006-12-01 2007-11-21 Mssan

Country Status (1)

Country Link
WO (1) WO2008065347A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8256010B2 (en) 2009-04-01 2012-08-28 Microsoft Corporation Providing access to a data item using access graphs

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7412462B2 (en) * 2000-02-18 2008-08-12 Burnside Acquisition, Llc Data repository and method for promoting network storage of data
US7062490B2 (en) * 2001-03-26 2006-06-13 Microsoft Corporation Serverless distributed file system
US20040153473A1 (en) * 2002-11-21 2004-08-05 Norman Hutchinson Method and system for synchronizing data in peer to peer networking environments
US7107419B1 (en) * 2003-02-14 2006-09-12 Google Inc. Systems and methods for performing record append operations

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8256010B2 (en) 2009-04-01 2012-08-28 Microsoft Corporation Providing access to a data item using access graphs

Also Published As

Publication number Publication date
WO2008065347A3 (fr) 2008-11-13

Similar Documents

Publication Publication Date Title
US20100058054A1 (en) Mssan
US8788803B2 (en) Self-encryption process
US9411976B2 (en) Communication system and method
US20150006895A1 (en) Distributed network system
Kher et al. Securing distributed storage: challenges, techniques, and systems
JP5663083B2 (ja) 移動中のデータをセキュア化するためのシステムおよび方法
JP5650348B2 (ja) 移動中のデータをセキュア化するためのシステムおよび方法
JP5757536B2 (ja) クラウド内にデータを確保するシステムおよび方法
US20040255137A1 (en) Defending the name space
WO2008065345A1 (fr) Cyberargent
GB2444339A (en) Shared access to private files in a distributed network
WO2008065343A1 (fr) Accès partagé à des fichiers privés
WO2008065349A1 (fr) Système de vote mondial
GB2444346A (en) Anonymous authentication in a distributed system
WO2008065348A2 (fr) Données perpétuelles
CN118740420A (zh) 一种物联网服务器的安全防护系统及方法
WO2008065346A2 (fr) Messager ms
AU2012202853B2 (en) Self encryption
WO2008065347A2 (fr) Mssan
WO2008065344A1 (fr) Authentification anonyme
GB2444344A (en) File storage and recovery in a Peer to Peer network
de Bruin et al. Analyzing the Tahoe-LAFS filesystem for privacy friendly replication and file sharing
GB2439969A (en) Perpetual data on a peer to peer network
GB2444341A (en) Distributed network messenger system with SPAM filtering, encryption, digital signing and digital contract generation
Bansal Securing Content in Peer-to-Peer File Systems

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

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

Ref document number: 07824645

Country of ref document: EP

Kind code of ref document: A2

122 Ep: pct application non-entry in european phase

Ref document number: 07824645

Country of ref document: EP

Kind code of ref document: A2