GB2444346A - Anonymous authentication in a distributed system - Google Patents

Abstract

This present invention relates to an authentication system for users requiring to be allowed access to resources stored on a distributed or peer-to-peer system. Information supplied during the authentication process by the user is extremely difficult to be compromised because these details are not stored on a central server and are not transmitted over the network during the process. In combination with this, information about the location of nodes is not stored together on the network. This obviates the opportunity for an unauthorised user to use that information to identify the location of resources in order to gain unauthorised access. It is the intention of this present invention to preserve the anonymity of the user and to provide a mechanism for secure access to private storage of data and preferably other resources on a distributed file system. The method comprises receiving a user identifier, retrieving an encrypted validation record identified by the user identifier, decrypting the encrypted validation record and authenticating access to data in a distributed file system using the decrypted information to provide anonymous authentication. The steps of validation, provision of key pairs and log on are also included.

Description

STATEMENT OF INVENTION:

14 Networks today rely on centralised servers or lists of account details and passwords; these are inherently insecure as they are a target in 16 their own right for an attacker. Rather than strengthen security of such a 17 target this invention removes the target altogether and provides a 18 mechanism to self authenticate.

19 Another problem with today's authentication systems is that attackers target user lOs to obtain or test passwords against it. This invention 21 removes this perception of a target by providing different user ID's on a 22 frequent basis thereby giving the attacker (even if they possessed the 23 password) no data element or clue to a data element that the password 24 would be useful against.

Upon authentication this invention allows the user access to their 26 resources as with traditional systems except in this case the user need 27 not be known.

BACKGROUND.

28 AUTHENTICATION 29 Authentication servers are for user and data transaction authentication e.g. JP2005311545 which describe a system wherein the application of 31 a digital seal' to electronic documents conforms to the Electronic 32 Signature Act This is similar to the case of signing paper documents 33 but uses the application of an electronic signature through an electronic 34 seal authentication system. The system includes: client computers, to each of which a graphics tablet is connected; an electronic seal 36 authentication server and a PKI authentication server, plus the 37 electronic seal authentication server. US2004254894 discloses an 38 automated system for the confirmed efficient authentication of an 39 anonymous subscriber's profile data in this case.

JP2005339247 describes a server based one time ID system and uses 41 a portable terminal. US2006136317 discloses bank drop down boxes 42 and suggests stronger protection by not transmitting any passwords or 43 IDs. Patent US2006126848 discloses a server centric and deals with a 44 one time password or authentication phrase and is not for use on a distributed network. Patent US2002 194484 discloses a distributed 46 network where all chunks are not individually verified and where the 47 manifest is only re-computed after updates to files and hashes are 48 applied and are for validation only.

49 SELF-AUTHENTICATION This is mostly used in biometric (W02006069158). System for 51 generating a patch file from an old version of data which consists of a 52 series of elements and a new version of data which also consists of a 53 series of elements US2006136514). Authentication servers (therefore 54 not a distributed networking principle as per this invention) are commonly used (JP2006107316, US2005273603, EP1548979).

56 However, server and client exchange valid certificates can be used 57 (US2004255037). Instead of server, uses of information exchange 58 system (semantic information) by participant for authentication can be 59 used (JP2004355358), again this semantic information is stored and referenced unlike this present invention, 61 Concepts of identity-based cryptography and threshold secret sharing 62 provides for a distributed key management and authentication. Without 63 any assumption of pre-fixed trust relationship between nodes, the ad 64 hoc network works in a self-organizing way to provide the key generation and key management service, which effectively solves the 66 problem of single point of failure in the traditional public key 67 infrastructure (PKI)-supported system (1JS2006023887). Authenticating 68 involves encryption keys for validation (W02005055162) These are 69 validated against known users unlike the present invention. Also, for authentication external housing are used (W02005034009), All of 71 these systems require a lost or (whether distributed or not) record of 72 authorised users and pass phrases or certificates and therefore do not

