├── Project-Safe.md ├── README.md ├── resources ├── end_users.png ├── projected_coin_distribution_over_time.png ├── projected_coin_distribution_over_time_log.png ├── resources_graph.png ├── safecoin_transaction_structure.png ├── split_safecoin_diagram.png ├── split_sdv_diagram.png ├── tech_stack.png ├── transaction_scenarios.png ├── transaction_scenarios_merged.png ├── transaction_scenarios_new.png ├── transaction_structure.png ├── transaction_structure_merged.png └── transfer_mechanism_diagram.png └── technical_papers ├── AutonomousNetwork.lyx ├── DHTbasedNATTraversal.lyx ├── MaidSafeDistributedFileSystem.lyx ├── MaidSafeDistributedHashTable.lyx ├── ManagedAuthentication.lyx ├── PeerToPeerPublicKeyInfrastructure.lyx ├── Safecoin.lyx ├── SelfAuthentication.lyx ├── SelfEncryptingData.lyx ├── img ├── Reference_List_Add.ddd ├── Reference_List_Add.pdf ├── STORE_NEW_CHUNK.pdf ├── Watch_List_Add.ddd ├── Watch_List_Add.pdf ├── Watch_List_Payment.ddd ├── Watch_List_Payment.pdf ├── Watch_List_Remove.ddd ├── Watch_List_Remove.pdf ├── safecoin farming speed.png ├── safecoin resources.png └── safecoin transfer mech.png ├── pd.lyx ├── safecoin citations.bib └── third_party └── Ford.pdf /README.md: -------------------------------------------------------------------------------- 1 | Whitepapers 2 | =========== 3 | 4 | MaidSafe Whitepapers 5 | 6 | 1. [Project Safe](https://github.com/maidsafe/Whitepapers/blob/master/Project-Safe.md) 7 | -------------------------------------------------------------------------------- /resources/end_users.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/resources/end_users.png -------------------------------------------------------------------------------- /resources/projected_coin_distribution_over_time.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/resources/projected_coin_distribution_over_time.png -------------------------------------------------------------------------------- /resources/projected_coin_distribution_over_time_log.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/resources/projected_coin_distribution_over_time_log.png -------------------------------------------------------------------------------- /resources/resources_graph.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/resources/resources_graph.png -------------------------------------------------------------------------------- /resources/safecoin_transaction_structure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/resources/safecoin_transaction_structure.png -------------------------------------------------------------------------------- /resources/split_safecoin_diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/resources/split_safecoin_diagram.png -------------------------------------------------------------------------------- /resources/split_sdv_diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/resources/split_sdv_diagram.png -------------------------------------------------------------------------------- /resources/tech_stack.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/resources/tech_stack.png -------------------------------------------------------------------------------- /resources/transaction_scenarios.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/resources/transaction_scenarios.png -------------------------------------------------------------------------------- /resources/transaction_scenarios_merged.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/resources/transaction_scenarios_merged.png -------------------------------------------------------------------------------- /resources/transaction_scenarios_new.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/resources/transaction_scenarios_new.png -------------------------------------------------------------------------------- /resources/transaction_structure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/resources/transaction_structure.png -------------------------------------------------------------------------------- /resources/transaction_structure_merged.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/resources/transaction_structure_merged.png -------------------------------------------------------------------------------- /resources/transfer_mechanism_diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/resources/transfer_mechanism_diagram.png -------------------------------------------------------------------------------- /technical_papers/DHTbasedNATTraversal.lyx: -------------------------------------------------------------------------------- 1 | #LyX 2.1 created this file. For more info see http://www.lyx.org/ 2 | \lyxformat 474 3 | \begin_document 4 | \begin_header 5 | \textclass IEEEtran 6 | \use_default_options false 7 | \maintain_unincluded_children false 8 | \language british 9 | \language_package default 10 | \inputencoding default 11 | \fontencoding global 12 | \font_roman default 13 | \font_sans default 14 | \font_typewriter default 15 | \font_math auto 16 | \font_default_family default 17 | \use_non_tex_fonts false 18 | \font_sc false 19 | \font_osf false 20 | \font_sf_scale 100 21 | \font_tt_scale 100 22 | \graphics default 23 | \default_output_format default 24 | \output_sync 0 25 | \bibtex_command default 26 | \index_command default 27 | \paperfontsize default 28 | \spacing single 29 | \use_hyperref true 30 | \pdf_title "DHT-based NAT Traversal" 31 | \pdf_author "David Irvine" 32 | \pdf_subject "NAT Traversal" 33 | \pdf_keywords "security, freedom, privacy, DHT, encryption" 34 | \pdf_bookmarks true 35 | \pdf_bookmarksnumbered false 36 | \pdf_bookmarksopen false 37 | \pdf_bookmarksopenlevel 1 38 | \pdf_breaklinks false 39 | \pdf_pdfborder true 40 | \pdf_colorlinks false 41 | \pdf_backref false 42 | \pdf_pdfusetitle true 43 | \papersize default 44 | \use_geometry false 45 | \use_package amsmath 0 46 | \use_package amssymb 0 47 | \use_package cancel 1 48 | \use_package esint 0 49 | \use_package mathdots 0 50 | \use_package mathtools 1 51 | \use_package mhchem 1 52 | \use_package stackrel 1 53 | \use_package stmaryrd 1 54 | \use_package undertilde 1 55 | \cite_engine basic 56 | \cite_engine_type default 57 | \biblio_style plain 58 | \use_bibtopic true 59 | \use_indices false 60 | \paperorientation portrait 61 | \suppress_date false 62 | \justification true 63 | \use_refstyle 0 64 | \index Index 65 | \shortcut idx 66 | \color #008000 67 | \end_index 68 | \secnumdepth 3 69 | \tocdepth 3 70 | \paragraph_separation indent 71 | \paragraph_indentation default 72 | \quotes_language english 73 | \papercolumns 2 74 | \papersides 1 75 | \paperpagestyle default 76 | \tracking_changes false 77 | \output_changes false 78 | \html_math_output 0 79 | \html_css_as_file 0 80 | \html_be_strict false 81 | \end_header 82 | 83 | \begin_body 84 | 85 | \begin_layout Title 86 | DHT-based NAT Traversal 87 | \end_layout 88 | 89 | \begin_layout Author 90 | \begin_inset Flex Author Name 91 | status open 92 | 93 | \begin_layout Plain Layout 94 | David Irvine 95 | \end_layout 96 | 97 | \end_inset 98 | 99 | 100 | \begin_inset Flex Author Mark 101 | status open 102 | 103 | \begin_layout Plain Layout 104 | 1 105 | \end_layout 106 | 107 | \end_inset 108 | 109 | 110 | \begin_inset Newline newline 111 | \end_inset 112 | 113 | 114 | \begin_inset Flex Author Affiliation 115 | status open 116 | 117 | \begin_layout Plain Layout 118 | MaidSafe.net, 72 Templehill, Troon, South Ayrshire, Scotland, UK. 119 | KA10 6BE. 120 | \end_layout 121 | 122 | \end_inset 123 | 124 | 125 | \begin_inset Newline newline 126 | \end_inset 127 | 128 | 129 | \begin_inset Flex Author Mark 130 | status open 131 | 132 | \begin_layout Plain Layout 133 | 1 134 | \end_layout 135 | 136 | \end_inset 137 | 138 | david.irvine@maidsafe.net 139 | \end_layout 140 | 141 | \begin_layout Page headings 142 | \begin_inset Argument 1 143 | status open 144 | 145 | \begin_layout Plain Layout 146 | Irvine: DHT-based NAT Traversal 147 | \end_layout 148 | 149 | \end_inset 150 | 151 | 152 | \end_layout 153 | 154 | \begin_layout Address 155 | First published September 2010. 156 | \end_layout 157 | 158 | \begin_layout Abstract 159 | Today's Distributed Hash Tables (DHT's) and other overlay networks are based 160 | on operating without hindrance of real world issues regarding connectivity 161 | between nodes. 162 | This is not a problem when operating in a private or controlled environment, 163 | but in the transition to peer to peer or fully distributed networks, it 164 | becomes a major headache. 165 | This paper introduces a pure p2p solution to Network Address Translation 166 | (NAT) traversal, which is probably the main problem facing public p2p networks. 167 | \end_layout 168 | 169 | \begin_layout Keywords 170 | security, freedom, privacy, DHT, encryption 171 | \end_layout 172 | 173 | \begin_layout Standard 174 | \begin_inset CommandInset toc 175 | LatexCommand tableofcontents 176 | 177 | \end_inset 178 | 179 | 180 | \end_layout 181 | 182 | \begin_layout Section 183 | Introduction 184 | \end_layout 185 | 186 | \begin_layout Standard 187 | \begin_inset Flex Paragraph Start 188 | status open 189 | 190 | \begin_layout Plain Layout 191 | \begin_inset Argument 1 192 | status open 193 | 194 | \begin_layout Plain Layout 195 | I 196 | \end_layout 197 | 198 | \end_inset 199 | 200 | nternet 201 | \end_layout 202 | 203 | \end_inset 204 | 205 | technology allows the interconnect of every device to every other device, 206 | in principle. 207 | In practice, this is not the case and for many reasons devices tend to 208 | be behind routers that allow them to go unnoticed or at least act as a 209 | proxy device. 210 | This helps connect multiple devices to a single publicly addressable IP 211 | location. 212 | The devices behind the router may have private or classified private addresses 213 | and number in thousands all connected to the Internet and appearing as 214 | one single identity. 215 | The router will proxy requests and responses in many cases to hide the 216 | devices. 217 | 218 | \end_layout 219 | 220 | \begin_layout Standard 221 | NAT is a good solution for the lack of publicly available IP addresses with 222 | the current incumbent scheme of IP version 4, IP version 6 will allow more 223 | than enough public addresses to exist and in fact provide several addresses 224 | for every square meter of the planet. 225 | Even with IP6, however there will still be NAT devices around and NAT traversal 226 | will still be required. 227 | \end_layout 228 | 229 | \begin_layout Standard 230 | Several methods exist for traversing NAT devices, including 231 | \emph on 232 | Session Traversal Utilities for NAT (STUN) 233 | \begin_inset CommandInset citation 234 | LatexCommand cite 235 | key "1" 236 | 237 | \end_inset 238 | 239 | 240 | \emph default 241 | which is extended to form 242 | \emph on 243 | Interactive Connectivity Establishment (ICE): A Protocol for Network Address 244 | Translator (NAT) Traversal for Offer/Answer Protocols 245 | \emph default 246 | 247 | \begin_inset CommandInset citation 248 | LatexCommand cite 249 | key "2" 250 | 251 | \end_inset 252 | 253 | . 254 | This paper will present a mechanism to exploit these technologies without 255 | the requirement for any servers to exist. 256 | This is therefore a solution for distributed protocols that in fact requires 257 | a distributed protocol to exist (a good fit). 258 | \end_layout 259 | 260 | \begin_layout Section 261 | NAT traversal methods 262 | \end_layout 263 | 264 | \begin_layout Subsection 265 | Router negotiation protocols 266 | \end_layout 267 | 268 | \begin_layout Subsubsection 269 | Universal Plug and Play (UPnP) 270 | \begin_inset CommandInset citation 271 | LatexCommand cite 272 | key "5" 273 | 274 | \end_inset 275 | 276 | 277 | \end_layout 278 | 279 | \begin_layout Standard 280 | UPnP is a UDT NAT traversal protocol which utilises HTTP over UDP to negotiate 281 | a port mapping with an enabled router. 282 | This allows a node to appear as though it has a directly connected IP (that 283 | of the router) and port combination. 284 | From this perspective the node appears directly connected (for that port). 285 | 286 | \end_layout 287 | 288 | \begin_layout Standard 289 | UPnP is seen as a security risk by many vendors and is supplied on a routing 290 | device switched off. 291 | 292 | \end_layout 293 | 294 | \begin_layout Standard 295 | Care should be taken with the protocol to ensure that a permanent mapping 296 | is requested, which would last until requested to be un-mapped or the router 297 | is rebooted. 298 | The more effective solution is to select a mapping for a period and refresh 299 | this every few seconds, to ensure the router device is not congested with 300 | stale mappings. 301 | 302 | \end_layout 303 | 304 | \begin_layout Standard 305 | Many routers will have a low limit of concurrent available UPnP mappings. 306 | \end_layout 307 | 308 | \begin_layout Subsubsection 309 | Network Address Translation Port Mapping Protocol (NAT-PMP) 310 | \end_layout 311 | 312 | \begin_layout Standard 313 | NAT-PMP is an upgrade of UPnP to attempt to alleviate the security issues 314 | surrounding UPnP, it is currently not provided in many routers, although 315 | this may change in the future. 316 | Again this is a UDP controlled protocol and as such will not operate in 317 | networks that have banned UDP. 318 | 319 | \end_layout 320 | 321 | \begin_layout Subsection 322 | Hole Punching 323 | \end_layout 324 | 325 | \begin_layout Standard 326 | Hole punching can successfully traverse approximately 82% 327 | \begin_inset CommandInset citation 328 | LatexCommand cite 329 | key "6" 330 | 331 | \end_inset 332 | 333 | of NAT devices. 334 | It makes use of the fact that a router will leave a UDP port mapped after 335 | sending data out. 336 | This is done whether the UDP packet is successfully delivered or not. 337 | This is a necessity for a connectionless protocol as the router cannot 338 | tell whether the transmission will be successful or whether there is to 339 | be a reply (which all well defined protocols using UDP should ensure there 340 | is). 341 | \end_layout 342 | 343 | \begin_layout Standard 344 | The basis of the process is described in Algorithm 1, it is relatively simple 345 | and uses this conversation method to operate. 346 | It should be noted for BSD type socket API's it is important to ensure 347 | the SO_REUSE_ADDR is set, allowing address reuse (very important). 348 | Using a UDP overlay type protocol sch as UDT 349 | \begin_inset CommandInset citation 350 | LatexCommand cite 351 | key "7" 352 | 353 | \end_inset 354 | 355 | would introduce some new difficulties here and the connection set-up time-out 356 | should be set very small, as the first connection attempt will most likely 357 | fail, reducing time-outs makes for more efficient code. 358 | 359 | \end_layout 360 | 361 | \begin_layout Standard 362 | \begin_inset Float algorithm 363 | wide false 364 | sideways false 365 | status open 366 | 367 | \begin_layout Plain Layout 368 | \begin_inset Caption Standard 369 | 370 | \begin_layout Plain Layout 371 | Let A and B be the two hosts, each in its own private network; N1 and N2 372 | are the two NAT devices; S is a public server with a well-known globally 373 | reachable IP address. 374 | A and B each send a UDP packet to S; the NAT devices N1 and N2 create UDP 375 | translation states and assign temporary external port numbers S relays 376 | these port numbers back to A and B A and B contact each others' NAT devices 377 | directly on the translated ports; the NAT devices use the previously created 378 | translation states and send the packets to A and B 379 | \end_layout 380 | 381 | \end_inset 382 | 383 | 384 | \end_layout 385 | 386 | \end_inset 387 | 388 | 389 | \end_layout 390 | 391 | \begin_layout Subsection 392 | Relay nodes 393 | \end_layout 394 | 395 | \begin_layout Standard 396 | TURN is a system where a node will relay informations from a another node 397 | behind an unfriendly NAT device. 398 | In this case fairness is a major concern as the relay node will have to 399 | provide more bandwidth to the fire-walled node. 400 | This cannot be handed off to alleviate the burden which is unfortunate. 401 | Further research may prove to be very interesting in these cases though. 402 | 403 | \end_layout 404 | 405 | \begin_layout Section 406 | NAT Traversal with a DHT 407 | \end_layout 408 | 409 | \begin_layout Standard 410 | Use of a DHT makes no difference to any router negotiation protocol as described 411 | above, but can significantly improve the performance and security of UDP 412 | hole punching techniques. 413 | 414 | \end_layout 415 | 416 | \begin_layout Subsection 417 | STUN server functionality in a DHT 418 | \end_layout 419 | 420 | \begin_layout Standard 421 | A STUN server, generally has 2 network interface cards on different IP addresses 422 | (and preferably routes). 423 | This allows multiple routes to a node to be confirmed in a manner similar 424 | to algorithm 1. 425 | In a DHT, there should be no servers and in maidsafe_dht all machines should 426 | be able to be unknown in configuration terms, i.e. 427 | we cannot presume we will have dual homed machines on the network. 428 | This initially would appear to be a problem, whereas in fact it is an advantage. 429 | In place of a dual homed server, a DHT has something more powerful, a full 430 | network of nodes on different networks that can all message each other 431 | and in many ways act like a huge server. 432 | Therefore, to emulate a simple dual homes machine that exists on two networks 433 | is perhaps one of the simplest tasks we can ask a DHT to perform. 434 | A DHT performs these tasks efficiently and without exposing any server 435 | location for an attack to be carried out. 436 | 437 | \end_layout 438 | 439 | \begin_layout Standard 440 | To achieve the STUN type functionality, we simply carry out the process 441 | as defined in section 442 | \begin_inset CommandInset ref 443 | LatexCommand ref 444 | reference "sub:DHT-hole-punch" 445 | 446 | \end_inset 447 | 448 | , where we use a node on the network to perform NAT detection and traversal 449 | techniques. 450 | This negates the requirement for a server, but, how do other clients know 451 | which sever to speak to in case of a port restricted situation, where the 452 | server requires a message to be sent and relayed to the node we intended. 453 | Without this any port restricted node would be unreachable. 454 | This is where we use a DHT component that provides us with such capability 455 | and this is the routing table or list of contacts. 456 | 457 | \end_layout 458 | 459 | \begin_layout Standard 460 | In the contact tuple for each contact, where an intermediate node is required 461 | (AKA STUN server) a node's address is stored along with the end nodes address. 462 | So every node that requires an intermediate, establishes the details of 463 | the intermediary and publishes this to the network as part of its contact 464 | details. 465 | This is extremely effective and simple to implement. 466 | \end_layout 467 | 468 | \begin_layout Subsection 469 | DHT Hole Punching 470 | \end_layout 471 | 472 | \begin_layout Standard 473 | The process is very similar to non DHT hole punching, except that for a 474 | network to be a pure distributed network there should be no servers, therefore 475 | the STUN type server employed in a normal configuration cannot be used. 476 | 477 | \end_layout 478 | 479 | \begin_layout Subsection 480 | DHT hole punch NAT traversal process 481 | \begin_inset CommandInset label 482 | LatexCommand label 483 | name "sub:DHT-hole-punch" 484 | 485 | \end_inset 486 | 487 | 488 | \end_layout 489 | 490 | \begin_layout Standard 491 | Booststrap node = [B]; Our node = [U], Other node who is not sharing the 492 | same IP as [U] = [O] 493 | \end_layout 494 | 495 | \begin_layout Enumerate 496 | On initial bootstrap, receive IP and port [B] detects. 497 | \end_layout 498 | 499 | \begin_layout Enumerate 500 | If IP = a local IP then directly connected [stop] 501 | \end_layout 502 | 503 | \begin_layout Enumerate 504 | Send Detection packet to [B] which in turn sends a packet to [O]. 505 | 506 | \end_layout 507 | 508 | \begin_layout Enumerate 509 | Both [B] and [O] send message to [U] and await reply. 510 | \end_layout 511 | 512 | \begin_layout Enumerate 513 | If [O] receives a reply, it messages [B] with success. 514 | [B] reports back to [U] that we are behind a full cone NAT. 515 | [stop] 516 | \end_layout 517 | 518 | \begin_layout Enumerate 519 | If [O] cannot get a reply, it asks [B] to message [U] with an attempt to 520 | connect to [O] (which may fail), at the same time [O] tries to connect 521 | to [U]. 522 | If successful [O] reports back to [B] with success, and is then behind 523 | a port restricted NAT [stop]. 524 | \end_layout 525 | 526 | \begin_layout Enumerate 527 | If 6. 528 | fails [U] is behind another type of NAT, probably symmetric, although these 529 | is some success at predicting port increment or decrement symmetric NAT 530 | devices, it is not efficient enough so [stop] with fail at this point. 531 | \end_layout 532 | 533 | \begin_layout Standard 534 | On all attempts failing the node should report NAT traversal fail to the 535 | application. 536 | This is not the final attempt as will be described in 537 | \begin_inset CommandInset ref 538 | LatexCommand ref 539 | reference "sub:TCP-fallback-configuration" 540 | 541 | \end_inset 542 | 543 | . 544 | 545 | \end_layout 546 | 547 | \begin_layout Standard 548 | This situation, however, should mean that a server node or an autonomous 549 | network node should fail as the remaining options would be bandwidth restrictiv 550 | e at this time to complete. 551 | 552 | \end_layout 553 | 554 | \begin_layout Subsubsection 555 | Implementation 556 | \end_layout 557 | 558 | \begin_layout Standard 559 | The above solution is purely hole punching, items 1 & 2 should always be 560 | tested first, on fail, then it is suggested three threads be created and 561 | on one thread run the rest of this list to complete the hole punch attempt. 562 | On threads 2 and 3 the router negotiations protocols should be attempted 563 | (one on each thread). 564 | 565 | \end_layout 566 | 567 | \begin_layout Standard 568 | If 5 above passes then all thread should be stopped and the node will start 569 | another thread to send keep alive messages to [B], otherwise UPnP or NAT-PMP 570 | will hopefully pass, it is advisable to accept a NAT-PMP as first choice 571 | in this case. 572 | 573 | \end_layout 574 | 575 | \begin_layout Subsection 576 | Relay request 577 | \end_layout 578 | 579 | \begin_layout Standard 580 | In situations where all attempts to traverse a NAT fail then the option 581 | of relay can be attempted. 582 | 583 | \end_layout 584 | 585 | \begin_layout Standard 586 | directly connected nodes should create a TCP listening socket on ports 80 587 | and 443. 588 | This information should also be published in the contact tuple for that 589 | node. 590 | The UDP port for listening is not important and any port should suffice. 591 | 592 | \end_layout 593 | 594 | \begin_layout Standard 595 | A relay request from any node is either honoured or not, depending on the 596 | configuration chosen. 597 | \end_layout 598 | 599 | \begin_layout Subsection 600 | TCP fall-back configuration 601 | \begin_inset CommandInset label 602 | LatexCommand label 603 | name "sub:TCP-fallback-configuration" 604 | 605 | \end_inset 606 | 607 | 608 | \end_layout 609 | 610 | \begin_layout Standard 611 | There will be networks where UDP is banned completely and all transports 612 | depending on this would be made useless. 613 | TCP has to be used in this case, but as stated TCP, is very difficult to 614 | use to traverse NAT devices, there have been some attempts with TCP hole-punchi 615 | ng but to no great avail, as the time-outs or time the hole is left open 616 | is significantly smaller, giving nodes little chance to sync into a conversatio 617 | n in time. 618 | 619 | \end_layout 620 | 621 | \begin_layout Standard 622 | In cases where UDP cannot work in a network we need to rely on a relay type 623 | configuration for TCP. 624 | \end_layout 625 | 626 | \begin_layout Section 627 | Conclusions 628 | \end_layout 629 | 630 | \begin_layout Standard 631 | NAT traversal is a huge issue for any peer to peer or distributed solution 632 | to networking in IT. 633 | It has become increasingly problematic with router manufacturers not rigidly 634 | implementing standards in a manner that is either consistent or helpful 635 | (in many cases). 636 | 637 | \end_layout 638 | 639 | \begin_layout Bibliography 640 | \begin_inset CommandInset bibitem 641 | LatexCommand bibitem 642 | label "1" 643 | key "1" 644 | 645 | \end_inset 646 | 647 | J. 648 | Rosenberg, R. 649 | Mahy (Cisco) Session Traversal Utilities for NAT (STUN), RFC 5389 650 | \end_layout 651 | 652 | \begin_layout Bibliography 653 | \begin_inset CommandInset bibitem 654 | LatexCommand bibitem 655 | label "2" 656 | key "2" 657 | 658 | \end_inset 659 | 660 | J. 661 | Rosenberg (Cisco), Interactive Connectivity Establishment (ICE): A Protocol 662 | for Network Address Translator (NAT) Traversal for Offer/Answer Protocols, 663 | draft-ietf-mmusic-ice-19 664 | \end_layout 665 | 666 | \begin_layout Bibliography 667 | \begin_inset CommandInset bibitem 668 | LatexCommand bibitem 669 | label "3" 670 | key "3" 671 | 672 | \end_inset 673 | 674 | J. 675 | Rosenberg, C. 676 | Huitema, and R. 677 | Mahy. 678 | Traversal using relay NAT (TURN), October 2003. 679 | Internet-Draft (Work in Progress). 680 | \end_layout 681 | 682 | \begin_layout Bibliography 683 | \begin_inset CommandInset bibitem 684 | LatexCommand bibitem 685 | label "4" 686 | key "4" 687 | 688 | \end_inset 689 | 690 | David Irvine, maidsafe: A new networking paradigm, david.irvine@maidsafe.net 691 | \end_layout 692 | 693 | \begin_layout Bibliography 694 | \begin_inset CommandInset bibitem 695 | LatexCommand bibitem 696 | label "5" 697 | key "5" 698 | 699 | \end_inset 700 | 701 | UPnP Forum. 702 | Internet gateway device (IGD) standardized device control protocol, November 703 | 2001. 704 | http://www.upnp.org/. 705 | \end_layout 706 | 707 | \begin_layout Bibliography 708 | \begin_inset CommandInset bibitem 709 | LatexCommand bibitem 710 | label "6" 711 | key "6" 712 | 713 | \end_inset 714 | 715 | http://midcom-p2p.sourceforge.net/ 716 | \end_layout 717 | 718 | \begin_layout Bibliography 719 | \begin_inset CommandInset bibitem 720 | LatexCommand bibitem 721 | label "7" 722 | key "7" 723 | 724 | \end_inset 725 | 726 | http://udt.sourceforge.net/ 727 | \end_layout 728 | 729 | \begin_layout Biography without photo 730 | \begin_inset Argument 1 731 | status open 732 | 733 | \begin_layout Plain Layout 734 | David Irvine 735 | \end_layout 736 | 737 | \end_inset 738 | 739 | is a Scottish Engineer and innovator who has spent the last 12 years researchin 740 | g ways to make computers function in a more efficient manner. 741 | \end_layout 742 | 743 | \begin_layout Biography without photo 744 | He is an Inventor listed on more than 20 patent submissions and was Designer 745 | of one of the World's largest private networks (Saudi Aramco, over $300M). 746 | He is an experienced Project Manager and has been involved in start up 747 | businesses since 1995 and has provided business consultancy to corporates 748 | and SMEs in many sectors. 749 | \end_layout 750 | 751 | \begin_layout Biography without photo 752 | He has presented technology at Google (Seattle), British Computer Society 753 | (Christmas Lecture) and many others. 754 | \end_layout 755 | 756 | \begin_layout Biography without photo 757 | He has spent many years as a lifeboat Helmsman and is a keen sailor when 758 | time permits. 759 | \begin_inset Newpage pagebreak 760 | \end_inset 761 | 762 | 763 | \end_layout 764 | 765 | \begin_layout Appendix 766 | 767 | \end_layout 768 | 769 | \begin_layout Standard 770 | \begin_inset External 771 | template PDFPages 772 | filename third_party/Ford.pdf 773 | extra LaTeX "pages=-" 774 | 775 | \end_inset 776 | 777 | 778 | \end_layout 779 | 780 | \end_body 781 | \end_document 782 | -------------------------------------------------------------------------------- /technical_papers/MaidSafeDistributedFileSystem.lyx: -------------------------------------------------------------------------------- 1 | #LyX 2.1 created this file. For more info see http://www.lyx.org/ 2 | \lyxformat 474 3 | \begin_document 4 | \begin_header 5 | \textclass IEEEtran 6 | \use_default_options false 7 | \maintain_unincluded_children false 8 | \language british 9 | \language_package default 10 | \inputencoding default 11 | \fontencoding global 12 | \font_roman default 13 | \font_sans default 14 | \font_typewriter default 15 | \font_math auto 16 | \font_default_family default 17 | \use_non_tex_fonts false 18 | \font_sc false 19 | \font_osf false 20 | \font_sf_scale 100 21 | \font_tt_scale 100 22 | \graphics default 23 | \default_output_format default 24 | \output_sync 0 25 | \bibtex_command default 26 | \index_command default 27 | \paperfontsize default 28 | \spacing single 29 | \use_hyperref true 30 | \pdf_title "MaidSafe Distributed File System" 31 | \pdf_author "David Irvine" 32 | \pdf_subject "Distributed File Systems" 33 | \pdf_keywords "security, freedom, privacy, file systems" 34 | \pdf_bookmarks true 35 | \pdf_bookmarksnumbered false 36 | \pdf_bookmarksopen false 37 | \pdf_bookmarksopenlevel 1 38 | \pdf_breaklinks false 39 | \pdf_pdfborder true 40 | \pdf_colorlinks false 41 | \pdf_backref false 42 | \pdf_pdfusetitle true 43 | \papersize default 44 | \use_geometry false 45 | \use_package amsmath 0 46 | \use_package amssymb 0 47 | \use_package cancel 1 48 | \use_package esint 0 49 | \use_package mathdots 1 50 | \use_package mathtools 1 51 | \use_package mhchem 1 52 | \use_package stackrel 1 53 | \use_package stmaryrd 1 54 | \use_package undertilde 1 55 | \cite_engine basic 56 | \cite_engine_type default 57 | \biblio_style plain 58 | \use_bibtopic false 59 | \use_indices false 60 | \paperorientation portrait 61 | \suppress_date false 62 | \justification true 63 | \use_refstyle 0 64 | \index Index 65 | \shortcut idx 66 | \color #008000 67 | \end_index 68 | \secnumdepth 3 69 | \tocdepth 3 70 | \paragraph_separation indent 71 | \paragraph_indentation default 72 | \quotes_language english 73 | \papercolumns 2 74 | \papersides 1 75 | \paperpagestyle default 76 | \tracking_changes false 77 | \output_changes false 78 | \html_math_output 0 79 | \html_css_as_file 0 80 | \html_be_strict false 81 | \end_header 82 | 83 | \begin_body 84 | 85 | \begin_layout Title 86 | MaidSafe Distributed File System 87 | \end_layout 88 | 89 | \begin_layout Author 90 | \begin_inset Flex Author Name 91 | status open 92 | 93 | \begin_layout Plain Layout 94 | David Irvine 95 | \end_layout 96 | 97 | \end_inset 98 | 99 | 100 | \begin_inset Flex Author Mark 101 | status open 102 | 103 | \begin_layout Plain Layout 104 | 1 105 | \end_layout 106 | 107 | \end_inset 108 | 109 | 110 | \begin_inset Newline newline 111 | \end_inset 112 | 113 | 114 | \begin_inset Flex Author Affiliation 115 | status open 116 | 117 | \begin_layout Plain Layout 118 | MaidSafe.net, 72 Templehill, Troon, South Ayrshire, Scotland, UK. 119 | KA10 6BE. 120 | \end_layout 121 | 122 | \end_inset 123 | 124 | 125 | \begin_inset Newline newline 126 | \end_inset 127 | 128 | 129 | \begin_inset Flex Author Mark 130 | status open 131 | 132 | \begin_layout Plain Layout 133 | 1 134 | \end_layout 135 | 136 | \end_inset 137 | 138 | david.irvine@maidsafe.net 139 | \end_layout 140 | 141 | \begin_layout Page headings 142 | \begin_inset Argument 1 143 | status open 144 | 145 | \begin_layout Plain Layout 146 | Irvine: MaidSafe Distributed File System 147 | \end_layout 148 | 149 | \end_inset 150 | 151 | 152 | \end_layout 153 | 154 | \begin_layout Address 155 | First published September 2010. 156 | \end_layout 157 | 158 | \begin_layout Abstract 159 | Distributed file systems require servers or control nodes. 160 | Access to a file system is a security issue that can apparently only be 161 | controlled by some kind of authority, and this is always a potential point 162 | of failure. 163 | These file systems also require an indexing mechanism. 164 | This paper presents a distributed file system without centralised control 165 | or indexing. 166 | This file system also utilises a distributed locking mechanism to ensure 167 | data integrity in the case of multi-user access to any file. 168 | \end_layout 169 | 170 | \begin_layout Keywords 171 | security, freedom, privacy, file systems 172 | \end_layout 173 | 174 | \begin_layout Standard 175 | \begin_inset CommandInset toc 176 | LatexCommand tableofcontents 177 | 178 | \end_inset 179 | 180 | 181 | \end_layout 182 | 183 | \begin_layout Section 184 | Introduction 185 | \end_layout 186 | 187 | \begin_layout Standard 188 | \begin_inset Flex Paragraph Start 189 | status open 190 | 191 | \begin_layout Plain Layout 192 | \begin_inset Argument 1 193 | status open 194 | 195 | \begin_layout Plain Layout 196 | F 197 | \end_layout 198 | 199 | \end_inset 200 | 201 | ilesystems 202 | \end_layout 203 | 204 | \end_inset 205 | 206 | are a relatively new and slow-changing part of computing. 207 | There are differences between operating systems (and even versions of operating 208 | systems) in their ability to handle access to data via a file system. 209 | This has proved to be problematic over the years and has led to many short-term 210 | fixes. 211 | Systems such as CIFS, Andrews, SMB and many others appear to be an answer, 212 | but for many reasons (occasionally political) they lose ground again. 213 | It is the intention of this paper to present a universal file system that 214 | implements a minimum set of features that will operate cross platform. 215 | 216 | \end_layout 217 | 218 | \begin_layout Standard 219 | This system will represent itself to a user as a native file system on any 220 | platform, and as such requires low level drivers and code to be installed 221 | alongside any application using it. 222 | 223 | \end_layout 224 | 225 | \begin_layout Standard 226 | A significant advance in distributed locking is also employed, which allows 227 | shared directories to be easily set up and maintained. 228 | 229 | \end_layout 230 | 231 | \begin_layout Standard 232 | In addition, there is a solution to the problem of location of data, or 233 | path sizes, which is currently limited on every operating system. 234 | This paper presents a mechanism to overcome this and enable an almost infinite 235 | number of levels of directories to be implemented. 236 | 237 | \end_layout 238 | 239 | \begin_layout Subsection 240 | Conventions Used 241 | \end_layout 242 | 243 | \begin_layout Standard 244 | There is scope for confusion when using the term 245 | \begin_inset Quotes eld 246 | \end_inset 247 | 248 | key 249 | \begin_inset Quotes erd 250 | \end_inset 251 | 252 | , as sometimes it refers to a cryptographic key, and at other times it is 253 | in respect to the key of a DHT 254 | \begin_inset Quotes eld 255 | \end_inset 256 | 257 | key, value 258 | \begin_inset Quotes erd 259 | \end_inset 260 | 261 | pair. 262 | In order to avoid confusion, cryptographic private and public keys will 263 | be referred to as 264 | \begin_inset Formula $\mathsf{K_{priv}}$ 265 | \end_inset 266 | 267 | and 268 | \begin_inset Formula $\mathsf{K_{pub}}$ 269 | \end_inset 270 | 271 | respectively, and DHT keys simply as keys. 272 | \end_layout 273 | 274 | \begin_layout Itemize 275 | Node ≡ a network resource which is a process, sometimes referred to as a 276 | vault in other papers. 277 | This is the computer program that maintains the network and on its own 278 | is not very special. 279 | It is in collaboration that this Node becomes part of a very complex, sophistic 280 | ated and efficient network. 281 | \end_layout 282 | 283 | \begin_layout Itemize 284 | \begin_inset Formula $\mathsf{H}$ 285 | \end_inset 286 | 287 | ≡ Hash function such as SHA, MD5, etc. 288 | \end_layout 289 | 290 | \begin_layout Itemize 291 | \begin_inset Formula $\mathsf{XXX_{priv}}$ 292 | \end_inset 293 | 294 | , 295 | \begin_inset Formula $\mathsf{XXX_{pub}}$ 296 | \end_inset 297 | 298 | ≡ Private and public keys respectively of cryptographic key pair named 299 | 300 | \begin_inset Formula $\mathsf{XXX}$ 301 | \end_inset 302 | 303 | 304 | \end_layout 305 | 306 | \begin_layout Itemize 307 | \begin_inset Formula $\mathsf{SymEnc{}_{[PASS]}(Data)}$ 308 | \end_inset 309 | 310 | ≡ Symmetrically encrypt 311 | \begin_inset Formula $\mathsf{Data}$ 312 | \end_inset 313 | 314 | using 315 | \begin_inset Formula $\mathsf{PASS}$ 316 | \end_inset 317 | 318 | 319 | \end_layout 320 | 321 | \begin_layout Itemize 322 | \begin_inset Formula $\mathsf{Sig{}_{[K_{priv}]}(Data)}$ 323 | \end_inset 324 | 325 | ≡ Create asymmetric signature of 326 | \begin_inset Formula $\mathsf{Data}$ 327 | \end_inset 328 | 329 | using 330 | \begin_inset Formula $\mathsf{K_{priv}}$ 331 | \end_inset 332 | 333 | 334 | \end_layout 335 | 336 | \begin_layout Itemize 337 | \begin_inset Formula $\mathsf{+}$ 338 | \end_inset 339 | 340 | ≡ Concatenation 341 | \end_layout 342 | 343 | \begin_layout Itemize 344 | 345 | \family roman 346 | \series medium 347 | \shape up 348 | \size normal 349 | \emph off 350 | \bar no 351 | \noun off 352 | \color none 353 | \begin_inset Formula $\mathsf{\bigoplus}$ 354 | \end_inset 355 | 356 | 357 | \family default 358 | \series default 359 | \shape default 360 | \size default 361 | \emph default 362 | \bar default 363 | \noun default 364 | \color inherit 365 | ≡ Bitwise Exclusive Or (XOR) 366 | \end_layout 367 | 368 | \begin_layout Itemize 369 | \begin_inset Formula $\mathsf{STORE}$ 370 | \end_inset 371 | 372 | ≡ Network or other key addressable storage system 373 | \end_layout 374 | 375 | \begin_layout Itemize 376 | \begin_inset Formula $\mathsf{PutV_{[Key]}(Value)}$ 377 | \end_inset 378 | 379 | ≡ Store 380 | \begin_inset Formula $\mathsf{Value}$ 381 | \end_inset 382 | 383 | under 384 | \begin_inset Formula $\mathsf{Key}$ 385 | \end_inset 386 | 387 | on 388 | \begin_inset Formula $\mathsf{STORE}$ 389 | \end_inset 390 | 391 | . 392 | This value is signed. 393 | \end_layout 394 | 395 | \begin_layout Subsection 396 | Security of Data 397 | \end_layout 398 | 399 | \begin_layout Standard 400 | In order to achieve data security, nodes requesting a 401 | \begin_inset Formula $\mathsf{PutV_{[Key]}(Value)}$ 402 | \end_inset 403 | 404 | 405 | \emph on 406 | must 407 | \emph default 408 | sign both 409 | \begin_inset Formula $\mathsf{Value}$ 410 | \end_inset 411 | 412 | and the request itself. 413 | 414 | \begin_inset Formula $\mathsf{STORE}$ 415 | \end_inset 416 | 417 | must only allow subsequent changes to 418 | \begin_inset Formula $\mathsf{Value}$ 419 | \end_inset 420 | 421 | if the request and replacement 422 | \begin_inset Formula $\mathsf{Value}$ 423 | \end_inset 424 | 425 | are similarly signed. 426 | \end_layout 427 | 428 | \begin_layout Section 429 | Overview 430 | \end_layout 431 | 432 | \begin_layout Standard 433 | To enable a huge amount of data to be organised into a directory structure 434 | (as we are used to) then a new method of data management is needed. 435 | In this case, we have created a system of divorcing the structure of any 436 | data from a tree in one direction. 437 | \end_layout 438 | 439 | \begin_layout Standard 440 | In this paper, we present a system where a directory structure may be traversed 441 | forward from any point and with efficient implementation back to that point, 442 | but no further back unless new knowledge of the structure is gained. 443 | This has the effect of allowing directory trees to be free forming rather 444 | than tied to any root or base level. 445 | \end_layout 446 | 447 | \begin_layout Section 448 | Distributed Directories 449 | \end_layout 450 | 451 | \begin_layout Subsection 452 | General 453 | \end_layout 454 | 455 | \begin_layout Standard 456 | Every directory has a unique identifier associated with it. 457 | Part of this identifier is used as a key under which its encrypted contents 458 | \begin_inset Foot 459 | status open 460 | 461 | \begin_layout Plain Layout 462 | \begin_inset Quotes eld 463 | \end_inset 464 | 465 | contents 466 | \begin_inset Quotes erd 467 | \end_inset 468 | 469 | here does 470 | \shape italic 471 | not 472 | \shape default 473 | mean the files listed in the directory, but rather the structure used to 474 | represent the list (e.g. 475 | a database) 476 | \end_layout 477 | 478 | \end_inset 479 | 480 | are held on 481 | \begin_inset Formula $\mathsf{STORE}$ 482 | \end_inset 483 | 484 | . 485 | The contents are encrypted (and hence can only be decrypted) by using the 486 | identifiers of the directory and the directory's parent. 487 | In this way, a given directory's contents (and hence files and subdirectories) 488 | can be recursively decrypted to yield all the levels of subdirectories 489 | it may contain. 490 | However, without knowledge of the identifier of the directory's parent, 491 | the parent cannot be decrypted. 492 | \end_layout 493 | 494 | \begin_layout Subsection 495 | Creation Process 496 | \begin_inset CommandInset label 497 | LatexCommand label 498 | name "sub:Creation-Process" 499 | 500 | \end_inset 501 | 502 | 503 | \end_layout 504 | 505 | \begin_layout Standard 506 | The process to create a subdirectory ( 507 | \begin_inset Formula $\mathsf{Child}$ 508 | \end_inset 509 | 510 | ) of a directory ( 511 | \begin_inset Formula $\mathsf{Parent}$ 512 | \end_inset 513 | 514 | which has identifier 515 | \begin_inset Formula $\mathsf{ParentID}$ 516 | \end_inset 517 | 518 | ) is as follows: 519 | \end_layout 520 | 521 | \begin_layout Enumerate 522 | Find a random key ( 523 | \begin_inset Formula $\mathsf{ChildKey}$ 524 | \end_inset 525 | 526 | ) which is unused on 527 | \begin_inset Formula $\mathsf{STORE}$ 528 | \end_inset 529 | 530 | 531 | \end_layout 532 | 533 | \begin_layout Enumerate 534 | Derive the 535 | \begin_inset Formula $\mathsf{Child}$ 536 | \end_inset 537 | 538 | 's identifier ( 539 | \begin_inset Formula $\mathsf{ChildID}$ 540 | \end_inset 541 | 542 | ) from 543 | \begin_inset Formula $\mathsf{ChildKey}$ 544 | \end_inset 545 | 546 | (e.g. 547 | by appending random data) 548 | \end_layout 549 | 550 | \begin_layout Enumerate 551 | Add a new entry 552 | \begin_inset Foot 553 | status open 554 | 555 | \begin_layout Plain Layout 556 | The entry may also contain all required metadata of 557 | \begin_inset Formula $\mathsf{Child}$ 558 | \end_inset 559 | 560 | . 561 | \end_layout 562 | 563 | \end_inset 564 | 565 | which includes 566 | \begin_inset Formula $\mathsf{ChildID}$ 567 | \end_inset 568 | 569 | in 570 | \begin_inset Formula $\mathsf{Parent}$ 571 | \end_inset 572 | 573 | to represent 574 | \begin_inset Formula $\mathsf{Child}$ 575 | \end_inset 576 | 577 | 578 | \end_layout 579 | 580 | \begin_layout Enumerate 581 | Encrypt 582 | \begin_inset Formula $\mathsf{Parent}$ 583 | \end_inset 584 | 585 | and 586 | \begin_inset Formula $\mathsf{Child}$ 587 | \end_inset 588 | 589 | (yielding 590 | \begin_inset Formula $\mathsf{ParentEnc}$ 591 | \end_inset 592 | 593 | and 594 | \begin_inset Formula $\mathsf{ChildEnc}$ 595 | \end_inset 596 | 597 | respectively) as described below 598 | \end_layout 599 | 600 | \begin_layout Enumerate 601 | \begin_inset Formula $\mathsf{PutV_{[ParentKey]}(ParentEnc)}$ 602 | \end_inset 603 | 604 | 605 | \end_layout 606 | 607 | \begin_layout Enumerate 608 | \begin_inset Formula $\mathsf{PutV_{[ChildKey]}(ChildEnc)}$ 609 | \end_inset 610 | 611 | 612 | \end_layout 613 | 614 | \begin_layout Subsection 615 | Encryption of Directory Entries 616 | \begin_inset CommandInset label 617 | LatexCommand label 618 | name "sub:Encryption-of-Directory" 619 | 620 | \end_inset 621 | 622 | 623 | \end_layout 624 | 625 | \begin_layout Standard 626 | This uses a process very similar to that described in 627 | \emph on 628 | Self Encrypting Data 629 | \emph default 630 | 631 | \begin_inset CommandInset citation 632 | LatexCommand cite 633 | key "1" 634 | 635 | \end_inset 636 | 637 | . 638 | The process is as follows: 639 | \end_layout 640 | 641 | \begin_layout Enumerate 642 | Self-encrypt the 643 | \begin_inset Formula $\mathsf{Child}$ 644 | \end_inset 645 | 646 | directory as any other file in 647 | \begin_inset CommandInset citation 648 | LatexCommand cite 649 | key "1" 650 | 651 | \end_inset 652 | 653 | . 654 | This yields a datamap ( 655 | \begin_inset Formula $\mathsf{ChildDM}$ 656 | \end_inset 657 | 658 | ) 659 | \end_layout 660 | 661 | \begin_layout Enumerate 662 | Where 663 | \begin_inset Formula $\mathsf{H(ChildID+ParentID)}$ 664 | \end_inset 665 | 666 | is named 667 | \begin_inset Formula $\mathsf{Obf}$ 668 | \end_inset 669 | 670 | , create a data chunk ( 671 | \begin_inset Formula $\mathsf{ObfChunk}$ 672 | \end_inset 673 | 674 | ) which is the same size as 675 | \begin_inset Formula $\mathsf{ChildDM}$ 676 | \end_inset 677 | 678 | by repeatedly rehashing 679 | \begin_inset Formula $\mathsf{Obf}$ 680 | \end_inset 681 | 682 | and appending the result, i.e. 683 | 684 | \begin_inset Formula $\mathsf{Obf+H(Obf)+H(H(Obf))+...}$ 685 | \end_inset 686 | 687 | 688 | \end_layout 689 | 690 | \begin_layout Enumerate 691 | Create an obfuscated datamap, 692 | \begin_inset Formula $\mathsf{ObfDM}$ 693 | \end_inset 694 | 695 | = 696 | \begin_inset Formula $\mathsf{ChildDM\,\bigoplus\,ObfChunk}$ 697 | \end_inset 698 | 699 | 700 | \end_layout 701 | 702 | \begin_layout Enumerate 703 | Create a symmetric encryption passphrase, 704 | \begin_inset Formula $\mathsf{Pass}$ 705 | \end_inset 706 | 707 | = 708 | \family roman 709 | \series medium 710 | \shape up 711 | \size normal 712 | \emph off 713 | \bar no 714 | \noun off 715 | \color none 716 | 717 | \begin_inset Formula $\mathsf{H(ParentID+ChildID)}$ 718 | \end_inset 719 | 720 | 721 | \end_layout 722 | 723 | \begin_layout Enumerate 724 | Finally, create the encrypted datamap, 725 | \begin_inset Formula $\mathsf{EncDM}$ 726 | \end_inset 727 | 728 | = 729 | \begin_inset Formula $\mathsf{SymEnc_{[Pass]}(ObfDM)}$ 730 | \end_inset 731 | 732 | 733 | \end_layout 734 | 735 | \begin_layout Subsection 736 | Advantages of Distributed Directories 737 | \end_layout 738 | 739 | \begin_layout Itemize 740 | We can have an almost infinite traversal of directories with no limit on 741 | depth 742 | \end_layout 743 | 744 | \begin_layout Itemize 745 | To share data, all that is required is access to a decrypted directory 746 | \begin_inset Foot 747 | status open 748 | 749 | \begin_layout Plain Layout 750 | or an encrypted directory along with the keys required for decryption 751 | \end_layout 752 | 753 | \end_inset 754 | 755 | and then all the directories below will be automatically shared 756 | \end_layout 757 | 758 | \begin_layout Itemize 759 | Directories following a distributed paradigm are more suited for mass distributi 760 | on 761 | \end_layout 762 | 763 | \begin_layout Itemize 764 | Avoidance of network bottlenecks 765 | \end_layout 766 | 767 | \begin_layout Subsection 768 | Data Locks 769 | \end_layout 770 | 771 | \begin_layout Standard 772 | If the 773 | \begin_inset Formula $\mathsf{STORE}$ 774 | \end_inset 775 | 776 | is a file system or database, then data locks are a standard feature. 777 | Here we discuss locking in a Distributed Hash Table (DHT) which is historically 778 | problematic. 779 | This section assumes a DHT of similar capability to 780 | \emph on 781 | MaidSafe's Distributed Hash Table 782 | \begin_inset CommandInset citation 783 | LatexCommand cite 784 | key "2" 785 | 786 | \end_inset 787 | 788 | . 789 | 790 | \end_layout 791 | 792 | \begin_layout Standard 793 | To ensure writes to data are atomic, we require a locking mechanism that 794 | is solid and allows the network to recover from stale locks. 795 | In a MaidSafe DHT this can be achieved quite simply and is efficient due 796 | to the speed of the network, via managed connections. 797 | \end_layout 798 | 799 | \begin_layout Standard 800 | To write data, a node requires to request a lock from the 801 | \size larger 802 | 803 | \begin_inset Formula $\kappa$ 804 | \end_inset 805 | 806 | 807 | \size default 808 | closest nodes to the data (this requires that no dead nodes exist in the 809 | DHT). 810 | On receiving a lock, each node will confer with the other nodes; if all 811 | accept the lock, then it will be implemented. 812 | If there are any collisions of two separate requests for a lock, both are 813 | rejected. 814 | In this case, the requesting nodes will back-off for a random time and 815 | try again. 816 | \end_layout 817 | 818 | \begin_layout Standard 819 | On receiving a lock, a node will read the data again to confirm it is the 820 | same version that has been updated and will then update the value. 821 | \end_layout 822 | 823 | \begin_layout Standard 824 | There should be a system wide lock duration 825 | \emph on 826 | constant 827 | \emph default 828 | in place that will remove any locks that have gone stale (as they will). 829 | \end_layout 830 | 831 | \begin_layout Standard 832 | Lock requests will be signed by the sender to allow the 833 | \size larger 834 | 835 | \begin_inset Formula $\kappa$ 836 | \end_inset 837 | 838 | 839 | \size default 840 | recipients to confirm the permissions of the requester. 841 | If the signature validation fails, the requests are silently dropped. 842 | \end_layout 843 | 844 | \begin_layout Subsection 845 | Private Shared Directory Structures 846 | \end_layout 847 | 848 | \begin_layout Standard 849 | To enable private shared directory structures, two issues need to be addressed; 850 | what to use in place of 851 | \begin_inset Formula $\mathsf{ParentID}$ 852 | \end_inset 853 | 854 | for the shared root directory, and how to allow permitted peers access 855 | to the decrypted shared root directory. 856 | \end_layout 857 | 858 | \begin_layout Subsubsection 859 | Creating a Shared Root Directory 860 | \end_layout 861 | 862 | \begin_layout Standard 863 | Creating a shared root directory is as per 864 | \begin_inset CommandInset ref 865 | LatexCommand ref 866 | reference "sub:Creation-Process" 867 | 868 | \end_inset 869 | 870 | above with the exception of the encryption element. 871 | The node creating the shared root directory cannot allow peers to know 872 | the 873 | \begin_inset Formula $\mathsf{ParentID}$ 874 | \end_inset 875 | 876 | for the directory (for security reasons). 877 | A replacement is derived, and the encryption phase is carried out as per 878 | 879 | \begin_inset CommandInset ref 880 | LatexCommand ref 881 | reference "sub:Encryption-of-Directory" 882 | 883 | \end_inset 884 | 885 | . 886 | Creating and storing the replacement for 887 | \begin_inset Formula $\mathsf{ParentID}$ 888 | \end_inset 889 | 890 | is completed as follows 891 | \begin_inset Foot 892 | status open 893 | 894 | \begin_layout Plain Layout 895 | Steps 1 to 6 describe creating a self-signed identity packet as detailed 896 | in 897 | \emph on 898 | "Peer to Peer" Public Key Infrastructure 899 | \emph default 900 | 901 | \begin_inset CommandInset citation 902 | LatexCommand cite 903 | key "3" 904 | 905 | \end_inset 906 | 907 | 908 | \end_layout 909 | 910 | \end_inset 911 | 912 | : 913 | \end_layout 914 | 915 | \begin_layout Enumerate 916 | Create a key pair 917 | \begin_inset Formula $\mathsf{ShareOwn{}_{priv}}$ 918 | \end_inset 919 | 920 | and 921 | \begin_inset Formula $\mathsf{ShareOwn{}_{pub}}$ 922 | \end_inset 923 | 924 | 925 | \end_layout 926 | 927 | \begin_layout Enumerate 928 | Create an ID for the share owner, 929 | \begin_inset Formula $\mathsf{ShareOwnID}$ 930 | \end_inset 931 | 932 | = 933 | \begin_inset Formula $\mathsf{H(ShareOwn_{pub}+Sig{}_{[ShareOwn_{priv}]}(ShareOwn{}_{pub}))}$ 934 | \end_inset 935 | 936 | 937 | \end_layout 938 | 939 | \begin_layout Enumerate 940 | \begin_inset Formula $\mathsf{PutV_{[ShareOwnID]}(ShareOwn_{pub}+}$ $\mathsf{\quad Sig{}_{[ShareOwn_{priv}]}(ShareOwn{}_{pub}))}$ 941 | 942 | \end_inset 943 | 944 | 945 | \end_layout 946 | 947 | \begin_layout Enumerate 948 | Create a key pair 949 | \begin_inset Formula $\mathsf{Share{}_{priv}}$ 950 | \end_inset 951 | 952 | and 953 | \begin_inset Formula $\mathsf{Share{}_{pub}}$ 954 | \end_inset 955 | 956 | 957 | \end_layout 958 | 959 | \begin_layout Enumerate 960 | Create an ID for the share, 961 | \begin_inset Formula $\mathsf{ShareID}$ 962 | \end_inset 963 | 964 | = 965 | \begin_inset Formula $\mathsf{H(Share_{pub}+Sig{}_{[ShareOwn_{priv}]}(Share{}_{pub}))}$ 966 | \end_inset 967 | 968 | 969 | \end_layout 970 | 971 | \begin_layout Enumerate 972 | \begin_inset Formula $\mathsf{PutV_{[ShareID]}(Share_{pub}+Sig{}_{[ShareOwn_{priv}]}(Share{}_{pub}))}$ 973 | \end_inset 974 | 975 | 976 | \end_layout 977 | 978 | \begin_layout Enumerate 979 | \begin_inset Formula $\mathsf{H(Share_{pub})}$ 980 | \end_inset 981 | 982 | is now used as the replacement for 983 | \begin_inset Formula $\mathsf{ParentID}$ 984 | \end_inset 985 | 986 | 987 | \end_layout 988 | 989 | \begin_layout Standard 990 | Normally, a node storing an encrypted datamap 991 | \begin_inset Formula $\mathsf{EncDM}$ 992 | \end_inset 993 | 994 | of a private non-shared directory would sign the 995 | \begin_inset Formula $\mathsf{PutV_{[DirectoryKey]}(EncDM)}$ 996 | \end_inset 997 | 998 | request and data with a cryptographic private key ( 999 | \begin_inset Formula $\mathsf{K_{priv}}$ 1000 | \end_inset 1001 | 1002 | ) known only to itself. 1003 | A single 1004 | \begin_inset Formula $\mathsf{K_{priv}}$ 1005 | \end_inset 1006 | 1007 | could be used for all directories, regardless of whether they are in the 1008 | same tree or not. 1009 | \end_layout 1010 | 1011 | \begin_layout Standard 1012 | However, in the case of a shared directory, peers must be able to modify 1013 | it, i.e. 1014 | they must be able to sign modified datamaps and requests with the original 1015 | private key. 1016 | For this reason, the 1017 | \begin_inset Formula $\mathsf{Share{}_{priv}}$ 1018 | \end_inset 1019 | 1020 | is used when storing an encrypted datamap of a shared directory. 1021 | The same 1022 | \begin_inset Formula $\mathsf{Share{}_{priv}}$ 1023 | \end_inset 1024 | 1025 | is used for all subdirectories of the shared root. 1026 | However, each new shared root directory must have a unique 1027 | \begin_inset Formula $\mathsf{Share_{priv}}$ 1028 | \end_inset 1029 | 1030 | to enable peer permissions to be assigned on a 'per-shared-directory' basis. 1031 | \end_layout 1032 | 1033 | \begin_layout Subsubsection 1034 | Getting Access to a Private Shared Directory 1035 | \end_layout 1036 | 1037 | \begin_layout Standard 1038 | The creator of a private shared root directory allocates permissions to 1039 | selected peers and sends each a signed and encrypted message on successful 1040 | creation of the directory. 1041 | All peers receive the share name (human-readable as assigned by the creator), 1042 | 1043 | \begin_inset Formula $\mathsf{ShareID}$ 1044 | \end_inset 1045 | 1046 | , 1047 | \begin_inset Formula $\mathsf{Share{}_{pub}}$ 1048 | \end_inset 1049 | 1050 | , and 1051 | \begin_inset Formula $\mathsf{ChildKey}$ 1052 | \end_inset 1053 | 1054 | . 1055 | This enables retrieval and decryption of the encrypted datamap (from 1056 | \begin_inset Formula $\mathsf{STORE}$ 1057 | \end_inset 1058 | 1059 | held under 1060 | \begin_inset Formula $\mathsf{ChildKey}$ 1061 | \end_inset 1062 | 1063 | ) (using 1064 | \begin_inset Formula $\mathsf{H(Share_{pub})}$ 1065 | \end_inset 1066 | 1067 | and 1068 | \begin_inset Formula $\mathsf{ChildKey}$ 1069 | \end_inset 1070 | 1071 | ), i.e. 1072 | read access to the directory and its subdirectories. 1073 | \end_layout 1074 | 1075 | \begin_layout Standard 1076 | For peers with write access, the message also contains 1077 | \begin_inset Formula $\mathsf{Share_{priv}}$ 1078 | \end_inset 1079 | 1080 | to enable them to modify the encrypted datamap held on 1081 | \begin_inset Formula $\mathsf{STORE}$ 1082 | \end_inset 1083 | 1084 | . 1085 | \end_layout 1086 | 1087 | \begin_layout Standard 1088 | For peers given administrator access, the message also contains 1089 | \begin_inset Formula $\mathsf{ShareOwn_{priv}}$ 1090 | \end_inset 1091 | 1092 | to enable them to alter 1093 | \begin_inset Formula $\mathsf{ShareID}$ 1094 | \end_inset 1095 | 1096 | s, remove users and delete the share completely from the 1097 | \begin_inset Formula $\mathsf{STORE}$ 1098 | \end_inset 1099 | 1100 | . 1101 | \end_layout 1102 | 1103 | \begin_layout Subsubsection 1104 | Revoking Access to a Private Shared Directory 1105 | \end_layout 1106 | 1107 | \begin_layout Standard 1108 | To revoke a peer's access to a shared directory, an administrator creates 1109 | a new 1110 | \begin_inset Formula $\mathsf{ShareID}$ 1111 | \end_inset 1112 | 1113 | and keypair. 1114 | Then the administrator locks the root of the share, copies the content 1115 | to the new root and creates a new 1116 | \begin_inset Formula $\mathsf{ChildKey}$ 1117 | \end_inset 1118 | 1119 | . 1120 | A message is sent to all authorised peers (minus the peer having its access 1121 | revoked) as in the previous section. 1122 | When a peer receives such a message, it must start re-reading the share 1123 | from the new root. 1124 | \end_layout 1125 | 1126 | \begin_layout Standard 1127 | The administrator then copies all the existing directory structures (locking 1128 | each in turn) to the new structure, starting at the new root and deleting 1129 | the old directories recursively. 1130 | \end_layout 1131 | 1132 | \begin_layout Standard 1133 | A user's system will note this action and if a file is opened, it will wait 1134 | for the new directory (and datamap) to become available if the current 1135 | directory is locked. 1136 | Otherwise it is safe to store the file as the recursive 'move' will not 1137 | have reached that point. 1138 | \end_layout 1139 | 1140 | \begin_layout Subsection 1141 | Public Shared Directory Structures 1142 | \end_layout 1143 | 1144 | \begin_layout Standard 1145 | Each user may also create public shared directory structures; i.e. 1146 | ones which can be accessed (read-only) by any peer. 1147 | The process is simpler than the one for private shared directories as the 1148 | datamaps need not be encrypted, and there is no need to send a message 1149 | to a group of peers. 1150 | \end_layout 1151 | 1152 | \begin_layout Standard 1153 | The creator of a public shared directory uses a different cryptographic 1154 | private key (named 1155 | \begin_inset Formula $\mathsf{MPID_{priv}}$ 1156 | \end_inset 1157 | 1158 | ) to sign the datamap and requests. 1159 | 1160 | \begin_inset Formula $\mathsf{MPID_{priv}}$ 1161 | \end_inset 1162 | 1163 | is not revealed to any peer and can be used for all public shared directories, 1164 | regardless of whether they are in the same tree or not. 1165 | This way anyone can see the data but only the creator can edit it, without 1166 | the need for locks. 1167 | \end_layout 1168 | 1169 | \begin_layout Standard 1170 | In order to allow peers to find public shared directories, users should 1171 | have a publicly-known ID (similar to the concept of an email address). 1172 | For a node whose public ID is 1173 | \begin_inset Formula $\mathsf{PublicID}$ 1174 | \end_inset 1175 | 1176 | , the datamap of its root public shared directory should be stored under 1177 | 1178 | \begin_inset Formula $\mathsf{H(PublicID)}$ 1179 | \end_inset 1180 | 1181 | . 1182 | \end_layout 1183 | 1184 | \begin_layout Standard 1185 | Using this directory structure, any user can publish information and it 1186 | can be read by any peer who merely knows the user's public ID. 1187 | Subsequently, data will be passed around and browser addons can be created 1188 | to facilitate widespread access to data on public shared directories. 1189 | \end_layout 1190 | 1191 | \begin_layout Subsection 1192 | Anonymous Shared Directory Structures 1193 | \end_layout 1194 | 1195 | \begin_layout Standard 1196 | In future, users will also be able to create anonymous shared directory 1197 | structures. 1198 | These will be similar to public shared ones, but the keys under which datamaps 1199 | are stored and any signing keys will not be traceable back to the user 1200 | concerned. 1201 | \end_layout 1202 | 1203 | \begin_layout Section 1204 | Conclusions 1205 | \end_layout 1206 | 1207 | \begin_layout Standard 1208 | This paper has introduced a method of storing data in a distributed network 1209 | in a manner that is addressable, searchable and very scalable. 1210 | It is apparent that such systems could in fact supplement or replace paradigms 1211 | used by the existing world wide web for data sharing. 1212 | It is evident that applications that make use of massively shared data 1213 | and data presented on a native format to users is an exciting proposition. 1214 | \end_layout 1215 | 1216 | \begin_layout Section* 1217 | Acknowledgment 1218 | \end_layout 1219 | 1220 | \begin_layout Standard 1221 | Thanks to Yanick Vézina who provided great assistance in proof reading this 1222 | paper. 1223 | \end_layout 1224 | 1225 | \begin_layout Bibliography 1226 | \begin_inset CommandInset bibitem 1227 | LatexCommand bibitem 1228 | label "1" 1229 | key "1" 1230 | 1231 | \end_inset 1232 | 1233 | David Irvine, Self Encrypting Data, david.irvine@maidsafe.net 1234 | \end_layout 1235 | 1236 | \begin_layout Bibliography 1237 | \begin_inset CommandInset bibitem 1238 | LatexCommand bibitem 1239 | label "2" 1240 | key "2" 1241 | 1242 | \end_inset 1243 | 1244 | David Irvine, MaidSafe Distributed Hash Table, david.irvine@maidsafe.net 1245 | \end_layout 1246 | 1247 | \begin_layout Bibliography 1248 | \begin_inset CommandInset bibitem 1249 | LatexCommand bibitem 1250 | label "3" 1251 | key "3" 1252 | 1253 | \end_inset 1254 | 1255 | David Irvine, "Peer to Peer" Public Key Infrastructure, david.irvine@maidsafe.net 1256 | \end_layout 1257 | 1258 | \begin_layout Biography without photo 1259 | \begin_inset Argument 1 1260 | status open 1261 | 1262 | \begin_layout Plain Layout 1263 | David Irvine 1264 | \end_layout 1265 | 1266 | \end_inset 1267 | 1268 | is a Scottish Engineer and innovator who has spent the last 12 years researchin 1269 | g ways to make computers function in a more efficient manner. 1270 | \end_layout 1271 | 1272 | \begin_layout Biography without photo 1273 | He is an Inventor listed on more than 20 patent submissions and was Designer 1274 | of one of the World's largest private networks (Saudi Aramco, over $300M). 1275 | He is an experienced Project Manager and has been involved in start up 1276 | businesses since 1995 and has provided business consultancy to corporates 1277 | and SMEs in many sectors. 1278 | \end_layout 1279 | 1280 | \begin_layout Biography without photo 1281 | He has presented technology at Google (Seattle), British Computer Society 1282 | (Christmas Lecture) and many others. 1283 | \end_layout 1284 | 1285 | \begin_layout Biography without photo 1286 | He has spent many years as a lifeboat Helmsman and is a keen sailor when 1287 | time permits. 1288 | \end_layout 1289 | 1290 | \end_body 1291 | \end_document 1292 | -------------------------------------------------------------------------------- /technical_papers/ManagedAuthentication.lyx: -------------------------------------------------------------------------------- 1 | #LyX 2.1 created this file. For more info see http://www.lyx.org/ 2 | \lyxformat 474 3 | \begin_document 4 | \begin_header 5 | \textclass IEEEtran 6 | \use_default_options false 7 | \maintain_unincluded_children false 8 | \language british 9 | \language_package default 10 | \inputencoding default 11 | \fontencoding global 12 | \font_roman default 13 | \font_sans default 14 | \font_typewriter default 15 | \font_math auto 16 | \font_default_family default 17 | \use_non_tex_fonts false 18 | \font_sc false 19 | \font_osf false 20 | \font_sf_scale 100 21 | \font_tt_scale 100 22 | \graphics default 23 | \default_output_format default 24 | \output_sync 0 25 | \bibtex_command default 26 | \index_command default 27 | \paperfontsize default 28 | \spacing single 29 | \use_hyperref true 30 | \pdf_title "Managed Authentication" 31 | \pdf_author "David Irvine" 32 | \pdf_subject "Authentication" 33 | \pdf_keywords "security, freedom, privacy, authentication" 34 | \pdf_bookmarks true 35 | \pdf_bookmarksnumbered false 36 | \pdf_bookmarksopen false 37 | \pdf_bookmarksopenlevel 1 38 | \pdf_breaklinks false 39 | \pdf_pdfborder true 40 | \pdf_colorlinks false 41 | \pdf_backref false 42 | \pdf_pdfusetitle true 43 | \papersize default 44 | \use_geometry false 45 | \use_package amsmath 0 46 | \use_package amssymb 0 47 | \use_package cancel 1 48 | \use_package esint 0 49 | \use_package mathdots 0 50 | \use_package mathtools 1 51 | \use_package mhchem 1 52 | \use_package stackrel 1 53 | \use_package stmaryrd 1 54 | \use_package undertilde 1 55 | \cite_engine basic 56 | \cite_engine_type default 57 | \biblio_style plain 58 | \use_bibtopic false 59 | \use_indices false 60 | \paperorientation portrait 61 | \suppress_date false 62 | \justification true 63 | \use_refstyle 0 64 | \index Index 65 | \shortcut idx 66 | \color #008000 67 | \end_index 68 | \secnumdepth 3 69 | \tocdepth 3 70 | \paragraph_separation indent 71 | \paragraph_indentation default 72 | \quotes_language english 73 | \papercolumns 2 74 | \papersides 1 75 | \paperpagestyle default 76 | \tracking_changes false 77 | \output_changes false 78 | \html_math_output 0 79 | \html_css_as_file 0 80 | \html_be_strict false 81 | \end_header 82 | 83 | \begin_body 84 | 85 | \begin_layout Title 86 | Managed Authentication 87 | \end_layout 88 | 89 | \begin_layout Author 90 | \begin_inset Flex Author Name 91 | status open 92 | 93 | \begin_layout Plain Layout 94 | David Irvine 95 | \end_layout 96 | 97 | \end_inset 98 | 99 | 100 | \begin_inset Flex Author Mark 101 | status open 102 | 103 | \begin_layout Plain Layout 104 | 1 105 | \end_layout 106 | 107 | \end_inset 108 | 109 | 110 | \begin_inset Newline newline 111 | \end_inset 112 | 113 | 114 | \begin_inset Flex Author Affiliation 115 | status open 116 | 117 | \begin_layout Plain Layout 118 | MaidSafe.net, 72 Templehill, Troon, South Ayrshire, Scotland, UK. 119 | KA10 6BE. 120 | \end_layout 121 | 122 | \end_inset 123 | 124 | 125 | \begin_inset Newline newline 126 | \end_inset 127 | 128 | 129 | \begin_inset Flex Author Mark 130 | status open 131 | 132 | \begin_layout Plain Layout 133 | 1 134 | \end_layout 135 | 136 | \end_inset 137 | 138 | david.irvine@maidsafe.net 139 | \end_layout 140 | 141 | \begin_layout Page headings 142 | \begin_inset Argument 1 143 | status open 144 | 145 | \begin_layout Plain Layout 146 | Irvine: Managed Authentication 147 | \end_layout 148 | 149 | \end_inset 150 | 151 | 152 | \end_layout 153 | 154 | \begin_layout Address 155 | First published September 2010. 156 | \end_layout 157 | 158 | \begin_layout Abstract 159 | Today all known access mechanisms that grant access to distributed or shared 160 | services requires a server or authoritative control in some form. 161 | This presents many issues, including security, trust and privacy to name 162 | only a few. 163 | This paper presents a system of authentication that abolishes the requirements 164 | for any user-name or password containers as lists or similar. 165 | It also negates the necessity for any server based systems as a login entity 166 | for people to connect with prior to gaining access to a system for any 167 | reason. 168 | In addition this paper allows management of user acess in a distributed 169 | network. 170 | \end_layout 171 | 172 | \begin_layout Keywords 173 | security, freedom, privacy, authentication 174 | \end_layout 175 | 176 | \begin_layout Standard 177 | \begin_inset CommandInset toc 178 | LatexCommand tableofcontents 179 | 180 | \end_inset 181 | 182 | 183 | \end_layout 184 | 185 | \begin_layout Section 186 | Introduction 187 | \end_layout 188 | 189 | \begin_layout Standard 190 | \begin_inset Flex Paragraph Start 191 | status open 192 | 193 | \begin_layout Plain Layout 194 | \begin_inset Argument 1 195 | status open 196 | 197 | \begin_layout Plain Layout 198 | A 199 | \end_layout 200 | 201 | \end_inset 202 | 203 | uthentication 204 | \end_layout 205 | 206 | \end_inset 207 | 208 | allows access to a system at a certain level or privilege. 209 | This is described in 210 | \emph on 211 | Self Authentication 212 | \emph default 213 | 214 | \begin_inset CommandInset citation 215 | LatexCommand cite 216 | key "1" 217 | 218 | \end_inset 219 | 220 | with reference to an identity created, managed and maintained in seclusion, 221 | or in another way of thinking, anonymously. 222 | In many other situations this is not beneficial; control over access and 223 | the ability to manage very large groups is required. 224 | Examples include corporate and military networks. 225 | 226 | \end_layout 227 | 228 | \begin_layout Subsection 229 | Conventions Used 230 | \end_layout 231 | 232 | \begin_layout Standard 233 | There is scope for confusion when using the term 234 | \begin_inset Quotes eld 235 | \end_inset 236 | 237 | key 238 | \begin_inset Quotes erd 239 | \end_inset 240 | 241 | , as sometimes it refers to a cryptographic key, and at other times it is 242 | in respect to the key of a DHT 243 | \begin_inset Quotes eld 244 | \end_inset 245 | 246 | key, value 247 | \begin_inset Quotes erd 248 | \end_inset 249 | 250 | pair. 251 | In order to avoid confusion, cryptographic private and public keys will 252 | be referred to as 253 | \begin_inset Formula $\mathsf{K_{priv}}$ 254 | \end_inset 255 | 256 | and 257 | \begin_inset Formula $\mathsf{K_{pub}}$ 258 | \end_inset 259 | 260 | respectively, and DHT keys simply as keys. 261 | \end_layout 262 | 263 | \begin_layout Itemize 264 | Node ≡ a network resource which is a process, sometimes referred to as a 265 | vault in other papers. 266 | This is the computer program that maintains the network and on its own 267 | is not very special. 268 | It is in collaboration that this Node becomes part of a very complex, sophistic 269 | ated and efficient network. 270 | \end_layout 271 | 272 | \begin_layout Itemize 273 | \begin_inset Formula $\mathsf{H}$ 274 | \end_inset 275 | 276 | ≡ Hash function such as SHA, MD5, etc. 277 | 278 | \end_layout 279 | 280 | \begin_layout Itemize 281 | \begin_inset Formula $\mathsf{PBKDF2_{[Passphrase][Salt][IterCount]}}$ 282 | \end_inset 283 | 284 | ≡ Password-Based Key Derivation Function or similar 285 | \end_layout 286 | 287 | \begin_layout Itemize 288 | \begin_inset Formula $\mathsf{XXX_{priv}}$ 289 | \end_inset 290 | 291 | , 292 | \begin_inset Formula $\mathsf{XXX_{pub}}$ 293 | \end_inset 294 | 295 | ≡ Private and public keys respectively of cryptographic key pair named 296 | 297 | \begin_inset Formula $\mathsf{XXX}$ 298 | \end_inset 299 | 300 | 301 | \end_layout 302 | 303 | \begin_layout Itemize 304 | \begin_inset Formula $\mathsf{AsymEnc_{[K_{pub}]}(Data)}$ 305 | \end_inset 306 | 307 | ≡ Asymmetrically encrypt 308 | \begin_inset Formula $\mathsf{Data}$ 309 | \end_inset 310 | 311 | using 312 | \begin_inset Formula $\mathsf{K_{pub}}$ 313 | \end_inset 314 | 315 | 316 | \end_layout 317 | 318 | \begin_layout Itemize 319 | \begin_inset Formula $\mathsf{AsymDec_{[K_{priv}]}(Data)}$ 320 | \end_inset 321 | 322 | ≡ Asymmetrically decrypt 323 | \begin_inset Formula $\mathsf{Data}$ 324 | \end_inset 325 | 326 | using 327 | \begin_inset Formula $\mathsf{K_{priv}}$ 328 | \end_inset 329 | 330 | 331 | \end_layout 332 | 333 | \begin_layout Itemize 334 | \begin_inset Formula $\mathsf{Sig{}_{[K_{priv}]}(Data)}$ 335 | \end_inset 336 | 337 | ≡ Create asymmetric signature of 338 | \begin_inset Formula $\mathsf{Data}$ 339 | \end_inset 340 | 341 | using 342 | \begin_inset Formula $\mathsf{K_{priv}}$ 343 | \end_inset 344 | 345 | 346 | \end_layout 347 | 348 | \begin_layout Itemize 349 | \begin_inset Formula $\mathsf{+}$ 350 | \end_inset 351 | 352 | ≡ Concatenation 353 | \end_layout 354 | 355 | \begin_layout Itemize 356 | \begin_inset Formula $\mathsf{STORE}$ 357 | \end_inset 358 | 359 | 360 | \begin_inset Formula $\equiv$ 361 | \end_inset 362 | 363 | Network or other key addressable storage system 364 | \end_layout 365 | 366 | \begin_layout Itemize 367 | \begin_inset Formula $\mathsf{PutV_{[Key]}(Value)}$ 368 | \end_inset 369 | 370 | ≡ Store 371 | \begin_inset Formula $\mathsf{Value}$ 372 | \end_inset 373 | 374 | under 375 | \begin_inset Formula $\mathsf{Key}$ 376 | \end_inset 377 | 378 | on 379 | \begin_inset Formula $\mathsf{STORE}$ 380 | \end_inset 381 | 382 | . 383 | This value is signed. 384 | \end_layout 385 | 386 | \begin_layout Itemize 387 | \begin_inset Formula $\mathsf{GetV_{[Key]}}$ 388 | \end_inset 389 | 390 | ≡ Retrieve 391 | \begin_inset Formula $\mathsf{Value}$ 392 | \end_inset 393 | 394 | under 395 | \begin_inset Formula $\mathsf{Key}$ 396 | \end_inset 397 | 398 | on 399 | \begin_inset Formula $\mathsf{STORE}$ 400 | \end_inset 401 | 402 | . 403 | This value is signed. 404 | \end_layout 405 | 406 | \begin_layout Itemize 407 | \begin_inset Formula $\mathsf{DelV_{[Key]}(Value)}$ 408 | \end_inset 409 | 410 | ≡ Delete 411 | \begin_inset Formula $\mathsf{Value}$ 412 | \end_inset 413 | 414 | under 415 | \begin_inset Formula $\mathsf{Key}$ 416 | \end_inset 417 | 418 | on 419 | \begin_inset Formula $\mathsf{STORE}$ 420 | \end_inset 421 | 422 | . 423 | This value is signed. 424 | \end_layout 425 | 426 | \begin_layout Section 427 | Outline 428 | \end_layout 429 | 430 | \begin_layout Subsection 431 | Creation of an Account 432 | \begin_inset CommandInset label 433 | LatexCommand label 434 | name "sub:Creation-of-an" 435 | 436 | \end_inset 437 | 438 | 439 | \end_layout 440 | 441 | \begin_layout Standard 442 | Here we will assume a 443 | \begin_inset Formula $\mathsf{User}$ 444 | \end_inset 445 | 446 | who is a member of an organisation named 447 | \begin_inset Quotes eld 448 | \end_inset 449 | 450 | 451 | \begin_inset Formula $\mathsf{Org}$ 452 | \end_inset 453 | 454 | 455 | \begin_inset Quotes erd 456 | \end_inset 457 | 458 | which has an ID on the system named 459 | \begin_inset Formula $\mathsf{ID_{Org}}$ 460 | \end_inset 461 | 462 | and a 463 | \begin_inset Formula $\mathsf{Manager}$ 464 | \end_inset 465 | 466 | with administator privileges. 467 | There are two inputs required by 468 | \begin_inset Formula $\mathsf{User}$ 469 | \end_inset 470 | 471 | : user-name 472 | \begin_inset Formula $\mathsf{U}$ 473 | \end_inset 474 | 475 | , and password 476 | \begin_inset Formula $\mathsf{W}$ 477 | \end_inset 478 | 479 | . 480 | A salt 481 | \begin_inset Formula $\mathsf{S}$ 482 | \end_inset 483 | 484 | is also derived (in a repeatable way) from 485 | \begin_inset Formula $\mathsf{U}$ 486 | \end_inset 487 | 488 | and 489 | \begin_inset Formula $\mathsf{ID_{Org}}$ 490 | \end_inset 491 | 492 | . 493 | 494 | \begin_inset Formula $\mathsf{Manager}$ 495 | \end_inset 496 | 497 | can recreate this ID at any time, but requires that 498 | \begin_inset Formula $\mathsf{User}$ 499 | \end_inset 500 | 501 | cannot alter the user-name. 502 | \end_layout 503 | 504 | \begin_layout Standard 505 | To generate a unique identifier, we hash the concatenation of the user-name 506 | and the salt, 507 | \begin_inset Formula $\mathsf{H(U+S)}$ 508 | \end_inset 509 | 510 | . 511 | 512 | \end_layout 513 | 514 | \begin_layout Standard 515 | PBKDF2 is used here to strengthen any password keys used. 516 | This is required as user-selected passwords are inevitably weak and the 517 | user may not know the user-name is also used as a password in the system. 518 | 519 | \begin_inset Formula $\mathsf{Account}$ 520 | \end_inset 521 | 522 | specifies session data, like user details or an index of references to 523 | further data. 524 | This packet is located through an Access Packet holding a random string 525 | 526 | \begin_inset Formula $\mathsf{RndStr}$ 527 | \end_inset 528 | 529 | . 530 | 531 | \end_layout 532 | 533 | \begin_layout Standard 534 | It is important to note that all packets in this process are signed by two 535 | seperate IDs called 536 | \begin_inset Formula $\mathsf{MID_{User}}$ 537 | \end_inset 538 | 539 | and 540 | \begin_inset Formula $\mathsf{TMID_{User}}$ 541 | \end_inset 542 | 543 | which are created as described in 544 | \begin_inset CommandInset citation 545 | LatexCommand cite 546 | key "3" 547 | 548 | \end_inset 549 | 550 | . 551 | These packets are in turn signed by 552 | \begin_inset Formula $\mathsf{Manager}$ 553 | \end_inset 554 | 555 | who keeps a copy of the IDs. 556 | In this way 557 | \begin_inset Formula $\mathsf{Manager}$ 558 | \end_inset 559 | 560 | can find the user's ID packets and delete them after deleting the data 561 | pointed to by the 562 | \begin_inset Formula $\mathsf{TMID_{User}}$ 563 | \end_inset 564 | 565 | to revoke access to the system. 566 | 567 | \end_layout 568 | 569 | \begin_layout Enumerate 570 | \begin_inset Formula $\mathsf{GetV_{[H(U+S)]}\equiv False}$ 571 | \end_inset 572 | 573 | (Ensure uniqueness) 574 | \end_layout 575 | 576 | \begin_layout Enumerate 577 | Generate random string 578 | \begin_inset Formula $\mathsf{RndStr}$ 579 | \end_inset 580 | 581 | 582 | \end_layout 583 | 584 | \begin_layout Enumerate 585 | \begin_inset Formula $\mathsf{PutV_{[H(U+S)]}\left(SymEnc_{[PBKDF2_{[U][S]}]}(RndStr)\right)}$ 586 | \end_inset 587 | 588 | (Store Access Packet) 589 | \end_layout 590 | 591 | \begin_layout Enumerate 592 | \begin_inset Formula $\mathsf{PutV_{[H(U+S+RndStr)]}\left(SymEnc_{[PBKDF2_{[W][S]}]}(Account)\right)}$ 593 | \end_inset 594 | 595 | (Store Account Packet) 596 | \end_layout 597 | 598 | \begin_layout Subsection 599 | Login / Load Session Process 600 | \begin_inset CommandInset label 601 | LatexCommand label 602 | name "sub:Login-to-a" 603 | 604 | \end_inset 605 | 606 | 607 | \end_layout 608 | 609 | \begin_layout Enumerate 610 | \begin_inset Formula $\mathsf{SymDec_{[PBKDF2_{[U][S]}]}\left(GetV_{[H(U+S)]}\right)\equiv RndStr}$ 611 | \end_inset 612 | 613 | 614 | \end_layout 615 | 616 | \begin_layout Enumerate 617 | \begin_inset Formula $\mathsf{SymDec_{[PBKDF2_{[W][S]}]}(GetV_{[H(U+S+RndStr)]})\equiv Account}$ 618 | \end_inset 619 | 620 | 621 | \end_layout 622 | 623 | \begin_layout Standard 624 | For the following operation, 625 | \begin_inset Formula $\mathsf{RndStr}$ 626 | \end_inset 627 | 628 | should be kept locally for the duration of the session. 629 | \end_layout 630 | 631 | \begin_layout Subsection 632 | Logout / Save Session Process 633 | \end_layout 634 | 635 | \begin_layout Enumerate 636 | Generate new random string 637 | \begin_inset Formula $\mathsf{RndStr_{new}}$ 638 | \end_inset 639 | 640 | 641 | \end_layout 642 | 643 | \begin_layout Enumerate 644 | \begin_inset Formula $\mathsf{PutV_{[H(U+S+RndStr_{new})]}\left(SymEnc_{[PBKDF2_{[W][S]}]}(Account)\right)}$ 645 | \end_inset 646 | 647 | (Store new Account Packet) 648 | \end_layout 649 | 650 | \begin_layout Enumerate 651 | \begin_inset Formula $\mathsf{PutV_{[H(U+S)]}\left(SymEnc_{[PBKDF2_{[U][S]}]}(RndStr_{new})\right)}$ 652 | \end_inset 653 | 654 | (Update Access Packet) 655 | \end_layout 656 | 657 | \begin_layout Enumerate 658 | \begin_inset Formula $\mathsf{DelV_{[H(U+S+RndStr)]}(OldAccount)}$ 659 | \end_inset 660 | 661 | (Delete old Account Packet) 662 | \end_layout 663 | 664 | \begin_layout Subsection 665 | Fallback Account Packets 666 | \end_layout 667 | 668 | \begin_layout Standard 669 | The previous sections outlined the basic system of authentication. 670 | However, this can be extended for safety reasons. 671 | As with any system, the serialisation and store operation of the account 672 | data can fail for any reason, resulting in unreadable data upon retrieval. 673 | This would be catastrophic as access to the user's data on the system may 674 | be rendered impossible. 675 | To reduce any such risk, a fallback copy of an Account Packet (and its 676 | Access Packet) is kept, to allow reverting to the previous version in case 677 | the current version can't be restored or turns out to have been generated 678 | erroneously. 679 | Like the main Access Packet, the fallback Access Packet contains an (encrypted) 680 | random string, designated 681 | \begin_inset Formula $\mathsf{RndStr_{fallback}}$ 682 | \end_inset 683 | 684 | . 685 | \end_layout 686 | 687 | \begin_layout Subsubsection 688 | Updated Account Creation Process 689 | \end_layout 690 | 691 | \begin_layout Enumerate 692 | \begin_inset Formula $\mathsf{GetV_{[H(U+S)]}\equiv False}$ 693 | \end_inset 694 | 695 | (Ensure uniqueness of Access Packet) 696 | \end_layout 697 | 698 | \begin_layout Enumerate 699 | \begin_inset Formula $\mathsf{GetV_{[H(U+(S-1))]}\equiv False}$ 700 | \end_inset 701 | 702 | (Ensure uniqueness of fallback Access Packet) 703 | \end_layout 704 | 705 | \begin_layout Enumerate 706 | Generate random string 707 | \begin_inset Formula $\mathsf{RndStr}$ 708 | \end_inset 709 | 710 | and copy 711 | \begin_inset Formula $\mathsf{RndStr\rightarrow RndStr_{fallback}}$ 712 | \end_inset 713 | 714 | 715 | \end_layout 716 | 717 | \begin_layout Enumerate 718 | \begin_inset Formula $\mathsf{PutV_{[H(U+S)]}\left(SymEnc_{[PBKDF2_{[U][S]}]}(RndStr)\right)}$ 719 | \end_inset 720 | 721 | 722 | \end_layout 723 | 724 | \begin_layout Enumerate 725 | \begin_inset Formula $\mathsf{PutV_{[H(U+(S-1)]}\left(SymEnc_{[PBKDF2_{[U][S-1]}]}(RndStr)\right)}$ 726 | \end_inset 727 | 728 | 729 | \end_layout 730 | 731 | \begin_layout Enumerate 732 | \begin_inset Formula $\mathsf{PutV_{[H(U+S+RndStr)]}\left(SymEnc_{[PBKDF2_{[W][S]}]}(Account)\right)}$ 733 | \end_inset 734 | 735 | 736 | \end_layout 737 | 738 | \begin_layout Standard 739 | In this case, the random strings in the Access Packets are the same, thus 740 | point to the same (unique) Account Packet. 741 | Fallback packets are only kept once the Account Packet is updated. 742 | \end_layout 743 | 744 | \begin_layout Subsubsection 745 | Updated Login Process 746 | \end_layout 747 | 748 | \begin_layout Enumerate 749 | if ( 750 | \begin_inset Formula $\mathsf{GetV_{[H(U+S)]}\equiv EncRndStr}$ 751 | \end_inset 752 | 753 | ) 754 | \end_layout 755 | 756 | \begin_deeper 757 | \begin_layout Enumerate 758 | \begin_inset Formula $\mathsf{SymDec_{[PBKDF2_{[U][S]}]}(EncRndStr)\equiv RndStr}$ 759 | \end_inset 760 | 761 | 762 | \end_layout 763 | 764 | \begin_layout Enumerate 765 | \begin_inset Formula $\mathsf{SymDec_{[PBKDF2_{[W][S]}]}\left(GetV_{[H(U+S+RndStr)]}\right)\equiv}$ 766 | \end_inset 767 | 768 | 769 | \begin_inset Newline newline 770 | \end_inset 771 | 772 | 773 | \begin_inset Formula $\mathsf{Account}$ 774 | \end_inset 775 | 776 | 777 | \end_layout 778 | 779 | \end_deeper 780 | \begin_layout Enumerate 781 | else (or if previous attempt failed) 782 | \end_layout 783 | 784 | \begin_deeper 785 | \begin_layout Enumerate 786 | \begin_inset Formula $\mathsf{GetV_{[H(U+(S-1))]}\equiv EncRndStr_{fallback}}$ 787 | \end_inset 788 | 789 | 790 | \end_layout 791 | 792 | \begin_layout Enumerate 793 | \begin_inset Formula $\mathsf{SymDec_{[PBKDF2_{[U][S-1]}]}(EncRndStr_{fallback})\equiv}$ 794 | \end_inset 795 | 796 | 797 | \begin_inset Newline newline 798 | \end_inset 799 | 800 | 801 | \begin_inset Formula $\mathsf{RndStr_{fallback}}$ 802 | \end_inset 803 | 804 | 805 | \end_layout 806 | 807 | \begin_layout Enumerate 808 | \begin_inset Formula $\mathsf{SymDec_{[PBKDF2_{[W][S-1]}]}\left(GetV_{[H(U+S+RndStr_{fallback})]}\right)}$ 809 | \end_inset 810 | 811 | 812 | \begin_inset Newline newline 813 | \end_inset 814 | 815 | 816 | \begin_inset Formula $\mathsf{\equiv Account_{fallback}}$ 817 | \end_inset 818 | 819 | 820 | \end_layout 821 | 822 | \end_deeper 823 | \begin_layout Subsubsection 824 | Updated Logout / Save Session Process 825 | \end_layout 826 | 827 | \begin_layout Standard 828 | Designate existing 829 | \begin_inset Formula $\mathsf{RndStr}$ 830 | \end_inset 831 | 832 | as 833 | \begin_inset Formula $\mathsf{RndStr_{old}}$ 834 | \end_inset 835 | 836 | and 837 | \begin_inset Formula $\mathsf{RndStr_{fallback}}$ 838 | \end_inset 839 | 840 | as 841 | \begin_inset Formula $\mathsf{RndStr_{fallback\,old}}$ 842 | \end_inset 843 | 844 | 845 | \end_layout 846 | 847 | \begin_layout Enumerate 848 | Generate new random string 849 | \begin_inset Formula $\mathsf{RndStr_{new}}$ 850 | \end_inset 851 | 852 | 853 | \end_layout 854 | 855 | \begin_layout Enumerate 856 | \begin_inset Formula $\mathsf{PutV_{[H(U+S)]}\left(SymEnc_{[PBKDF2_{[U][S]}]}(RndStr_{new})\right)}$ 857 | \end_inset 858 | 859 | (Update Access Packet with new random string) 860 | \end_layout 861 | 862 | \begin_layout Enumerate 863 | \begin_inset Formula $\mathsf{PutV_{[H(U+(S-1)]}\left(SymEnc_{[PBKDF2_{[U][S-1]}]}(RndStr_{old})\right)}$ 864 | \end_inset 865 | 866 | (Update fallback Access Packet with old random string) 867 | \end_layout 868 | 869 | \begin_layout Enumerate 870 | \begin_inset Formula $\mathsf{PutV_{[H(U+S+RndStr_{new})]}\left(SymEnc_{[PBKDF2_{[W][S]}]}(Account)\right)}$ 871 | \end_inset 872 | 873 | (Update Account Packet using new random string) 874 | \end_layout 875 | 876 | \begin_layout Enumerate 877 | \begin_inset Formula $\mathsf{DelV_{[H(U+S+RndStr_{fallback\,old})]}(Account_{fallback\,old})}$ 878 | \end_inset 879 | 880 | (Delete old Account Packet) 881 | \end_layout 882 | 883 | \begin_layout Standard 884 | The previous Account Packet remains untouched. 885 | Instead the fallback Access Packet is redirected to it and the normal Access 886 | Packet points to the new Account Packet. 887 | The previous fallback Account Packet is deleted. 888 | This is a security measure to hinder slow brute-force attacks on decrypting 889 | the Access Packet, which by the time the clear-text random string is obtained 890 | would make it obsolete. 891 | \end_layout 892 | 893 | \begin_layout Subsection 894 | Creating a User Identity (publically broadcastable identity) 895 | \end_layout 896 | 897 | \begin_layout Enumerate 898 | \begin_inset Formula $\mathsf{Manager}$ 899 | \end_inset 900 | 901 | creates 902 | \begin_inset Formula $\mathsf{USER_{priv}}$ 903 | \end_inset 904 | 905 | and 906 | \begin_inset Formula $\mathsf{USER_{pub}}$ 907 | \end_inset 908 | 909 | 910 | \end_layout 911 | 912 | \begin_layout Enumerate 913 | \begin_inset Formula $\mathsf{H(USER_{pub}\,+Sig{}_{MANAGER_{priv}})}$ 914 | \end_inset 915 | 916 | is stored on 917 | \begin_inset Formula $\mathsf{STORE}$ 918 | \end_inset 919 | 920 | ; this also will be the ID for 921 | \begin_inset Formula $\mathsf{User}$ 922 | \end_inset 923 | 924 | . 925 | \end_layout 926 | 927 | \begin_layout Enumerate 928 | \begin_inset Formula $\mathsf{Manager}$ 929 | \end_inset 930 | 931 | creates a 932 | \begin_inset Formula $\mathsf{H(User@Org+Sig{}_{MANAGER_{priv}})}$ 933 | \end_inset 934 | 935 | packet in 936 | \begin_inset Formula $\mathsf{STORE}$ 937 | \end_inset 938 | 939 | (this is the contact address of 940 | \begin_inset Formula $\mathsf{User}$ 941 | \end_inset 942 | 943 | when connected with 944 | \begin_inset Formula $\mathsf{Org}$ 945 | \end_inset 946 | 947 | ); again this is revokable by 948 | \begin_inset Formula $\mathsf{Manager}$ 949 | \end_inset 950 | 951 | . 952 | \end_layout 953 | 954 | \begin_layout Standard 955 | It should be emphasised that any communcation from 956 | \begin_inset Formula $\mathsf{User@Org}$ 957 | \end_inset 958 | 959 | should require a check of 960 | \begin_inset Formula $\mathsf{STORE}$ 961 | \end_inset 962 | 963 | to ensure the ID is still valid; therefore there is no possibility of simply 964 | passing the information in a message. 965 | This may involve a recursive check on 966 | \begin_inset Formula $\mathsf{Manager}$ 967 | \end_inset 968 | 969 | 's keys to get to the root 970 | \begin_inset Formula $\mathsf{Org}$ 971 | \end_inset 972 | 973 | packet which is the packet signed by the 974 | \begin_inset Formula $\mathsf{Org}$ 975 | \end_inset 976 | 977 | key itself (first user). 978 | This is identified as being signed by the 979 | \begin_inset Formula $\mathsf{ID_{Org}}$ 980 | \end_inset 981 | 982 | packet. 983 | This ID will be published in many places and found in 984 | \begin_inset Formula $\mathsf{STORE}$ 985 | \end_inset 986 | 987 | as a packet simply called 988 | \begin_inset Formula $\mathsf{Org}$ 989 | \end_inset 990 | 991 | and signed by 992 | \begin_inset Formula $\mathsf{Org}$ 993 | \end_inset 994 | 995 | (self-signed original packet). 996 | \end_layout 997 | 998 | \begin_layout Subsection 999 | Creating User Root Directory 1000 | \end_layout 1001 | 1002 | \begin_layout Enumerate 1003 | \begin_inset Formula $\mathsf{Manager}$ 1004 | \end_inset 1005 | 1006 | creates a parent directory for 1007 | \begin_inset Formula $\mathsf{User}$ 1008 | \end_inset 1009 | 1010 | as per 1011 | \begin_inset CommandInset citation 1012 | LatexCommand cite 1013 | key "6" 1014 | 1015 | \end_inset 1016 | 1017 | . 1018 | \end_layout 1019 | 1020 | \begin_layout Enumerate 1021 | \begin_inset Formula $\mathsf{Manager}$ 1022 | \end_inset 1023 | 1024 | adds a child directory entry to the parent. 1025 | 1026 | \end_layout 1027 | 1028 | \begin_layout Enumerate 1029 | This child directory entry is the organisation drive. 1030 | 1031 | \end_layout 1032 | 1033 | \begin_layout Standard 1034 | In this manner the user has the ability to alter the child directory and 1035 | add in his or her own files. 1036 | This is the root drive of 1037 | \begin_inset Formula $\mathsf{User}$ 1038 | \end_inset 1039 | 1040 | , and personal information can be stored there. 1041 | 1042 | \begin_inset Formula $\mathsf{Manager}$ 1043 | \end_inset 1044 | 1045 | though, has access to this as he or she knows the ID and the passkey to 1046 | it. 1047 | In addition, as 1048 | \begin_inset Formula $\mathsf{Manager}$ 1049 | \end_inset 1050 | 1051 | stores and signs the parent directory, 1052 | \begin_inset Formula $\mathsf{User}$ 1053 | \end_inset 1054 | 1055 | cannot alter this or change passwords. 1056 | \end_layout 1057 | 1058 | \begin_layout Subsection 1059 | BootStrapping the Network 1060 | \end_layout 1061 | 1062 | \begin_layout Standard 1063 | An initial ID is required to bootstrap the network of ID's in the store. 1064 | This ID is created as described in 1065 | \begin_inset CommandInset citation 1066 | LatexCommand cite 1067 | key "3" 1068 | 1069 | \end_inset 1070 | 1071 | as a 1072 | \emph on 1073 | selectable ID 1074 | \emph default 1075 | 1076 | \begin_inset Foot 1077 | status open 1078 | 1079 | \begin_layout Plain Layout 1080 | This is the major claim in the managed distributed authentication patent 1081 | \end_layout 1082 | 1083 | \end_inset 1084 | 1085 | . 1086 | This ID may be countersigned by another party, such as the company who 1087 | supplies such a system to a customer 1088 | \begin_inset Foot 1089 | status open 1090 | 1091 | \begin_layout Plain Layout 1092 | This is the check that MS SAN uses to ensure license payments are made 1093 | \end_layout 1094 | 1095 | \end_inset 1096 | 1097 | , assuming that supplier is trusted. 1098 | In the case of a software supplier, then the suppliers ID can be built 1099 | in as a trusted party. 1100 | 1101 | \end_layout 1102 | 1103 | \begin_layout Standard 1104 | This ID is then the 1105 | \emph on 1106 | root 1107 | \emph default 1108 | ID of the network, we shall refer to this as 1109 | \begin_inset Formula $\mathsf{ID_{Net}}$ 1110 | \end_inset 1111 | 1112 | . 1113 | The initial user then creates a 1114 | \begin_inset Formula $\mathsf{ID_{User@Org}}$ 1115 | \end_inset 1116 | 1117 | . 1118 | This ID is signed by the private of the ID associated with 1119 | \begin_inset Formula $\mathsf{ID_{Org}}$ 1120 | \end_inset 1121 | 1122 | . 1123 | 1124 | \end_layout 1125 | 1126 | \begin_layout Fact 1127 | All client systems accessing this network will test 1128 | \begin_inset Formula $\mathsf{ID_{User@Org}}$ 1129 | \end_inset 1130 | 1131 | is signed by the ID associated with 1132 | \begin_inset Formula $\mathsf{ID_{Org}}$ 1133 | \end_inset 1134 | 1135 | . 1136 | This is to prevent fraud as any attacker or ID wishing to fraudulently 1137 | claim they are a valid 1138 | \begin_inset Formula $\mathsf{ID_{something@Org}}$ 1139 | \end_inset 1140 | 1141 | would not have access to the ID associated with 1142 | \begin_inset Formula $\mathsf{ID_{Org}}$ 1143 | \end_inset 1144 | 1145 | . 1146 | 1147 | \end_layout 1148 | 1149 | \begin_layout Remark 1150 | This is essential as many nodes or network entities may create a 1151 | \begin_inset Formula $\mathsf{ID_{something@Org}}$ 1152 | \end_inset 1153 | 1154 | which cannot and should not be prevented, however only one will have the 1155 | private key required to validate this ID. 1156 | This ensures mathematical correctness in testing a proposition such as 1157 | 1158 | \begin_inset Formula $\mathsf{ID_{something@Org}}$ 1159 | \end_inset 1160 | 1161 | which ensures that the security algorithm is intact and not dependent on 1162 | obfuscation or obscurity of code or similar. 1163 | \end_layout 1164 | 1165 | \begin_layout Remark 1166 | To check an ID then there is a possibility that the ID who signs the 1167 | \begin_inset Formula $\mathsf{ID_{something@Org}}$ 1168 | \end_inset 1169 | 1170 | is in fact not 1171 | \begin_inset Formula $\mathsf{ID_{Org}}$ 1172 | \end_inset 1173 | 1174 | but another 1175 | \begin_inset Formula $\mathsf{ID_{something@Org}}$ 1176 | \end_inset 1177 | 1178 | (this shoudl be a manager of teh first ID checked). 1179 | This requires a recursive check until 1180 | \begin_inset Formula $\mathsf{ID_{Org}}$ 1181 | \end_inset 1182 | 1183 | is reached, otherwise the 1184 | \begin_inset Formula $\mathsf{ID_{something@Org}}$ 1185 | \end_inset 1186 | 1187 | is fraudulent and not as expected. 1188 | \end_layout 1189 | 1190 | \begin_layout Remark 1191 | On confirming 1192 | \begin_inset Formula $\mathsf{ID_{something@Org}}$ 1193 | \end_inset 1194 | 1195 | it is assumed that the recipient will maintain the ID associated and possibly 1196 | sign a validated record and maintain this somehow 1197 | \begin_inset Foot 1198 | status open 1199 | 1200 | \begin_layout Plain Layout 1201 | In MS SAN and MaidSafe this is stored in the data atlas. 1202 | \end_layout 1203 | 1204 | \end_inset 1205 | 1206 | . 1207 | 1208 | \end_layout 1209 | 1210 | \begin_layout Subsection 1211 | Banning User from Network 1212 | \end_layout 1213 | 1214 | \begin_layout Standard 1215 | As 1216 | \begin_inset Formula $\mathsf{ID_{User}}$ 1217 | \end_inset 1218 | 1219 | is signed by 1220 | \begin_inset Formula $\mathsf{Manager}$ 1221 | \end_inset 1222 | 1223 | , then 1224 | \begin_inset Formula $\mathsf{Manager}$ 1225 | \end_inset 1226 | 1227 | can delete this packet. 1228 | This renders 1229 | \begin_inset Formula $\mathsf{User}$ 1230 | \end_inset 1231 | 1232 | 's access key useless and all access revoked. 1233 | To ensure this is absolute, the message type sent cannot be used to verify 1234 | an ID (by sending public key plus signature in a packet for hashing by 1235 | the recipient) and instead a 1236 | \begin_inset Formula $\mathsf{STORE}$ 1237 | \end_inset 1238 | 1239 | lookup for a valid ID has to happen every time. 1240 | 1241 | \end_layout 1242 | 1243 | \begin_layout Standard 1244 | In addition the user's ability to access any data from the network is revoked 1245 | with the deletions of the 1246 | \begin_inset Formula $\mathsf{MID_{User}}$ 1247 | \end_inset 1248 | 1249 | , 1250 | \begin_inset Formula $\mathsf{SMID_{User}}$ 1251 | \end_inset 1252 | 1253 | and 1254 | \begin_inset Formula $\mathsf{TMID_{User}}$ 1255 | \end_inset 1256 | 1257 | packets. 1258 | 1259 | \end_layout 1260 | 1261 | \begin_layout Subsection 1262 | N Plus P Key Sharing 1263 | \end_layout 1264 | 1265 | \begin_layout Standard 1266 | As the initial node has an extreme amount of power and no equal to absorb 1267 | this power should that identity become unstable for whatever reason (such 1268 | as retiring, leaving or simply becoming hostile) then a mechanism must 1269 | be put into place to ensure this ID is not stand alone. 1270 | 1271 | \end_layout 1272 | 1273 | \begin_layout Standard 1274 | The answer is n+p 1275 | \begin_inset Foot 1276 | status collapsed 1277 | 1278 | \begin_layout Plain Layout 1279 | There are many methods for achieving this, Shamir's scheme is as good as 1280 | any and an implemention of this is availiable in many crypto libraries 1281 | such as cryptopp. 1282 | \end_layout 1283 | 1284 | \end_inset 1285 | 1286 | key sharing scheme where a user can select 1287 | \begin_inset Formula $\mathsf{p}$ 1288 | \end_inset 1289 | 1290 | users to share his key with. 1291 | If there is ever an issue, then 1292 | \begin_inset Formula $\mathsf{n}$ 1293 | \end_inset 1294 | 1295 | of these users are all that are required to recreate the key. 1296 | \end_layout 1297 | 1298 | \begin_layout Section 1299 | Hardened security mode 1300 | \end_layout 1301 | 1302 | \begin_layout Standard 1303 | As this system allows access to a distributed file-system such as 1304 | \begin_inset CommandInset citation 1305 | LatexCommand cite 1306 | key "6" 1307 | 1308 | \end_inset 1309 | 1310 | we can achieve a level of security unknown until now. 1311 | This file-system can be presented through a File System In Userspace (FUSE) 1312 | format (or through a system that can reconstitute files in real time and 1313 | display them, such as the light versions of LifeStuff [tm] and mssan), 1314 | thereby appearing like a hard disk to the operating system. 1315 | On this disk can run any system that runs on a normal hard disk (with the 1316 | exception of extreme fast transaction services 1317 | \begin_inset Foot 1318 | status collapsed 1319 | 1320 | \begin_layout Plain Layout 1321 | This is only a current limitation and can be overcome even today with a 1322 | NOSQL policy 1323 | \end_layout 1324 | 1325 | \end_inset 1326 | 1327 | ). 1328 | With this being the case, even applications can be installed on the disk 1329 | as shares the users can access and presented through a menu system as one 1330 | would normally expect to see on a computer. 1331 | 1332 | \end_layout 1333 | 1334 | \begin_layout Standard 1335 | If such systems were built that had no external access capabilities (USB, 1336 | FireWire, Bluetooth etc.) and had a read only file system (which is possible 1337 | as this system does not require disk access at all) then a extreme level 1338 | of security could be obtained. 1339 | All applications managed as well as virtual disk access with no virus capabilit 1340 | y or no way to write to the hard disk (no trojans) and no requirement for 1341 | a firewall or intrusion detection system as there is no hard disk. 1342 | 1343 | \end_layout 1344 | 1345 | \begin_layout Standard 1346 | Such system would find use in military, financial institutes and organisations 1347 | requiring 100% control and protection of internal data. 1348 | 1349 | \end_layout 1350 | 1351 | \begin_layout Subsection 1352 | Multi factor authentication 1353 | \end_layout 1354 | 1355 | \begin_layout Standard 1356 | In some situations there may be a requirement to present more than one method 1357 | of authentication. 1358 | As described this system presented makes use of a User name, PIN and password 1359 | combination, which may or may not require the PIN to be entered. 1360 | This does not however provide security of theft of the user entered components, 1361 | i.e. 1362 | via a key logger, over the shoulder attack or similar. 1363 | Another factor is required. 1364 | 1365 | \end_layout 1366 | 1367 | \begin_layout Standard 1368 | Such a system may be a mobile device such as a phone with a unique serial 1369 | number (SIM card) that can be registered to the ID in question. 1370 | Therefore an organisation may provide access to certain ID's for certain 1371 | privileges, there may also be a requirement for a further check. 1372 | \end_layout 1373 | 1374 | \begin_layout Standard 1375 | In this case a simple solution would be to map the user ID to a telephone 1376 | number or similar and when access is requested and validated via the encryption 1377 | keys, a message can be sent to the device. 1378 | The application at login or access screen will await a code (encrypted 1379 | with the public key of the ID presented, to prevent man in the middle attacks) 1380 | to be sent from the organisation to the device. 1381 | On receipt the application will send this pass-phrase back to the organisation, 1382 | thereby validating against something the user has (phone) as well as what 1383 | he knows (user name/password). 1384 | \end_layout 1385 | 1386 | \begin_layout Section 1387 | Conclusions 1388 | \end_layout 1389 | 1390 | \begin_layout Standard 1391 | This paper presents a mechanism for managed access to organisations networks 1392 | that may exist completely distributed. 1393 | From this point forward there is occasion for many additional features 1394 | to be added to this system. 1395 | If combined with a DHT 1396 | \begin_inset CommandInset citation 1397 | LatexCommand cite 1398 | key "5" 1399 | 1400 | \end_inset 1401 | 1402 | , distributed databases 1403 | \begin_inset CommandInset citation 1404 | LatexCommand cite 1405 | key "6" 1406 | 1407 | \end_inset 1408 | 1409 | and a network such as the maidsafe network 1410 | \begin_inset CommandInset citation 1411 | LatexCommand cite 1412 | key "4" 1413 | 1414 | \end_inset 1415 | 1416 | , then this could represent a new paradigm for corporate computing. 1417 | This would enable remote working, network scalability and security at a 1418 | level never seen previously. 1419 | 1420 | \end_layout 1421 | 1422 | \begin_layout Section 1423 | Future Works 1424 | \end_layout 1425 | 1426 | \begin_layout Subsection 1427 | Time Based Obfuscation 1428 | \end_layout 1429 | 1430 | \begin_layout Standard 1431 | In the previous sections a system of authentication was detailed which is 1432 | very effective. 1433 | A potential failure point, however, may be the Access Packets, as those 1434 | are never altering their location (key) and can pose a target for any attacker 1435 | who is monitoring data traffic between the user and the system. 1436 | \end_layout 1437 | 1438 | \begin_layout Standard 1439 | To remove this weakness, a predictably altering piece of data can be introduced, 1440 | such as time (e.g. 1441 | week number, day of year or similar). 1442 | In this case in 1443 | \begin_inset CommandInset ref 1444 | LatexCommand ref 1445 | reference "sub:Login-to-a" 1446 | 1447 | \end_inset 1448 | 1449 | the 1450 | \begin_inset Formula $\mathsf{GetV}$ 1451 | \end_inset 1452 | 1453 | call would be iterative, starting at the current time slot and decrementing 1454 | until it returns with a value. 1455 | Access Packets at 1456 | \begin_inset Quotes eld 1457 | \end_inset 1458 | 1459 | outdated 1460 | \begin_inset Quotes erd 1461 | \end_inset 1462 | 1463 | locations would be deleted on detection, and updates always stored in the 1464 | current location, resulting in regularly 1465 | \begin_inset Quotes eld 1466 | \end_inset 1467 | 1468 | moving 1469 | \begin_inset Quotes erd 1470 | \end_inset 1471 | 1472 | packets. 1473 | \end_layout 1474 | 1475 | \begin_layout Bibliography 1476 | \begin_inset CommandInset bibitem 1477 | LatexCommand bibitem 1478 | label "1" 1479 | key "1" 1480 | 1481 | \end_inset 1482 | 1483 | David Irvine, Self-Authentication, david.irvine@maidsafe.net 1484 | \end_layout 1485 | 1486 | \begin_layout Bibliography 1487 | \begin_inset CommandInset bibitem 1488 | LatexCommand bibitem 1489 | label "2" 1490 | key "2" 1491 | 1492 | \end_inset 1493 | 1494 | David Irvine, Self Encrypting Data, david.irvine@maidsafe.net 1495 | \end_layout 1496 | 1497 | \begin_layout Bibliography 1498 | \begin_inset CommandInset bibitem 1499 | LatexCommand bibitem 1500 | label "3" 1501 | key "3" 1502 | 1503 | \end_inset 1504 | 1505 | David Irvine, "Peer to Peer" Public Key Infrastructure, david.irvine@maidsafe.net 1506 | \end_layout 1507 | 1508 | \begin_layout Bibliography 1509 | \begin_inset CommandInset bibitem 1510 | LatexCommand bibitem 1511 | label "4" 1512 | key "4" 1513 | 1514 | \end_inset 1515 | 1516 | David Irvine, maidsafe: A new networking paradigm , david.irvine@maidsafe.net 1517 | \end_layout 1518 | 1519 | \begin_layout Bibliography 1520 | \begin_inset CommandInset bibitem 1521 | LatexCommand bibitem 1522 | label "5" 1523 | key "5" 1524 | 1525 | \end_inset 1526 | 1527 | David Irvine, Autonomous Network, david.irvine@maidsafe.net 1528 | \end_layout 1529 | 1530 | \begin_layout Bibliography 1531 | \begin_inset CommandInset bibitem 1532 | LatexCommand bibitem 1533 | label "6" 1534 | key "6" 1535 | 1536 | \end_inset 1537 | 1538 | David Irvine, MaidSafe Distributed File System, david.irvine@maidsafe.net 1539 | \end_layout 1540 | 1541 | \begin_layout Biography without photo 1542 | \begin_inset Argument 1 1543 | status open 1544 | 1545 | \begin_layout Plain Layout 1546 | David Irvine 1547 | \end_layout 1548 | 1549 | \end_inset 1550 | 1551 | is a Scottish Engineer and innovator who has spent the last 12 years researchin 1552 | g ways to make computers function in a more efficient manner. 1553 | \end_layout 1554 | 1555 | \begin_layout Biography without photo 1556 | He is an Inventor listed on more than 20 patent submissions and was Designer 1557 | of one of the World's largest private networks (Saudi Aramco, over $300M). 1558 | He is an experienced Project Manager and has been involved in start up 1559 | businesses since 1995 and has provided business consultancy to corporates 1560 | and SMEs in many sectors. 1561 | \end_layout 1562 | 1563 | \begin_layout Biography without photo 1564 | He has presented technology at Google (Seattle), British Computer Society 1565 | (Christmas Lecture) and many others. 1566 | \end_layout 1567 | 1568 | \begin_layout Biography without photo 1569 | He has spent many years as a lifeboat Helmsman and is a keen sailor when 1570 | time permits. 1571 | \end_layout 1572 | 1573 | \end_body 1574 | \end_document 1575 | -------------------------------------------------------------------------------- /technical_papers/Safecoin.lyx: -------------------------------------------------------------------------------- 1 | #LyX 2.1 created this file. For more info see http://www.lyx.org/ 2 | \lyxformat 474 3 | \begin_document 4 | \begin_header 5 | \textclass article 6 | \begin_preamble 7 | \usepackage[hyphens]{url} 8 | \usepackage{hyperref} 9 | \end_preamble 10 | \use_default_options true 11 | \maintain_unincluded_children false 12 | \language english 13 | \language_package default 14 | \inputencoding auto 15 | \fontencoding global 16 | \font_roman default 17 | \font_sans default 18 | \font_typewriter default 19 | \font_math auto 20 | \font_default_family default 21 | \use_non_tex_fonts false 22 | \font_sc false 23 | \font_osf false 24 | \font_sf_scale 100 25 | \font_tt_scale 100 26 | \graphics default 27 | \default_output_format default 28 | \output_sync 0 29 | \bibtex_command default 30 | \index_command default 31 | \paperfontsize default 32 | \spacing single 33 | \use_hyperref false 34 | \papersize custom 35 | \use_geometry false 36 | \use_package amsmath 1 37 | \use_package amssymb 1 38 | \use_package cancel 1 39 | \use_package esint 1 40 | \use_package mathdots 1 41 | \use_package mathtools 1 42 | \use_package mhchem 1 43 | \use_package stackrel 1 44 | \use_package stmaryrd 1 45 | \use_package undertilde 1 46 | \cite_engine natbib 47 | \cite_engine_type numerical 48 | \biblio_style plain 49 | \use_bibtopic true 50 | \use_indices false 51 | \paperorientation portrait 52 | \suppress_date false 53 | \justification false 54 | \use_refstyle 1 55 | \index Index 56 | \shortcut idx 57 | \color #008000 58 | \end_index 59 | \secnumdepth 3 60 | \tocdepth 3 61 | \paragraph_separation indent 62 | \paragraph_indentation default 63 | \quotes_language english 64 | \papercolumns 2 65 | \papersides 1 66 | \paperpagestyle default 67 | \tracking_changes false 68 | \output_changes false 69 | \html_math_output 0 70 | \html_css_as_file 0 71 | \html_be_strict false 72 | \end_header 73 | 74 | \begin_body 75 | 76 | \begin_layout Title 77 | Safecoin: The Decentralised Network Token 78 | \end_layout 79 | 80 | \begin_layout Author 81 | Nick Lambert, Qi Ma and David Irvine 82 | \end_layout 83 | 84 | \begin_layout Date 85 | January 2015 86 | \end_layout 87 | 88 | \begin_layout Abstract 89 | There are many examples of tokens (coins) being an effective mechanism for 90 | incentivising behaviour. 91 | These cases demonstrate the benefits of tokens in a wide variety of settings, 92 | but there is evidence that they are effective within a computer networking 93 | environment. 94 | This paper attempts to explain the reasoning behind safecoin, the digital 95 | token of the SAFE Network, a decentralised data and communications network. 96 | It is anticipated that the introduction of safecoin will incentivise behaviour 97 | that ensures the long term health of the network for all its users. 98 | \end_layout 99 | 100 | \begin_layout Section 101 | Token Economies 102 | \end_layout 103 | 104 | \begin_layout Standard 105 | The use of tokens to incentivise behaviour is not novel and their use in 106 | multiple settings prove their utility. 107 | For example, token economy systems have been used to influence and guide 108 | behaviour in animals, prison populations, the military and education 109 | \begin_inset CommandInset citation 110 | LatexCommand citep 111 | key "2" 112 | 113 | \end_inset 114 | 115 | . 116 | Doll et al. 117 | (2013) describe the nature of a token economy: 118 | \end_layout 119 | 120 | \begin_layout Quotation 121 | \begin_inset Quotes eld 122 | \end_inset 123 | 124 | Within a token economy, tokens are most often a neutral stimulus in the 125 | form of points or tangible items that are awarded to economy participants 126 | for target behaviours. 127 | \begin_inset Quotes erd 128 | \end_inset 129 | 130 | 131 | \end_layout 132 | 133 | \begin_layout Standard 134 | In essence, tokens provide their holder with perceived economic or social 135 | benefit as a reward for acting out defined and desired actions. 136 | Bitcoin represents an excellent example of stimulating action (mining) 137 | through token reward. 138 | Its ability to eliminate double spending by harnessing the power of a distribut 139 | ed consensus network has given rise to a plethora of new digital currencies 140 | and assets. 141 | At the time of writing, there are currently 571 currencies listed on the 142 | leading cryptocurrency market capitalisation website 143 | \begin_inset CommandInset citation 144 | LatexCommand citep 145 | key "1" 146 | 147 | \end_inset 148 | 149 | . 150 | 151 | \end_layout 152 | 153 | \begin_layout Standard 154 | However, it is the Bitcoin protocol and the additional features created 155 | by so called Bitcoin 2.0 technologies that are particularly interesting. 156 | The protocol enables additional features to be incorporated into the block 157 | chain (Bitcoin’s immutable public ledger). 158 | These features include the ability for anyone to create digital assets 159 | or tokens that are cryptographically secured and inextricably tied to an 160 | ID on the network. 161 | These tokens can represent either ownership, or access to services. 162 | \end_layout 163 | 164 | \begin_layout Standard 165 | The case for using tokens within a computer network is further strengthened 166 | by technologies that were restricted from reaching their potential in the 167 | absence of any incentivisation mechanism. 168 | \end_layout 169 | 170 | \begin_layout Standard 171 | One such example is TOR, software that provides user anonymity by redirecting 172 | Internet traffic through a series of relays run by volunteers, who contribute 173 | their own computing resources to the TOR network. 174 | Current metrics from the network report that around 6500 relays are in 175 | operation while there are in excess of 2,000,000 directly connected users 176 | 177 | \begin_inset CommandInset citation 178 | LatexCommand citep 179 | key "3,4" 180 | 181 | \end_inset 182 | 183 | . 184 | In order that the network continues to expand, the project recognises that 185 | the current volunteer approach is not sufficient and incentives to run 186 | relays are required. 187 | One of the suggested solutions is TorCoin, a incentivisation mechanism 188 | that attempts to compensate users running relays. 189 | It is proposed that TorCoin will enable relays to mine for TorCoins once 190 | they have successfully transferred a batch of data packets across the network 191 | as a reward for providing bandwidth to the Tor network 192 | \begin_inset CommandInset citation 193 | LatexCommand citep 194 | key "5" 195 | 196 | \end_inset 197 | 198 | . 199 | 200 | \end_layout 201 | 202 | \begin_layout Subsection 203 | The SAFE Network 204 | \end_layout 205 | 206 | \begin_layout Standard 207 | The SAFE (Secure Access For Everyone) Network, is a P2P decentralised data 208 | and communications network designed and built by MaidSafe.net and is currently 209 | in implementation phase 210 | \begin_inset CommandInset citation 211 | LatexCommand citep 212 | key "6" 213 | 214 | \end_inset 215 | 216 | . 217 | The network will compliment all existing centralised web services and data 218 | centres with a secure and anonymous network comprised of the spare computing 219 | resources of its users. 220 | It is anticipated that this new network will provide a more secure and 221 | private experience, whilst achieving higher performance as the network 222 | reaches critical mass. 223 | \end_layout 224 | 225 | \begin_layout Section 226 | Safecoin 227 | \end_layout 228 | 229 | \begin_layout Standard 230 | The requirement of users to contribute is an unmistakable part of any P2P 231 | network and the implementation of incentives is essential to ensure its 232 | health. 233 | The introduction of safecoin, the cryptographic token of the SAFE Network, 234 | is an approach designed to encourage a number of different users and contributo 235 | rs to the network. 236 | \end_layout 237 | 238 | \begin_layout Standard 239 | Safecoins can only exist on SAFE and it's distribution is handled entirely 240 | by the network on a per use basis. 241 | It is anticipated that 4.3 billion coins will be produced during the life 242 | of the network. 243 | Each safecoin has it's own unique identity and they are required to access 244 | services on the Safe Network. 245 | The type of services that will be available will depend on those being 246 | developed by third party developers. 247 | It is worth noting that any type of web service currently possible on the 248 | existing centralised Internet is possible on the SAFE Network. 249 | The cost for these services will be set by the service provider and it 250 | is anticipated that as more and more competing apps are developed that 251 | market forces will maintain prices at economic levels. 252 | \end_layout 253 | 254 | \begin_layout Section 255 | Obtaining Safecoin 256 | \end_layout 257 | 258 | \begin_layout Standard 259 | Safecoin can be obtained through; farming, assisting with the maintenance 260 | of the underlying code, creating applications or by purchasing them. 261 | 262 | \end_layout 263 | 264 | \begin_layout Standard 265 | Farming is a process akin to bitcoin mining, whereby users provide resource 266 | (storage space, CPU and bandwidth) to the network. 267 | When each user creates their credentials, they will set up a safecoin wallet 268 | via their SAFE Network client and this wallet identity will be cryptographicall 269 | y linked to their account. 270 | As figure 1 demonstrates, the safecoin earning algorithm is based on a 271 | Sigmoid curve, in that all vaults earn, slowly at first and the rate increases 272 | as the farmer stores up to the network average. 273 | The earning rate also takes into account the rank of the vault, a process 274 | whereby the network scores the usefulness of each node from 0 (being the 275 | worst) to 1 (the best). 276 | The safecoin farming rate is ultimately the result of the network rate, 277 | a balance of the demand and supply on the network, multiplied by the vault 278 | rank. 279 | The network rate will start to level at 20% above average, thus discouraging 280 | massive vaults which would bring centralisation to the network's farming 281 | process. 282 | Safecoin is allocated to them by the network and is paid to the successful 283 | node as data is retrieved from it (GETS), as opposed to when it is stored 284 | (PUTS). 285 | 286 | \end_layout 287 | 288 | \begin_layout Standard 289 | \begin_inset Graphics 290 | filename img/safecoin farming speed.png 291 | width 7cm 292 | 293 | \end_inset 294 | 295 | 296 | \end_layout 297 | 298 | \begin_layout Standard 299 | The network automatically increases farming rewards as space is required 300 | and reduces them as space becomes abundant. 301 | Data is evenly distributed on the network and therefore farmers looking 302 | to maximise their earnings may do so by running several average performance 303 | nodes rather than one high specification node. 304 | \end_layout 305 | 306 | \begin_layout Subsection 307 | Proof of Resource 308 | \end_layout 309 | 310 | \begin_layout Standard 311 | Utilising a process called Proof of Resource (POR), the network is able 312 | to continually validate who and what is providing resource to it in a mathemati 313 | cally verifiable way. 314 | The network does this by attempting to store and retrieve data chunks onto/from 315 | its nodes. 316 | The ability for a node to carry out these actions will be determined by 317 | a combination of its CPU speed, bandwidth availability, unused storage 318 | capacity and on-line time. 319 | The SAFE Network uses a zero knowledge proof mechanism, where the network 320 | does not require to know the content of any data to be checked, but must 321 | know the data is in fact held and held in a manner that is accurate. 322 | Nodes that are either unreliable or are trying to game the network, by 323 | removing previously provided resource, are de ranked by the network if 324 | the node is unable to serve a chunk of data. 325 | \end_layout 326 | 327 | \begin_layout Subsection 328 | Core Development and Building Applications 329 | \end_layout 330 | 331 | \begin_layout Standard 332 | It is also possible for core developers to earn safecoin by fixing bugs 333 | and developing new features for the underlying network. 334 | At the time of writing, this process has not yet been finalised. 335 | It is possible that code bounties will be raised by the core development 336 | team in conjunction with the SAFE project community. 337 | There are a number of existing platforms that facilitate the advertisement 338 | and management of code bounties, such as Bountysource and Bountify 339 | \begin_inset CommandInset citation 340 | LatexCommand citep 341 | key "7,8" 342 | 343 | \end_inset 344 | 345 | . 346 | 347 | \end_layout 348 | 349 | \begin_layout Standard 350 | People or companies building applications on the SAFE Network will also 351 | be able to earn safecoins. 352 | As they create and release new applications, they will code their SAFE 353 | wallet address into their application. 354 | Based on how much the application is used, the network will pay safecoins 355 | to the safecoin wallet address of the app creator. 356 | This provides a built in revenue stream for app developers, one that is 357 | directly proportional to how successful their application is. 358 | \end_layout 359 | 360 | \begin_layout Subsection 361 | Decentralised Exchanges 362 | \end_layout 363 | 364 | \begin_layout Standard 365 | It will also be possible to buy safecoin. 366 | It is anticipated that these purchases will be made from decentralised 367 | peer to peer exchanges that will be built by third party developers. 368 | These exchanges will serve as platforms, enabling a buyer and seller to 369 | trade directly, potentially using multi signature (3 or more private keys 370 | are associated with an address, a majority must sign to make the transaction 371 | valid) technology to manage the transaction. 372 | It would also be possible to have centralised exchanges. 373 | \end_layout 374 | 375 | \begin_layout Standard 376 | Exchanges are essential to the liquidity of safecoin as they ensure that 377 | people unwilling or unable (as they are using a mobile device) can still 378 | gain access to network services. 379 | Additionally, exchanges will also enable those earning safecoins to convert 380 | them into cash or into other cryptocurrencies. 381 | 382 | \end_layout 383 | 384 | \begin_layout Section 385 | The Price of Safecoin 386 | \end_layout 387 | 388 | \begin_layout Standard 389 | As with other digital coins, the exchange or purchase price of safecoin 390 | will be set by the market. 391 | This is a price established through the combination of supply and demand. 392 | As this paper has already described, the number of safecoins in circulation 393 | will increase based on network use. 394 | Almost all early safecoin holders will be farmers with this supply of resource 395 | creating both liquidity and distribution of wealth. 396 | It is anticipated that almost all users will possess at least a few safecoins 397 | in their wallet. 398 | Users may trade their safecoin for services on the network, or for cash 399 | (or another digital currency) using an exchange. 400 | The ratio of safecoin being saved (left in new wallets) versus the ratio 401 | being issued to Farmers will produce a price point. 402 | This point will be the market value of safecoin. 403 | \end_layout 404 | 405 | \begin_layout Standard 406 | It is anticipated that as the number of applications on the network grows, 407 | the utility of safecoin will increase, helping to drive the price of the 408 | coin overtime. 409 | This, coupled with the increase supply of safecoin, will also potentially 410 | increase the stability of the coin. 411 | Safecoins will not have a finite quantity, as after the initial 4.3 billion 412 | are produced, a small percentage (dependent on usage) will be recycled 413 | in order to incentivise the storage of new data. 414 | 415 | \end_layout 416 | 417 | \begin_layout Standard 418 | The number of resources or services it is possible to buy will not be linked 419 | to the exchange price. 420 | The amount of storage, for example, that each safecoin buys over time will 421 | increase, otherwise the network resources could become very expensive if 422 | allowed to rise in line with the exchange price. 423 | This is highlighted in figure 2. 424 | \end_layout 425 | 426 | \begin_layout Standard 427 | 428 | \end_layout 429 | 430 | \begin_layout Standard 431 | \begin_inset Graphics 432 | filename img/safecoin resources.png 433 | width 7cm 434 | 435 | \end_inset 436 | 437 | 438 | \end_layout 439 | 440 | \begin_layout Section 441 | The Transaction Manager 442 | \end_layout 443 | 444 | \begin_layout Standard 445 | Unlike Bitcoin, the SAFE Network does not use a block chain to manage ownership 446 | of coins. 447 | Conversely, the SAFE Network’s Transaction Managers are unchained, meaning 448 | that only the past and current coin owner is known. 449 | It is helpful to think of safecoin as digital cash in this respect, providing 450 | safecoin users with more anonymity than they experience with bitcoin. 451 | 452 | \end_layout 453 | 454 | \begin_layout Standard 455 | The Transaction Manager is a persona or role carried out by the SAFE Network’s 456 | vaults. 457 | Vaults store data on a Farmer's computer and consist of a series of processes 458 | or roles that vary from managing the storage of data, managing other vaults 459 | and more importantly in this case, managing the processing and completion 460 | of transactions. 461 | The entire SAFE Network reaches decisions based on consensus of close groups 462 | of 32 nodes and the transaction manager is the trusted group closest to 463 | any given transaction identity. 464 | These close groups are chosen by the network based on the closeness of 465 | their IDs to the ID of the safecoin. 466 | Closeness in this respect refers to the XOR distance as opposed to geographical 467 | closeness 468 | \begin_inset CommandInset citation 469 | LatexCommand citep 470 | key "19" 471 | 472 | \end_inset 473 | 474 | . 475 | 476 | \end_layout 477 | 478 | \begin_layout Standard 479 | \begin_inset Graphics 480 | filename img/safecoin transfer mech.png 481 | width 7.5cm 482 | 483 | \end_inset 484 | 485 | 486 | \end_layout 487 | 488 | \begin_layout Standard 489 | One of the major problems any virtual currency or coin must overcome is 490 | the ability to avoid double spending. 491 | Within the SAFE Network, transfer of data, safecoin included, is atomic, 492 | using a cryptographic signature to demonstrate that the last person who 493 | owned the safecoin has signed the coin over to the current owner. 494 | When the current owner spends the coin, they ask the network (their close 495 | group of 32) to accept a signed message transferring ownership to the new 496 | owner. 497 | This process is highlighted in figure 3. 498 | The knowledge of coin ownership (each has their own unique ID) is kept 499 | in several close groups and each group must agree upon and reach consensus 500 | (28 of 32) on the transfer of ownership before the transaction is processed 501 | and the ownership of the coin is transferred. 502 | 503 | \end_layout 504 | 505 | \begin_layout Section 506 | Minting safecoin 507 | \end_layout 508 | 509 | \begin_layout Standard 510 | The transaction model, described in Section 5, enables safecoin ownership 511 | to be transferred. 512 | However, it will be possible, after the SAFE Network is launched, to mint 513 | safecoin in a more physical and anonymous way. 514 | 515 | \end_layout 516 | 517 | \begin_layout Standard 518 | Minting safecoin can be achieved by the network enabling the registration 519 | of a special transaction with the transaction managers, that facilitates 520 | transfer of the ownship of the coin to any user that acknowledges the transacti 521 | on. 522 | The minting process effectively removes the requirement for the transaction 523 | validation step from the Transaction Manager. 524 | When Alice wants to mint safecoin, she sends a request to Transaction Managers 525 | with a special request to transfer the coin(s) to anyone. 526 | The Transaction Managers, once they have confirmed by consensus that Alice 527 | is the current owner, will then generate the transaction. 528 | Once Alice receives the transaction name from the network, she can store 529 | it on an external storage device, such as a usb drive, together with a 530 | special validation signature which has been used as a salt when generating 531 | the previous sent request 532 | \begin_inset Foot 533 | status open 534 | 535 | \begin_layout Plain Layout 536 | A salt is random data that is used as an additional input to a one-way function 537 | that hashes a password or passphrase 538 | \end_layout 539 | 540 | \end_inset 541 | 542 | . 543 | This salt is used to prevent Transaction Managers themselves trying to 544 | acknowledge the transaction to steal the coin. 545 | 546 | \end_layout 547 | 548 | \begin_layout Standard 549 | When Bob receives the minted safecoin and decides he would like to spend 550 | them, he reads the transaction name and the validation signature from the 551 | storage device and then sends an acknowledgement to the network. 552 | Once the Transaction Managers receive the acknowledgement, the pre-generated 553 | transaction will be updated, thus completing the transfer of ownership 554 | of that coin(s) from Alice to Bob. 555 | \end_layout 556 | 557 | \begin_layout Standard 558 | The benefit of using safecoin in this way is a reduction in the complexity 559 | of the transaction by removing the acknowledgement procedure, making minted 560 | safecoin similar to a cash note. 561 | It also means that Alice, in this case, no longer needs to worry about 562 | keeping her private key safe as the transaction has been pre generated. 563 | Minted safecoin is also more anonymous, eliminating the need to store safecoins 564 | only in a digital wallet that can be compromised should an adversory obtain 565 | access to a users SAFE Network credentials. 566 | However, there is risk that after the transfer transaction has been registered, 567 | if the owner loses the external storage device containing the safecoin(s), 568 | anyone will be able to claim ownership. 569 | However, this is no greater than the risk anyone undertakes when withdrawing 570 | cash from a bank, convenience comes at the price of security. 571 | \end_layout 572 | 573 | \begin_layout Section 574 | The Economics of Safecoin 575 | \end_layout 576 | 577 | \begin_layout Standard 578 | Unlike many cryptocurrencies, whose creation is not backed by anything, 579 | the distribution of safecoin is backed by data. 580 | The generation of safecoin is entirely network led and they are only created 581 | as the network is used and data retrieved from network nodes. 582 | This activity is in contrast to currencies like bitcoin, whose coin distributio 583 | n is arbitrarily set to 10 minute blocks. 584 | This means that if the SAFE Network is in great demand a large volume of 585 | safecoins will be created, while low demand will lead to minimal coins 586 | being generated. 587 | This demand generation cycle has a desirable affect in that it should ensure 588 | no over supply of safecoins, which may potentially lead to a unit price 589 | decrease. 590 | This is not to say that the price of safecoin will not be volatile, the 591 | comparatively small coin supply (Bitcoin’s market capitalisation is currently 592 | $5.2 billion, whereas the US Dollar has around $17 trillion (M4 definition 593 | - notes, coins and bank accounts) in circulation) of cryptocurrencies makes 594 | this inevitable. 595 | However, it may provide greater stability in the long term 596 | \begin_inset CommandInset citation 597 | LatexCommand citep 598 | key "18" 599 | 600 | \end_inset 601 | 602 | . 603 | \end_layout 604 | 605 | \begin_layout Standard 606 | In many respects, the underlying economics of safecoin can be directly compared 607 | to Cap and Trade Economics, a strategy utilised by governments in an attempt 608 | to limit the amount of greenhouse (GHG) emitted by private enterprises 609 | 610 | \begin_inset CommandInset citation 611 | LatexCommand citep 612 | key "17" 613 | 614 | \end_inset 615 | 616 | . 617 | In the same way that the Cap and Trade system limits the overall emissions, 618 | enabling companies to pay for releasing GHGs, the safecoin cap will be 619 | influenced by the network average resources, with safecoins being traded 620 | to reach the market price. 621 | \end_layout 622 | 623 | \begin_layout Standard 624 | Furthermore, current supply of traditional FIAT currencies has become elastic, 625 | with central banks of many nations engaging in quantitative easing, effectively 626 | printing money to ensure greater supply. 627 | Unfortunately this can have many negative consequences as printing money 628 | does not solve the underlying economic problems and can potentially lead 629 | to increases in inflation 630 | \begin_inset CommandInset citation 631 | LatexCommand citep 632 | key "10" 633 | 634 | \end_inset 635 | 636 | . 637 | These drawbacks have led some economists to start calling for a return 638 | to the gold standard, a situation where supply of money was linked to the 639 | supply of gold, known to be valuable and very difficult to counterfeit 640 | 641 | \begin_inset CommandInset citation 642 | LatexCommand citep 643 | key "11" 644 | 645 | \end_inset 646 | 647 | . 648 | 649 | \end_layout 650 | 651 | \begin_layout Standard 652 | With coin generation on the SAFE Network being directly linked to network 653 | use, the issuance of safecoins will be linked to supply and demand for 654 | data services. 655 | Data is valuable and is considered by some as becoming a commodity in its 656 | own right. 657 | The World Economic Forum has established data as an asset class 658 | \begin_inset CommandInset citation 659 | LatexCommand citep 660 | key "12" 661 | 662 | \end_inset 663 | 664 | . 665 | The realisation of data having significant monetary value is also born 666 | out by recent valuations in technology companies, many of whom are not 667 | sustainable 668 | \begin_inset CommandInset citation 669 | LatexCommand citep 670 | key "13" 671 | 672 | \end_inset 673 | 674 | . 675 | Having a network generated digital currency inextricably linked to a valuable 676 | commodity, has the potential for a stable environment, one that as the 677 | money supply increases, has the potential to be more resistant to price 678 | fluctuations. 679 | \end_layout 680 | 681 | \begin_layout Section 682 | A Revenue Model for a New Internet 683 | \end_layout 684 | 685 | \begin_layout Standard 686 | In addition to incentivising user behaviour, safecoin may also provide an 687 | alternative revenue source for the Internet, in the shape of micro payments. 688 | It is possible to implement safecoin without transaction costs (although 689 | these could be added to aid security 690 | \begin_inset Foot 691 | status open 692 | 693 | \begin_layout Plain Layout 694 | An adversory could process a large number of transaction requests to the 695 | network in an attempt to overload it, the addition of a very small transaction 696 | fee may mitigate this risk. 697 | \end_layout 698 | 699 | \end_inset 700 | 701 | ) and high divisibility (coins are valued at $0.05 at the time of writing 702 | (Jan 2015) and have the potential to be divided up to 4.3 billion times) 703 | make them well suited to very low value transactions. 704 | Furthermore, the SAFE Networks ability to enable an unlimited number of 705 | transactions with confirmations at network speed equips it well for micro 706 | payments. 707 | \end_layout 708 | 709 | \begin_layout Standard 710 | Micro payments are one of many ways to replace the current methods of funding 711 | today’s centralised Internet, typically this is achieved through advertising. 712 | Large Internet companies, such as Google and Facebook, earn the vast majority 713 | of their revenue (91% and 89% respectively) by selling adverts at their 714 | users 715 | \begin_inset CommandInset citation 716 | LatexCommand citep 717 | key "14,15" 718 | 719 | \end_inset 720 | 721 | . 722 | This model has been criticised as it not only promotes increasing surveillance 723 | of user data, as advertisers require to know more and more about us, but 724 | also removes the rewards away from content creators 725 | \begin_inset CommandInset citation 726 | LatexCommand citep 727 | key "16" 728 | 729 | \end_inset 730 | 731 | . 732 | \end_layout 733 | 734 | \begin_layout Standard 735 | It would be technically feasible, using safecoin on the SAFE Network, to 736 | pay for films on a cost per frame basis, with the user only paying for 737 | what they watch. 738 | This amount would automatically be deducted from the viewers safecoin wallet 739 | as they watch. 740 | A similar model could also be utilised for music, or for bloggers, with 741 | individual articles paid for via a paywall or on a voluntary basis. 742 | The decision about how to structure payment for their work would reside 743 | with the copyright owner. 744 | The SAFE Network enables an optional watermarking feature that serves to 745 | inform the user the identity of the content creator, however, this should 746 | not be confused with a DRM mechanism. 747 | 748 | \end_layout 749 | 750 | \begin_layout Section 751 | Conclusion 752 | \end_layout 753 | 754 | \begin_layout Standard 755 | There are several examples of advanced technologies that did not reach their 756 | full potential as their incentives were poorly aligned. 757 | Tokens or coins have been used in a wide vareity of settings, including 758 | decentralised computer networks, to motivate, influence and guide desired 759 | behaviour. 760 | Bitcoin in particular has shown that by properly aligning incentives, the 761 | health of the network is sufficiently increased as miners are compensated 762 | for providing their hashing power to the block chain. 763 | \end_layout 764 | 765 | \begin_layout Standard 766 | It is anticipated that safecoin will provide sufficient incentives to ensure 767 | the long term health of the SAFE Network, encouraging end users to provide 768 | their resource, while enticing both application and core developers to 769 | assist in the continued growth of the network. 770 | It is hoped that by tying together supply and demand for data services, 771 | the SAFE Network economy will retain a natural balancing mechanism that 772 | increases the reward for space as it is required and reduces the reward 773 | when it is not. 774 | \end_layout 775 | 776 | \begin_layout Section* 777 | Acknowledgment 778 | \end_layout 779 | 780 | \begin_layout Standard 781 | Many thanks to the SAFE Network community, and in particular Yanick Vézina, 782 | for helping to proof read this paper. 783 | 784 | \end_layout 785 | 786 | \begin_layout Standard 787 | \begin_inset CommandInset bibtex 788 | LatexCommand bibtex 789 | btprint "btPrintCited" 790 | bibfiles "safecoin citations" 791 | options "plainnat" 792 | 793 | \end_inset 794 | 795 | 796 | \end_layout 797 | 798 | \end_body 799 | \end_document 800 | -------------------------------------------------------------------------------- /technical_papers/SelfAuthentication.lyx: -------------------------------------------------------------------------------- 1 | #LyX 2.1 created this file. For more info see http://www.lyx.org/ 2 | \lyxformat 474 3 | \begin_document 4 | \begin_header 5 | \textclass IEEEtran 6 | \use_default_options false 7 | \maintain_unincluded_children false 8 | \language british 9 | \language_package default 10 | \inputencoding default 11 | \fontencoding global 12 | \font_roman default 13 | \font_sans default 14 | \font_typewriter default 15 | \font_math auto 16 | \font_default_family default 17 | \use_non_tex_fonts false 18 | \font_sc false 19 | \font_osf false 20 | \font_sf_scale 100 21 | \font_tt_scale 100 22 | \graphics default 23 | \default_output_format default 24 | \output_sync 0 25 | \bibtex_command default 26 | \index_command default 27 | \paperfontsize default 28 | \spacing single 29 | \use_hyperref true 30 | \pdf_title "Self-Authentication" 31 | \pdf_author "David Irvine" 32 | \pdf_subject "Authentication" 33 | \pdf_keywords "security, freedom, privacy, authentication" 34 | \pdf_bookmarks true 35 | \pdf_bookmarksnumbered false 36 | \pdf_bookmarksopen false 37 | \pdf_bookmarksopenlevel 1 38 | \pdf_breaklinks false 39 | \pdf_pdfborder true 40 | \pdf_colorlinks false 41 | \pdf_backref false 42 | \pdf_pdfusetitle true 43 | \papersize default 44 | \use_geometry false 45 | \use_package amsmath 0 46 | \use_package amssymb 0 47 | \use_package cancel 1 48 | \use_package esint 0 49 | \use_package mathdots 0 50 | \use_package mathtools 1 51 | \use_package mhchem 1 52 | \use_package stackrel 1 53 | \use_package stmaryrd 1 54 | \use_package undertilde 1 55 | \cite_engine basic 56 | \cite_engine_type default 57 | \biblio_style plain 58 | \use_bibtopic false 59 | \use_indices false 60 | \paperorientation portrait 61 | \suppress_date false 62 | \justification true 63 | \use_refstyle 0 64 | \index Index 65 | \shortcut idx 66 | \color #008000 67 | \end_index 68 | \secnumdepth 3 69 | \tocdepth 3 70 | \paragraph_separation indent 71 | \paragraph_indentation default 72 | \quotes_language english 73 | \papercolumns 2 74 | \papersides 1 75 | \paperpagestyle default 76 | \tracking_changes false 77 | \output_changes false 78 | \html_math_output 0 79 | \html_css_as_file 0 80 | \html_be_strict false 81 | \end_header 82 | 83 | \begin_body 84 | 85 | \begin_layout Title 86 | Self-Authentication 87 | \end_layout 88 | 89 | \begin_layout Author 90 | \begin_inset Flex Author Name 91 | status open 92 | 93 | \begin_layout Plain Layout 94 | David Irvine 95 | \end_layout 96 | 97 | \end_inset 98 | 99 | 100 | \begin_inset Flex Author Mark 101 | status open 102 | 103 | \begin_layout Plain Layout 104 | 1 105 | \end_layout 106 | 107 | \end_inset 108 | 109 | 110 | \begin_inset Newline newline 111 | \end_inset 112 | 113 | 114 | \begin_inset Flex Author Affiliation 115 | status open 116 | 117 | \begin_layout Plain Layout 118 | MaidSafe.net, 72 Templehill, Troon, South Ayrshire, Scotland, UK. 119 | KA10 6BE. 120 | \end_layout 121 | 122 | \end_inset 123 | 124 | 125 | \begin_inset Newline newline 126 | \end_inset 127 | 128 | 129 | \begin_inset Flex Author Mark 130 | status open 131 | 132 | \begin_layout Plain Layout 133 | 1 134 | \end_layout 135 | 136 | \end_inset 137 | 138 | david.irvine@maidsafe.net 139 | \end_layout 140 | 141 | \begin_layout Page headings 142 | \begin_inset Argument 1 143 | status open 144 | 145 | \begin_layout Plain Layout 146 | Irvine: Self-Authentication 147 | \end_layout 148 | 149 | \end_inset 150 | 151 | 152 | \end_layout 153 | 154 | \begin_layout Address 155 | First published September 2010. 156 | \end_layout 157 | 158 | \begin_layout Abstract 159 | Today all known mechanisms that grant access to distributed or shared services 160 | and resources require central authoritative control in some form, raising 161 | issues in regard to security, trust and privacy. 162 | This paper presents a system of authentication that not only abolishes 163 | the requirements for any centrally stored user credential records, it also 164 | negates the necessity for any server based systems as a login entity for 165 | users to connect with prior to gaining access to a system. 166 | \end_layout 167 | 168 | \begin_layout Keywords 169 | security, freedom, privacy, authentication 170 | \end_layout 171 | 172 | \begin_layout Standard 173 | \begin_inset CommandInset toc 174 | LatexCommand tableofcontents 175 | 176 | \end_inset 177 | 178 | 179 | \end_layout 180 | 181 | \begin_layout Section 182 | Introduction 183 | \end_layout 184 | 185 | \begin_layout Standard 186 | \begin_inset Flex Paragraph Start 187 | status open 188 | 189 | \begin_layout Plain Layout 190 | \begin_inset Argument 1 191 | status open 192 | 193 | \begin_layout Plain Layout 194 | A 195 | \end_layout 196 | 197 | \end_inset 198 | 199 | uthentication 200 | \end_layout 201 | 202 | \end_inset 203 | 204 | allows access to a system at a certain level or privilege. 205 | This is generally accepted as the privilege as granted by an authoritative 206 | third party who owns or manages the particular service or resource being 207 | accessed. 208 | In cloud-computing or personal computing this is a limiting factor and 209 | a significant security risk. 210 | Trust in third parties with personal or confidential data is something 211 | that is arguably impossible without any radical change in the very structure 212 | and fabric of modern society. 213 | This paper presents a system where there is no requirement for such a third-par 214 | ty involvement. 215 | 216 | \end_layout 217 | 218 | \begin_layout Standard 219 | A significant shift in thinking nowadays is to spread data across multiple 220 | locations for security and ease of access. 221 | This has surfaced privacy concerns, and increased awareness of ownership 222 | of data, something that is often disregarded very easily. 223 | But rarely all personal data is surrendered in this way; many systems offer 224 | some level of encryption to ensure privacy of data, but none offer any 225 | system of personal access to personal data, privately. 226 | In almost every case there is some form of contract, whether implied or 227 | actual between the third-party service provider and the client. 228 | Furthermore the supplier may independently decide or be forced to act on 229 | the data, whether deleting encrypted data, going out of business or becoming 230 | a victim of damage or theft. 231 | 232 | \end_layout 233 | 234 | \begin_layout Standard 235 | This situation is a crucial impediment to personal freedom, and without 236 | a change in technical capabilities that allow the mindset change that appears 237 | more prevalent as time goes by, there will be a significant gulf between 238 | people's individual desires and technology's ability to deliver. 239 | This in itself may impede progress and innovation, which would be an enormous 240 | failure of Science and Engineering to take responsibility for. 241 | 242 | \end_layout 243 | 244 | \begin_layout Standard 245 | This paper will outline and detail a significant mind-shift in access controls 246 | that not only answer these issues, but take the current situation and dramatica 247 | lly alter our relationship with technology, particularly in regard to storing, 248 | sharing and developing our most personal thoughts, aspirations and desires. 249 | \end_layout 250 | 251 | \begin_layout Section 252 | Implementation 253 | \end_layout 254 | 255 | \begin_layout Subsection 256 | Issues to be Solved 257 | \end_layout 258 | 259 | \begin_layout Standard 260 | Given a traditional resource exchange, the bargain between involved parties 261 | tends to be direct and physically local. 262 | However, the 263 | \emph on 264 | de facto 265 | \emph default 266 | replacement of barter by monetary systems in modern societies introduced 267 | the requirement of trust in third parties providing and controlling the 268 | necessary infrastructure, such as banks and financial authorities. 269 | \end_layout 270 | 271 | \begin_layout Standard 272 | It is an illogical consideration to have created a technology based solution 273 | which requires this demand of trust, and to do so in a manner that is almost 274 | uncontrolled. 275 | Technology tends to be based on logic, thus it would appear obvious that 276 | creating, sharing and retrieving information fed into a computing device 277 | by a person should not require that computer to connect to a network of 278 | computers with a controller or guardian that is not a system of pure logic. 279 | \end_layout 280 | 281 | \begin_layout Standard 282 | A significant reason for the current situation is the inability for identities 283 | to be created, managed and personally controlled. 284 | This is a reasonable request from people to make from their technology, 285 | but so far has been regarded as impossible by technology professionals. 286 | A system of personal identity management is fundamental for the removal 287 | of the illogical situation of today. 288 | 289 | \end_layout 290 | 291 | \begin_layout Subsection 292 | Conventions 293 | \end_layout 294 | 295 | \begin_layout Standard 296 | There is scope for confusion when using the term 297 | \begin_inset Quotes eld 298 | \end_inset 299 | 300 | key 301 | \begin_inset Quotes erd 302 | \end_inset 303 | 304 | , as sometimes it refers to a cryptographic key, and at other times it is 305 | in respect to the key of a DHT 306 | \begin_inset Quotes eld 307 | \end_inset 308 | 309 | key, value 310 | \begin_inset Quotes erd 311 | \end_inset 312 | 313 | pair. 314 | In order to avoid confusion, cryptographic keys will be referred to as 315 | 316 | \begin_inset Formula $\mathsf{K}$ 317 | \end_inset 318 | 319 | , and DHT keys simply as keys. 320 | \end_layout 321 | 322 | \begin_layout Itemize 323 | \begin_inset Formula $\mathsf{H}$ 324 | \end_inset 325 | 326 | ≡ Hash function such as SHA, MD5, etc. 327 | 328 | \end_layout 329 | 330 | \begin_layout Itemize 331 | \begin_inset Formula $\mathsf{PBKDF2_{[Passphrase][Salt]}}$ 332 | \end_inset 333 | 334 | ≡ Password-Based Key Derivation Function or similar. 335 | \end_layout 336 | 337 | \begin_layout Itemize 338 | \begin_inset Formula $\mathsf{SymEnc_{[K]}(Data)}$ 339 | \end_inset 340 | 341 | ≡ Symmetrically encrypt 342 | \begin_inset Formula $\mathsf{Data}$ 343 | \end_inset 344 | 345 | using 346 | \begin_inset Formula $\mathsf{K}$ 347 | \end_inset 348 | 349 | . 350 | \end_layout 351 | 352 | \begin_layout Itemize 353 | \begin_inset Formula $\mathsf{SymDec_{[K]}(Data)}$ 354 | \end_inset 355 | 356 | ≡ Symmetrically decrypt 357 | \begin_inset Formula $\mathsf{Data}$ 358 | \end_inset 359 | 360 | using 361 | \begin_inset Formula $\mathsf{K}$ 362 | \end_inset 363 | 364 | . 365 | \end_layout 366 | 367 | \begin_layout Itemize 368 | \begin_inset Formula $\mathsf{+}$ 369 | \end_inset 370 | 371 | ≡ Concatenation. 372 | \end_layout 373 | 374 | \begin_layout Itemize 375 | \begin_inset Formula $\mathsf{PutV_{[Key]}(Value)}$ 376 | \end_inset 377 | 378 | ≡ Store a 379 | \begin_inset Formula $\mathsf{Value}$ 380 | \end_inset 381 | 382 | under the given 383 | \begin_inset Formula $\mathsf{Key}$ 384 | \end_inset 385 | 386 | . 387 | \end_layout 388 | 389 | \begin_layout Itemize 390 | \begin_inset Formula $\mathsf{GetV_{[Key]}}$ 391 | \end_inset 392 | 393 | ≡ Retrieve the 394 | \begin_inset Formula $\mathsf{Value}$ 395 | \end_inset 396 | 397 | identified by 398 | \begin_inset Formula $\mathsf{Key}$ 399 | \end_inset 400 | 401 | . 402 | \end_layout 403 | 404 | \begin_layout Itemize 405 | \begin_inset Formula $\mathsf{DelV_{[Key]}(Value)}$ 406 | \end_inset 407 | 408 | ≡ Delete 409 | \begin_inset Formula $\mathsf{Value}$ 410 | \end_inset 411 | 412 | identified by 413 | \begin_inset Formula $\mathsf{Key}$ 414 | \end_inset 415 | 416 | . 417 | 418 | \begin_inset Formula $\mathsf{Value}$ 419 | \end_inset 420 | 421 | must be provided as multiple values can be stored under a single key. 422 | \end_layout 423 | 424 | \begin_layout Subsection 425 | Overview of Self-Authentication 426 | \end_layout 427 | 428 | \begin_layout Subsubsection 429 | Requirements 430 | \end_layout 431 | 432 | \begin_layout Standard 433 | Self-authentication requires a storage mechanism accessible by the users 434 | of the system. 435 | This may be public (such as a peer-to-peer network) or private (such a 436 | a storage area network); this paper assumes that it should also be a key 437 | addressable storage system. 438 | \end_layout 439 | 440 | \begin_layout Subsubsection 441 | Methodology 442 | \end_layout 443 | 444 | \begin_layout Standard 445 | Self-authentication relies on a system where an entity can create a unique 446 | key to store a value in the storage system. 447 | The value stored with this key should contain an encrypted passport to 448 | data. 449 | This passport may be cryptographically secure keys and or a list of other 450 | keys to make use of the information to be stored and or shared as well 451 | as any additional components required. 452 | \end_layout 453 | 454 | \begin_layout Standard 455 | The location of this initial key should be masked or at least not obvious 456 | in the storage mechanism. 457 | Further masking should be considered. 458 | This simplified approach is the basis for self authentication and is extended 459 | into a system that is capable of security in a manner that allows access 460 | data to be stored publically and with no additional requirement such as 461 | firewalls or access controls. 462 | 463 | \end_layout 464 | 465 | \begin_layout Section 466 | Detailed Implementation 467 | \end_layout 468 | 469 | \begin_layout Subsection 470 | Creation of an Account 471 | \end_layout 472 | 473 | \begin_layout Standard 474 | Here we will assume there are two inputs from the user of the system: user-name 475 | 476 | \begin_inset Formula $\mathsf{U}$ 477 | \end_inset 478 | 479 | , and password 480 | \begin_inset Formula $\mathsf{W}$ 481 | \end_inset 482 | 483 | . 484 | A salt 485 | \begin_inset Formula $\mathsf{S}$ 486 | \end_inset 487 | 488 | is also derived (in a repeatable way) from 489 | \begin_inset Formula $\mathsf{U}$ 490 | \end_inset 491 | 492 | and 493 | \begin_inset Formula $\mathsf{W}$ 494 | \end_inset 495 | 496 | . 497 | \end_layout 498 | 499 | \begin_layout Standard 500 | To generate a unique identifier, we hash the concatenation of the user-name 501 | and the salt, 502 | \begin_inset Formula $\mathsf{H(U+S)}$ 503 | \end_inset 504 | 505 | . 506 | 507 | \end_layout 508 | 509 | \begin_layout Standard 510 | PBKDF2 is used here to strengthen any password keys used. 511 | This is required as user selected passwords are inevitably weak and the 512 | user may not know the user-name is also used as a password in the system. 513 | 514 | \begin_inset Formula $\mathsf{Account}$ 515 | \end_inset 516 | 517 | specifies session data, like user details or an index of references to 518 | further data. 519 | This packet is located through an Access Packet holding a random string 520 | 521 | \begin_inset Formula $\mathsf{RndStr}$ 522 | \end_inset 523 | 524 | . 525 | \end_layout 526 | 527 | \begin_layout Enumerate 528 | \begin_inset Formula $\mathsf{GetV_{[H(U+S)]}\equiv False}$ 529 | \end_inset 530 | 531 | (Ensure uniqueness) 532 | \end_layout 533 | 534 | \begin_layout Enumerate 535 | Generate random string 536 | \begin_inset Formula $\mathsf{RndStr}$ 537 | \end_inset 538 | 539 | 540 | \end_layout 541 | 542 | \begin_layout Enumerate 543 | \begin_inset Formula $\mathsf{PutV_{[H(U+S)]}\left(SymEnc_{[PBKDF2_{[U][S]}]}(RndStr)\right)}$ 544 | \end_inset 545 | 546 | (Store Access Packet) 547 | \end_layout 548 | 549 | \begin_layout Enumerate 550 | \begin_inset Formula $\mathsf{PutV_{[H(U+S+RndStr)]}\left(SymEnc_{[PBKDF2_{[W][S]}]}(Account)\right)}$ 551 | \end_inset 552 | 553 | (Store Account Packet) 554 | \end_layout 555 | 556 | \begin_layout Subsection 557 | Login / Load Session Process 558 | \begin_inset CommandInset label 559 | LatexCommand label 560 | name "sub:Login-to-a" 561 | 562 | \end_inset 563 | 564 | 565 | \end_layout 566 | 567 | \begin_layout Enumerate 568 | \begin_inset Formula $\mathsf{SymDec_{[PBKDF2_{[U][S]}]}\left(GetV_{[H(U+S)]}\right)\equiv RndStr}$ 569 | \end_inset 570 | 571 | 572 | \end_layout 573 | 574 | \begin_layout Enumerate 575 | \begin_inset Formula $\mathsf{SymDec_{[PBKDF2_{[W][S]}]}(GetV_{[H(U+S+RndStr)]})\equiv Account}$ 576 | \end_inset 577 | 578 | 579 | \end_layout 580 | 581 | \begin_layout Standard 582 | For the following operation, 583 | \begin_inset Formula $\mathsf{RndStr}$ 584 | \end_inset 585 | 586 | should be kept locally for the duration of the session. 587 | \end_layout 588 | 589 | \begin_layout Subsection 590 | Logout / Save Session Process 591 | \end_layout 592 | 593 | \begin_layout Enumerate 594 | Generate new random string 595 | \begin_inset Formula $\mathsf{RndStr_{new}}$ 596 | \end_inset 597 | 598 | 599 | \end_layout 600 | 601 | \begin_layout Enumerate 602 | \begin_inset Formula $\mathsf{PutV_{[H(U+S+RndStr_{new})]}\left(SymEnc_{[PBKDF2_{[W][S]}]}(Account)\right)}$ 603 | \end_inset 604 | 605 | (Store new Account Packet) 606 | \end_layout 607 | 608 | \begin_layout Enumerate 609 | \begin_inset Formula $\mathsf{PutV_{[H(U+S)]}\left(SymEnc_{[PBKDF2_{[U][S]}]}(RndStr_{new})\right)}$ 610 | \end_inset 611 | 612 | (Update Access Packet) 613 | \end_layout 614 | 615 | \begin_layout Enumerate 616 | \begin_inset Formula $\mathsf{DelV_{[H(U+S+RndStr)]}(OldAccount)}$ 617 | \end_inset 618 | 619 | (Delete old Account Packet) 620 | \end_layout 621 | 622 | \begin_layout Subsection 623 | Fallback Account Packets 624 | \end_layout 625 | 626 | \begin_layout Standard 627 | The previous sections outlined the basic system of authentication. 628 | However, this can be extended for safety reasons. 629 | As with any system, the serialisation and store operation of the account 630 | data can fail for any reason, resulting in unreadable data upon retrieval. 631 | This would be catastrophic as access to the user's data on the system may 632 | be rendered impossible. 633 | To reduce any such risk, a fallback copy of an Account Packet (and its 634 | Access Packet) is kept, to allow reverting to the previous version in case 635 | the current version can't be restored or turns out to have been generated 636 | erroneously. 637 | Like the main Access Packet, the fallback Access Packet contains an (encrypted) 638 | random string, designated 639 | \begin_inset Formula $\mathsf{RndStr_{fallback}}$ 640 | \end_inset 641 | 642 | . 643 | \end_layout 644 | 645 | \begin_layout Subsubsection 646 | Updated Account Creation Process 647 | \end_layout 648 | 649 | \begin_layout Enumerate 650 | \begin_inset Formula $\mathsf{GetV_{[H(U+S)]}\equiv False}$ 651 | \end_inset 652 | 653 | (Ensure uniqueness of Access Packet) 654 | \end_layout 655 | 656 | \begin_layout Enumerate 657 | \begin_inset Formula $\mathsf{GetV_{[H(U+(S-1))]}\equiv False}$ 658 | \end_inset 659 | 660 | (Ensure uniqueness of fallback Access Packet) 661 | \end_layout 662 | 663 | \begin_layout Enumerate 664 | Generate random string 665 | \begin_inset Formula $\mathsf{RndStr}$ 666 | \end_inset 667 | 668 | and copy 669 | \begin_inset Formula $\mathsf{RndStr\rightarrow RndStr_{fallback}}$ 670 | \end_inset 671 | 672 | 673 | \end_layout 674 | 675 | \begin_layout Enumerate 676 | \begin_inset Formula $\mathsf{PutV_{[H(U+S)]}\left(SymEnc_{[PBKDF2_{[U][S]}]}(RndStr)\right)}$ 677 | \end_inset 678 | 679 | 680 | \end_layout 681 | 682 | \begin_layout Enumerate 683 | \begin_inset Formula $\mathsf{PutV_{[H(U+(S-1))]}\left(SymEnc_{[PBKDF2_{[U][S-1]}]}(RndStr)\right)}$ 684 | \end_inset 685 | 686 | 687 | \end_layout 688 | 689 | \begin_layout Enumerate 690 | \begin_inset Formula $\mathsf{PutV_{[H(U+S+RndStr)]}\left(SymEnc_{[PBKDF2_{[W][S]}]}(Account)\right)}$ 691 | \end_inset 692 | 693 | 694 | \end_layout 695 | 696 | \begin_layout Standard 697 | In this case, the random strings in the Access Packets are the same, thus 698 | point to the same (unique) Account Packet. 699 | Fallback packets are only kept once the Account Packet is updated. 700 | \end_layout 701 | 702 | \begin_layout Subsubsection 703 | Updated Login Process 704 | \end_layout 705 | 706 | \begin_layout Enumerate 707 | if ( 708 | \begin_inset Formula $\mathsf{GetV_{[H(U+S)]}\equiv EncRndStr}$ 709 | \end_inset 710 | 711 | ) 712 | \end_layout 713 | 714 | \begin_deeper 715 | \begin_layout Enumerate 716 | \begin_inset Formula $\mathsf{SymDec_{[PBKDF2_{[U][S]}]}(EncRndStr)\equiv RndStr}$ 717 | \end_inset 718 | 719 | 720 | \end_layout 721 | 722 | \begin_layout Enumerate 723 | \begin_inset Formula $\mathsf{SymDec_{[PBKDF2_{[W][S]}]}\left(GetV_{[H(U+S+RndStr)]}\right)\equiv}$ 724 | \end_inset 725 | 726 | 727 | \begin_inset Newline newline 728 | \end_inset 729 | 730 | 731 | \begin_inset Formula $\mathsf{Account}$ 732 | \end_inset 733 | 734 | 735 | \end_layout 736 | 737 | \end_deeper 738 | \begin_layout Enumerate 739 | else (or if previous attempt failed) 740 | \end_layout 741 | 742 | \begin_deeper 743 | \begin_layout Enumerate 744 | \begin_inset Formula $\mathsf{GetV_{[H(U+(S-1))]}\equiv EncRndStr_{fallback}}$ 745 | \end_inset 746 | 747 | 748 | \end_layout 749 | 750 | \begin_layout Enumerate 751 | \begin_inset Formula $\mathsf{SymDec_{[PBKDF2_{[U][S-1]}]}(EncRndStr_{fallback})\equiv}$ 752 | \end_inset 753 | 754 | 755 | \begin_inset Newline newline 756 | \end_inset 757 | 758 | 759 | \begin_inset Formula $\mathsf{RndStr_{fallback}}$ 760 | \end_inset 761 | 762 | 763 | \end_layout 764 | 765 | \begin_layout Enumerate 766 | \begin_inset Formula $\mathsf{SymDec_{[PBKDF2_{[W][S-1]}]}\left(GetV_{[H(U+S+RndStr_{fallback})]}\right)}$ 767 | \end_inset 768 | 769 | 770 | \begin_inset Newline newline 771 | \end_inset 772 | 773 | 774 | \begin_inset Formula $\mathsf{\equiv Account_{fallback}}$ 775 | \end_inset 776 | 777 | 778 | \end_layout 779 | 780 | \end_deeper 781 | \begin_layout Subsubsection 782 | Updated Logout / Save Session Process 783 | \end_layout 784 | 785 | \begin_layout Standard 786 | Designate existing 787 | \begin_inset Formula $\mathsf{RndStr}$ 788 | \end_inset 789 | 790 | as 791 | \begin_inset Formula $\mathsf{RndStr_{old}}$ 792 | \end_inset 793 | 794 | and 795 | \begin_inset Formula $\mathsf{RndStr_{fallback}}$ 796 | \end_inset 797 | 798 | as 799 | \begin_inset Formula $\mathsf{RndStr_{fallback\,old}}$ 800 | \end_inset 801 | 802 | 803 | \end_layout 804 | 805 | \begin_layout Enumerate 806 | Generate new random string 807 | \begin_inset Formula $\mathsf{RndStr_{new}}$ 808 | \end_inset 809 | 810 | 811 | \end_layout 812 | 813 | \begin_layout Enumerate 814 | \begin_inset Formula $\mathsf{PutV_{[H(U+S)]}\left(SymEnc_{[PBKDF2_{[U][S]}]}(RndStr_{new})\right)}$ 815 | \end_inset 816 | 817 | (Update Access Packet with new random string) 818 | \end_layout 819 | 820 | \begin_layout Enumerate 821 | \begin_inset Formula $\mathsf{PutV_{[H(U+(S-1))]}\left(SymEnc_{[PBKDF2_{[U][S-1]}]}(RndStr_{old})\right)}$ 822 | \end_inset 823 | 824 | (Update fallback Access Packet with old random string) 825 | \end_layout 826 | 827 | \begin_layout Enumerate 828 | \begin_inset Formula $\mathsf{PutV_{[H(U+S+RndStr_{new})]}\left(SymEnc_{[PBKDF2_{[W][S]}]}(Account)\right)}$ 829 | \end_inset 830 | 831 | (Update Account Packet using new random string) 832 | \end_layout 833 | 834 | \begin_layout Enumerate 835 | \begin_inset Formula $\mathsf{DelV_{[H(U+S+RndStr_{fallback\,old})]}(Account_{fallback\,old})}$ 836 | \end_inset 837 | 838 | (Delete old Account Packet) 839 | \end_layout 840 | 841 | \begin_layout Standard 842 | The previous Account Packet remains untouched, instead the fallback Access 843 | Packet is redirected to it and the normal Access Packet points to the new 844 | Account Packet. 845 | The previous fallback Account Packet is deleted. 846 | This is a security measure to hinder slow brute-force attacks on decrypting 847 | the Access Packet, which by the time the cleartext random string is obtained 848 | would make it obsolete. 849 | \end_layout 850 | 851 | \begin_layout Subsection 852 | Further Enhancements 853 | \end_layout 854 | 855 | \begin_layout Subsubsection 856 | Time Based Obfuscation 857 | \end_layout 858 | 859 | \begin_layout Standard 860 | In the previous sections a system of self authentication was detailed which 861 | is very effective. 862 | A potential failure point, however, may be the Access Packets, as those 863 | are never altering their location (key) and can pose a target for any attacker 864 | who is monitoring data traffic between the user and the system. 865 | \end_layout 866 | 867 | \begin_layout Standard 868 | To remove this weakness, a predictably altering piece of data can be introduced, 869 | such as time (e.g. 870 | week number, day of year or similar). 871 | In this case in 872 | \begin_inset CommandInset ref 873 | LatexCommand ref 874 | reference "sub:Login-to-a" 875 | 876 | \end_inset 877 | 878 | the 879 | \begin_inset Formula $\mathsf{GetV}$ 880 | \end_inset 881 | 882 | call would be iterative, starting at the current time slot and decrementing 883 | until it returns with a value. 884 | Access Packets at 885 | \begin_inset Quotes eld 886 | \end_inset 887 | 888 | outdated 889 | \begin_inset Quotes erd 890 | \end_inset 891 | 892 | locations would be deleted on detection, and updates always stored in the 893 | current location, resulting in regularly 894 | \begin_inset Quotes eld 895 | \end_inset 896 | 897 | moving 898 | \begin_inset Quotes erd 899 | \end_inset 900 | 901 | packets. 902 | \end_layout 903 | 904 | \begin_layout Subsubsection 905 | Distributed Storage System 906 | \end_layout 907 | 908 | \begin_layout Standard 909 | This system can be enhanced with the introduction of a distributed storage 910 | network as described in 911 | \begin_inset CommandInset citation 912 | LatexCommand cite 913 | key "4" 914 | 915 | \end_inset 916 | 917 | . 918 | This has many advantages including the ability to mask any account data 919 | in a large address space and protect with cryptographically secure privileges 920 | that can prevent unauthorised deletion or any loss of data packets. 921 | 922 | \end_layout 923 | 924 | \begin_layout Section 925 | Conclusions 926 | \end_layout 927 | 928 | \begin_layout Standard 929 | The system presented is one version of a server-less authentication system. 930 | There is a strong case for this to enable true cloud based services with 931 | users being in control of their own data and access privileges. 932 | Such a system can be applied in a multitude of situations and may be particular 933 | ly useful with paid services, which would not require the customer to divulge 934 | any personal information or create yet another identity specifically for 935 | a single service, providing a shared infrastructure exists. 936 | \end_layout 937 | 938 | \begin_layout Standard 939 | We demonstrated a working version of such a system for the first time in 940 | April 2008 in our offices in Troon, Scotland, and as far as we are aware 941 | this was the first time in history a person created their own identity, 942 | stored it and managed all their actions without any server requirement 943 | and without any third party control. 944 | \end_layout 945 | 946 | \begin_layout Section* 947 | Acknowledgment 948 | \end_layout 949 | 950 | \begin_layout Standard 951 | Thanks to Yanick Vézina who provided great assistance in proof reading this 952 | paper. 953 | \end_layout 954 | 955 | \begin_layout Bibliography 956 | \begin_inset CommandInset bibitem 957 | LatexCommand bibitem 958 | label "1" 959 | key "1" 960 | 961 | \end_inset 962 | 963 | as described by Van Jacobson in this link below, August 30, 2006 http://video.Goo 964 | gle.com/videoplay?docid=-6972678839686672840 965 | \end_layout 966 | 967 | \begin_layout Bibliography 968 | \begin_inset CommandInset bibitem 969 | LatexCommand bibitem 970 | label "2" 971 | key "2" 972 | 973 | \end_inset 974 | 975 | David Irvine, Self Encrypting Data, david.irvine@maidsafe.net 976 | \end_layout 977 | 978 | \begin_layout Bibliography 979 | \begin_inset CommandInset bibitem 980 | LatexCommand bibitem 981 | label "3" 982 | key "3" 983 | 984 | \end_inset 985 | 986 | David Irvine, "Peer to Peer" Public Key Infrastructure, david.irvine@maidsafe.net 987 | \end_layout 988 | 989 | \begin_layout Bibliography 990 | \begin_inset CommandInset bibitem 991 | LatexCommand bibitem 992 | label "4" 993 | key "4" 994 | 995 | \end_inset 996 | 997 | David Irvine, maidsafe: A new networking paradigm, david.irvine@maidsafe.net 998 | \end_layout 999 | 1000 | \begin_layout Biography without photo 1001 | \begin_inset Argument 1 1002 | status open 1003 | 1004 | \begin_layout Plain Layout 1005 | David Irvine 1006 | \end_layout 1007 | 1008 | \end_inset 1009 | 1010 | is a Scottish Engineer and innovator who has spent the last 12 years researchin 1011 | g ways to make computers function in a more efficient manner. 1012 | \end_layout 1013 | 1014 | \begin_layout Biography without photo 1015 | He is an Inventor listed on more than 20 patent submissions and was Designer 1016 | of one of the World's largest private networks (Saudi Aramco, over $300M). 1017 | He is an experienced Project Manager and has been involved in start up 1018 | businesses since 1995 and has provided business consultancy to corporates 1019 | and SMEs in many sectors. 1020 | \end_layout 1021 | 1022 | \begin_layout Biography without photo 1023 | He has presented technology at Google (Seattle), British Computer Society 1024 | (Christmas Lecture) and many others. 1025 | \end_layout 1026 | 1027 | \begin_layout Biography without photo 1028 | He has spent many years as a lifeboat Helmsman and is a keen sailor when 1029 | time permits. 1030 | \end_layout 1031 | 1032 | \end_body 1033 | \end_document 1034 | -------------------------------------------------------------------------------- /technical_papers/SelfEncryptingData.lyx: -------------------------------------------------------------------------------- 1 | #LyX 2.1 created this file. For more info see http://www.lyx.org/ 2 | \lyxformat 474 3 | \begin_document 4 | \begin_header 5 | \textclass IEEEtran 6 | \use_default_options false 7 | \maintain_unincluded_children false 8 | \language british 9 | \language_package default 10 | \inputencoding default 11 | \fontencoding global 12 | \font_roman default 13 | \font_sans default 14 | \font_typewriter default 15 | \font_math auto 16 | \font_default_family default 17 | \use_non_tex_fonts false 18 | \font_sc false 19 | \font_osf false 20 | \font_sf_scale 100 21 | \font_tt_scale 100 22 | \graphics default 23 | \default_output_format default 24 | \output_sync 0 25 | \bibtex_command default 26 | \index_command default 27 | \paperfontsize default 28 | \spacing single 29 | \use_hyperref true 30 | \pdf_title "Self Encrypting Data" 31 | \pdf_author "David Irvine" 32 | \pdf_subject "Encryption" 33 | \pdf_keywords "security, freedom, privacy, encryption" 34 | \pdf_bookmarks true 35 | \pdf_bookmarksnumbered false 36 | \pdf_bookmarksopen false 37 | \pdf_bookmarksopenlevel 1 38 | \pdf_breaklinks false 39 | \pdf_pdfborder true 40 | \pdf_colorlinks false 41 | \pdf_backref false 42 | \pdf_pdfusetitle true 43 | \papersize default 44 | \use_geometry false 45 | \use_package amsmath 0 46 | \use_package amssymb 0 47 | \use_package cancel 1 48 | \use_package esint 0 49 | \use_package mathdots 1 50 | \use_package mathtools 1 51 | \use_package mhchem 1 52 | \use_package stackrel 1 53 | \use_package stmaryrd 1 54 | \use_package undertilde 1 55 | \cite_engine basic 56 | \cite_engine_type default 57 | \biblio_style plain 58 | \use_bibtopic true 59 | \use_indices false 60 | \paperorientation portrait 61 | \suppress_date false 62 | \justification true 63 | \use_refstyle 0 64 | \index Index 65 | \shortcut idx 66 | \color #008000 67 | \end_index 68 | \secnumdepth 3 69 | \tocdepth 3 70 | \paragraph_separation indent 71 | \paragraph_indentation default 72 | \quotes_language english 73 | \papercolumns 2 74 | \papersides 1 75 | \paperpagestyle default 76 | \tracking_changes false 77 | \output_changes false 78 | \html_math_output 0 79 | \html_css_as_file 0 80 | \html_be_strict false 81 | \end_header 82 | 83 | \begin_body 84 | 85 | \begin_layout Title 86 | Self Encrypting Data 87 | \end_layout 88 | 89 | \begin_layout Author 90 | \begin_inset Flex Author Name 91 | status open 92 | 93 | \begin_layout Plain Layout 94 | David Irvine 95 | \end_layout 96 | 97 | \end_inset 98 | 99 | 100 | \begin_inset Flex Author Mark 101 | status open 102 | 103 | \begin_layout Plain Layout 104 | 1 105 | \end_layout 106 | 107 | \end_inset 108 | 109 | 110 | \begin_inset Newline newline 111 | \end_inset 112 | 113 | 114 | \begin_inset Flex Author Affiliation 115 | status open 116 | 117 | \begin_layout Plain Layout 118 | MaidSafe.net, 72 Templehill, Troon, South Ayrshire, Scotland, UK. 119 | KA10 6BE. 120 | \end_layout 121 | 122 | \end_inset 123 | 124 | 125 | \begin_inset Newline newline 126 | \end_inset 127 | 128 | 129 | \begin_inset Flex Author Mark 130 | status open 131 | 132 | \begin_layout Plain Layout 133 | 1 134 | \end_layout 135 | 136 | \end_inset 137 | 138 | david.irvine@maidsafe.net 139 | \end_layout 140 | 141 | \begin_layout Page headings 142 | \begin_inset Argument 1 143 | status open 144 | 145 | \begin_layout Plain Layout 146 | Irvine: Self Encrypting Data 147 | \end_layout 148 | 149 | \end_inset 150 | 151 | 152 | \end_layout 153 | 154 | \begin_layout Address 155 | First published September 2010. 156 | Revised June 2015. 157 | \end_layout 158 | 159 | \begin_layout Abstract 160 | This paper presents a system of encryption that requires no user intervention 161 | or passwords. 162 | The resultant data item then has to be saved or stored somewhere as in 163 | all methods. 164 | The encryption here is aimed at creating cipher-text (encrypted) objects 165 | that are extremely strong and closer to perfect in terms of reversibility, 166 | as opposed to known encryption ciphers available today. 167 | This paper focuses on symmetric encryption, but does not introduce a new 168 | cipher. 169 | Instead the paper describes a method of enhancing the use of this technology 170 | to produce highly secure data and, to do so in many situations and implementati 171 | ons. 172 | \end_layout 173 | 174 | \begin_layout Keywords 175 | security, freedom, privacy, encryption 176 | \end_layout 177 | 178 | \begin_layout Standard 179 | \begin_inset CommandInset toc 180 | LatexCommand tableofcontents 181 | 182 | \end_inset 183 | 184 | 185 | \end_layout 186 | 187 | \begin_layout Section 188 | Introduction 189 | \end_layout 190 | 191 | \begin_layout Standard 192 | \begin_inset Flex Paragraph Start 193 | status open 194 | 195 | \begin_layout Plain Layout 196 | \begin_inset Argument 1 197 | status open 198 | 199 | \begin_layout Plain Layout 200 | E 201 | \end_layout 202 | 203 | \end_inset 204 | 205 | ncryption 206 | \end_layout 207 | 208 | \end_inset 209 | 210 | has been a goal of man since before the times of the Romans, and Caesar 211 | Ciphers (simple replacement ciphers) through Enigma machine ciphers to 212 | modern day complex matrix manipulations are present in abundance in computer 213 | enhanced algorithms. 214 | This paper describes a way to use such algorithms in addition to direct 215 | encryption that clearly shows significant improvements in our use of encryption. 216 | \end_layout 217 | 218 | \begin_layout Subsection 219 | The Issues Addressed by this Paper 220 | \end_layout 221 | 222 | \begin_layout Standard 223 | The issue with today's encryption of data is in just that; we encrypt data, 224 | as a whole. 225 | This reduces the potential set of possible inputs, i.e. 226 | if we are chasing somebody's bank balance, we may expect the output to 227 | be roughly the size of a bank statement, and guess what? It is! Furthermore, 228 | the security of a whole piece of data encrypted with a single algorithm 229 | depends upon just that single algorithm not getting broken. 230 | Almost all encryption ciphers appear to reduce in effectiveness as we understan 231 | d the mathematics better and create more powerful computers. 232 | One may believe then, that the answer is to encrypt bits of files. 233 | However, this would require many passwords or algorithms; like putting 234 | more locks on a door to make it more secure, it gives people a headache 235 | to think that they may have to remember multiple passwords for each file. 236 | This is unlikely to be a successful manoeuvre. 237 | \end_layout 238 | 239 | \begin_layout Subsection 240 | Conventions Used 241 | \end_layout 242 | 243 | \begin_layout Standard 244 | This paper does not require all the operations listed below, but lists these 245 | for example implementations, which are outlined later. 246 | \end_layout 247 | 248 | \begin_layout Standard 249 | Hash = Hash function such as SHA, MD5, etc. 250 | We assume a cryptographically secure algorithm. 251 | \end_layout 252 | 253 | \begin_layout Standard 254 | Enc = Symmetrical encryption such as AES, 3DES, etc. 255 | \end_layout 256 | 257 | \begin_layout Subsection 258 | Symmetric Encryption 259 | \end_layout 260 | 261 | \begin_layout Standard 262 | This paper will use AES as an example to cover all symmetric encryption 263 | algorithms (to some extent) and therefore will use a key and initialisation 264 | vector and plain-text input data. 265 | There will be no mention of MAC or similar additions to the algorithms 266 | in the hope that the reader would not attempt to implement a poorly stated 267 | or incorrect algorithm. 268 | The primary role in, interestingly, not encryption, it is to produce difficult 269 | to guess uncompress-able output. 270 | There may be alternative methods of producing difficult to guess uncompress-abl 271 | e output, these are not considered here. 272 | \end_layout 273 | 274 | \begin_layout Proposition 275 | Difficult to guess and uncompress-able output equates to random results 276 | based on random input data and random, unrelated algorithm inputs (plain 277 | text, key and iv in the case of modern symmetric cyphers). 278 | \end_layout 279 | 280 | \begin_layout Subsection 281 | Cryptographically Secure Hash 282 | \begin_inset CommandInset label 283 | LatexCommand label 284 | name "sub:Cryptographically-secure-hash" 285 | 286 | \end_inset 287 | 288 | 289 | \end_layout 290 | 291 | \begin_layout Fact 292 | The ideal cryptographic hash function has four main or significant properties: 293 | \end_layout 294 | 295 | \begin_layout Enumerate 296 | it is easy (but not necessarily quick) to compute the hash value for any 297 | given message 298 | \end_layout 299 | 300 | \begin_layout Enumerate 301 | it is infeasible to generate a message that has a given hash 302 | \end_layout 303 | 304 | \begin_layout Enumerate 305 | it is infeasible to modify a message without changing the hash 306 | \end_layout 307 | 308 | \begin_layout Enumerate 309 | it is infeasible to find two different messages with the same hash 310 | \end_layout 311 | 312 | \begin_layout Conjecture 313 | A cryptographically secure hash which is a one way function will create 314 | output that has a uniform distribution and can be computed in polynomial 315 | time. 316 | The output should be in fact random, although can be affected by size of 317 | input. 318 | Given a sufficiently large input the output will be random (within limits). 319 | The size of input required is dependent on the strength of the hash functions 320 | employed. 321 | In essence output can be considered evenly distributed and random. 322 | The limits of this randomness are not presented in this paper. 323 | It is assumed a sufficiently secure algorithm acting on a significantly 324 | large input will produce randomness that is acceptable for this conjecture. 325 | \end_layout 326 | 327 | \begin_layout Standard 328 | A hash function can be thought of as a digital fingerprint. 329 | Just as a fingerprint of a person is supposed to be unique, then a digital 330 | hash function is also supposedly unique. 331 | We have all heard of two people with identical fingerprints (but perhaps 332 | have never met any!) and in the digital world it can be possible to get 333 | two pieces of data with the same hash result. 334 | This is referred to as a collision and reduces the security of the hash 335 | algorithm. 336 | The more secure the algorithm, then the likelihood of a collision is reduced. 337 | It is very similar to taking more points of reference on an actual fingerprint 338 | to reduce collisions in that area of science also. 339 | This is an area where both systems share a similarity in the increasing 340 | complexity of measurement and recording of data points of reference. 341 | \end_layout 342 | 343 | \begin_layout Standard 344 | In cryptographically secure hashing, the data is analysed and a fixed length 345 | key called the hash of the data is produced. 346 | Again similarly to human fingerprinting a hash cannot reveal data just 347 | as a fingerprint cannot reveal a person (i.e. 348 | you cannot recreate the person from the print) and you cannot recreate 349 | the data from the hash. 350 | \end_layout 351 | 352 | \begin_layout Standard 353 | Early hash algorithms such as MD4, MD5 and even early SHA are considered 354 | broken, in the sense that they simply allow too many collisions to occur. 355 | Hence larger descriptors (keylengths) and more efficient algorithms are 356 | almost always required. 357 | \begin_inset Foot 358 | status open 359 | 360 | \begin_layout Plain Layout 361 | you can see where the problem exists as the logical conclusion is a key 362 | longer than any known piece of uncompress-able data, to ensure no collisions 363 | \end_layout 364 | 365 | \end_inset 366 | 367 | 368 | \end_layout 369 | 370 | \begin_layout Section 371 | Implementation 372 | \end_layout 373 | 374 | \begin_layout Subsection 375 | Overview 376 | \begin_inset CommandInset label 377 | LatexCommand label 378 | name "sub:Overvew" 379 | 380 | \end_inset 381 | 382 | 383 | \end_layout 384 | 385 | \begin_layout Enumerate 386 | Split into several chunks (C 387 | \begin_inset Formula $_{n}$ 388 | \end_inset 389 | 390 | ). 391 | \end_layout 392 | 393 | \begin_layout Enumerate 394 | Take hash of each chunk (H 395 | \begin_inset Formula $_{c_{n}})$ 396 | \end_inset 397 | 398 | . 399 | \end_layout 400 | 401 | \begin_layout Enumerate 402 | In case of AES or similar cypher, use [keysize] (C 403 | \begin_inset Formula $_{n-1})$ 404 | \end_inset 405 | 406 | as the key, use [next bytes iv size](C 407 | \begin_inset Formula $_{n-1})$ 408 | \end_inset 409 | 410 | as the IV. 411 | (for AES 0 to 32 == key and 32 to 48 == iv) 412 | \end_layout 413 | 414 | \begin_layout Enumerate 415 | Create obfuscation chunk (OBFC 416 | \begin_inset Formula $_{n}$ 417 | \end_inset 418 | 419 | ) by concatenating the hashes of other chunks (C 420 | \begin_inset Formula $_{n}$ 421 | \end_inset 422 | 423 | , [unused part of]C 424 | \begin_inset Formula $_{n-1}$ 425 | \end_inset 426 | 427 | and C 428 | \begin_inset Formula $_{n-2}$ 429 | \end_inset 430 | 431 | ). 432 | \end_layout 433 | 434 | \begin_layout Enumerate 435 | Run encryption cypher or similar reversible method on (C 436 | \begin_inset Formula $_{n})$ 437 | \end_inset 438 | 439 | , to produce (C 440 | \begin_inset Formula $_{random}$ 441 | \end_inset 442 | 443 | ). 444 | \end_layout 445 | 446 | \begin_layout Enumerate 447 | Now data is considered to be randomised and of the same length as input 448 | data. 449 | \end_layout 450 | 451 | \begin_layout Enumerate 452 | OBFC 453 | \begin_inset Formula $_{n}$ 454 | \end_inset 455 | 456 | is also random output, but of a length less than the input data. 457 | \end_layout 458 | 459 | \begin_layout Enumerate 460 | Now we take OBFC 461 | \begin_inset Formula $_{n}(repeated)\;XOR\;C_{random}$ 462 | \end_inset 463 | 464 | to produce our output data. 465 | \end_layout 466 | 467 | \begin_layout Enumerate 468 | Rename each with the hash of the new content and save these hashes. 469 | \end_layout 470 | 471 | \begin_layout Definition 472 | One Time Pad as defined by Shannon 473 | \begin_inset CommandInset citation 474 | LatexCommand cite 475 | key "2,5" 476 | 477 | \end_inset 478 | 479 | is regarded as the only cryptosystem with theoretically perfect secrecy. 480 | It posseses the following 3 items that define it: 481 | \end_layout 482 | 483 | \begin_layout Enumerate 484 | Pads cannot be reused. 485 | \end_layout 486 | 487 | \begin_layout Enumerate 488 | For a Shannon implementation as opposed to earlier cyclic pads, the pad 489 | must be as long as the message to be encrypted. 490 | i.e. 491 | a pad must be non repeating. 492 | This is the enhancement that takes this system a step further than the 493 | Vernam cypher 494 | \begin_inset CommandInset citation 495 | LatexCommand cite 496 | key "3,4" 497 | 498 | \end_inset 499 | 500 | 501 | \end_layout 502 | 503 | \begin_layout Enumerate 504 | The pad must contain only random data. 505 | \end_layout 506 | 507 | \begin_layout Fact 508 | In this paper on the NSA web site, the Vernam cypher appears as the 509 | \emph on 510 | unbreakable cypher 511 | \emph default 512 | for on line tty (teleprinter) encryption, although XOR in this case is 513 | called modulo 2 division (simply different wording for the same mathematical 514 | operation). 515 | This paper is found here http://www.nsa.gov/about/_files/ cryptologic_heritage/pu 516 | blications/misc/tsec_kw26.pdf The title of this paper is 517 | \begin_inset Quotes eld 518 | \end_inset 519 | 520 | Securing Record Communications: The TSEC/KW-26 521 | \begin_inset Quotes erd 522 | \end_inset 523 | 524 | . 525 | \end_layout 526 | 527 | \begin_layout Conjecture 528 | As the Shannon system suggests a one time use random pad that is longer 529 | than the data to be encrypted is required for a true one time pad. 530 | In this paper we have used a symmetric encryption cypher (AES as example, 531 | with CFB) to introduce what can be described as randomness to the data 532 | itself. 533 | If this is truly random then it's the perfect pad in it's own right. 534 | We have also created an Obfuscation pad, which almost creates a pad that 535 | is usable as a OTP, however it fails to answer 2 above, i.e. 536 | it repeats as it's shorted than the data to be encrypted. 537 | \end_layout 538 | 539 | \begin_layout Proposition 540 | We propose given the above definition and conjecture that the data itself 541 | be considered the pad and the obfuscation chunk is now repeating data (which 542 | is allowed by the definition of the Shannon Pad), although this is rather 543 | large amount of repeating data, it is also repeating random data. 544 | We propose this be considered as a form of one time pad. 545 | Added to that we also propose the actions taken on the data ton include 546 | randomness as well as pad randomness may in fact take the whole concept 547 | of OTP, just a little further, making a guess significantly more difficult. 548 | \end_layout 549 | 550 | \begin_layout Subsection 551 | File Chunking 552 | \end_layout 553 | 554 | \begin_layout Definition 555 | \align left 556 | \begin_inset Formula $\mathsf{f_{c}}$ 557 | \end_inset 558 | 559 | ≡ file content; 560 | \begin_inset Formula $\mathsf{f_{m}}$ 561 | \end_inset 562 | 563 | ≡ file metadata; 564 | \begin_inset Formula $\mathsf{fh}$ 565 | \end_inset 566 | 567 | ≡ 568 | \begin_inset Formula $\mathsf{H(f_{c})}$ 569 | \end_inset 570 | 571 | or 572 | \begin_inset Formula $\mathsf{fh\equiv H(H(C_{1})+H(C_{2})+...H(C_{n-1}))}$ 573 | \end_inset 574 | 575 | . 576 | \end_layout 577 | 578 | \begin_layout Enumerate 579 | Take the size of the file 580 | \begin_inset Formula $\mathsf{(f.size())}$ 581 | \end_inset 582 | 583 | and calculate number 584 | \begin_inset Formula $\mathsf{n}$ 585 | \end_inset 586 | 587 | of chunks 588 | \begin_inset Foot 589 | status open 590 | 591 | \begin_layout Plain Layout 592 | Number of chunks is a setting and depends on implementation, you may wish 593 | a max number of chunks, or maximum chunk size, this decision and code is 594 | left to the reader. 595 | \end_layout 596 | 597 | \end_inset 598 | 599 | 600 | \end_layout 601 | 602 | \begin_layout Enumerate 603 | Create chunks of 1MB (settable) in length and hash these chunks. 604 | \end_layout 605 | 606 | \begin_layout Enumerate 607 | Take hash of each chunk and log these hashes in a structure, which we will 608 | refer to as a data map. 609 | \end_layout 610 | 611 | \begin_layout Standard 612 | The chunks are created with fixed size to ensure the set required to recreate 613 | the file is as almost as large as the number of available chunks in any 614 | data store. 615 | This data map is mapped to file metadata through 616 | \begin_inset Formula $\mathsf{fh}$ 617 | \end_inset 618 | 619 | . 620 | \end_layout 621 | 622 | \begin_layout Subsection 623 | Encryption Step 624 | \end_layout 625 | 626 | \begin_layout Standard 627 | In the encryption stage, we require two separate non deterministic pieces 628 | of data, the encryption key (or password) and the Initialisation Vector 629 | (IV). 630 | To ensure all data encrypts to the same end result we determine the IV 631 | from what can be considered non deterministic data 632 | \begin_inset Foot 633 | status open 634 | 635 | \begin_layout Plain Layout 636 | This is an area of debate as to whether this is non deterministic data, 637 | in this case the argument is that the only way to determine the data is 638 | to have the original data in the first place, therefore there is no need 639 | to determine keys as it would be fruitless. 640 | This is somewhat of a philosophical debate and likely to be the topic of 641 | a few furled eyebrows over a few drams in a few bars for a few years to 642 | come. 643 | \end_layout 644 | 645 | \end_inset 646 | 647 | , that being the hash of one of the chunks. 648 | \end_layout 649 | 650 | \begin_layout Definition 651 | Encrypt with key and IV is shown as 652 | \begin_inset Formula $\mathsf{Enc_{[key][IV]}(data)}$ 653 | \end_inset 654 | 655 | in the following example. 656 | It is assumed the key and the IV for chunk 657 | \begin_inset Formula $\mathsf{n}$ 658 | \end_inset 659 | 660 | are derived from separate portions of the hash of chunk 661 | \begin_inset Formula $\mathsf{n-1}$ 662 | \end_inset 663 | 664 | . 665 | In the case of AES for instance the first 32 bytes of this hash are the 666 | Key and the next 16 bytes may be presumed to be the IV. 667 | Therefore these items are selected from random data, although the randomness 668 | can be deterministic (if we can guess the output of an algorithm such as 669 | AES, by guessing the input parameters, i.e. 670 | brute force) on the case of a one way function such as a cryptographic 671 | hash (as discussed). 672 | \end_layout 673 | 674 | \begin_layout Example 675 | \begin_inset Formula $\mathsf{Enc_{[H(C_{n-1})first32bytes][H(C_{n-1})bytes32to48]}(C_{n})\equiv E_{n}}$ 676 | \end_inset 677 | 678 | 679 | \end_layout 680 | 681 | \begin_layout Subsection 682 | Obfuscation Step 683 | \end_layout 684 | 685 | \begin_layout Standard 686 | In the obfuscation step, we pollute each chunk with data from other chunks. 687 | \end_layout 688 | 689 | \begin_layout Example 690 | For 691 | \begin_inset Formula $\mathsf{E_{n}}$ 692 | \end_inset 693 | 694 | , create an identically-sized data chunk by repeated concatenating the hash 695 | of chunk 696 | \begin_inset Formula $\mathsf{n}$ 697 | \end_inset 698 | 699 | with the unused part of the hash of chunk 700 | \begin_inset Formula $\mathsf{n-1}$ 701 | \end_inset 702 | 703 | and the hash of chunk 704 | \begin_inset Formula $\mathsf{n-2}$ 705 | \end_inset 706 | 707 | , then trimming to size, i.e. 708 | 709 | \begin_inset Formula $\mathsf{H(C_{n})+H(C_{n-1})last16bytes+H(C_{n-2})+H(C_{n})+...}$ 710 | \end_inset 711 | 712 | 713 | \end_layout 714 | 715 | \begin_layout Standard 716 | This is called the XOR chunk 717 | \begin_inset Formula $\mathsf{n}$ 718 | \end_inset 719 | 720 | ( 721 | \begin_inset Formula $\mathsf{X_{n}}$ 722 | \end_inset 723 | 724 | ) and is unsurprisingly XORed ( 725 | \begin_inset Formula $\bigoplus$ 726 | \end_inset 727 | 728 | ) with chunk 729 | \begin_inset Formula $\mathsf{n}$ 730 | \end_inset 731 | 732 | . 733 | \begin_inset Foot 734 | status open 735 | 736 | \begin_layout Plain Layout 737 | In this case we have selected XOR to represent a logical operation to obfuscate 738 | the data, this is not restrictive in any way and may be replaced by other 739 | obfuscation methods. 740 | \end_layout 741 | 742 | \end_inset 743 | 744 | 745 | \end_layout 746 | 747 | \begin_layout Example 748 | \align left 749 | \begin_inset Formula $\mathsf{E_{1}\bigoplus X_{1}\equiv EX_{1}}$ 750 | \end_inset 751 | 752 | , 753 | \begin_inset Formula $\mathsf{E_{2}\bigoplus X_{2}\equiv EX_{2}}$ 754 | \end_inset 755 | 756 | , etc. 757 | \end_layout 758 | 759 | \begin_layout Subsection 760 | Data Map 761 | \end_layout 762 | 763 | \begin_layout Standard 764 | In the previous sections, we described the process of self encrypting data. 765 | However, it did leave an important question unanswered. 766 | How do we reverse this process to retrieve the plain-text from the cipher-text 767 | chunks? The answer is data maps. 768 | \end_layout 769 | 770 | \begin_layout Standard 771 | In the 772 | \begin_inset CommandInset ref 773 | LatexCommand ref 774 | reference "sub:Overvew" 775 | 776 | \end_inset 777 | 778 | steps 1, 3 & 7 we collected important data. 779 | This data alone is enough to reverse the encryption process and this is 780 | stored in a structure we refer to as a data map. 781 | This is described in the following table. 782 | \end_layout 783 | 784 | \begin_layout Standard 785 | \begin_inset Tabular 786 | 787 | 788 | 789 | 790 | 791 | 792 | \begin_inset Text 793 | 794 | \begin_layout Plain Layout 795 | \begin_inset Formula $\mathsf{fh=H(H(C_{1})+H(C_{2})+...H(C_{n-1}))}$ 796 | \end_inset 797 | 798 | 799 | \begin_inset Foot 800 | status open 801 | 802 | \begin_layout Plain Layout 803 | In this case we use the hash of the concatenated pre-encryption hashes as 804 | the file hash. 805 | This is simply more efficient in terms of cpu time. 806 | The full file hash may be used and is left to the reader to decide on which 807 | method suits better. 808 | \end_layout 809 | 810 | \end_inset 811 | 812 | 813 | \end_layout 814 | 815 | \end_inset 816 | 817 | 818 | \begin_inset Text 819 | 820 | \begin_layout Plain Layout 821 | 822 | \end_layout 823 | 824 | \end_inset 825 | 826 | 827 | 828 | 829 | \begin_inset Text 830 | 831 | \begin_layout Plain Layout 832 | \begin_inset Formula $\mathsf{H(C_{1})}$ 833 | \end_inset 834 | 835 | 836 | \end_layout 837 | 838 | \end_inset 839 | 840 | 841 | \begin_inset Text 842 | 843 | \begin_layout Plain Layout 844 | \begin_inset Formula $\mathsf{H(EX_{1})}$ 845 | \end_inset 846 | 847 | 848 | \end_layout 849 | 850 | \end_inset 851 | 852 | 853 | 854 | 855 | \begin_inset Text 856 | 857 | \begin_layout Plain Layout 858 | \begin_inset Formula $\mathsf{H(C_{2})}$ 859 | \end_inset 860 | 861 | 862 | \end_layout 863 | 864 | \end_inset 865 | 866 | 867 | \begin_inset Text 868 | 869 | \begin_layout Plain Layout 870 | \begin_inset Formula $\mathsf{H(EX_{2})}$ 871 | \end_inset 872 | 873 | 874 | \end_layout 875 | 876 | \end_inset 877 | 878 | 879 | 880 | 881 | \begin_inset Text 882 | 883 | \begin_layout Plain Layout 884 | \begin_inset Formula $\ldots$ 885 | \end_inset 886 | 887 | 888 | \end_layout 889 | 890 | \end_inset 891 | 892 | 893 | \begin_inset Text 894 | 895 | \begin_layout Plain Layout 896 | \begin_inset Formula $\ldots$ 897 | \end_inset 898 | 899 | 900 | \end_layout 901 | 902 | \end_inset 903 | 904 | 905 | 906 | 907 | \begin_inset Text 908 | 909 | \begin_layout Plain Layout 910 | \begin_inset Formula $\mathsf{H(C_{n})}$ 911 | \end_inset 912 | 913 | 914 | \end_layout 915 | 916 | \end_inset 917 | 918 | 919 | \begin_inset Text 920 | 921 | \begin_layout Plain Layout 922 | \begin_inset Formula $\mathsf{H(EX_{n})}$ 923 | \end_inset 924 | 925 | 926 | \end_layout 927 | 928 | \end_inset 929 | 930 | 931 | 932 | 933 | \end_inset 934 | 935 | 936 | \end_layout 937 | 938 | \begin_layout Standard 939 | With this structure the names of all the chunks are in the right hand column 940 | and all keys and IVs (which are derived from the original chunk hashes) 941 | are stored in the left hand column. 942 | The file hash in the top row identifies the data element and acts as the 943 | unique key for this file. 944 | Reversing the process is now obvious. 945 | \end_layout 946 | 947 | \begin_layout Enumerate 948 | Retrieve the chunks listed in right hand column. 949 | \end_layout 950 | 951 | \begin_layout Enumerate 952 | Create each XOR chunk again. 953 | \end_layout 954 | 955 | \begin_layout Enumerate 956 | Reverse the obfuscation stage. 957 | \end_layout 958 | 959 | \begin_layout Enumerate 960 | Decrypt each result. 961 | \end_layout 962 | 963 | \begin_layout Enumerate 964 | Concatenate the results. 965 | \end_layout 966 | 967 | \begin_layout Standard 968 | This is the complete encrypt / decrypt process for each file. 969 | \end_layout 970 | 971 | \begin_layout Section 972 | Future works 973 | \end_layout 974 | 975 | \begin_layout Standard 976 | To provide effectiveness the algorithms presented in this paper will require 977 | the addition of a secure mechanism to protect the data map. 978 | This will be furthered in an example of self authenticating system that 979 | will use this as entry to a system. 980 | \end_layout 981 | 982 | \begin_layout Standard 983 | In addition the information should be looked after a network or system that 984 | is secured itself. 985 | This would require a very secure network or perhaps even the advancement 986 | of a self-managing, self-healing network. 987 | This will be presented in a future paper on such a system. 988 | \end_layout 989 | 990 | \begin_layout Section 991 | Conclusions 992 | \end_layout 993 | 994 | \begin_layout Standard 995 | This process allows for multiple data elements to be encrypted in a very 996 | powerful fashion. 997 | Indeed there may be some debate as to whether the encryption or obfuscation 998 | stages cannot be left out (well, at least one of them). 999 | It is decided this is not a bottleneck in such a system, as data can be 1000 | processed at speeds in excess of current networking capabilities in many 1001 | cases. 1002 | This is open to further research for differing situations though. 1003 | \end_layout 1004 | 1005 | \begin_layout Standard 1006 | An important issue here is that all data is encrypted using no user information 1007 | or input. 1008 | This means that if the container for all the chunks is a single container 1009 | then duplicate files will produce the exact same chunks and the storage 1010 | system can automatically remove duplicate information. 1011 | It is estimated the savings in such a system would be greater than 95%. 1012 | \end_layout 1013 | 1014 | \begin_layout Standard 1015 | Also interesting is the fact that the encryption may be seen as a 1016 | \begin_inset Quotes eld 1017 | \end_inset 1018 | 1019 | step too far 1020 | \begin_inset Quotes erd 1021 | \end_inset 1022 | 1023 | ; nevertheless it does indicate that any break in an encryption cipher will 1024 | not reveal any data to an attacker. 1025 | This is a valuable and important point. 1026 | \end_layout 1027 | 1028 | \begin_layout Standard 1029 | It is hoped the research in this field will continue and measures of number 1030 | of chunks versus data map size, etc. 1031 | would reveal interesting scope for optimisations and improvements. 1032 | \end_layout 1033 | 1034 | \begin_layout Standard 1035 | Compression has been missed out from the steps in this paper and can be 1036 | simply added to the process of hash/encryption of each chunk. 1037 | This further improves efficiency, particularly with regard to improving 1038 | data de-duplication results. 1039 | \end_layout 1040 | 1041 | \begin_layout Bibliography 1042 | \labelwidthstring References 1043 | \begin_inset CommandInset bibitem 1044 | LatexCommand bibitem 1045 | label "1" 1046 | key "1" 1047 | 1048 | \end_inset 1049 | 1050 | David Irvine, maidsafe: A new networking paradigm, david.irvine@maidsafe.net 1051 | \end_layout 1052 | 1053 | \begin_layout Bibliography 1054 | \labelwidthstring References 1055 | \begin_inset CommandInset bibitem 1056 | LatexCommand bibitem 1057 | label "2" 1058 | key "2" 1059 | 1060 | \end_inset 1061 | 1062 | Shannon, Claude (1949). 1063 | "Communication Theory of Secrecy Systems". 1064 | Bell System Technical Journal 28 (4): 656–715. 1065 | \end_layout 1066 | 1067 | \begin_layout Bibliography 1068 | \labelwidthstring References 1069 | \begin_inset CommandInset bibitem 1070 | LatexCommand bibitem 1071 | label "3" 1072 | key "3" 1073 | 1074 | \end_inset 1075 | 1076 | Gilbert S. 1077 | Vernam, "Cipher Printing Telegraph Systems For Secret Wire and Radio Telegraphi 1078 | c Communications", Journal of the IEEE, Vol 55, pp109–115 (1926). 1079 | \end_layout 1080 | 1081 | \begin_layout Bibliography 1082 | \labelwidthstring References 1083 | \begin_inset CommandInset bibitem 1084 | LatexCommand bibitem 1085 | label "4" 1086 | key "4" 1087 | 1088 | \end_inset 1089 | 1090 | Gilbert S. 1091 | Vernam, "Automatic Telegraph Switching System Plan 55-A", AIEE Transactions 1092 | on Communication and Electronics, May 1958, p. 1093 | 239. 1094 | Also in Western Union Technical Review Vol 12 No 2, April 1958, p. 1095 | 37. 1096 | \end_layout 1097 | 1098 | \begin_layout Bibliography 1099 | \labelwidthstring References 1100 | \begin_inset CommandInset bibitem 1101 | LatexCommand bibitem 1102 | label "5" 1103 | key "5" 1104 | 1105 | \end_inset 1106 | 1107 | C.E. 1108 | Shannon, “Communication Theory of Secrecy Systems,” Bell System Technical 1109 | Journal, Vol. 1110 | 28, No. 1111 | 4 (October 1949), pp. 1112 | 656–715. 1113 | \end_layout 1114 | 1115 | \begin_layout Biography without photo 1116 | \begin_inset Argument 1 1117 | status open 1118 | 1119 | \begin_layout Plain Layout 1120 | David Irvine 1121 | \end_layout 1122 | 1123 | \end_inset 1124 | 1125 | is a Scottish Engineer and innovator who has spent the last 12 years researchin 1126 | g ways to make computers function in a more efficient manner. 1127 | \end_layout 1128 | 1129 | \begin_layout Biography without photo 1130 | He is an Inventor listed on more than 20 patent submissions and was Designer 1131 | of one of the World's largest private networks (Saudi Aramco, over $300M). 1132 | He is an experienced Project Manager and has been involved in start up 1133 | businesses since 1995 and has provided business consultancy to corporates 1134 | and SMEs in many sectors. 1135 | \end_layout 1136 | 1137 | \begin_layout Biography without photo 1138 | He has presented technology at Google (Seattle), British Computer Society 1139 | (Christmas Lecture) and many others. 1140 | \end_layout 1141 | 1142 | \begin_layout Biography without photo 1143 | He has spent many years as a lifeboat Helmsman and is a keen sailor when 1144 | time permits. 1145 | \end_layout 1146 | 1147 | \end_body 1148 | \end_document 1149 | -------------------------------------------------------------------------------- /technical_papers/img/Reference_List_Add.ddd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/technical_papers/img/Reference_List_Add.ddd -------------------------------------------------------------------------------- /technical_papers/img/Reference_List_Add.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/technical_papers/img/Reference_List_Add.pdf -------------------------------------------------------------------------------- /technical_papers/img/STORE_NEW_CHUNK.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/technical_papers/img/STORE_NEW_CHUNK.pdf -------------------------------------------------------------------------------- /technical_papers/img/Watch_List_Add.ddd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/technical_papers/img/Watch_List_Add.ddd -------------------------------------------------------------------------------- /technical_papers/img/Watch_List_Add.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/technical_papers/img/Watch_List_Add.pdf -------------------------------------------------------------------------------- /technical_papers/img/Watch_List_Payment.ddd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/technical_papers/img/Watch_List_Payment.ddd -------------------------------------------------------------------------------- /technical_papers/img/Watch_List_Payment.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/technical_papers/img/Watch_List_Payment.pdf -------------------------------------------------------------------------------- /technical_papers/img/Watch_List_Remove.ddd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/technical_papers/img/Watch_List_Remove.ddd -------------------------------------------------------------------------------- /technical_papers/img/Watch_List_Remove.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/technical_papers/img/Watch_List_Remove.pdf -------------------------------------------------------------------------------- /technical_papers/img/safecoin farming speed.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/technical_papers/img/safecoin farming speed.png -------------------------------------------------------------------------------- /technical_papers/img/safecoin resources.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/technical_papers/img/safecoin resources.png -------------------------------------------------------------------------------- /technical_papers/img/safecoin transfer mech.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/technical_papers/img/safecoin transfer mech.png -------------------------------------------------------------------------------- /technical_papers/safecoin citations.bib: -------------------------------------------------------------------------------- 1 | %% This BibTeX bibliography file was created using BibDesk. 2 | %% http://bibdesk.sourceforge.net/ 3 | 4 | 5 | %% Created for Nick Lambert at 2015-01-07 10:11:39 +0000 6 | 7 | 8 | %% Saved with string encoding Unicode (UTF-8) 9 | 10 | 11 | 12 | @jurthesis{19, 13 | Date-Added = {2015-01-07 10:07:00 +0000}, 14 | Date-Modified = {2015-01-07 10:11:29 +0000}, 15 | Lastchecked = {7}, 16 | Month = {January}, 17 | Title = {Kademlia wikipedia page}, 18 | Url = {http://en.wikipedia.org/wiki/Kademlia}, 19 | Year = {2015}} 20 | 21 | @webpage{18, 22 | Author = {John Aziz}, 23 | Date-Added = {2014-12-11 16:38:39 +0000}, 24 | Date-Modified = {2014-12-11 16:40:04 +0000}, 25 | Lastchecked = {11}, 26 | Month = {December}, 27 | Title = {Does the Federal Reserve really control the money supply?}, 28 | Url = {http://theweek.com/article/index/244899/does-the-federal-reserve-really-control-the-money-supply}, 29 | Year = {2014}, 30 | Bdsk-Url-1 = {http://theweek.com/article/index/244899/does-the-federal-reserve-really-control-the-money-supply}} 31 | 32 | @webpage{17, 33 | Author = {Paul Krugman}, 34 | Date-Added = {2014-12-11 15:08:47 +0000}, 35 | Date-Modified = {2014-12-11 15:10:58 +0000}, 36 | Lastchecked = {11}, 37 | Month = {December}, 38 | Title = {The textbook economics of cap-and-trade}, 39 | Url = {http://krugman.blogs.nytimes.com/2009/09/27/the-textbook-economics-of-cap-and-trade/?_r=0}, 40 | Year = {2014}, 41 | Bdsk-Url-1 = {http://krugman.blogs.nytimes.com/2009/09/27/the-textbook-economics-of-cap-and-trade/?_r=0}} 42 | 43 | @webpage{16, 44 | Author = {The Atlantic}, 45 | Date-Added = {2014-11-28 11:03:07 +0000}, 46 | Date-Modified = {2014-11-28 11:03:45 +0000}, 47 | Lastchecked = {28}, 48 | Month = {November}, 49 | Title = {The Internet's Original Sin}, 50 | Url = {http://www.theatlantic.com/technology/archive/2014/08/advertising-is-the-internets-original-sin/376041/}, 51 | Year = {2014}, 52 | Bdsk-Url-1 = {http://www.theatlantic.com/technology/archive/2014/08/advertising-is-the-internets-original-sin/376041/}} 53 | 54 | @webpage{15, 55 | Author = {Facebook Inc}, 56 | Date-Added = {2014-11-28 11:00:05 +0000}, 57 | Date-Modified = {2014-11-28 11:00:53 +0000}, 58 | Lastchecked = {28}, 59 | Month = {November}, 60 | Title = {Facebook Reports Fourth Quarter and Full Year 2013 Results}, 61 | Url = {http://investor.fb.com/releasedetail.cfm?ReleaseID=821954}, 62 | Year = {2014}, 63 | Bdsk-Url-1 = {http://investor.fb.com/releasedetail.cfm?ReleaseID=821954}} 64 | 65 | @jurthesis{14, 66 | Author = {Google Inc}, 67 | Date-Added = {2014-11-28 10:58:41 +0000}, 68 | Date-Modified = {2014-12-11 16:48:12 +0000}, 69 | Lastchecked = {28}, 70 | Month = {November}, 71 | Title = {2013 Financial Tables}, 72 | Url = {https://investor.google.com/financial/2013/tables.html}, 73 | Year = {2014}, 74 | Bdsk-Url-1 = {https://investor.google.com/financial/2013/tables.html}} 75 | 76 | @webpage{13, 77 | Author = {Joe McCann}, 78 | Date-Added = {2014-11-28 10:55:50 +0000}, 79 | Date-Modified = {2014-11-28 11:01:03 +0000}, 80 | Lastchecked = {28}, 81 | Month = {November}, 82 | Title = {Data Is The Most Valuable Commodity On Earth}, 83 | Url = {http://subprint.com/blog/data-is-the-most-valuable-commodity-on-earth}, 84 | Year = {2014}, 85 | Bdsk-Url-1 = {http://subprint.com/blog/data-is-the-most-valuable-commodity-on-earth}} 86 | 87 | @webpage{12, 88 | Author = {World Economic Forum}, 89 | Date-Added = {2014-11-28 10:51:45 +0000}, 90 | Date-Modified = {2014-11-28 10:52:51 +0000}, 91 | Lastchecked = {28}, 92 | Month = {November}, 93 | Title = {Personal Data: The Emergence of a New Asset Class}, 94 | Url = {http://www3.weforum.org/docs/WEF_ITTC_PersonalDataNewAsset_Report_2011.pdf}, 95 | Year = {2014}, 96 | Bdsk-Url-1 = {http://www3.weforum.org/docs/WEF_ITTC_PersonalDataNewAsset_Report_2011.pdf}} 97 | 98 | @webpage{11, 99 | Author = {BBC News Web Page}, 100 | Date-Added = {2014-11-28 10:36:05 +0000}, 101 | Date-Modified = {2014-11-28 10:36:58 +0000}, 102 | Lastchecked = {28}, 103 | Month = {November}, 104 | Title = {Gold v paper money}, 105 | Url = {http://www.bbc.co.uk/news/business-18644230}, 106 | Year = {2014}, 107 | Bdsk-Url-1 = {http://www.bbc.co.uk/news/business-18644230}} 108 | 109 | @webpage{10, 110 | Date-Added = {2014-11-28 10:34:17 +0000}, 111 | Date-Modified = {2014-11-28 10:35:07 +0000}, 112 | Lastchecked = {28}, 113 | Month = {November}, 114 | Title = {ECR Research Web Page}, 115 | Url = {http://www.ecrresearch.com/world-economy/dangers-and-drawbacks-quantitative-easing}, 116 | Year = {2014}, 117 | Bdsk-Url-1 = {http://www.ecrresearch.com/world-economy/dangers-and-drawbacks-quantitative-easing}} 118 | 119 | @webpage{9, 120 | Date-Added = {2014-11-28 10:31:55 +0000}, 121 | Date-Modified = {2014-11-28 10:32:47 +0000}, 122 | Lastchecked = {28}, 123 | Month = {November}, 124 | Title = {Federal Reserve Web Site}, 125 | Url = {http://www.federalreserve.gov/faqs/currency_12773.htm}, 126 | Year = {2014}, 127 | Bdsk-Url-1 = {http://www.federalreserve.gov/faqs/currency_12773.htm}} 128 | 129 | @webpage{8, 130 | Date-Added = {2014-11-28 10:29:03 +0000}, 131 | Date-Modified = {2014-11-28 11:01:10 +0000}, 132 | Lastchecked = {28}, 133 | Month = {November}, 134 | Title = {Bountify Web Page}, 135 | Url = {https://bountify.co/}, 136 | Year = {2014}, 137 | Bdsk-Url-1 = {https://bountify.co/}} 138 | 139 | @webpage{7, 140 | Date-Added = {2014-11-28 10:27:49 +0000}, 141 | Date-Modified = {2014-11-28 10:28:30 +0000}, 142 | Lastchecked = {28}, 143 | Month = {November}, 144 | Title = {Bounty Source Web Page}, 145 | Url = {https://www.bountysource.com/}, 146 | Year = {2014}, 147 | Bdsk-Url-1 = {https://www.bountysource.com/}} 148 | 149 | @webpage{6, 150 | Date-Added = {2014-11-28 10:25:36 +0000}, 151 | Date-Modified = {2014-11-28 11:01:22 +0000}, 152 | Lastchecked = {28}, 153 | Month = {November}, 154 | Title = {MaidSafe Wikipedia}, 155 | Url = {http://en.wikipedia.org/wiki/MaidSafe}, 156 | Year = {2014}, 157 | Bdsk-Url-1 = {http://en.wikipedia.org/wiki/MaidSafe}} 158 | 159 | @webpage{5, 160 | Date-Added = {2014-11-28 10:23:00 +0000}, 161 | Date-Modified = {2014-11-28 10:24:14 +0000}, 162 | Lastchecked = {28}, 163 | Month = {November}, 164 | Title = {Tor Incentives Roundup}, 165 | Url = {https://blog.torproject.org/blog/tor-incentives-research-roundup-goldstar-par-braids-lira-tears-and-torcoin}, 166 | Year = {2014}, 167 | Bdsk-Url-1 = {https://blog.torproject.org/blog/tor-incentives-research-roundup-goldstar-par-braids-lira-tears-and-torcoin}} 168 | 169 | @webpage{4, 170 | Date-Added = {2014-11-27 16:52:58 +0000}, 171 | Date-Modified = {2014-11-28 11:01:57 +0000}, 172 | Lastchecked = {27}, 173 | Month = {November}, 174 | Title = {Tor Metrics --- Direct users by country}, 175 | Url = {https://metrics.torproject.org/userstats-relay-country.html}, 176 | Year = {2014}, 177 | Bdsk-Url-1 = {https://metrics.torproject.org/userstats-relay-country.html}} 178 | 179 | @webpage{3, 180 | Date-Added = {2014-11-27 16:49:37 +0000}, 181 | Date-Modified = {2014-11-27 16:51:52 +0000}, 182 | Lastchecked = {27}, 183 | Month = {November}, 184 | Title = {Tor Metrics --- Relays and bridges in the network}, 185 | Url = {https://metrics.torproject.org/networksize.html}, 186 | Year = {2014}, 187 | Bdsk-Url-1 = {https://metrics.torproject.org/networksize.html}} 188 | 189 | @url{2, 190 | Author = {Christopher Doll, T. F. McLaughlin, Anjali Barretto}, 191 | Date-Added = {2014-11-27 16:29:54 +0000}, 192 | Date-Modified = {2015-01-06 10:07:32 +0000}, 193 | Journal = {The International Journal of Basic and Applied Science}, 194 | Month = {July}, 195 | Number = {01}, 196 | Pages = {131-149}, 197 | Title = {The Token Economy: A Recent Review and Evaluation}, 198 | Url = {http://www.insikapub.com/Vol-02/No-01/12IJBAS(2)(1).pdf}, 199 | Volume = {02}, 200 | Year = {2013}, 201 | Bdsk-Url-1 = {http://www.insikapub.com/Vol-02/No-01/12IJBAS(2)(1).pdf}} 202 | 203 | @webpage{1, 204 | Date-Modified = {2014-11-27 16:36:09 +0000}, 205 | Owner = {nicklambert}, 206 | Timestamp = {2014.11.27}, 207 | Title = {Crypto-Currency Market Capitalizations}, 208 | Url = {https://coinmarketcap.com/all/}, 209 | Bdsk-Url-1 = {https://coinmarketcap.com/all/}} 210 | -------------------------------------------------------------------------------- /technical_papers/third_party/Ford.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maidsafe/Whitepapers/5f2829160f0d680b89ca99c86478708036e1de39/technical_papers/third_party/Ford.pdf --------------------------------------------------------------------------------