GB2446198A - Non-repudiation of messages in peer-to-peer network - Google Patents

Abstract

Disclosed is a system for message (e.g. email) delivery across a peer-to-peer network. The system has the property of non-repudiation, to prevent spam. The messages are also encrypted to provide confidentiality, and may remain in encrypted form when stored in buffers during transit. An initial step in the security procedure requires the user to enter a non-public ID, which is used to generate a public-private key pair. The user also has a public ID which is equivalent to an e-mail address in conventional systems. When a user wishes to communicate with another node a handshake procedure may be carried out. This involves sending a signed message to the other node. Also disclosed is a system for signing digital contracts to subject subsequent "conversations" to the terms of the contract. According to another aspect of the invention a user is only granted a public ID if he/she has a sufficient trust ranking.

Description

STATEMENT OF INVENTION:

12 This present invention relates to secure and non refutable 13 messengering. Unlike today's systems such as email and instant 14 messenger this system is fully distributed. Today's systems have many weaknesses such as centralised authentication, poorly maintained and 16 quite complex mail servers. This system seeks to remove this issue by 17 removing the cause, centralisation. Added to this, this present invention 18 introduces another completely new concept, contracted non refutable 19 electronic conversations. The system will allow the selection of existing contracts or allow the user to input his own and then request signatories 21 from all involved in the conversation, allowing a legally protected (in 22 many countries) conversation to take place. This conversation could be 23 a selling, purchasing or merely business deal or indeed any other issue 24 requiring legal protection.

Another important aspect of this system is that the login details are not 26 from this system per say, the system uses anonymously logged in 27 clients who can create a key pair and ID for the messenger. This means 28 any potential theft of ID is made extremely difficult

BACKGROUND:

29 AUTHENTICATION Authentication servers are for user and data transaction authentication 31 e.g. JP200531 1545 which describe a system wherein the application of 32 a digital seal' to electronic documents conforms to the Electronic 33 Signature Act. This is similar to the case of signing paper documents 34 but uses the application of an electronic signature through an electronic seal authentication system. The system includes: client computers, to 36 each of which a graphics tablet is connected; an electronic seal 37 authentication server and a PKI authentication server, plus the

I

38 electronic seal authentication server. US2004254894 discloses an 39 automated system for the confirmed efficient authentication of an anonymous subscriber's profile data in this case.

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

SELF-A UTHENTICA TION

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

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

62 Concepts of identity-based cryptography and threshold secret sharing 63 provides for a distributed key management and authentication. Without 64 any assumption of pre-fixed trust relationship between nodes, the ad hoc network works in a self-organizing way to provide the key 66 generation and key management service, which effectively solves the 67 problem of single point of failure in the traditional public key 68 infrastructure (PKl)-supparted system (US2006023887). Authenticating 69 involves encryption keys for validation (W02005055162) These are validated against known users unlike the present invention. Also, for 7t authentication external housing are used (W02005034009). All of 72 these systems require a lost or (whether distributed or not) record of 73 authorised users and pass phrases or certificates and therefore do not

74 represent prior art.

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

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

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

9! Other authentication modes are, device for exchanging packets of 92 information (JP2001 186186), open key certificate management data 93 (JP 10285156), and certification for authentication (W0961 39210).

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

98 therefore not prior art. I'.

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

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

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

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

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

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

S

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

SECURITY & ENCRYPTION 131 Common email communications of sensitive information is in plain text 132 and is subject to being read by unauthorized code on the senders 133 system, during transit and by unauthorized code on the receiver's 134 system. Where there is a high degree of confidentially required, a combination of hardware and software secures data.

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

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

147 ENCRYPTION 148 W02005093582 discloses method of encryption where data is secured 149 in the receiving node via private tag for anonymous network browsing.