73 represent prior art.

74 Ranking, hashing for authentication can be implemented step-by-step and empirical authentication of devices upon digital authentication 76 among a plurality of devices. Each of a plurality of authentication 77 devices can unidirectionally generate a hash value of a low experience 78 rank from a hash value of a high experience rank, and receive a set of 79 high experience rank and hash value in accordance with an experience.

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

84 QuicK ENCiPHERING This is another method for authentication (JP2001308845). Self- 86 verifying certificate for computer system, uses private and public keys - 87 no chunking but for trusted hardware subsystems (US2002080973) this 88 is a mechanism of self signing certificates for authentication, again 89 useful for effort based computing but not used in this present invention.

Other authentication modes are, device for exchanging packets of 91 information (JP2001186186), open key certificate management data 92 (JP 10285156), and certification for authentication (W0961 39210).

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

97 therefore not prior art.

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

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

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

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

117 Document 3: H. R. Amirazizi, "Controlling Synchronous Networks With 118 Digital Cross-Connect Systems", Proceedings of Globecom 88, 119 December 1988.

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

126 Document 3 also relates to fault recovery for single transmission 127 systems and has a disadvantage in that route-finding packets tend to 128 form a loop and hence a delay is likely to be encountered.

Summary of Invention

129 The main embodiments of this invention are as follows: A system of anonymous authentication for data being stored or 131 accessed within a distributed or peer to peer network.

132 An anonymous authentication product for data storage or access within 133 a distributed or peer to peer network.

