GB2444339A - Shared access to private files in a distributed network - Google Patents

Abstract

A mechanism for secure sharing of data within a distributed or peer-to-peer secure/insecure network environment. It is an object of the present invention to obviate the need for file servers and replace their function with a distributed network of preferably standard processing nodes. This network may be private as in a corporate network or an open network like the Internet and it will preferably not contain any lists of user authentication records. Shared access to private files is provided using decentralized and anonymously authenticated shared data areas, which have a granular access restriction. Preferably the data is stored in chunks which are individually hashed and/or encrypted, and furthermore the location of the chunks is identified by data maps which may be shared among authenticated users. Preferably users share concatenated data maps of stored private content in the network and further utilize the features of public IDs, encrypted communication and identification of data/content with very small files (e.g. hashes). The system may also be anonymous and involve anonymous authentication.

Description

STATEMENT OF INVENTION.

8 Currently, sharing files or data requires access to centralised file 9 repositories. Non public files may be freely shared on a distributed network but not private files as there is no anonymous authentication II suitable for this environment. Shared private files also rely on 12 centralised user account lists and validation that usually requires a 13 super user or administrator to set this up and maintain it.

14 This invention depicts a distributed or peer to peer network that wHI allow individuals to construct their own private file sharing system with 16 no interaction from anyone else. This also has the added benefit of not 17 requIring a file server or users ending up with multiple copies of 18 individual files.

BACKGROUND.

19 Digital data is today shared amongst trusted users via centralised file or authentication servers. This allows a single point of failure and may 21 possibly open the system to attack as these servers present a target.

22 Storage and authentication today require a great deal of administration, 23 security analysis and time, it is also very likely most systems today can 24 be fully accessed by a system administrator which in itself is a security weakness.

26 Storage on distributed systems such as the internet is also possible but 27 requires specific storage servers to be available. In addition to these 28 physical systems, data management elements such as security, repair, 29 encryption, authentication, anonymity and mapping etc. are required to ensure successful data transactions and management via the Internet.

31 Listed below is some prior art for these individual elements: 32 PRIVATE SHARED FILES 33 US6859812 discloses a system and method for differentiating private 34 and shared files, where clustered computers share a common storage resource, Network-Attached Storage (NAS) and Storage Area Network 36 (SAN), therefore not distributed as in this present invention. US531 3646 37 has a system which provides a copy-on-write feature which protects the 38 integrity of the shared files by automatically copying a shared file into 39 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 41 knowledge -not anonymous. W002095545 discloses a system using a 42 server for private file sharing which is not anonymous.

43 DIsTRIBuTED NETWORK SHARED MAPS 44 A computer system having plural nodes interconnected by a common broadcast bus is disclosed by US5117350. US5423034 shows how 46 each file and level in the directory structure has network access 47 privileges. The file directory structure generator and retrieval tool have a 48 document locator module that maps the directory structure of the files 49 stored in the memory to a real world hierarchical file structure of files.

Therefore not distributed across public networks or anonymous or self 51 encrypting, the present inventions does not use broadcasting in this 52 manner.

53 AUTHENTICATION 54 Authentication servers are for user and data transaction authentication e.g. JP2005311545 which describe a system wherein the application of 56 a digital seal' to electronic documents conforms to the Electronic 57 Signature Act. This is similar to the case of signing paper documents 58 but uses the application of an electronic signature through an electronic 59 seal authentication system. The system includes: client computers, to each of which a graphics tablet is connected; an electronic seal 61 authentication server and a PKI authentication server, plus the 62 electronic seal authentication server, US2004254894 discloses an 63 automated system for the confirmed efficient authentication of an 64 anonymous subscriber's profile data in this case.

JP2005339247 describes a server based one time ID system and uses 66 a portable terminal. US2006136317 discloses bank drop down boxes 67 and suggests stronger protection by not transmitting any passwords or 68 IDs. Patent US2006126848 discloses a server centric and deals with a 69 one time password or authentication phrase and is not for use on a distributed network. Patent US2002194484 discloses a distributed 71 network where all chunks are not individually verified and where the 72 manifest is only re-computed after updates to files and hashes are 73 applied and are for validation only.

74 SELF-AUTHENTICATION This is mostly used in biometric (W020060691 58). System for 76 generating a patch file from an old version of data which consists of a 77 series of elements and a new version of data which also consists of a 78 series of elements US2006136514). Authentication servers (therefore 79 not a distributed networking principle as per this invention) are commonly used (JP2006107316, US2005273603, EP1548979).

81 However, server and client exchange valid certificates can be used 82 (US2004255037). Instead of server, uses of information exchange 83 system (semantic information) by participant for authentication can be 84 used (JP2004355358), again this semantic information is stored and referenced unlike this present invention.

86 Concepts of identity-based cryptography and threshold secret sharing 87 provides for a distributed key management and authentication. Without 88 any assumption of pre-fixed trust relationship between nodes, the ad 89 hoc network works in a self-organizing way to provide the key generation and key management service, which effectively solves the 91 problem of single point of failure in the traditional public key 92 infrastructure (PKI)-supported system (US2006023887). Authenticating k 93 involves encryption keys for validation (W02005055162) These are 94 validated against known users unlike the present invention. Also, for authentication external housing are used (W02005034009). All of 96 these systems require a lost or (whether distributed or not) record of 97 authorised users and pass phrases or certificates and therefore do not

98 represent prior art.

99 Ranking, hashing for authentication can be implemented step-by-step and empirical authentication of devices upon digital authentication 101 among a plurality of devices. Each of a plurality of authentication 102 devices can unidirectionally generate a hash value of a low experience 103 rank from a hash value of a high experience rank, and receive a set of 104 high experience rank and hash value in accordance with an experience.

In this way, the authentication devices authenticate each other's 106 experience ranks (US2004019788). This is a system of hashing access 107 against known identities and providing a mechanism of effort based 108 access. This present invention does not rely or use such mechanisms.

109 QuicK ENcIPHERING This is another method for authentication (JP2001308845). Self- 111 verifying certificate for computer system, uses private and public keys - 112 no chunking but for trusted hardware subsystems (US2002080973) this 113 is a mechanism of self signing certificates for authentication, again 114 useful for effort based computing but not used in this present invention.

Other authentication modes are, device for exchanging packets of 116 information (JP2001 186186), open key certificate management data 117 (JP10285156), and certification for authentication (W096139210).

118 Authentication for Peer to Peer system is demonstrated by digital rights 119 management (US2003120928). Digital rights management and CSC (part of that patent s a DRM container) issues which are based on 121 ability to use rather than gaining access to network or resources and

122 therefore not prior art.

123 Known self-healing techniques are divided broadly into two classes.