However, other numerous encryption methods are also available such 151 as (i) implantation of Reed Solomon algorithm (W002052787), which 152 ensures data is coded in parabolic fashion for self-repairing and (53 storage, (ii) storage involves incremental backup (W002052787), (ii) 154 uses stenographic (US2006177094), (iv) use cipher keys (CN1620005), encryption for non text (US2006107048) and US2005108240 discloses 156 user keys and randomly generated leaf node keys. The present 157 invention uses none of these methods of encryption and in particular [58 ensures all chunks are unique and do not point to another for security 159 (an issue with Reed Solomon and N + K implementations of parabolic coding) 161 ENCRYPTED DOCUMENT SIGNING 162 W02005060152 discloses a digital watermark representing the one- 163 way hash is embedded in a signature document is used for electronic 164 signing. Mostly encrypted document signing is associated with legal documents, e.g. on-line notary etc. e.g. US2006161781, signature 166 verification (US6381344). WOOl 82036 discloses a system and method 167 for signing, storing, and authenticating electronic documents using 168 public key cryptography. The system comprises a document service 169 computer cluster connected to user computers, document owner server computers, and registration computers via a network such as for 171 example, the internetorthe world wide web. W00013368 discloses 172 both the data object and the signature data are encrypted. None of 173 these systems are designed or allow for distributed signing networks 174 unlike the present invention.

US6912660 discloses a method for parallel approval of an electronic 176 document. A document authentication code (DAC 0) is generated, 177 linked to the original document. Subsequent approvals of the document 178 generate a DAC x related to that specific approval. This is not linked to 179 the present invention as itts a document approval system -i.e one which allows a document to have multiple signatories to authenticate 181 approval, the present invention does not do this at all.

182 US6098056 discloses a system and method for controlling access 183 rights to and security of digital content in a distributed information 184 system, e.g., Internet. The network includes at least one server coupled to a storage device for storing the limited access digital content 186 encrypted using a random-generated key, known as a Document 187 Encryption Key (DEK). The DEK is further encrypted with the server's 188 public key, using a public/private key pair algorithm and placed in a 189 digital container stored in a storage device and including as a part of the meta-information which is in the container. The client's workstation is 191 coupled to the server (one of the many differences from the present 192 invention) for acquiring the limited access digital content under the 193 authorized condition. A Trusted Information Handler (TIH) is validated 194 by the server after the handler provides a data signature and type of signing algorithm to transaction data descriptive of the purchase 196 agreement between the client and the owner. After the handler has 197 authenticated, the server decrypts the encrypted DEK with its private 198 key and re-encrypts the DEK with the handler's public key ensuring that 199 only the information handler can process the information. The encrypted DEK is further encrypted with the client's public key personalizing the 201 digital content to the client. The client's program decrypts the DEK with 202 his private key and passes it along with the encrypted content to the 203 handler which decrypts the DEK with his private key and proceeds to 204 decrypt the content for displaying to the client.

205 US5436972 discloses a method for preventing inadvertent betrayal by a 206 trustee of escrowed digital secrets. After unique identification data 207 describing a user has been entered into a computer system, the user is 208 asked to select a password to protect the system. US5557518 discloses 209 a system to open electronic commerce using trusted agents.

210 US5557765 discloses a system and method for data recovery. An 211 encrypting user encrypts a method using a secret storage key (KS) and 212 attaches a Data Recovery Field (DRF), including an Access Rule Index 213 (ARI) and the KS to the encrypted message.

214 US5590199 discloses a system for authenticating and authorizing a 215 user to access services on a heterogeneous computer network. The 216 system includes at least one workstation and one authorization server 217 connected to each other through a network.

28 US2006123227 and W00221409 describe trust based effort measuring 219 techniques to validate signatures without the requirement for a central 220 body or central messaging entity. This is an interesting new concept but 221 not used in the current invention.

Summaty of Invention 222 The main embodiments of this invention are as follows: 223 A messaging system which has the functional elements of: 224 1. Provision of Public ID 225 2. Encrypted Communications 226 3. Document Signing 227 4. Contract conversations 228... with the additionally linked functional elements of: 229 1. Share Maps 230 2. Interface with Non-Anonymous Systems 231 3. Provision Key Pairs 232 4. Proven Individual 233 5. Validation of Vote Being Used 234 This present invention relates to secure and non refutable 235 messengering. Unlike today's systems such as email and instant 236 messenger this system is fully distributed. Today's systems have many 237 weaknesses such as centralised authentication, poorly maintained and 238 quite complex mail servers, this system seeks to remove this issue by 239 removing the cause, centralisation. Added to this, this present invention 240 introduces another completely new concept, contracted non refutable 241 electronic conversations. The system will allow the selection of existing 242 contracts or allow the user to input his own and then request signatories 243 from all involved in the conversation, allowing a legally protected (in 244 many countries) conversation to take place. This conversation could be 245 a selling, purchasing or merely business deal or indeed any other issue 246 requiring legal protection.

247 Another important aspect of this system is that the login details are not 248 from this system per say, the system uses anonymously logged in 249 clients who can create a key pair and ID for the messenger. This means 250 any potential theft of ID is made extremely difficult.

251 A system of secure and non refutable message sending in a distributed 252 and peer to peer network 253 A product for a secure and non refutable message sending in a 254 distributed and peer to peer network 255 A method for above product and system of secure and non refutable 256 message sending in a distributed and peer to peer network 257 A method for above product and system of message sending in a 258 distributed server less environment comprising of; 259 a. create a distributed messaging system with secure message 260 buffering; 261 b. create a system of non repudiation between parties; 262 c. create a system of public ID created from private ID and linked 263 by user.

264 From above method further enhance security by passing join requests 265 between users securely over a secure medium and encrypted. io -

266 The method from above wherein the steps to contact another node is 267 carried out by a signed message indicating the wish to communicate 268 which may comprise of; 269 a. a signed message with private information contained in it or; 270 b. a signed message with previously known information contained 271 initor; 272 c. a signed message with a previously agreed code.

273 A method from above where a contract may be agreed to and signed 274 prior to a conversation taking place; the conversation is then governed 275 by this contract and may include, but not be limited to;

276 a. Non disclosure agreements

277 b. Full disclosure agreements

278 c. Purchase orders.

279 A method of above where to create a public ID the user has to prove or 280 be spawned as an active participant in another network where 281 resources are stored and utilised to provide an effort based ranking 282 mechanism.

283 A method of above where a user may provide another user with a 284 digitally signed equivalent of a power of attorney' to agree contracts on 285 their behalf.

286 A method of above where messaging activity is ranked by peers and 287 the rank transmitted in conversation requests.

288 A method of above where the Public ID may also indicate a 289 biometricaLly signed user. ii

290 A method of above where users may require a ranking or effort score of 291 a certain level before allowing another node to communicate with them.

292 A method of above where this power of attorney' can be instantly 293 withdrawn by originating user without permission or requiring of 294 acceptance by receiver or the power of attorney'.

295 At least one computer program comprising instructions for causing at 296 least one computer to perform the method, system and product 297 according to any of above methods.

298 That at least one computer program of above embodied on a recording 299 medium or read-only memory, stored in at least one computer memory, 300 or carried on an electrical carrier signal.

DESCRIPTION

Detailed Description:

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

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

305 PMID -This is the proxy mid which is used to manage the receiving of 306 instructions to the node from any network node such as getl put I forget 307 etc. This is a key pair which is stored on the node -if stolen the key pair 308 can be regenerated simply disabling the thief's stolen PMID -although 309 there's not much can be done with a PMID key pair.

310 CID -Chunk Identifier, this is simply the chunkid.KID message on the 311 net.

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

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

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

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

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

Anonymous Authentication Description

331 Anonymous authentication relates to system authentication and, in 332 particular, authentication of users for accessing resources stored on a 333 distributed or peer-to-peer file system. Its aim is to preserve the 334 anonymity of the users and to provide secure and private storage of data 335 and shared resources for users on a distributed system. It is a method of 336 authenticating access to a distributed system comprising the steps of; 337 * Receiving a user identifier; 338 * Retrieving an encrypted validation record identified by the user 339 identifier; 340 * Decrypting the encrypted validation record so as to provide 341 decrypted information; and 342 * Authenticating access to data in the distributed system using the 343 decrypted information.

344 Receiving, retrieving and authenticating may be performed on a node in 345 the distributed system preferably separate from a node performing the 346 step of decrypting. The method further comprises the step of generating 347 the user identifier using a hash. Therefore, the user identifier may be 348 considered unique (and altered if a collision occurs) and suitable for 349 identifying unique validation records. The step of authenticating access 350 may preferably further comprise the step of digitally signing the user 351 identifier. This provides authentication that can be validated against 352 trusted authorities. The method further comprises the step of using the 353 signed user identifier as a session passport to authenticate a plurality of 354 accesses to the distributed system. This allows persistence of the 355 authentication for an extended session.

356 The step of decrypting preferably comprises decrypting an address in the 357 distributed system of a first chunk of data and the step of authenticating 358 access further comprises the step of determining the existence of the first 359 chunk at the address, or providing the location and names of specific 360 data elements in the network in the form of a data map as previously 361 describe. This efficiently combines the tasks of authentication and 362 starting to retrieve the data from the system. The method preferably 363 further comprises the step of using the content of the first chunk to obtain 364 further chunks from the distributed system. Additionally the decrypted 365 data from the additional chunks may contain a key pair allowing the user 366 at that stage to sign a packet sent to the network to validate them or 367 additionally may preferable self sign their own Id.

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

372 There is provided a distributed system comprising; 373 * a storage module adapted to store an encrypted validation record; 374 * a client node comprising a decryption module adapted to decrypt an 375 encrypted validation record so as to provide decrypted information; 376 and 377 * a verifying node comprising: -Ls 378 * a receiving module adapted to receive a user identifier: 379 * a retrieving module adapted to retrieve from the storage module an 380 encrypted validation record identified by the user identifier; 381 * a transmitting module adapted to transmit the encrypted validation 382 record to the client node; and 383 * an authentication module adapted to authenticate access to data in 384 the distributed file system using the decrypted information from the 385 client node.

386 The client node is further adapted to generate the user identifier using a 387 hash. The authentication module is further adapted to authenticate 388 access by digitally sign the user identifier. The signed user identifier is 389 used as a session passport to authenticate a plurality of accesses by the 390 client node to the distributed system. The decryption module is further 391 adapted to decrypt an address in the distributed system of a first chunk of 392 data from the validation record and the authentication module is further 393 adapted to authenticate access by determining the existence of the first 394 chunk at the address. The client node is further adapted to use the 395 content of the first chunk to obtain further authentication chunks from the 396 distributed system.

397 There is provided at least one computer program comprising program 398 instructions for causing at least one computer to perform. One computer 399 program is embodied on a recording medium or read-only memory, 400 stored in at least one computer memory, or carried on an electrical 401 carrier signal.

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

Linked elements for ms Messenger (Figure 1 -PT6) 407 The Anonymous Authentication invention consists of 4 key functional 408 elements, with a further 4 functional elements being linked with.

409 The key functional elements are: 410 P17 -Provision of Public ID 411 P18 -Encrypted Communications 412 P19 -Document Signing 413 P20 -Contract Conversations 414 The linked functional elements are: 415 P16-ShareMaps 416 P23 -Interface with Anonymous Systems 417 P13 Provision of Key Pairs 418 P26 -Proven Individual 419 P28 -Validation of Vote Being Used

421 (Figure 1 description here ****)

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

427 2. A user will input some data known to them such as a userid (random ID) 428 and PIN number in this case. These pieces of information may be i? - 429 concatenated together and hashed to create a unique (which may be 430 confirmed via a search) identifier. In this case this is called the MID 431 (maidsafe.net ID) 432 3. A TMID (Today's MID) is retrieved from the network, the TMID is then 433 calculated as follows: 434 The TMID is a single use or single day ID that is constantly changed.

435 This allows maidsafe.net to calculate the hash based on the user ID pin 436 and another known variable which is calculable. For this variable we use 437 a day variable for now and this is the number of days since epoch 438 (01/01/1 970). This allows for a new ID daily, which assists in maintaining 439 the anonymity of the user. This TMID will create a temporary key pair to 440 sign the database chunks and accept a challenge response from the 441 holder of these db chunks. After retrieval and generation of a new key 442 pair the db is put again in new locations -rendering everything that was 443 contained in the TMID chunk useless. The TMID CANNOT be signed by 444 anyone (therefore hackers can't BAN an unsigned user from retrieving 445 this -in a DOS attack)-it is a special chunk where the data hash does 446 NOT match the name of the chunk (as the name is a random number 447 calculated by hashing other information (i.e. its a hash of the TMID as 448 described below) 449 * take dave as user ID and 1267 as pin.

450 * dave + (pin) 1267 = davel267 Hash of this becomes MID 451 * day variable (say today is 13416 since epoch) = 13416 452 * so take pin, and for example add the number in where the pin states 453 i.e. 454 *613dav41e1267 455 * (6 at beginning is going round pin again) 456 * so this is done by taking 1st pin 1 -so put first day value at position 1 457 * then next pin number 2 -so day value 2 at position 2 458 * then next pin number 6 so day value 3 at position 6 459 * then next pin number 7 so day value 4 at position 7 460 * then next pin number is 1 so day value 5 at position 1 (again) 461 * soTMID is hash of 613dav41e1267 and the MID is simply a hash of 462 davel 267 463 (This is an example algorithm and many more can be used to enforce 464 further security.) 465 4. From the TMID chunk the map of the user's database (or list of files 466 maps) is identified. The database is recovered from the net which 467 includes the data maps for the user and any keys passwords etc.. The 468 database chunks are stored in another location immediately and the old 469 chunks forgotten. This can be done now as the MID key pair is also in 470 the database and can now be used to manipulate user's data.

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

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

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

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

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

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

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

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

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

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

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

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

503 4. When answering challenge responses any other machine will confirm the 504 PMID by seeking and checking the MIAD for the PMID and making sure 505 the PMID is mentioned in the MAID bit -otherwise the PMID is 506 considered rouge.

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

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

514 Figure 3 illustrates, in schematic form, a peer-to-peer network in 515 accordance with an embodiment of the invention; and 516 Figure 4 illustrates a flow chart of the authentication, in accordance with 517 a preferred embodiment of the present invention.

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

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

533 The verifying node 12 has a receiving module 28 for receiving a user 534 identifier from the client node. The retrieving module 30 is configured to 535 retrieve from the data node an encrypted validation record identified by 536 the user identifier. Alternatively, in the preferred embodiment, the 537 validation record node 8 is the same node as the verifying node 12, i.e. 538 the storage module 18 is part of the verifying node 12 (not as shown in 539 Figure 3). The transmitting module 32 sends the encrypted validation 540 record to the client node. The authentication module 34 authenticates 541 access to chunks of data distributed across the data nodes using the 542 decrypted information.

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

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

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

556 This hash' is now known as the User ID Key' (MID), which at this point is 22.

557 classed as unverified' within the system. This is stored on the network as 558 the MAID and is simply the hash of the public key containing an 559 unencrypted version of the public key for later validation by any other 560 node. This obviates the requirement for a validation authority 561 The software on the user's PC then combines this MID with a standard 562 hello' code element 50, to create 52 a hello.packet'. This hello.packet is 563 then transmitted with a timed validity on the Internet.

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

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

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

575 When the validation record file is decrypted 62, the first data chunk 576 details, including a decrypted address', are extracted 64 and the user PC 577 sends back a request 66 to the verifying node for it to initiate a query for 57g the first file-chunk ID' at the decrypted address' that it has extracted 579 from the decrypted validation record file, or preferably the data map of 580 the database chunks to recreate the database and provide access to the 581 key pair associated with this MID.

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

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

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

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

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

602 The handshaking check is initiated from the PC that a user logs on to 603 (the User PC'), by generating the unverified encrypted hash' known as 604 the User ID Key', this preferably being created from the user's 605 information preferably email address and their PIN number. This hash' 606 is transmitted as a hello.packet' on the Internet, to be picked up by any 607 system that recognises the User ID as being associated with specific 608 data that it holds. This PC then becomes the verifying PC' and will 609 initially act as the User PC's gateway' into the system during the 610 authentication process. The encrypted item of data held by the verifying 611 PC will temporarily be used as a validation record', it being directly 612 associated with the user's identity and holding the specific address of a 613 number of data chunks belonging to the user and which are located 614 elsewhere in the peer-to-peer distributed file system. This validation 615 record' is returned to the User PC for decryption, with the expectation 616 that only the legal user can supply the specific information that will allow 617 its accurate decryption.

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

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

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

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

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

645 Figure 5 illustrates a flow chart of data assurance event sequence in 646 accordance with first embodiment of this invention 647 Figure 6 illustrates a flow chart of file chunking event sequence in 648 accordance with second embodiment of this invention 649 Figure 7 illustrates a schematic diagram of file chunking example 650 Figure 8 illustrates a flow chart of self healing event sequence 651 Figure 9 illustrates a flow chart of peer ranking event sequence 652 Figure 10 illustrates a flow chart of duplicate removal event sequence 653 With reference to Figure 5, guaranteed accessibility to user data by data 654 assurance is demonstrated by flow chart. The data is copied to at least 655 three disparate locations at step (10). The disparate locations store data 656 with an appendix pointing to the other two locations by step (20) and is 657 renamed with hash of contents. Preferably this action is managed by 658 another node i.e. super node acting as an intermediary by step (30).

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

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

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

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

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

673 With reference to Figure 6, provides a methodology to manageable sized 674 data elements and to enable a complimentary data structure for and 675 compression and encryption and the step is to file chunking. By user's 676 pre-selection the nominated data elements (files are passed to chunking 677 process. Each data element (file) is split into small chunks by step (80) 678 and the data chunks are encrypted by step (90) to provide security for the 679 data. The data chunks are stored locally at step (100) ready for network 680 transfer of copies. Only the person or the group, to whom the overall data 681 belongs, will know the location of these (100) or the other related but 682 dissimilar chunks of data. All operations are conducted within the user's 683 local system. No data is presented externally.

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

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

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

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

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

699 With reference to Figure 7 which illustrates flow chart example of file 700 chunking. User's normal file has 5Mb document, which is chunked into 701 smaller variable sizes e.g. 135kb, 512kb, 768kb in any order. All chunks 702 may be compressed and encrypted by using Pass phrase. Next step is to 703 individually hash chunks and given hashes as names. Then database 704 record as a file is made from names of hashed chunks brought together 705 e.g. in empty version of original file (Cl II (I Ii il/ill II#,tl,t2,t3: 706 C2#llhIIIllllllh!,tl,t2,13 etc), this file is then sent to transmission queue in 707 storage space allocated to client application.

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

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

720 Therefore, the introduction of viruses, worms etc. will be prevented and 721 faulty machines/ equipment identified automatically.

722 The network will use SSL or TLS type encryption to prevent unauthorised 723 access or snooping.

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

729 Each data store (whether a network service, physical drive etc.) is 730 monitored for availability. A qualified availability ranking is appended to 731 the (leaf) storage node address by consensus of a monitoring super node 732 group by step (160). A ranking figure will be appended by step (160) and 733 signed by the supply of a key from the monitoring super node; this would 734 preferably be agreed by more super nodes to establish a consensus for 735 altering the ranking of the node. The new rank will preferably be 736 appended to the node address or by a similar mechanism to allow the 737 node to be managed preferably in terms of what is stored there and how 738 many copies there has to be of the data for it to be seen as perpetual.

739 Each piece of data is checked via a content hashing mechanism for data 740 integrity, which is carried out by the storage node itself by step (170) or 741 by its partner nodes via super nodes by step (180) or by instigating node 742 via super nodes by step (190) by retrieval and running the hashing 743 a'gorithm against that piece of data. The data checking cycle repeats 744 itself.

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

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

753 Additional checks are carried out on data stored on the leaf node marked 754 as dirty' by step (220). If pre-determined percentage of data found to be 755 dirty' node is removed from the network except for message traffic by 756 step (230). A certain percentage of dirty data being established may 757 conclude that this node is compromised or otherwise damaged and the 758 network would be informed of this. At that point the node will be removed 759 from the network except for the purpose of sending it warning messages 760 by step (230).

761 This allows either having data stored on nodes of equivalent availability 762 and efficiency or dictating the number of copies of data required to 763 maintain reliability.

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

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

773 Notification of shared key existence is passed back to instigating node by 774 step (260) to access authority check requested, which has to pass for 775 signed result is to be passed back to storage node. The storage node 776 passes shared key and database back to instigating node by step (270) 3c 777 Such data is backed up via a shared key which after proof of the file 778 existing (260) on the instigating node, the shared key (270) is shared with 779 this instigating node. The location of the data is then passed to the node 780 for later retrieval if required.

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

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

786 The protected data ignores sharing process.

ms_messenger (Figure 1-PT6 and Figure 11) 787 1. A non public ID preferably one which is used in some other autonomous 788 system is used as a sign in mechanism and creates a Public ID key pair.

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

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

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

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

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

808 7. This system also allows document signing (digital signatures) and 809 interestingly, contract conversations. This is where a contract is signed 810 and shared between the users. Preferably this signed contract is equally 811 available to all in a signed (non changeable manner) and retrievable by 812 all. Therefore a distributed environment suits this method. These 813 contracts may be NDAs Tenders, Purchase Orders etc. 814 8. This may in some cases require individuals to prove their identity and this 815 can take many forms from dealing with drivers licenses to utility bills 816 being signed off in person or by other electronic methods such as 817 inputting passport numbers, driving license numbers etc. 818 9. If the recipient is on line then messages are sent straight to them for 819 decoding.

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

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

826 12. Messages will look like receivers ID.message 1.message 2 or simply 827 be appended to the users MPID chunk, in both cases messages are 828 signed by the sender. This allows messages to be buffered in cases 829 where the user is offline. When the user comes on line he will check his 830 ID chunk and look for appended messages as above lD.messagel etc. 831 which is MPID.<message 1 data>.<message 2 data> etc 832 This system allows the ability for automatic system messages to be sent, 833 i.e... in the case of sharing the share, data maps can exist on everyon&s 834 database and never be transmitted or stored in the open. File locks and 835 changes to the maps can automatically be routed between users using 836 the messenger system as described above. This is due to the distributed 837 nature of maidsafe.net and is a great, positive differentiator from other 838 messenger systems. These system commands will be strictly limited for 839 security reasons and will initially be used to send alerts from trusted 840 nodes and updates to share information by other shares of a private file 841 share (whether they are speaking with them or not).

Provision of Public ID (Figure 1 -P17) 842 According to a related aspect of this invention, a public and Private 843 key pair is created for a network where preferably the user is 844 anonymously logged on, and preferably has a changeable pseudo 845 random private Id which is only used for transmission and retrieval of ID 846 blocks giving access to that network.

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

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

854 This ID can be printed on business cards or stationary like a phone 855 number or email address and cannot be linked to the users private ID by 856 external sources. However the user's own private information makes this 857 link by storing the data in the ID bit the user retrieves when logging in to 858 the network or via another equally valid method of secure network 859 authentication. 860 This ID can then be used in data or resource sharing with others in

a 861 more open manner than with the private id. This keeps the private ID 862 private and allows much improved inter-node or inter- person 863 communications.

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

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

874 Preferably this is a code passed between users over another 875 communications mechanism in a form such as a pin number known only 876 to the users involved or it may be as simple as appending the user's 877 name and other info to a communication request packet such as exists in 3(4-878 some instant messaging clients today -i.e. David wants to communicate 879 with you allow I deny I block.

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

885 This is preferably achieved by the node creating a unique identifier for 886 only this session and passing that ID to all known nodes in the user's 887 address book. Users on-line get this immediately, users off-line have this 888 buffered to their last known random ID. This ensures that the ability to 889 snoop on a user's messages is significantly reduced as there is no 890 identifier to people outside the address book as to the name of the 891 random ID bit the messages are stored to. The random ID bit is 892 preferably used as the first part of the identified buffer file name and 893 when more messages are stored then another file is saved with the 894 random id and a number appended to it representing the next sequential 895 available number. Therefore a user will log on and retrieve the messages 896 sequentially. This allows buffered secured and distributed messaging to 897 exist.

Document Signing (Figure 1 -P19) 898 According to a related aspect of this invention, a by-product of 899 securing communications between nodes using asymmetric encryption is 900 as previously stated, introducing a non-refutable link. This allows for not 901 only messages between nodes to be non-refutable but also for 902 documents signed in the same manner as messages to be non refutable.

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

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

Contract Conversations (Figure 1 -P20) 908 According to a related aspect of this invention, a conversation or 909 topic can be requested under various contracted conditions. The system 910 may have a non disclosure agreement as an example and both parties 911 digitally sign this agreement automatically on acceptance of a contract 912 conversation. In this case a non disclosure conversation. This will 913 preferably speed up and protect commercial entities entering into 914 agreements or where merely investigating a relationship. Preferably other 915 conditions can be applied here such as preferably full disclosure 916 conversations, Purchase order conversations, contract signing 917 conversations etc. This is all carried out via a system preferably having 918 ready made enforceable contracts for automatic signing. These contracts 919 may preferably be country or legal domain specific and will require to be 920 enforceable under the law of the countries where the conversation is 921 happening. This will require the users to preferably automatically use a 922 combination of geographic IP status and by selecting which is their home 923 country and where are they are at that time located and having that 924 conversation.

925 Preferably only the discussion thread is under this contract, allowing any 926 party to halt the contract but not the contents of the thread which is under 927 contract.

928 Preferably there can also be a very clear intent statement for a 929 conversation that both parties agree to. This statement will form the basis 930 of a contract in the event of any debate. The clearer the intent statement 931 is; the better for enforceability. These conversations are potentially not 3(0 932 enforceable but should lead to simplifying any resolution required at a 933 later date. Preferably this can be added together with an actual contract 934 conversation such as a non disclosure agreement to form a pack of 935 contracts per conversation. Contract conversations will be clearly 936 identified as such with copies of the contracts easily viewable by both 937 parties at any time, these contracts will preferably be data maps and be 938 very small in terms of storage space required. Ii-

Claims (15)

1. 939 1. A system of secure and non refutable message sending in a distributed 940 and peer to peer network; 941
2. 2. A product for a secure and non refutable message sending in a 942 distributed and peer to peer network; 943
3. 3. A method for claims 1,2 of secure and non refutable message sending in 944 a distributed and peer to peer network; 945
4. 4. A method for claims 1,2 of message sending in a distributed server less 946 environment comprising of; 947 a. create a distributed messaging system with secure message 948 buffering; 949 b. create a system of non repudiation between parties; 950 c. create a system of public ID created from private ID and linked by 951 user; 952
5. 5. From claim 3, 4 further enhance security by passing join requests 953 between users securely over a secure medium and encrypted; 954
6. 6. The method from claim 3, 4 wherein the steps to contact another node is 955 carried out by a signed message indicating the wish to communicate 956 which may comprise of; 957 a. a signed message with private information contained in it or; 958 b. a signed message with previously known information contained in it 959 or; 960 c. a signed message with a previously agreed code; 3' 961
7. 7. A method from claim 3,4 where a contract may be agreed to and signed 962 prior to a conversation taking place; the conversation is then governed 963 by this contract and may include, but not be limited to;

   964 a. Non disclosure agreements

   965 b. Full disclosure agreements

   966 c. Purchase orders.

   967
8. 8. A method of claim 3, 4 where to create a public ID the user has to prove 968 or be spawned as an active participant in another network where 969 resources are stored and utilised to provide an effort based ranking 970 mechanism; 971
9. 9. A method of claim 7 where a user may provide another user with a 972 digitally signed equivalent of a power of attorney' to agree contracts on 973 their behalf; 974
10. 10. A method of claim 8 where messaging activity is ranked by peers and the 975 rank transmitted in conversation requests; 976
11. 11. A method of claim 8 where the Public ID may also indicate a 977 biometrically signed user; 978
12. 12. A method of claim 8 where users may require a ranking or effort score of 979 a certain level before allowing another node to communicate with them; 980
13. 13. A method of claim 12 where this power of attorney' can be instantly 981 withdrawn by originating user without permission or requiring of 982 acceptance by receiver or the power of attorney'; 983
14. 14. At least one computer program comprising instructions for causing at 984 least one computer to perform the method, system and product 985 according to any of claims 1 to 13; 3c 986
15. 15. That at least one computer program of claim 14 embodied on a recording 987 medium or read-only memory, stored in at least one computer memory, 988 or carried on an electrical carrier signal.