134 A system of anonymous authentication which has the functional elements of: 136 1. Validation 137 2. Provision of Key Pairs 138 3. Logon 139 A preferred system of claims 3, of anonymous authentication with functional linkages of: 141 1. Validation 142 a. anonymity 143 b. anonymous transaction 144 c. peer ranking 2. Provision of Key Pairs 146 a. provision of public ID 147 b. document signing 148 c. encryption/decryption (-p 149 3. Logon A product for anonymous authentication with functional linkages of; 151 a. Validation 152 b. Provision of Key Pairs 153 c. Logon 154 A product for anonymous authentication with functional linkages of; a. Validation 156 i. anonymity 157 ii. anonymous transaction 158 Hi. peer ranking 159 b. Provision of Key Pairs i. provision of public ID 161 ii. document signing 162 iii. encryption/decryption 163 c. Logon 164 A method of above system and product of anonymous authentication for data storage or access in a distributed network or peer to peer network.

166 A method of above system and product of authenticating access to a 167 distributed network comprising the steps of: 168 * creating a user identifier 169 * retrieving an encrypted validation record identified by the user identifier 171 * decrypting the encrypted validation record so as to provide a 172 decrypted result 173 * authenticating access to data in the distributed network using the 174 decrypted result A method of above wherein the steps of receiving, retrieving and 176 authenticating are performed on a node in the distributed network separate 177 from a node performing the step of decrypting.

178 A method of any of the above wherein the method further comprises the 179 step of generating the user identifier using a hash of user input data.

A method of any previous claim wherein the user identifier is unique and 181 suitable for identifying unique validation records.

182 A method of any previous claim wherein the step of authenticating access 183 further comprises the step of digitally signing the user identifier.

184 A method of claim wherein the method further comprises the step of using the signed user identifier as a session passport to authenticate a plurality 186 of accesses to the distributed network.

187 A method of any previous claim wherein the step of decrypting comprises 188 decrypting an address in the distributed network of a first chunk of data 189 and the step of authenticating access further comprises the step of determining the existence of the first chunk at the address.

191 A method of above where successful decryption of the ID chunk provides 192 the user with a key pair to sign any requests and to consider the user as 193 being authentic.

194 A method of above where successful decryption of the ID chunk provides a data map of the data set of user's data and any keys associated with such.

196 A method of above wherein the method further comprises the step of using 197 the content of the first chunk to obtain further chunks from the distributed 198 network.

199 A method of any previous claim where the user ID is made unique using known changing data such as days since a time in history.

201 A system which provides a mechanism for self-authentication 202 A system which upon authentication allows the user access to their 203 resources as with traditional systems except in this case the user need not 204 be known.

205 A method of above where this variable information is merged or diluted 206 into the user provided data prior to hashing or similar to produce a one 207 time ID to further anonymity.

DESCRIPTION

Detailed Description.

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

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

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

217 CID -Chunk Identifier, this is simply the chunkid.KID message on the 218 net.

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

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

226 MAID -this is basically the hash of and actual public key of the MID. this 227 ID Es used to identify the user actions such as put I forget I get on the 228 maidsafe.net network. This allows a distributed PKI infrastructure to exist 229 and be automatically checked. lO

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

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

Anonymous Authentication Description

238 Anonymous authentication relates to system authentication and, in 239 particular, authentication of users for accessing resources stored on a 240 distributed or peer-to-peer file system. Its aim is to preserve the 241 anonymity of the users and to provide secure and private storage of data 242 and shared resources for users on a distributed system. It is a method of 243 authenticating access to a distributed system comprising the steps of; 244 * Receiving a user identifier; 245 * Retrieving an encrypted validation record identified by the user 246 identifier; 247 * Decrypting the encrypted validation record so as to provide 248 decrypted information; and 249 * Authenticating access to data in the distributed system using the 250 decrypted information.

251 Receiving, retrieving and authenticating may be performed on a node in 252 the distributed system preferably separate from a node performing the 253 step of decrypting. The method further comprises the step of generating 254 the user identifier using a hash. Therefore, the user identifier may be 255 considered unique (and altered if a collision occurs) and suitable for I' 256 identifying unique validation records. The step of authenticating access 257 may preferably further comprise the step of digitally signing the user 258 identifier. This provides authentication that can be validated against 259 trusted authorities. The method further comprises the step of using the 260 signed user identifier as a session passport to authenticate a plurality of 261 accesses to the distributed system. This allows persistence of the 262 authentication for an extended session.

263 The step of decrypting preferably comprises decrypting an address in the 264 distributed system of a first chunk of data and the step of authenticating 265 access further comprises the step of determining the existence of the first 266 chunk at the address, or providing the location and names of specific 267 data elements in the network in the form of a data map as previously 268 describe. This efficiently combines the tasks of authentication and 269 starting to retrieve the data from the system. The method preferably 270 further comprises the step of using the content of the first chunk to obtain 271 further chunks from the distributed system. Additionally the decrypted 272 data from the additional chunks may contain a key pair allowing the user 273 at that stage to sign a packet sent to the network to validate them or 274 additionally may preferable self sign their own Id.

275 Therefore, there is no need to have a potentially vulnerable record of the 276 file structure persisting in one place on the distributed system, as the 277 user's node constructs its database of file locations after logging onto the 278 system.

279 There is provided a distributed system comprising; 280 * a storage module adapted to store an encrypted validation record; 281 * a client node comprising a decryption module adapted to decrypt an 282 encrypted validation record so as to provide decrypted information; 283 and 284 * a verifying node comprising 285 * a receiving module adapted to receive a user identifier; 286 * a retrieving module adapted to retrieve from the storage module an 287 encrypted validation record identified by the user identifier; 288 * a transmitting module adapted to transmit the encrypted validation 289 record to the client node; and 290. an authentication module adapted to authenticate access to data in 291 the distributed file system using the decrypted information from the 292 client node.

293 The client node is further adapted to generate the user identifier using a 294 hash. The authentication module is further adapted to authenticate 295 access by digitally sign the user identifier. The signed user identifier is 296 used as a session passport to authenticate a plurality of accesses by the 297 client node to the distributed system The decryption module is further 298 adapted to decrypt an address in the distributed system of a first chunk of 299 data from the validation record and the authentication module is further 300 adapted to authenticate access by determining the existence of the first 301 chunk at the address. The client node is further adapted to use the 302 content of the first chunk to obtain further authentication chunks from the 303 distributed system.

304 There is provided at least one computer program comprising program 305 instructions for causing at least one computer to perform. One computer 306 program is embodied on a recording medium or read-only memory, 307 stored in at least one computer memory, or carried on an electrical 308 carrier signal.

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

Linked elements for Anonymous Authentication (Figure 1 -PT4) 314 The Anonymous Authentication invention consists of 3 key functional 315 elements, with a further 6 functional elements being linked with.

316 The key functional elements are: 317 P12-Logon 318 P13 -Provision of Key Pairs 319 P14 -Validation 320 The linked functional elements are.

321 P8 -Encryption / Decryption 322 P19 -Document Signing 323 P17 -Provision of Public ID 324 P1 -Peer Ranking 325 P24 -Anonymous Transactions 326 P25 -Anonymity 327 The anonymous authentication (PT4) itself is made up from linkage of 328 elements, logon (P12) preferably provision of key pairs (P13) and 329 validation (P14), to provide an anonymous authentication system for 330 users requiring to be allowed access to resources stored on a distributed 331 or peer-to-peer system and to preserve the anonymity of the user and to 332 provide a mechanism for secure access to private storage of data and 333 preferably other resources on a distributed file system. In addition, logon 334 provision of key pairs element (P 13) provides a sub-element provision of 335 public ID (P17) which allows sub-element document signing (P19), and 336 sub-element encryption/decryption (P8) where required; element 337 validation is dependent on sub-element anonymity (P25) and provides 338 sub-element anonymous transaction (P24) and is provisioned by sub- 339 element peer ranking (P1).

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

344 2. A user will input some data known to them such as a userid (random ID) 345 and PIN number in this case. These pieces of information may be 346 concatenated together and hashed to create a unique (which may be 347 confirmed via a search) identifier. In this case this is called the MID 348 (maidsafe.net ID) 349 3. A TMID (Today's MID) is retrieved from the network, the TMID is then 350 calculated as follows: 351 The TMID is a single use or single day ID that is constantly changed.

352 This allows maidsafe.net to calculate the hash based on the user ID pin 353 and another known variable which is calculable. For this variable we use 354 a day variable for now and this is the number of days since epoch 355 (01/01/1 970). This allows for a new ID daily, which assists in maintaining 356 the anonymity of the user. This TMID will create a temporary key pair to 357 sign the database chunks and accept a challenge response from the 358 holder of these db chunks, After retrieval and generation of a new key 359 pair the db is put again in new locations -rendering everything that was 360 contained in the TMID chunk useless. The TMID CANNOT be signed by 361 anyone (therefore hackers can't BAN an unsigned user from retrieving 362 this -in a DOS attack)-it is a special chunk where the data hash does 363 NOT match the name of the chunk (as the name is a random number 364 calculated by hashing other information (i.e. its a hash of the TMID as 365 described below) 366 * take dave as user ID and 1267 as pin.

367 * dave + (pin) 1267 = davel267 Hash of this becomes MID 368 * day variable (say today is 13416 since epoch) 13416 369 * so take pin, and for example add the number in where the pin states 370 i.e. 371 * 613dav41e1267 372 * (6 at beginning is going round pin again) 373 * so this is done by taking 1St plfl 1 -so put first day value at position 1 374 * then next pin number 2 -so day value 2 at position 2 375 * then next pin number 6 so day value 3 at position 6 376 * then next pin number 7 So day value 4 at position 7 377 * then next pin number is 1 so day value 5 at position I (again) 378 * so TM)D is hash of 613dav41e1267 and the MID is simply a hash of 379 davel267 380 (This is an example algorithm arid many more can be used to enforce 381 further security.) 382 4. From the TMID chunk the map of the user's database (or list of files 383 maps) is identified. The database is recovered from the net which 384 includes the data maps for the user and any keys passwords etc.. The 385 database chunks are stored in another location immediately and the old 386 chunks forgotten. This can be done now as the MID key pair is also in 387 the database and can now be used to manipulate user's data.

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

390 6 The watcher process and Chunk server always have access to the PMID 391 key pair as they are stored on the machine itself, so can start and (p 392 receive and authenticate anonymous put I get I forget commands.

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

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

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

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

403 4. Using this mechanism this allows validation of MID signatures by 404 allowing any users access to this data element and checking the 405 signature of it against any challenge response from any node pertaining 406 to be this MID (as only the MID owner has the private key that signs this 407 MID) Any crook could not create the private key to match to the public 408 key to digitally sign so forgery is made impossible given today's 409 computer resources.

410 5. This mechanism also allows a user to add or remove PMIDS (or chunk 411 servers acting on their behalf like a proxy) at will and replace PMID's at 412 any time in case of the PMID machine becoming compromised.

413 Therefore this can be seen as the PMID authentication element. v-i

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

416 2. It contains the PMD public key and the MID ID (i.e. the hash of the MID 417 public key) and is signed by the MID private key (authenticated).

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

420 4. When answering challenge responses any other machine will confirm the 421 PMID by seeking and checking the MIAD for the PMID and making sure 422 the PMID is mentioned in the MAID bit -otherwise the PMID is 423 considered rouge.

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

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

431 Figure 3 illustrates, in schematic form, a peer-to-peer network in 432 accordance with an embodiment of the invention; and 433 Figure 4 illustrates a flow chart of the authentication, in accordance with 434 a preferred embodiment of the present invention.

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

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

450 The verifying node 12 has a receiving module 28 for receiving a user 451 identifier from the client node. The retrieving module 30 is configured to 452 retrieve from the data node an encrypted validation record identified by 453 the user identifier. Alternatively, in the preferred embodiment, the 454 validation record node 8 is the same node as the verifying node 12, i.e. 455 the storage module 18 is part of the verifying node 12 (not as shown in 456 Figure 3). The transmitting module 32 sends the encrypted validation 457 record to the client node. The authentication module 34 authenticates 458 access to chunks of data distributed across the data nodes using the 459 decrypted information.

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

465 A login box is presented 46 that requires the user's name or otherdetail 466 Preferably email address (the same one used in the client node software 467 installation and registration process) or simply name (i.e nickname) and 468 the user's unique number, preferably PIN number. If the user is a main 469 user' then some details may already be stored on the PC. If the user is a 470 visitor, then the login box appears.

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

473 This hash' is now known as the User ID Key' (MID), which at this point is 474 classed as unverified' within the system. This is stored on the network as 475 the MAID and is simply the hash of the public key containing an 476 unencrypted version of the public key for later validation by any other 477 node. This obviates the requirement for a validation authority 478 The software on the user's PC then combines this MID with a standard 479 hello' code element 50, to create 52 a hel)o.packet'. This hello.packet is 480 then transmitted with a timed validity on the Internet.

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

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

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

492 When the validation record file is decrypted 62, the first data chunk 2P 493 details, including a decrypted address', are extracted 64 and the user PC 494 sends back a request 66 to the verifying node for it to initiate a query for 495 the first file-chunk ID' at the decrypted address that it has extracted 496 from the decrypted validation record file, or preferably the data map of 497 the database chunks to recreate the database and provide access to the 498 key pair associated with this MID.

499 The verifying node then acts as a relay node' and initiates a notify only' 500 query for this file-chunk ID' at the decrypted address'.

501 Given that some other node (for this embodiment, called the data node') 502 has recognised 68 this request and has sent back a valid notification 503 only' message 70 that a file-chunk ID' corresponding to the request sent 504 by the verifying node does indeed exist, the verifying node then digitally 505 signs 72 the initial User ID Key, which is then sent back to the user.

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

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

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

519 The handshaking check is initiated from the PC that a user logs on to 520 (the User PC'), by generating the unverified encrypted hash' known as 52) the User ID Key', this preferably being created from the user's 522 information preferably email address and their PIN number. This hash' 523 is transmitted as a hefIo packet' on the Internet, to be picked up by any 524 system that recognises the User ID as being associated with specific 525 data that it holds. This PC then becomes the verifying PC' and will 526 initially act as the User PC's gateway' into the system during the 527 authentication process. The encrypted item of data held by the verifying 528 PC will temporarily be used as a validation record', it being directly 529 associated with the user's identity and holding the specific address of a 530 number of data chunks belonging to the user and which are located 531 elsewhere in the peer-to-peer distributed file system. This validation 532 record' is returned to the User PC for decryption, with the expectation 533 that only the legal user can supply the specific information that will allow 534 its accurate decryption.

535 Preferably this data may be a signed response being given back to the 536 validating node which s possible as the id chunk when decrypted 537 (preferably symmetrically) contains the users public and private keys 538 allowing non refutable signing of data packets.

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

543 It should be noted that in this embodiment, preferably no communication 544 is carried out via any nodes without an encrypted channel such as TLS 545 (Transport Layer Security) or SSL (Secure Sockets Layer) being set up 546 first, A peer talks to another peer via an encrypted channel and the other 547 peer (proxy) requests the information (e.g. for some space to save 548 information on or for the retrieval of a file) An encrypted link is formed 549 between all peers at each end of communications and also through the 550 proxy during the authentication process. This effectively bans snoopers 551 from detecting who is talking to whom and also what is being sent or 22.

552 retrieved. The initial handshake for self authentication is also over an 553 encrypted link.

554 Secure connection is provided via certificate passing nodes, in a manner 555 that does not require intervention, with each node being validated by 556 another, where any invalid event or data, for whatever reason (fraud 557 detection, snooping from node or any invalid algorithms that catch the 558 node) wifl invalidate the chain created by the node. This is all transparent 559 to the user.

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

562 Figure 5 illustrates a flow chart of data assurance event sequence in 563 accordance with first embodiment of this invention 564 Figure 6 illustrates a flow chart of file chunking event sequence in 565 accordance with second embodiment of this invention 566 Figure 7 illustrates a schematic diagram of file chunking example 567 Figure 8 illustrates a flow chart of self healing event sequence 568 Figure 9 illustrates a flow chart of peer ranking event sequence 569 Figure 10 illustrates a flow chart of duplicate removal event sequence 570 With reference to Figure 5, guaranteed accessibility to user data by data 571 assurance is demonstrated by flow chart. The data is copied to at least 572 three disparate locations at step (10). The disparate locations store data 573 with an appendix pointing to the other two locations by step (20) and is 574 renamed with hash of contents. Preferably this action is managed by 575 another node i.e. super node acting as an intermediary by step (30).

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

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

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

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

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

590 With reference to Figure 6, provides a methodology to manageable sized 591 data elements and to enable a complimentary data structure for and 592 compression and encryption and the step is to file chunking. By user's 593 pre-selection the nominated data elements (files are passed to chunking 594 process. Each data element (file) is split into small chunks by step (80) 595 and the data chunks are encrypted by step (90) to provide security for the 596 data. The data chunks are stored locally at step (100) ready for network 597 transfer of copies. Only the person or the group, to whom the overall data 598 belongs, will know the location of these (100) or the other related but 599 dissimilar chunks of data. All operations are conducted within the user's 600 local system. No data is presented externally.

601 Each of the above chunks does not contain location information for any 602 other dissimilar chunks. This provides for, security of data content, a 603 basis for integrity checking and redundancy.

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

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

609 On the occasion when all data chunks have been relocated (i.e. the user 610 has not logged on for a while,) a redirection record is created and stored 611 in the super node network, (a three copy process -similar to data) 612 therefore when a user requests a check, the redirection record is given to 613 the user to update their database 614 This efficiently aflows data resilience in cases where network churn is a 615 problem as in peer to peer or distributed networks.

616 With reference to Figure 7 which illustrates flow chart example of file 617 chunking. Users normal file has 5Mb document, which is chunked into 618 smaller variable sizes e.g. 135kb, 512kb, 768kb in any order. All chunks 619 may be compressed and encrypted by using Pass phrase. Next step is to 620 individually hash chunks and given hashes as names. Then database 621 record as a file is made from names of hashed chunks brought together 622 e.g. in empty version of original file (ClfthIIlIIIiIIll/I,tl,t2,t3: 623 C211h11111!JIIffhI,tlt2,t3 etc), this file is then sent to transmission queue in 624 storage space allocated to client application.

625 With reference to Figure 8 provides a self healing event sequence 626 methodology. Self healing is required to guarantee availability of accurate 627 data. As data or chunks become invalid by failing integrity test by step 628 (110). The location of failing data chunks is assessed as unreliable and

I-

629 further data from the leaf node is ignored from that location by step (120).

630 A Good Copy' from the known good' data chunk is recreated in a new 631 and equivalent leaf node. Data or chunks are recreated in a new and 632 safer location by step (130). The leaf node with failing data chunks is 633 marked as unreliable and the data therein as dirty' by step (140). Peer 634 leaf nodes become aware of this unreliable leaf node and add its location 635 to watch list by step (150). All operations conducted within the user's 636 local system. No data is presented externally 637 Therefore, the introduction of viruses, worms etc. will be prevented and 638 faulty machines/ equipment identified automatically.

639 The network will use SSL or TLS type encryption to prevent unauthorised 640 access or snooping.

641 With reference to Figure 9, Peer Ranking id required to ensure consistent 642 response and performance for the level of guaranteed interaction 643 recorded for the user. For Peer Ranking each node (leaf node) monitors 644 its own peer node's resources and availability in a scaleable manner, 645 each leaf node is constantly monitored.

646 Each data store (whether a network service, physical drive etc.) is 647 monitored for availability. A qualified availability ranking is appended to 648 the (leaf) storage node address by consensus of a monitoring super node 649 group by step (160). A ranking figure will be appended by step (160) and 650 signed by the supply of a key from the monitoring super node; this would 651 preferably be agreed by more super nodes to establish a consensus for 652 altering the ranking of the node. The new rank will preferably be 653 appended to the node address or by a similar mechanism to allow the 654 node to be managed preferably in terms of what is stored there and how 655 many copies there has to be of the data for it to be seen as perpetual.

656 Each piece of data is checked via a content hashing mechanism for data 657 integrity, which is carried out by the storage node itself by step (170) or 658 by its partner nodes via super nodes by step (180) or by instigating node 659 via super nodes by step (190) by retrieval and running the hashing 660 algorithm against that piece of data. The data checking cycle repeats 661 itself.

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

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

670 Additional checks are carried out on data stored on the leaf node marked 671 as dirty' by step (220). If pre-determined percentage of data found to be 672 dirty' node is removed from the network except for message traffic by 673 step (230). A certain percentage of dirty data being established may 674 conclude that this node is compromised or otherwise damaged and the 675 network would be informed of this. At that point the node will be removed 676 from the network except for the purpose of sending it warning messages 677 by step (230) 678 This allows either having data stored on nodes of equivalent availability 679 and efficiency or dictating the number of copies of data required to 680 maintain reliability.

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

683 With reference to Figure 10, duplicate data is removed to maximise the 684 efficient use of the disk space. Prior to the initiation of the data backup 685 process by step (240), internally generated content hash may be 686 checked for a match against hashes stored on the Internet by step (250) 687 or a list of previously backed up data (250). This will allow only one 688 backed up copy of data to be kept. This reduces the network wide 689 requirement to backup data which has the exact same contents.

690 Notification of shared key existence is passed back to instigating node by 691 step (260) to access authority check requested, which has to pass for 692 signed result is to be passed back to storage node. The storage node 693 passes shared key and database back to instigating node by step (270) 694 Such data is backed up via a shared key which after proof of the file 695 existing (260) on the instigating node, the shared key (270) is shared with 696 this instigating node. The location of the data is then passed to the node 697 for later retrieval if required.

698 This maintains copyright as people can only backup what they prove to 699 have on their systems and not publicly share copyright infringed data 700 openly on the network.

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

703 The protected data ignores sharing process.

Claims (5)

1. 704 1. A system of anonymous authentication for data resource, participation or 705 access in a distributed network or peer to peer network with inter linkage 706 and combination of all or some of functional elements; 707 a. Validation 708 b. Provision of Key Pairs 709 c. Logon 711
2. 2. A preferred system of claims 1, of anonymous authentication with 712 combination of all or some of functional elements and sub-elements; 713 a. Validation 714 i) anonymity 715 ii) anonymous transaction 716 iii) peer ranking 717 b. Provision of Key Pairs 718 I) provision of public ID 719 ii) document signing 720 iii) encryption/decryption 721 c. Logon 723
3. 3. A product of anonymous authentication for data resource, participation or 724 access in a distributed network or peer to peer network with inter linkage 725 and combination of all or some of functional elements; 726 a. Validation 727 b. Provision of Key Pairs 728 c. Logon 730
4. 4. A product claim of 3 for anonymous authentication with functional 731 linkages and combination of aD or some of elements and sub-elements; 732 a. Validation 733 i) anonymity 734 ii) anonymous transaction 735 iii) peer ranking 736 b. Provision of Key Pairs 737 I) provision of public ID 738 ii) document signing 739 iii) encryption/decryption 740 c. Logon 741
5. 5. A method of claims 1 to 4, for authenticating access to a distributed 742 network comprising the steps of; 743 a. creating a user identifier; 744 b. retrieving an encrypted validation record identified by the user 745 identifier; 746 c. decrypting the encrypted validation record to provide a decrypted 747 result; 748 d. authenticating access to data in the distributed network using the 749 decrypted result.

   751 6 A method of claim 5 wherein the steps of receiving, retrieving and 752 authenticating are performed on a node in the distributed network 753 separate from a node performing the step of decrypting; 755 7. A method of any of claims 5, 6 wherein the method further comprises the 756 step of generating the user identifier using a hash of user input data; 757 8. A method of any previous claims wherein the user identifier is unique 758 and suitable for identifying unique validation records; 759 9 A method of any previous claims wherein the step of authenticating 760 access further comprises the step of digitally signing the user identifier; 761 10. A method of claim 9 wherein the method further comprises the step of 762 using the signed user identifier as a session passport to authenticate a 763 plurality of accesses to the distributed network; 764 11. A method of any previous claims wherein the step of decrypting 765 comprises decrypting an address in the distributed network of a first 766 chunk of data and the step of authenticating access further comprises 767 the step of determining the existence of the first chunk at the address; 768 12. A method of claims 1-2 where successful decryption of the ID chunk 769 provides the user with a key pair to sign any requests and to consider the 770 user as being authentic; 771 13. A method of claim 12 where successful decryption of the ID chunk 772 provides a data map of the data set of user's data and preferably any 773 keys associated with such; 774 14. A method of claim 13 wherein the method further comprises the step of 775 using the content of the first chunk to obtain further chunks from the 776 distributed network; 778 15. A method of claim 13 which provides mechanism for self-authentication 779 16. A method of any previous claims where the user ID is made unique using 780 known calculable data such as days since a time in history or data 781 retrievable from calculable location, 783 17. A method of claim 16 where this variable information is merged or diluted 784 into the user provided data prior to hashing or similar to produce a one 785 time ID to further enhance anonymity.

   786 18. A method of claim 17 which upon authentication allows the user access 787 to their resources as with traditional systems except in this case the user 788 remains anonymous.