124 One is a centralized control system that provides overall rerouting control from the central location of a network. In this approach, the 126 rerouting algorithm and the establishing of alarm collection times 127 become increasingly complex as the number of failed channels 128 increases, and a substantial amount of time will be taken to collect 129 alarm signals and to transfer rerouting information should a large number of channels of a multiplexed transmission system fail. The other 131 is a distributed approach in which the rerouting functions are provided 132 by distributed points of the network. The following papers on distributed 133 rerouting approach have been published: (these are all related to self 134 healing but from a network pathway perspective and therefore are not prior art for this invention which deals with data or data chunks self 136 healing mechanisms.

137 Document 1: W. D. Grover, "The Selfhealing Network", Proceedings of 138 Grobecom 87, November 1987.

139 Document 2: H. C. Yang and S. Hasegawa, "Fitness: Failure Immunization Technology For Network Service Survivability", 141 Proceedings of Globecom 88, December 1988.

142 Document 3: H. R. Amirazizi, "Controlling Synchronous Networks With 143 Digital Cross-Connect Systems', Proceedings of Globecom 88, 144 December 1988.

Document 1 is concerned with a restoration technique for failures in a 146 single transmission system, and Document 2 relates to a "multiple- 147 wave" approach in which route-finding packets are broadcast in multiple 148 wave fashion in search of a maximum bandwidth until alternate routes 149 having the necessary bandwidth are established. One shortcoming of this multiple wave approach is that it takes a long recovery time.

151 Document 3 also relates to fault recovery for single transmission (47 152 systems and has a disadvantage in that route-finding packets tend to 153 form a loop and hence a delay is likely to be encountered.

154 PERPETUAL DATA Most perpetual data generation is allocated with time & calendar etc. 156 (US62669563, JP200I 100633). This is not related to this current 157 invention as we have no relation to calendaring, which demonstrates 158 perpetual generation time related data. However, External devices as 159 communication terminal (JP2005057392) (this is a hardware device not related to this present invention) have been used for plurality of packet 161 switching to allow perpetual hand-if of roaming data between networks 162 and battery pack (EP0944232) has been used to around-the-clock 163 accessibility of customer premises equipment interconnected to a 164 broadband network is enhanced by perpetual mode operation of a broadband network interface. In addition, perpetual data storage and 166 retrieval in reliable manner in peer to peer or distributed network The 167 only link here is these devices are connected to Internet connections

168 but otherwise presents no prior art.

169 DATABASES & DATA STORAGE METHODS Patents W09637837, TW223167B, US6760756 and US7099898 171 describe methods of data replication and retention of data during failure.

172 Patent W0200505060625 discloses method of secure interconnection 173 when failure occurs.

174 SEcURITY Today systems secure transactions through encryption technologies 176 such as Secure Sockets Layer (SSL), Digital Certificates, and Public 177 Key Encryption technologies. The systems today address the hackers 178 through technologies such as Firewalls and Intrusion Detection 179 systems. The merchant certification programs are designed to ensure the merchant has adequate inbuilt security to reasonably assure the 181 consumer their transaction will be secure. These systems also ensure 182 that the vendor will not incur a charge back by attempting to verify the 183 consumer through secondary validation systems such as password 184 protection and eventually, Smart Card technology.

Network firewalls are typically based on packet filtering which is limited 186 in principle, since the rules that judge which packets to accept or reject 187 are based on subjective decisions. Even VPNs (Virtual Private 188 Networks) and other forms of data encryption, including digital 189 signatures, are not really safe because the information can be stolen before the encryption process, as default programs are allowed to do 191 whatever they like to other programs or to their data files or to critical 192 files of the operating system. This is done by (CA247150) automatically 193 creating an unlimited number of Virtual Environments (VEs) with virtual 194 sharing of resources, so that the programs in each VE think that they are alone on the computer. The present invention takes a totally 196 different approach to security and obviates the requirement of much of 197 the above particularly CA2471 505.

198 US6I 85316 discloses security via fingerprint imaging testing bit of code 199 using close false images to deter fraudulent copying, this is different from the present invention in that we store no images at all and certainly 201 not in a database.

202 SEcURITY & STORAGE SYSTEMS 203 There are currently several types of centralised file storage systems 204 that are used in business environments. One such system is a server- 205 tethered storage system that communicates with the end users over a 206 local area network, or LAN. The end users send requests for the 207 storage and retrieval of files over the LAN to a file server, which 208 responds by controlling the storage and/or retrieval operations to 209 provide or store the requested files. While such a system works well for 210 smaller networks, there is a potential bottleneck at the interface 211 between the LAN and the file storage system.

212 Another type of centralised storage system is a storage area network, 213 which is a shared, dedicated high-speed network for connecting storage 214 resources to the servers. While the storage area networks are generally 215 more flexible and scalable in terms of providing end user connectivity to 216 different server-storage environments, the systems are also more 217 complex. The systems require hardware, such as gateways, routers, 218 switches, and are thus costly in terms of hardware and associated 219 software acquisition.

220 Yet another type of storage system is a network attached storage 221 system in which one or more special-purpose servers handle file 222 storage over the LAN.

223 Another file storage system utilizes distributed storage resources 224 resident on various nodes, or computers, operating on the system, 225 rather than a dedicated centralised storage system. These are 226 distributed systems, with the clients communicating peer-to-peer to 227 determine which storage resources to allocate to particular files, 228 directories and so forth. These systems are organized as global file 229 stores that are physically distributed over the computers on the system.

230 A global file store is a monolithic file system that is indexed over the 231 system as, for example, a hierarchical directory. The nodes in the 232 systems use Byzantine agreements to manage file replications, which 233 are used to promote file availability and/or reliability. The Byzantine 234 agreements require rather lengthy exchanges of messages and thus 235 are inefficient and even impractical for use in a system in which many 236 modifications to files are anticipated. US20021 1434 shows a peer-to- 237 peer storage system which describes a storage coordinator that 238 centrally manages distributed storage resources. The difference here is 239 the requirement of a storage broker, making this not fully distributed.

240 The present invention also differs in that the present invention has no 241 central resources for any of the system and we also encrypt data for 242 security as well as the self healing aspect of our system which is again 243 distributed.

244 US7010532 discloses improved access to information stored on a 245 storage device. A plurality of first nodes and a second node are coupled 246 to one another over a communications pathway, the second node being 247 coupled to the storage device for determining meta data including block 248 address maps to file data in the storage device.

249 JP2003273860 discloses a method of enhancing the security level 250 during access of an encrypted document including encrypted content. A 251 document access key for decrypting an encrypted content within an 252 encrypted document is stored in a management device, and a user 253 device wishing to access the encrypted document transmits its user ID 254 and a document identification key for the encrypted document, which 255 are encrypted by a private key, together with a public key to the 256 management device to request transmission of the document access 257 key. Differing from this invention in that it never transmit user id or login 258 in the network at all. Also it does not require management devices of 259 any form.

260 JP20021 85444 discloses improves security in networks and the 261 certainty for satisfying processing requests. In the case of user 262 registration, a print server forms a secret key and a public key, and 263 delivers the public key to a user terminal, which forms a user ID, a 264 secret key and a public key, encrypts the user ID and the public key by 265 using the public key, and delivers them to the print server. This is not 266 linked at all to this invention and is a system for a PKI infrastructure for 267 certificate access to network nodes.

268 The private and public keys of users are used in US6925182, and are 269 encrypted with a symmetric algorithm by using individual user to 270 identifying keys and are stored on a network server making it a different 271 proposition from a distributed network 272 US2005091234 describes data chunking system which divides data into 273 predominantly fixed-sized chunks such that duplicate data may be 274 identified. This is associated with storing and transmitting data for 275 distributed network. US2006206547 discloses a centralised storage 276 system, whilst US2005004947 discloses a new PC based file system.

277 US2005256881 discloses data storage in a place defined by a path 278 algorithm. This is a server based duplicate removal and not necessarily 279 encrypting data, unlike the present invention which does both and 280 requires no servers.

281 SECuRITY & ENCRYPTION 282 Common email communications of sensitive information is in plain text 283 and is subject to being read by unauthorized code on the senders 284 system, during transit and by unauthorized code on the receiver's 285 system. Where there is a high degree of confidentially required, a 286 combination of hardware and software secures data.

287 A high degree of security to a computer or several computers 288 connected to the Internet or a LAN as disclosed in US2002099666.

289 Hardware system is used which consists of a processor module, a 290 redundant non-volatile memory system, such as dual disk drives, and 291 multiple communications interfaces. This type of security system must 292 be unlocked by a pass phrase to access data, and all data is 293 transparently encrypted, stored, archived and available for encrypted 294 backup. A system for maintaining secure communications, file transfer 295 and document signing with PKI, and a system for intrusion monitoring 296 and system integrity checks are provided, logged and selectively 297 alarmed in a tamper-proof, time-certain manner.

II

Summaiy of Invention 298 The main embodiments of this invention are as follows: 299 A system of sharing access to private files which has the functional 300 elements of: 301 1. Create Mapof Maps 302 2. Share Maps 303... with the additionally linked functional elements of: 304 1. Identify Data with Very Small File 305 2. Encrypted Communications 306 3. Provision of Public ID 307 A system to share access to private files in a distributed or peer to peer 308 network 309 A product to share access to private files in a distributed or peer to peer 310 network 31 1 A system to share access to private files in a distributed or peer to peer 312 network which is made of inter linkage all or some of the following 313 elements: 314 a. provision of public ID 315 b. encrypted communication 316 c. identify data with very small file 317 A system to share access to private files in a distributed or peer to peer 318 network which is made of inter linkage all or some of the following 319 elements and sub-elements: 320 a. provision of public ID 321 i. share maps 322 b. encrypted communication 323 i. share maps 324 c. identify data with very small file 325 i. create map of maps 326 A product for sharing access to private files in a distributed or peer to 327 peer network which is made of inter linkage all or some of the following 328 elements: 329 a. provision of public ID 330 b. encrypted communication 331 c. identify data with very small file 332 A product for sharing access to private files in a distributed or peer to 333 peer network which is made of inter linkage all or some of the following 334 elements and sub-elements: 335 b. provision of public ID 336 i. share maps 337 c. encrypted communication 338 i. share maps 339 d. identify data with very small file 340 I. create map of maps 341 A product to remove the requirement for centrally held authentication 342 records in a data sharing environment; 343 A product to remove the requirement for central storage nodes that hold 344 authentication records in a data sharing environment; I,';, 345 A product for providing secured decentralised and anonymously 346 authenticated shared data areas in a distributed network or a peer to 347 peer network; 348 A method of above system and product to share access to private files 349 in a distributed or peer to peer network 350 A method to remove the requirement for centrally held authentication 351 records in a data sharing environment.

352 A method to remove the requirement for central storage nodes that hold 353 authentication records in a data sharing environment.

354 A method of providing secured decentralised and anonymously 355 authenticated shared data areas in a distributed network or a peer to 356 peer network.

357 A method of above where significant reductions in IT infrastructure are 358 made possible by removing centralised resources and increasing 359 security.

360 A method of above where access levels can be added to provide the 361 ability to enhance a private network using a completely granular access 362 system such as n + p key sharing.

363 A method of providing an environmentally friendly method for file 364 sharing by reusing existing infrastructure and computers through 365 maximising their existing resources.

366 A method of above which will provide a system to significantly enhance 367 security of mobile computing devices and to mitigate the implications of 368 the theft of those devices by aHowing aH user information and company 369 data to be removed from the mobile/ portable devices and for it to be 370 only available when authenticated.

371 A method of above to provide the ability to render existing data disk 372 contents useless without passwords/ keys and maps of data chunks; 373 this can be thought of as an off line secure mode.

374 A method of above which allows data stored on the Internet to be 375 retrieved securely from any location, thereby rendering existing VPN 376 systems for sharing files obsolete.

377 A system in distributed or peer to peer network which allows individuals 378 to construct their own private file sharing system with no interaction 379 from anyone else and not requiring a file server DESCRtPTION

Detailed Description:

380 (References to IDs used in descriptions of the system's functionality) 381 MID -this is the base ID and is mainly used to store and forget files.

382 Each of these operations will require a signed request. Restoring may 383 simply require a request with an ID attached.

384 PMID -This is the proxy mid which is used to manage the receiving of 385 instructions to the node from any network node such as get] put / forget 386 etc. This is a key pair which is stored on the node -if stolen the key pair 387 can be regenerated simply disabling the thief's stolen PMID -although 388 there's not much can be done with a PMID key pair.

389 CID -Chunk Identifier, this is simply the chunkid.KID message on the 390 net.

391 TMID -This is today's ID a one time ID as opposed to a one time 392 password. This is to further disguise users and also ensure that their MID 393 stays as secret as possible.

394 MPID -The maidsafe.net public ID. This is the ID to which users can add 395 their own name and actual data if required. This is the ID for messenger, 396 sharing, non anonymous voting and any other method that requires we 397 know the user.

398 MAID -this is basically the hash of and actual public key of the MID. this 399 ID is used to identify the user actions such as put / forget I get on the 400 maidsafe.net network. This allows a distributed PKI infrastructure to exist 401 and be automatically checked.

402 KID -Kademlia ID this can be randomly generated or derived from 403 known and preferably anonymous information such as an anonymous 404 public key hash as with the MAID.. In this case we use kademlia as the 405 example overlay network although this can be almost any network 406 environment at all.

407 MSID -maidsafe.net Share ID, an ID and key pair specifically created for 408 each share to allow users to interact with shares using a unique key not 409 related to their MID which should always be anonymous and separate.

Anonymous Authentication Description

410 Anonymous authentication relates to system authentication and, in 411 particular, authentication of users for accessing resources stored on a 412 distributed or peer-to-peer file system. Its aim is to preserve the 413 anonymity of the users and to provide secure and private storage of data 414 and shared resources for users on a distributed system. It is a method of 415 authenticating access to a distributed system comprising the steps of; 416 * Receiving a user identifier; 417 * Retrieving an encrypted validation record identified by the user 418 identifier; 419 * Decrypting the encrypted validation record so as to provide 420 decrypted information; and 421 * Authenticating access to data in the distributed system using the 422 decrypted information.

423 Receiving, retrieving and authenticating may be performed on a node in 424 the distributed system preferably separate from a node performing the 425 step of decrypting The method further comprises the step of generating 426 the user identifier using a hash. Therefore, the user identifier may be 427 considered unique (and altered if a collision occurs) and suitable for V) 428 identifying unique validation records. The step of authenticating access 429 may preferably further comprise the step of digitally signing the user 430 identifier. This provides authentication that can be validated against 43] trusted authorities. The method further comprises the step of using the 432 signed user identifier as a session passport to authenticate a plurality of 433 accesses to the distributed system. This allows persistence of the 434 authentication for an extended session.

435 The step of decrypting preferably comprises decrypting an address in the 436 distributed system of a first chunk of data and the step of authenticating 437 access further comprises the step of determining the existence of the first 438 chunk at the address, or providing the location and names of specific 439 data elements in the network in the form of a data map as previously 440 describe. This efficiently combines the tasks of authentication and 441 starting to retrieve the data from the system. The method preferably 442 further comprises the step of using the content of the first chunk to obtain 443 further chunks from the distributed system. Additionally the decrypted 444 data from the additional chunks may contain a key pair allowing the user 445 at that stage to sign a packet sent to the network to validate them or 446 additionally may preferable self sign their own id.

447 Therefore, there is no need to have a potentially vulnerable record of the 448 file structure persisting in one place on the distributedsystem, as the 449 user's node constructs its database of file locations after logging onto the 450 system.

451 There is provided a distributed system comprising; 452 * a storage module adapted to store an encrypted validation record; 453 * a client node comprising a decryption module adapted to decrypt an 454 encrypted validation record so as to provide decrypted information; 455 and 456 * a verifying node comprising: 457. a receiving module adapted to receive a user identifier; 458 * a retrieving module adapted to retrieve from the storage module an 459 encrypted validation record identified by the user identifier; 460 * a transmitting module adapted to transmit the encrypted validation 461 record to the client node; and 462 * an authentication module adapted to authenticate access to data in 463 the distributed file system using the decrypted information from the 464 client node.

465 The client node is further adapted to generate the user identifier using a 466 hash. The authentication module is further adapted to authenticate 467 access by digitally sign the user identifier. The signed user identifier is 468 used as a session passport to authenticate a plurality of accesses by the 469 client node to the distributed system. The decryption module is further 470 adapted to decrypt an address in the distributed system of a first chunk of 471 data from the validation record and the authentication module is further 472 adapted to authenticate access by determining the existence of the first 473 chunk at the address. The client node is further adapted to use the 474 content of the first chunk to obtain further authentication chunks from the 475 distributed system.

476 There is provided at least one computer program comprising program 477 instructions for causing at least one computer to perform. One computer 478 program is embodied on a recording medium or read-only memory, 479 stored in at least one computer memory, or carried on an electrical 480 carrier signal.

481 Additionally there is a check on the system to ensure the user is login 482 into a valid node (software package). This will preferably include the 483 ability of the system to check validity of the running maidsafe.net 484 software by running content hashing or preferably certificate checking of 485 the node and also the code itself.

Linked elements for Shared Access to Private Files (Figure 1) 486 The shared access to private files invention consists of 2 individual 487 inventions, which collectively have 3 inter-linked functional elements, 488 these are: 489 The individual inventions are: 490 P16 - Share Maps 491 P15 -Create Map of Maps 492 The inter-linked functional elements are: 493 P17 -Provision of Public ID 494 P18 -Encrypted Communication 495 P11 -Identify Data With Very Small File 497 The shared access to private files (PT5) itself is made up from linkage of 498 elements, share maps (P16) and create map of maps (P15) to provide a 499 mechanism for secure sharing of data within a secure or insecure 500 network environment and to obviate the need for file servers and replace 501 their function with a distributed network of preferably standard processing 502 or computing nodes. In addition, share maps element (P16)) is preferably 503 dependent on sub-element provision of public ID (P17) and preferably 504 subelement encrypted communication (P18), and may make use of 505 create map of maps element (P15) which is dependent on sub-element 506 identify data with very small data element (P1 1).

Self Authentication Detail (Figure 2) 507 1. A computer program consisting of a user interface and a chunk server (a 508 system to process anonymous chunks of data) should be running, if not 509 they are started when user selects an icon or other means of starting the 510 program.

511 2. A user will input some data known to them such as a userid (random ID) 512 and PIN number in this case. These pieces of information may be 513 concatenated together and hashed to create a unique (which may be 514 confirmed via a search) identifier. in this case this is called the MID 515 (maidsafe.net ID) 516 3. A TMD (Today's MID) is retrieved from the network, the TMID is then 517 calculated as follows: 518 The TMID is a single use or single day ID that is constantly changed.

519 This allows maidsafe.net to calculate the hash based on the user ID pin 520 and another known variable which is calculable. For this variable we use 521 a day variable for now and this is the number of days since epoch 522 (01/01/1 970). This allows for a new ID daily, which assists in maintaining 523 the anonymity of the user. This TMID wilt create a temporary key pair to 524 sign the database chunks and accept a challenge response from the 525 holder of these db chunks. After retrieval and generation of a new key 526 pair the db is put again in new locations -rendering everything that was 527 contained in the TMID chunk useless. The TMID CANNOT be signed by 528 anyone (therefore hackers can't BAN an unsigned user from retrieving 529 this -in a DOS attack)-it is a special chunk where the data hash does 530 NOT match the name of the chunk (as the name is a random number 531 calculated by hashing other information (i.e. its a hash of the TMID as 532 described below) 533 * take dave as user ID and 1267 as pin.

534 * dave + (pin) 1267 = davel267 Hash of this becomes MID 535 * day variable (say today is 13416 since epoch) = 13416 536 * so take pin, and for example add the number in where the pin states 537 i.e. 538 * 613dav41e1267 539 * (6 at beginning is going round pin again) 540 * so this is done by taking 1st pin 1 -so put first day value at position 1 541 * then next pin number 2 -so day value 2 at position 2 542 * then next pin number 6 so day value 3 at position 6 543 * then next pin number 7 so day value 4 at position 7 544 * then next pin number is I so day value 5 at position 1 (again) 545 * so TMID is hash of 613dav41e1267 and the MID is simply a hash of 546 davel267 547 (This is an example algorithm and many more can be used to enforce 548 further security.) 549 4. From the TMID chunk the map of the user's database (or list of files 550 maps) is identified. The database is recovered from the net which 551 includes the data maps for the user and any keys passwords etc.. The 552 database chunks are stored in another location immediately and the old 553 chunks forgotten. This can be done now as the MID key pair is also in 554 the database and can now be used to manipulate user's data.

555 5. The maidsafe.net application can now authenticate itself as acting for 556 this MID and put get or forget data chunks belonging to the user.

557 6. The watcher process and Chunk server always have access to the PMID 558 key pair as they are stored on the machine itself, so can start and 559 receive and authenticate anonymous put / get / forget commands.

560 7. A DHT ID is required for a node in a DHT network this may be randomly 561 generated or in fact we can use the hash of the PMID public key to 562 identify the node.

563 8. When the users successfully logged in he can check his authentication 564 validation records exist on the network. These may be as follows: MAID (maidsafe.net anonymous ID) 565 1. This is a data element stored on net and preferably named with the hash 566 of the MID public Key.

567 2. It contains the MID public key + any PMID public keys associated with 568 this user.

569 3. This is digitally signed with the MID private key to prevent forgery.

570 4. Using this mechanism this allows validation of MID signatures by 571 allowing any users access to this data element and checking the 572 signature of it against any challenge response from any node pertaining 573 to be this MID (as only the MID owner has the private key that signs this 574 MID) Any crook could not create the private key to match to the public 575 key to thgitally sign so forgery is made impossible given today's 576 computer resources 577 5. This mechanism also allows a user to add or remove PMIDS (or chunk 578 servers acting on their behalf like a proxy) at will and replace PMID's at 579 any time in case of the PMID machine becoming compromised.

580 Therefore this can be seen as the PMID authentication element.

PMID (Proxy MID) 581 1. This is a data element stored on the network and preferably named with 582 the hash of the PMID public key. 22?

583 2. It contains the PMID public key and the MID ID (i.e. the hash of the MID 584 public key) and is signed by the MID private key (authenticated).

585 3. This allows a machine to act as a repository for anonymous chunks and 586 supply resources to the net for a MID.

587 4. When answering challenge responses any other machine will confirm the 588 PMID by seeking and checking the MIAD for the PMID and making sure 589 the PMID is mentioned in the MAID bit -otherwise the PMID is 590 considered rouge.

591 5. The key pair is stored on the machine itself and may be encoded or 592 encrypted against a password that has to be entered upon start-up 593 (optionally) in the case of a proxy provider who wishes to further 594 enhance PMID security.

595 6. The design allows for recovery from attack and theft of the PMID key pair 596 as the MAID data element can simply remove the PMID ID from the 597 MAID rendering it unauthenticated.

598 Figure 3 illustrates, in schematic form, a peer-to-peer network in 599 accordance with an embodiment of the invention; and 600 Figure 4 illustrates a flow chart of the authentication, in accordance with 601 a preferred embodiment of the present invention.

602 With reference to Figure 3, a peer-to-peer network 2 is shown with nodes 603 4 to 12 connected by a communication network 14. The nodes may be 604 Personal Computers (PCs) or any other device that can perform the 605 processing, communication and/or storage operations required to 606 operate the invention. The file system will typically have many more 607 nodes of all types than shown in Figure 3 and a PC may act as one or 608 many types of node described herein. Data nodes 4 and 6 store chunks 609 16 of files in the distributed system. The validation record node 8 has a 610 storage module 18 for storing encrypted validation records identified by a 611 user identifier.

612 The client node 10 has a module 20 for input and generation of user 613 identifiers. It also has a decryption module 22 for decrypting an encrypted 614 validation record so as to provide decrypted information, a database or 615 data map of chunk locations 24 and storage 26 for retrieved chunks and 616 files assembled from the retrieved chunks.

617 The verifying node 12 has a receiving module 28 for receiving a user 618 identifier from the client node. The retrieving module 30 is configured to 619 retrieve from the data node an encrypted validation record identified by 620 the user identifier. Alternatively, in the preferred embodiment, the 621 validation record node 8 is the same node as the verifying node 12, i.e. 622 the storage module 18 is part of the verifying node 12 (not as shown in 623 Figure 3). The transmitting module 32 sends the encrypted validation 624 record to the client node. The authentication module 34 authenticates 625 access to chunks of data distributed across the data nodes using the 626 decrypted information.

627 With reference to Figure 4, a more detailed flow of the operation of the 628 present invention is shown laid out on the diagram with the steps being 629 performed at the User's PC (client node) on the left 40, those of the 630 verifying PC (node) in the centre 42 and those of the data PC (node) on 631 the right 44.

632 A login box is presented 46 that requires the user's name or other detail 633 Preferably email address (the same one used in the client node software 634 installation and registration process) or simply name (i.e. nickname) and 635 the user's unique number, preferably PIN number. If the user is a main 636 user' then some details may already be stored on the PC. If the user is a 637 visitor, then the login box appears.

638 A content hashed number such as SHA (Secure Hash Algorithm), 639 Preferably 160 bits in length, is created 48 from these two items of data.

640 This hash' is now known as the User ID Key' (MID), which at this point is 641 classed as unverified' within the system. This is stored on the network as 642 the MAID and is simply the hash of the public key containing an 643 unencrypted version of the public key for later validation by any other 644 node. This obviates the requirement for a validation authority 645 The software on the user's PC then combines this MID with a standard 646 hello' code element 50, to create 52 a hello.packet'. This hello.packet is 647 then transmitted with a timed validity on the Internet.

648 The hello.packet will be picked up by the first node (for this description, 649 now called the verifying node') that recognises 54 the User ID Key 650 element of the hello.packet as matching a stored, encrypted validation 651 record file 56 that it has in its storage area. A login attempt monitoring 652 system ensures a maximum of three responses. Upon to many attempts, 653 the verifying PC creates a black list' for transmission to peers.

654 Optionally, an alert is returned to the user if a black list' entry is found 655 and the user may be asked to proceed or perform a virus check.

656 The verifying node then returns this encrypted validation record file to the 657 user via the internet. The user's pass phrase 58 is requested by a dialog 658 box 60, which then will allow decryption of this validation record file.

659 When the validation record file is decrypted 62, the first data chunk 660 details, including a decrypted address', are extracted 64 and the user PC 661 sends back a request 66 to the verifying node for it to initiate a query for 662 the first file-chunk ID' at the decrypted address' that it has extracted 663 from the decrypted validation record file, or preferably the data map of 664 the database chunks to recreate the database and provide access to the 665 key pair associated with this MID.

666 The verifying node then acts as a relay node' and initiates a notify only 667 query for this file-chunk ID' at the decrypted address' 668 Given that some other node (for this embodiment, called the data node') 669 has recognised 68 this request and has sent back a valid notification 670 only' message 70 that a file-chunk ID' corresponding to the request sent 671 by the verifying node does indeed exist, the verifying node then digitally 672 signs 72 the initial User ID Key, which is then sent back to the user.

673 On reception by the user 74, this verified User ID Key is used as the 674 user's session passport. The user's PC proceeds to construct 76 the 675 database of the file system as backed up by the user onto the network.

676 This database describes the location of all chunks that make up the 677 user's file system. Preferably the ID Key will contain irrefutable evidence 678 such as a public/private key pair to allow signing onto the network as 679 authorised users, preferably this is a case of self signing his or her own 680 ID -in which case the ID Key is decrypted and user is valid -self 681 validating.

682 Further details of the embodiment will now be described. A proxy-683 controlled' handshake routine is employed through an encrypted point-to- 684 point channel, to ensure only authorised access by the legal owner to the 685 system, then to the user's file storage database, then to the files therein.

686 The handshaking check is initiated from the PC that a user logs on to 687 (the User PC'), by generating the unverified encrypted hash' known as 688 the User ID Key', this preferably being created from the user's 689 information preferably email address and their PIN number. This hash' 690 is transmitted as a hello.packet' on the Internet, to be picked up by any 691 system that recognises the User ID as being associated with specific 692 data that it holds. This PC then becomes the verifying PC' and will 693 initially act as the User PC's gateway' into the system during the 694 authentication process. The encrypted item of data held by the verifying 695 PC will temporarily be used as a validation record', it being directly 696 associated with the user's identity and holding the specific address of a 697 number of data chunks belonging to the user and which are located 698 elsewhere in the peer-to-peer distributed file system. This validation 699 record' is returned to the User PC for decryption, with the expectation 700 that only the legal user can supply the specific information that will allow 70! its accurate decryption.

702 Preferably this data may be a signed response being given back to the 703 validating node which is possible as the id chunk when decrypted 704 (preferably symmetrically) contains the users public and private keys 705 allowing non refutable signing of data packets.

706 Preferably after successful decryption of the TMID packet (as described 707 above) the machine will now have access to the data map of the 708 database and public/private key pair allowing unfettered access to the 709 system.

710 It should be noted that in this embodiment, preferably no communication 711 is carried out via any nodes without an encrypted channel such as TLS 712 (Transport Layer Security) or SSL (Secure Sockets Layer) being set up 713 first. A peer talks to another peer via an encrypted channel and the other 714 peer (proxy) requests the information (e.g. for some space to save 715 information on or for the retrieval of a file). An encrypted link is formed 716 between all peers at each end of communications and also through the 717 proxy during the authentication process. This effectively bans snoopers 718 from detecting who is talking to whom and also what is being sent or 719 retrieved. The initial handshake for self authentication is also over an 720 encrypted link.

721 Secure connection is provided via certificate passing nodes, in a manner 722 that does not require intervention, with each node being validated by 723 another, where any invalid event or data, for whatever reason (fraud 724 detection, snooping from node or any invalid algorithms that catch the 725 node) will invalidate the chain created by the node. This is all transparent 726 to the user.

727 Further modifications and improvements may be added without departing 728 from the scope of the invention herein described.

729 Figure 5 illustrates a flow chart of data assurance event sequence in 730 accordance with first embodiment of this invention 731 Figure 6 illustrates a flow chart of file chunking event sequence in 732 accordance with second embodiment of this invention 733 Figure 7 illustrates a schematic diagram of file chunking example 734 Figure 8 illustrates a flow chart of self healing event sequence 735 Figure 9 illustrates a flow chart of peer ranking event sequence 736 Figure 10 illustrates a flow chart of duplicate removal event sequence 737 With reference to Figure 5, guaranteed accessibility to user data by data 738 assurance is demonstrated by flow chart. The data is copied to at least 739 three disparate locations at step (10). The disparate locations store data 740 with an appendix pointing to the other two locations by step (20) and is 741 renamed with hash of contents. Preferably this action is managed by 742 another node i.e. super node acting as an intermediary by step (30).

743 Each local copy at user's PC is checked for validity by integrity test by 744 step (40) and in addition validity checks by integrity test are made that 745 the other 2 copies are also still ok by step (50).

746 Any single node failure initiates a replacement copy of equivalent leaf 747 node being made in another disparate location by step (60) and the other 748 remaining copies are updated to reflect this change to reflect the newly 749 added replacement leaf node by step (70).

750 The steps of storing and retrieving are carried out via other network 751 nodes to mask the initiator (30).

752 The method further comprises the step of renaming all files with a hash 753 of their contents.

754 Therefore, each file can be checked for validity or tampering by running a 755 content hashing algorithm such as (for example) MD5 or an SHA variant, 756 the result of this being compared with the name of the file.

757 With reference to Figure 6, provides a methodology to manageable sized 758 data elements and to enable a complimentary data structure for and 759 compression and encryption and the step is to file chunking. By user's 760 pre-selection the nominated data elements (files are passed to chunking 761 process. Each data element (file) is split into small chunks by step (80) 762 and the data chunks are encrypted by step (90) to provide security for the 763 data. The data chunks are stored locally at step (100) ready for network 764 transfer of copies. Only the person or the group, to whom the overall data 765 belongs, will know the location of these (100) or the other related but 766 dissimilar chunks of data. All operations are conducted within the user's 767 local system. No data is presented externally.

768 Each of the above chunks does not contain location information for any 769 other dissimilar chunks. This provides for, security of data content, a 770 basis for integrity checking and redundancy. 3D

771 The method further comprises the step of only allowing the person (or 772 group) to whom the data belongs, to have access to it, preferably via a 773 shared encryption technique. This allows persistence of data.

774 The checking of data or chunks of data between machines is carried out 775 via any presence type protocol such as a distributed hash table network.

776 on the occasion when all data chunks have been relocated (i.e. the user 777 has not logged on for a while,) a redirection record is created and stored 778 in the super node network, (a three copy process -similar to data) 779 therefore when a user requests a check, the redirection record is given to 780 the user to update their database.

781 This efficiently allows data resilience in cases where network churn is a 782 problem as in peer to peer or distributed networks.

783 With reference to Figure 7 which illustrates flow chart example of file 784 chunking. User's normal file has 5Mb document, which is chunked into 785 smaller variable sizes e.g. 135kb, 512kb, 768kb in any order. All chunks 786 may be compressed and encrypted by using Pass phrase. Next step is to 787 individually hash chunks and given hashes as names. Then database 788 record as a file is made from names of hashed chunks brought together 789 e.g. in empty version of original file (Cl!! II ii I! II II I! II,tl,t2,t3: 790 C211 II II /111/111/! ,tl,t2,t3 etc), this file is then sent to transmission queue in 791 storage space allocated to client application.

792 With reference to Figure 8 provides a self healing event sequence 793 methodology. Self healing is required to guarantee availability of accurate 794 data. As data or chunks become invalid by failing integrity test by step 795 (110). The location of failing data chunks is assessed as unreliable and 796 further data from the leaf node is ignored from that location by step (120).

797 A Good Copy' from the known good' data chunk is recreated in a new 798 and equivalent leaf node. Data or chunks are recreated in a new and 799 safer location by step (130). The leaf node with failing data chunks is 800 marked as unreliable and the data therein as dirty' by step (140). Peer 801 leaf nodes become aware of this unreliable leaf node and add its location 802 to watch list by step (150). All operations conducted within the user's 803 local system. No data is presented externally.

804 Therefore, the introduction of viruses, worms etc. wilt be prevented and 805 faulty machines! equipment identified automatically.

806 The network will use SSL or TLS type encryption to prevent unauthorised 807 access or snooping.

808 With reference to Figure 9, Peer Ranking Id required to ensure consistent 809 response and performance for the level of guaranteed interaction 810 recorded for the user. For Peer Ranking each node (leaf node) monitors 811 its own peer node's resources and availability in a scaleable manner, 812 each leaf node is constantly monitored.

813 Each data store (whether a network service, physical drive etc.) is 814 monitored for availability. A qualified availability ranking is appended to 815 the (leaf) storage node address by consensus of a monitoring super node 816 group by step (160). A ranking figure will be appended by step (160) and 817 signed by the supply of a key from the monitoring super node; this would 818 preferably be agreed by more super nodes to establish a consensus for 819 altering the ranking of the node. The new rank will preferably be 820 appended to the node address or by a similar mechanism to allow the 821 node to be managed preferably in terms of what is stored there and how 822 many copies there has to be of the data for it to be seen as perpetual.

823 Each piece of data is checked via a content hashing mechanism for data 824 integrity, which is carried out by the storage node itself by step (170) or 825 by its partner nodes via super nodes by step (180) or by instigating node 826 via super nodes by step (190) by retrieval and running the hashing 827 algorithm against that piece of data. The data checking cycle repeats 828 itself.

829 As a peer (whether an instigating node or a partner peer (i.e. one that 830 has same chunk)) checks the data, the super node querying the storage 831 peer will respond with the result of the integrity check and update this 832 status on the storage peer. The instigating node or partner peer will 833 decide to forget this data and will replicate it in a more suitable location.

834 If data fails the integrity check the node itself will be marked as dirty' by 835 step (200) and dirty' status appended to leaf node address to mark it as 836 requiring further checks on the integrity of the data it holds by step (210).

837 Additional checks are carried out on data stored on the leaf node marked 838 as dirty' by step (220). If pie-determined percentage of data found to be 839 dirty' node is removed from the network except for message traffic by 840 step (230). A certain percentage of dirty data being established may 841 conclude that this node is compromised or otherwise damaged and the 842 network would be informed of this. At that point the node will be removed 843 from the network except for the purpose of sending it warning messages 844 by step (230).

845 This allows either having data stored on nodes of equivalent availability 846 and efficiency or dictating the number of copies of data required to 847 maintain reliability.

848 Further modifications and improvements may be added without departing 849 from the scope of the invention herein described.

850 With reference to Figure 10, duplicate data is removed to maximise the 851 efficient use of the disk space. Prior to the initiation of the data backup 852 process by step (240), internally generated content hash may be 853 checked for a match against hashes stored on the internet by step (250) 854 or a list of previously backed up data (250). This will allow only one 855 backed up copy of data to be kept. This reduces the network wide 856 requirement to backup data which has the exact same contents.

857 Notification of shared key existence is passed back to instigating node by 858 step (260) to access authority check requested, which has to pass for 859 signed result is to be passed back to storage node. The storage node 860 passes shared key and database back to instigating node by step (270) 861 Such data is backed up via a shared key which after proof of the file 862 existing (260) on the instigating node, the shared key (270)15 shared with 863 this instigating node. The location of the data is then passed to the node 864 for later retrieval if required. 865 This maintains copyright as people can only backup what they prove

to 866 have on their systems and not publicly share copyright infringed data 867 openly on the network.

868 This data may be marked as protected or not protected by step (280) 869 which has check carried out for protected or non-protected data content.

870 The protected data ignores sharing process.

Perpetual Data (Figure 11) 871 According to a related aspect of this invention, a file is chunked or 872 split into constituent parts (1) this process involves calculating the chunk 873 size, preferably from known data such as the first few bytes of the hash 874 of the file itself and preferably using a modulo division technique to 875 resolve a figure between the optimum minimum and optimum maximum 876 chunk sizes for network transmission and storage.

877 Preferably each chunk is then encrypted and obfuscated in some manner 878 to protect the data. Preferably a search of the network is carried out 879 looking for values relating to the content hash of each of the chunks (2).

-

880 If this is found (4) then the other chunks are identified too, failure to 881 identify all chunks may mean there is a collision on the network of file 882 names or some other machine is in the process of backing up the same 883 file. A back-off time is calculated to check again for the other chunks. If 884 all chunks are on the network the file is considered backed up and the 885 user will add their MID signature to the file after preferably a challenge 886 response to ensure there a valid user and have enough resources to do 887 this.

888 If no chunks are on the net the user preferably via another node (3) will 889 request the saving of the first copy (preferably in distinct time zones or 890 other geographically dispersing method).

891 The chunk will be stored (5) on a storage node allowing us to see the 892 PMID of the storing node and store this.

893 Then preferably a Key.value pair of chunkid.public key of initiator is 894 written to net creating a Chunk ID (CID) (6) Storage and Retrieval 895 According to a related aspect of this invention, the data is stored in 896 multiple locations. Each location stores the locations of its peers that hold 897 identical chunks (at least identical in content) and they all communicate 898 regularly to ascertain the health of the data. The preferable method is as 899 follows: 900 Preferably the data is copied to at least three disparate locations.

901 Preferably each copy is performed via many nodes to mask the initiator.

902 Preferably each local copy is checked for validity and checks are made 903 that the preferably other 2 copies are also still valid.

904 Preferably any single node failure initiates a replacement copy being 905 made in another disparate location and the other associated copies are 906 updated to reflect this change.

907 Preferably the steps of storing and retrieving are carried out via other 908 network nodes to mask the initiator.

909 Preferably, the method further comprises the step of renaming all files 910 with a hash of their contents.

911 Preferably each chunk may alter its name by a known process such as a 912 binary shift left of a section of the data. This allows the same content to 913 exist but also allows the chunks to appear as three different bits of data 914 for the sake of not colliding on the network.

915 Preferably each chunk has a counter attached to it that allows the 916 network to understand easily just how many users are attached to the 917 chunk -either by sharing or otherwise. A user requesting a chunk forget' 918 will initiate a system question if they are the only user using the chunk 919 and if so the chunk will be deleted and the user's required disk space 920 reduced accordingly. This allows users to remove files no longer required 921 and free up local disk space. Any fife also being shared is preferably 922 removed from the user's quota and the user's database record or data 923 map (see later) is deleted.

924 Preferably this counter is digitally signed by each node sharing the data 925 and therefore will require a signed forget' or delete' command.

926 Preferably even store', put', retrieve' and get' commands should also 927 be either digitally signed or preferably go through a PKI challenge 928 response mechanism.

929 To ensure fairness preferably this method will be monitored by a 930 supernode or similar to ensure the user has not simply copied the data 931 map for later use without giving up the disk space for it. Therefore the 932 user's private ID public key will be used to request the forget chunk 933 statement. This will be used to indicate the user's acceptance of the 934 chunk forget' command and allow the user to recover the disk space.

935 Any requests against the chunk will preferably be signed with this key 936 and consequently rejected unless the user's system gives up the space 937 required to access this file.

938 Preferably each user storing a chunk will append their signed request to 939 the end of the chunk in an identifiable manner i.e. prefixed with 80 -or 940 similar.

941 Forgetting the chunk means the signature is removed from the file. This 942 again is done via a signed request from the storage node as with the 943 original backup request.

944 Preferably this signed request is another small chunk stored at the same 945 location as the data chunk with an appended postfix to the chunk 946 identifier to show a private ID is storing this chunk. Any attempt by 947 somebody else to download the file is rejected unless they first subscribe 948 to it, i.e. a chunk is called 12345 so a file is saved called 12345 <signed 949 store request>. This will allow files to be forgotten when all signatories to 950 the chunk are gone. A user will send a signed no store' or forget' and 951 their ID chunk will be removed, and in addition if they are the last user 952 storing that chunk, the chunk is removed. Preferably this will allow a 953 private anonymous message to be sent upon chunk failure or damage 954 allowing a proactive approach to maintaining clean data.

955 Preferably as a node fails the other nodes can preferably send a 956 message to all sharers of the chunk to identify the new location of the 957 replacement chunk.

958 Preferably any node attaching to a file then downloading immediately 959 should be considered an alert and the system may take steps to slow 960 down this node's activity or even halt it to protect data theft.

Chunk Checks: (Figure 12) 961 1. Storage node containing chunk 1 checks its peers. As each peer is 962 checked it reciprocates the check. These checks are split into preferably 963 2 types: 964 a. Availability check (i.e. simple network ping) 965 b. Data integrity check -in this instance the checking node takes a chunk 966 and appends random data to it and takes a hash of the result, It then 967 sends the random data to the node being checked and requests the 968 hash of the chunk with the random data appended. The result is 969 compared with a known result and the chunk will be assessed as 970 either healthy or not. If not, further checks with other nodes occur to 971 find the bad node.

972 2. There may be multiple storage nodes depending on the rating of 973 machines and other factors. The above checking is carried out by all 974 nodes from 1 to n (where n is total number of storage nodes selected for 975 the chunk). Obviously a poorly rated node will require to give up disk 976 space in relation to the number of chunks being stored to allow perpetual 977 data to exist. This is a penalty paid by nodes that are switched off.

978 3. The user who stored the chunk will check on a chunk from I storage 979 node randomly selected. This check will ensure the integrity of the chunk 980 and also ensure there are at least 10 other signatures existing already for 981 the chunk. If there are not and the user's ID is not listed, the user signs 982 the chunk.

983 4. This shows another example of another user checking the chunk. Note 984 that the user checks X (40 days in this diagram) are always at least 75% 985 of the forget time retention (Y) (i.e. when a chunk is forgotten by all 986 signatories it is retained for a period of time Y). This is another algorithm 987 that will continually develop.

Storage of Additional Chunks (Figure 13) 988 1. maidsafe.net program with user logged in (so MID exists) has chunked a 989 file. It has already stored a chunk and is now looking to store additional 990 chunks. Therefore a Chunk ID (CID) should exist on the net. This process 991 retrieves this CID.

992 2. The CID as shown in storing initial chunk contains the chunk name and 993 any public keys that are sharing the chunk. In this instance it should only 994 be our key as we are first ones storing the chunks (others would be in a 995 back-off period to see if we back other chunks up). We shift the last bit 996 (could be any function on any bit as long as we can replicate it) 997 3. We then check we won't collide with any other stored chunk on the net - 998 i e. it does a CID search again.

999 4. We then issue our broadcast to our supernodes (i.e. the supernodes we 1000 are connected to) stating we need to store X bytes and any other 1001 information about where we require to store it (geographically in our case 1002 -time zone (TZ)) 1003 5. The supernode network finds a storage location for us with the correct 1004 rank etc. 1005 6. The chunk is stored after a successful challenge response i.e. In the 1006 maidsafe.net network. MIDs will require to ensure they are talking or 1007 dealing with validated nodes, so to accomplish this a challenge process 1008 is carried out as follows: sender (S] receiver (R] 1009 * (SI I wish to communicate (store retrieve forget data etc.) and I am MAID 1010 * ER] retrieves MAID public key from DHT and encrypts a challenge 1011 (possibly a very large number encrypted with the public key retrieved) 1012 * [S] gets key and decrypts and encrypts [R] answer with his challenge 1013 number also encrypted with (R]'s public key 1014 * [R] receives response and decrypts his challenge and passes back 1015 answer encrypted again with ES] public key 1016 (Communication is now authenticated between these two nodes.) 1017 7. The CID is then updated with the second chunk name and the location it 1018 is stored at. This process is repeated for as many copies of a chunk that 1019 are required.

1020 8. Copies of chunks will be dependent on many factors including file 1021 popularity (popular files may require to be more dispersed closer to 1022 nodes and have more copies. Very poorly ranked machines may require 1023 an increased amount of chunks to ensure they can be retrieved at any 1024 time (poorly ranked machines will therefore have to give up more space.) Security Availability 1025 According to a related aspect of this invention, each file is split into 1026 small chunks and encrypted to provide security for the data. Only the 4ç0 1027 person or the group, to whom the overall data belongs, will know the 1028 location of the other related but dissimilar chunks of data.

029 Preferably, each of the above chunks does not contain location 1030 information for any other dissimilar chunks; which provides for security of 1031 data content, a basis for integrity checking and redundancy.

1032 Preferably, the method further comprises the step of only allowing the 1033 person (or group) to whom the data belongs to have access to it, 1034 preferably via a shared encryption technique which allows persistence of 1035 data.

1036 Preferably, the checking of data or chunks of data between machines is 1037 carried out via any presence type protocol such as a distributed hash

1038 table network.

1039 Preferably, on the occasion when all data chunks have been relocated, 1040 i.e. the user has not logged on for a while, a redirection record is created 1041 and stored in the super node network, (a three copy process -similar to 1042 data) therefore when a user requests a check, the redirection record is 1043 given to the user to update their database, which provides efficiency that 1044 in turn allows data resilience in cases where network churn is a problem 1045 as in peer to peer or distributed networks. This system message can be 1046 preferably passed via the messenger system described herein.

1047 Preferably the system may simply allow a user to search for his chunks 1048 and through a challenge response mechanism, locate and authenticate 1049 himself to have authority to get/forget this chunk.

1050 Further users can decide on various modes of operation preferably such 1051 as maintain a local copy of all files on their local machine, unencrypted or 1052 chunked or chunk and encrypt even local files to secure machine 1053 (preferably referred to as off line mode operation) or indeed users may 4-' 1054 decide to remove all local data and rely completely on preferably 1055 maidsafe.net or similar system to secure their data.

Self Healing 1056 According to a related aspect of this invention, a self healing network 1057 method is provided via the following process; 1058 * As data or chunks become invalid -data is ignored from that location 1059 * Data or chunks are recreated in a new and safer location.

1060 * The original location is marked as bad.

1061 * Peers note this condition and add the bad location to a watch list.

1062 This will prevent the introduction of viruses; worms etc. will allow faulty 1063 machines! equipment to be identified automatically.

1064 Preferably, the network layer will use SSL or TLS channel encryption to 1065 prevent unauthorised access or snooping.

Self Healing (Figure 1 4aIb) 1066 1. A data element called a Chunk ID (CID) is created for each chunk. Added 1067 to this is the also stored at' MID for the other identical chunks. The other 1068 chunk names are also here as they may be renamed slightly (i.e. by bit 1069 shifting a part of the name in a manner that calculable).

1070 2. All storing nodes (related to this chunk) have a copy of this CID file or 1071 can access it at any stage from the DHT network, giving each node 1072 knowledge of all others.

1073 3. Each of the storage nodes have their copy of the chunk.

1074 4. Each node queries its partner's availability at frequent intervals, On less 1075 frequent intervals a chunk health check is requested. This involves a 1076 node creating some random data and appending this to it's chunk and 1077 taking the hash. The partner node will be requested to take the random 1078 data and do likewise and return the hash result. This result is checked 1079 against the result the initiator had and chunk is then deemed healthy or 1080 not. Further tests can be done as each node knows the hash their chunk 1081 should create and can self check n that manner on error and report a 1082 dirty node.

1083 5. Now we have a node fail (creating a dirty chunk) 1084 6. The first node to note this carries out a broadcast to other nodes to say it 1085 is requesting a move of the data.

1086 7. The other nodes agree to have CID updated (they may carry out their 1087 own check to confirm this).

1088 8. A broadcast is sent to the supernode network closest to the storage node 1089 that failed, to state a re-storage requirement.

1090 9. The supernode network picks up the request.

1091 10. The request is to the supernode network to store x amount of data at a 1092 rank of y.

1093 11.A supernode will reply with a location 1094 12. The storage node and new location carry out a challenge response 1095 request to validate each other.

1096 13. The chunk is stored and the CID is updated and signed by the three or 1097 more nodes storing the chunk.

Peer Ranking 1098 According to a related aspect of this invention, there is the addition of 1099 a peer ranking mechanism, where each node (leaf node) monitors its 1100 own peer node's resources and availability in a scalable manner. Nodes 1101 constantly perform this monitoring function.

1102 Each data store (whether a network service, physical drive etc.) is 1103 monitored for availability. A ranking figure is appended and signed by the 1104 supply of a key from the monitoring super node, this being preferably 1105 agreed by more super nodes to establish a consensus before altering the 1106 ranking of the node. Preferably, the new rank will be appended to the 1107 node address or by a similar mechanism to allow the node to be 1108 managed in terms of what is stored there and how many copies there 1109 has to be of the data for it to be seen as perpetual.

1110 Each piece of data is checked via a content hashing mechanism. This is 1111 preferably carried out by the storage node itself or by its partner nodes 1112 via super nodes or by an instigating node via super nodes by retrieving 1113 and running the hashing algorithm against that piece of data.

1114 Preferably, as a peer (whether an instigating node or a partner peer (i.e. 1115 one that has same chunk)) checks the data, the super node querying the 1116 storage peer will respond with the result of the integrity check and update 1117 this status on the storage peer. The instigating node or partner peer will 1118 decide to forget this data and will replicate it in a more suitable location.

1119 If data fails the integrity check, the node itself will be marked as dirty' and 1120 this status will preferably be appended to the node's address for further 1121 checks on other data to take this into account. Preferably a certain 1122 percentage of dirty data being established may conclude that this node is 1123 compromised or otherwise damaged and the network would be informed 1124 of this. At that point the node will be removed from the network except for 1125 the purpose of sending it warning messages.

1126 In general, the node ranking figure will take into account at least; 1127 availability of the network connection, availability of resources, time on 1128 the network with a rank (later useful for effort based trust model), amount 1129 of resource (including network resources) and also the connectivity 1130 capabilities of any node (i.e. directly or indirectly contactable) 1131 This then allows data to be stored on nodes of equivalent availability and 1132 efficiency, and to determine the number of copies of data required to 1133 maintain reliability.

Enctypt-Dec,ypt 1134 According to a related aspect of this invention, the actual encrypting 1135 and decrypting is carried out via knowledge of the file's content and this 1136 is somehow maintained (see next). Keys will be generated and preferably 1137 stored for decrypting. Actually encrypting the file will preferably include a 1138 compression process and further obfuscation methods. Preferably the 1139 chunk will be stored with a known hash preferably based on the contents 1140 of that chunk.

1141 Decrypting the file will preferably require the collation of all chunks and 1142 rebuilding of the file itself. The file may preferably have its content mixed 1143 up by an obfuscation technique rendering each chunk useless on its own.

1144 Preferably every file will go through a process of byte (or preferably bit) 1145 swapping between its chunks to ensure the original file is rendered 1146 useless without all chunks.

1147 This process will preferably involve running an algorithm which preferably 1148 takes the chunk size and then distributes the bytes in a pseudo random 1 149 manner preferably taking the number of chunks and using this as an 1150 iteration count for the process. This will preferably protect data even in 1151 event of somebody getting hold of the encryption keys -as the chunks 1152 data is rendered useless even if transmitted in the open without 1153 encryption.

1154 This defends against somebody copying all data and storing for many 1155 years until decryption of today's algorithms is possible, although this is 1156 many years away.

1157 This also defends against somebody; instead of attempting to decrypt a 1158 chunk by creating the enormous amount of keys possible, (in the region 1159 of 2"54) rather instead creating the keys and presenting chunks to all 1160 keys -if this were possible (which is unlikely) a chunk would decrypt.

1161 The process defined here makes this attempt useless.

1162 All data will now be considered to be diluted throughout the original 1163 chunks and preferably additions to this algorithm will only strengthen the 1164 process.

Identify Chunks 1I65 According to a related aspect of this invention, a chunk's original 1166 hash or other calculable unique identifier will be stored. This will be 1167 stored with preferably the final chunk name. This aspect defines that 1168 each file will have a separate map preferably a file or database entry to 1169 identify the file and the name of its constituent parts. Preferably this will 1170 include local information to users such as original location and rights 1171 (such as a read only system etc). Preferably some of this information 1172 can be considered shareable with others such as filename, content hash 1173 and chunks names.

ID Data with Small File (Figure 1 -P11) 1174 According to a related aspect of this invention; these data maps may 1175 be very small in relation to the original data itself allowing transmission of 1176 files across networks such as the internet with extreme simplicity, 1177 security and bandwidth efficiency. Preferably the transmission of maps 1178 will be carried out in a very secure manner, but failure to do this is akin to 1179 currently emailing a file in its entirety.

1180 This allows a very small file such as the data map or database record to 1181 be shared or maintained by a user in a location not normally large 1182 enough to fit a file system of any great size, such as on a PDA or mobile 1183 phone. The identification of the chunk names, original names and final 1184 names are all that is required to retrieve the chunks and rebuild the file 1185 with certainty.

1186 With data maps in place a user's whole machine, or all its data, can exist 1187 elsewhere. Simply retrieving the data maps of all data, is all that is 1188 required to allow the user to have complete visibility and access to all 1189 their data as well as any shared files they have agreed to.

Revision Control 1190 According to a related aspect of this invention, as data is updated 1191 and the map contents alter to reflect the new contents, this will preferably c7 1192 not require the deletion or removal of existing chunks, but instead allow 1193 the existing chunks to remain and the map appended to with an 1194 indication of a new revision existing. Preferably further access to the file 1195 will automatically open the last revision unless requested to open an 1196 earlier revision.

1197 Preferably revisions of any file can be forgotten or deleted (preferably 1198 after checking the file counter or access list of sharers as above). This 1199 will allow users to recover space from no longer required revisions.

Create Map of Maps (Figure 1 -P15) 1200 According to a related aspect of this invention, data identifiers, 1201 preferably data maps as mentioned earlier, can be appended to each 1202 other in a way that preferably allows a single file or database record to 1203 identify several files in one map. This is known as a share. Such a share 1204 can be private to the individual, thereby replacing the directory structure 1205 of files that users are normally used to, and replacing this with a new 1206 structure of shares very similar to volumes or filing cabinets as this is 1207 more in line with normal human nature and should make things simpler.

Share Maps (Figure 1 -P16) 1208 According to a related aspect of this invention, this map of maps will 1209 preferably identify the users connected to it via some public ID that is 1210 known to each other user, with the map itself will being passed to users 1211 who agree to join the share. This will preferably be via an encrypted 1212 channel such as ms messenger or similar. This map may then be 1213 accessed at whatever rank level users have been assigned. Preferably 1214 there will be access rights such as read / delete / add / edit as is typically 1215 used today. As a map is altered, the user instigating this is checked 1216 against the user list in the map to see if this is allowed. If not, the request 1217 is ignored but preferably the users may then save the data themselves to 1218 their own database or data maps as a private file or even copy the file to 1219 a share they have access rights for. These shares will preferably also 1220 exhibit the revision control mechanism described above.

1221 Preferably joining the share will mean that the users subscribe to a 1222 shared amount of space and reduce the other subscription, i.e. a 10Gb 1223 share is created then the individual gives up 10Gb (or equivalent 1224 dependent on system requirements which may be a multiple or divisor of 1225 10Gb). Another user joining means they both have a 5Gb space to give 1226 up and 5 users would mean they all have a 2Gb or equivalent space to 1227 give up. So with more people sharing, requirements on all users reduce.

Shared Access to Private Files (Figure 1 -PT5 and Figure 15) 1228 1. User I logs on to network 1229 2. Authenticates ID -i.e. gets access to his public and private keys to sign 1230 messages. This should NOT be stored locally but should have been 1231 retrieved from a secure location -anonymously and securely.

1232 3. User I saves a file as normal (encrypted, obfuscated, chunked, and 1233 stored on the net via a signed and anonymous ID. This ID is a special 1234 maidsafe.net Share ID (MSID) and is basically a new key pair created 1235 purely for interacting with the share users -to mask the user's MID (i.e. 1236 cannot be tied to MPID via a share). So again the MSID is a key pair and 1237 the ID is the hash of the public key -this public key is stored in a chunk 1238 called the hash and signed and put on the net for others to retrieve and 1239 confirm that the public key belongs to the hash. "-9

1240 4. User creates a share -which is a data map with some extra elements to 1241 cover users and privileges.

1242 5. File data added to file map is created in the backup process, with one 1243 difference, this is a map of maps and may contain many files -see 14 1244 6. User 2 logs in 1245 7. User 2 has authentication details (i.e. their private MPID key) and can 1246 sign / decrypt with this MPID public key.

1247 8. User I sends a share join request to user 2 (shares are invisible on the 1248 net -i.e. nobody except the sharers to know they are there).

1249 9. User 1 signs the share request to state he will join share. He creates his 1250 MSID key pair at this time. The signed response includes User 2's MSID 1251 public key.

1252 10. Share map is encrypted or sent encrypted (possibly by secure 1253 messenger) to User I along with the MSID public keys of any users of the 1254 share that exist. Note the transmittion of MSID public key may not be 1255 required as the MSID chunks are saved on the net as described in 3 so 1256 any user can check the public key at any time - this just saves the search 1257 operation on that chunk to speed the process up slightly.

1261 Note that as each user saves new chunks he does so with the MSID 1262 keys. this means that if a shares is deleted or removed the chunks still 1263 exist in the users home database and he can have the option to keep the 1264 data maps and files as individual files or simply forget them all.

1258 11. Each user has details added to the share these include public name 1259 (MP1D) and rights (read / write / delete / admin etc.)

1260 12. A description of the share file

1265 Note also that as a user opens a file, a lock is transmitted to all other 1266 shares and they will only be allowed to open a file read only -they can 1267 request unlock (i.e. another user unlocks the file-meaning it becomes 1268 read only). Non-logged in users will have a message buffered for them - 1269 if the file is closed the buffered message is deleted (as there is no point 1270 in sending it to the user now) and logged in users are updated also.

1271 This will take place using the messenger component of the system to 1272 automatically receive messages from share users about shares (but 1273 being limited to that).

Provide Public ID (Figure 1 -P17) 1274 According to a related aspect of this invention, a public and Private 1275 key pair is created for a network where preferably the user is 1276 anonymously logged on, and preferably has a changeable pseudo 1277 random private id which is only used for transmission and retrieval of ID 1278 blocks giving access to that network.

1279 Preferably this public private key pair will be associated with a public ID.

1280 This ID will be transmittable in a relatively harmless way using almost 1281 any method including in the open (email, ftp, www etc.) but preferably in 1282 an encrypted form. Preferably this ID should be simple enough to 1283 remember such as a phone number type length. Preferably this ID will be 1284 long enough however, to cope with all the world's population and more, 1285 therefore it would be preferably approx 11 characters long.

1286 This ID can be printed on business cards or stationary like a phone 1287 number or email address and cannot be linked to the users private ID by 1288 external sources. However the user's own private information makes this 1289 link by storing the data in the ID bit the user retrieves when logging in to 1290 the network or via another equally valid method of secure network 1291 authentication.

1292 This ID can then be used in data or resource sharing with others in a 1293 more open manner than with the private id. This keeps the private ID 1294 private and allows much improved inter-node or inter-person 1295 communications.

Encrypted Communications (Figure 1 -P18) 1296 According to a related aspect of this invention, the communications 1297 between nodes should be both private and validated. This is preferably 1298 irrefutable but there should be options for refutable communications if 1299 required. For irrefutable communications the user logs on to the network 1300 and retrieves their key pair and ID. This is then used to start 1301 communications. Preferably the user's system will seek another node to 1302 transmit and receive from randomly -this adds to the masking of the 1303 user's private ID as the private ID is not used in any handshake with 1304 network resources apart from logging in to the network.

1305 As part of the initial handshake between users, a key may be passed.

1306 Preferably this is a code passed between users over another 1307 communications mechanism in a form such as a pin number known only 1308 to the users involved or it may be as simple as appending the user's 1309 name and other info to a communication request packet such as exists in 1310 some instant messaging clients today -i.e. David wants to communicate 1311 with you allow / deny / block.

1312 Unlike many communications systems today, this is carried out on a 1313 distributed server-less network. This however provides the problem of 1314 what to do when users are off line. Today messages are either, stopped 1315 or stored on a server, and in many cases not encrypted or secured. This 1316 invention allows users to have messages securely buffered whilst off line.

1317 This is preferably achieved by the node creating a unique identifier for 1318 only this session and passing that ID to all known nodes in the user's 1319 address book. Users on-line get this immediately, users off-line have this 1320 buffered to their last known random ID. This ensures that the ability to 1321 snoop on a user's messages is significantly reduced as there is no 1322 identifier to people outside the address book as to the name of the 1323 random ID bit the messages are stored to. The random ID bit is 1324 preferably used as the first part of the identified buffer file name and 1325 when more messages are stored then another file is saved with the 1326 random Id and a number appended to it representing the next sequential 1327 available number. Therefore a user will log on and retrieve the messages 1328 sequentially. This allows buffered secured and distributed messaging to 1329 exist.

Document Signing 1330 According to a related aspect of this invention, a by-product of 1331 securing communications between nodes using asymmetric encryption is 1332 as previously stated, introducing a non-refutable link. This allows for not 1333 only messages between nodes to be non-refutable but also for 1334 documents signed in the same manner as messages to be non refutable.

1335 Today somebody can easily steal a user's password or purposely attack 1336 users as they are not anonymous; this invention provides a great deal of 1337 anonymity and backs this up with access to resources.

1338 Documents may be signed and passed as legally enforceable between 1339 parties as a contract in many countries.

ms_messenger (Figure 16) 1340 1. A non public ID preferably one which is used in some other autonomous 1341 system is used as a sign in mechanism and creates a Public ID key pair.

1342 2. The user selects or creates their public ID by entering a name that can 1343 easily be remembered (such as a nickname) the network is checked for a 1344 data element existing with a hash of this and if not there1 this name is 1345 allowed. Otherwise the user is asked to choose again.

1346 3. This ID called the MPID (maidsafe.net public ID) can be passed freely 1347 between friends or printed on business cards etc. as an email address is 1348 today.

1349 4. To initiate communications a user enters the nickname of the person he 1350 is trying to communicate with along with perhaps a short statement (like a 1351 prearranged pin or other challenge). The receiver agrees or otherwise to 1352 this request, disagreeing means a negative score starts to build with 1353 initiator. This score may last for hours, days or even months depending 1354 on regularity of refusals. A high score will accompany any communication 1355 request messages. Users may set a limit on how many refusals a user 1356 has prior to being automatically ignored.

1357 5. All messages now transmitted are done so encrypted with the receiving 1358 party's public key, making messages less refutable.

1359 6. These messages may go through a proxy system or additional nodes to 1360 mask the location of each user.

1361 7. This system also allows document signing (digital signatures) and 1362 interestingly, contract conversations. This is where a contract is signed 1363 and shared between the users. Preferably this signed contract is equally I 364 available to all in a signed (non changeable manner) and retrievable by 1365 all. Therefore a distributed environment suits this method. These 1366 contracts may be NDAs Tenders, Purchase Orders etc 1367 8. This may in some cases require individuals to prove their identity and this 1368 can take many forms from dealing with drivers licenses to utility bills 1369 being signed off in person or by other electronic methods such as 1370 inputting passport numbers, driving license numbers etc. 1371 9. If the recipient is on line then messages are sent straight to them for 1372 decoding.

1373 10. If the recipient is not on line, messages are require to be buffered as 1374 required with email today.

1375 11. Unlike today's email though, this is a distributed system with no servers to 1376 buffer to. In maidsafe.net messages are stored on the net encrypted with 1377 the receiver's public key. Buffer nodes may be known trusted nodes or 1378 not.

1379 12. Messages will look like receivers id.message I message 2 or simply 1380 be appended to the users MPID chunk, in both cases messages are 1381 signed by the sender. This allows messages to be buffered in cases 1382 where the user is offline. When the user comes on line he will check his 1383 ID chunk and look for appended messages as above ID.messagel etc. 1384 which is MPID.<message 1 data>.<message 2 data> etc 1385 This system allows the ability for automatic system messages to be sent, 1386 i.e... in the case of sharing the share, data maps can exist on everyone's 1387 database and never be transmitted or stored in the open. File locks and 1388 changes to the maps can automatically be routed between users using 1389 the messenger system as described above. This is due to the distributed 1390 nature of maidsafe.net and is a great, positive differentiator from other 1391 messenger systems. These system commands will be strictly limited for 9; 1392 security reasons and will initially be used to send alerts from trusted 1393 nodes and updates to share information by other shares of a private file 1394 share (whether they are speaking with them or not).

1395 The best way within our current power to get rid of email spam is to get 1396 rid of email servers.

Anonymous Transactions 1397 According to a related aspect of this invention, the ability to transact 1398 in a global digital medium is made available with this invention. This is 1399 achieved by passing signed credits to sellers in return for goods. The 1400 credits are data chunks with a given worth preferably 1, 5, 10, 20, 50, 1401 100 etc. units (called cybers in this case). These cybers are a digital 1402 representation of a monetary value and can be purchased as described 1403 below or earned for giving up machine resources such as disk space of 1404 cpu time etc. There should be preferably many ways to earn cybers.

1405 A cyber is actually a digitally signed piece of data containing the value 1406 statement i.e. 10 cybers and preferably a serial number. During a 1407 transaction the seller's serial number database is checked for validity of 1408 the cyber alone. The record of the ID used to transact is preferably not 1409 transmitted or recorded. This cyber will have been signed by the issuing 1410 authority as having a value. This value will have been proven and 141 1 preferably initially will actually equate to a single currency for instance 1412 linked to a Euro. This will preferably alter through time as the system 1413 increases in capability.

1414 Some sellers may request non anonymous transactions and if the user 1415 agrees he will then use the public ID creation process to authenticate the 1416 transaction and may have to supply more data. However there may be 1417 other sellers who will sell anonymously. This has a dramatic effect on 1418 marketing and demographic analysis etc. as some goods will sell 1419 anywhere and some will not. It is assumed this system allows privacy 1420 and freedom to purchase goods without being analysed.

1421 The process of transacting the cybers will preferably involve a signing 1422 system such that two people in a transaction will actually pass the cyber 1423 from the buyer to the seller. This process will preferably alter the 1424 signature on the cyber to the seller's signature. This new signature is 1425 reported back to the issuing authority.

Claims (17)

1427 1. A system to share access to private files in a distributed or peer to peer 1428 network which is made of combination and inter linkage of all or some of 1429 the following elements: 1430 a. provision of public ID 1431 b. encrypted communication 1432 c. identify data with very small file 1433

2. A system of claim I to share access to private files in a distributed or 1434 peer to peer network which is made of combination and inter linkage of 1435 all or some of the following elements and sub-elements: 1436 a. provision of public ID 1437 i) share maps 1438 b. encrypted communication 1439 i) share maps 1440 c. identify data with very small file 1441 i) create map of maps 1442

3. A product for sharing access to private files in a distributed or peer to 1443 peer network which is made of combination and inter linkage of all or 1444 some of the following elements: 1445 a. provision of public ID 1446 b. encrypted communication 1447 c. identify data with very small file 1448

4. A product of claim 3 for sharing access to private files in a distributed or 1449 peer to peer network which is made of combination and inter linkage of 1450 all or some of the following elements and sub-elements: 1451 a. provision of public ID 1452 I) share maps 1453 b. encrypted communication 1454 I) share maps 1455 c. identify data with very small file 1456 i) create map of maps 1457

5. A product of claims 3-4 to remove the requirement for centrally held 1458 authentication records in a data sharing environment; 1459

6. A product claims 3-4 to remove the requirement for central storage nodes 1460 in a data sharing environment; 1461

7. A product claims 3-4 for providing secured decentralised and 1462 anonymously authenticated shared data areas in a distributed network or 1463 a peer to peer network; 1464

8. A method of claims 1 to 7 to share access to private resources in a 1465 distributed or peer to peer network; 1466

9. A method of claims I to 7 to remove the requirement for centrally held 1467 authentication records in a data sharing environment; 1468

10. A method of claims I to 7 to remove the requirement for central storage 1469 nodes in a data sharing environment; 1470

II. A method of claims I to 7 of providing secured decentralised and 1471 anonymously authenticated shared data areas in a distributed network or 1472 a peer to peer network; 1473

12. A method of claim 6 where access levels can be added to provide the 1474 ability to enhance a private network using a completely granular access 1475 system such as n + p key sharing; 1476

13. A method of claims ito 7 of providing an environmentally friendly 1477 method for file sharing by reusing existing infrastructure and computers 1478 through maximising their existing resources; 1479

14. A method of claim 10 which will provide a system to significantly 1480 enhance security of mobile computing devices and to mitigate the 1481 implications of the theft of those devices by allowing all user information 1482 and company data to be removed from the mobile/ portable devices and 1483 for it to be only available when authenticated; 1484

15. A method of claim 13 to provide the ability to render existing data disk 1485 contents useless without passwords/ keys and maps of data chunks; this 1486 can be thought of as an off line secure mode; 1487

16. A method of claim 13 which allows data stored on the Internet to be 1488 retrieved securely from any location, thereby rendering existing VPN 1489 systems for sharing files obsolete: 1490

17. A system of claims 1-2 in distributed or peer to peer network which 1491 allows individuals to construct their own private file sharing system with 1492 no interaction from anyone else and not requiring a file server.