|
@@ -15,14 +15,15 @@ surveilence it not surepticious, it's quite overt. Consumers hand over this data
|
|
|
tech companies because of the benefits they receive in return. But why should people be forced to
|
|
|
choose between privacy and convenience?
|
|
|
|
|
|
-The cost of computing power, storage, and bandwidth are not very cheap. A single board computer
|
|
|
-can provide more than enough computing power for the average web-browsing consumer. A classic rotating magnetic hard drive can hold terrabytes of data, more than enough to hold an individuals
|
|
|
-social media output. Broadband internet access is not universal, but it is very common, and
|
|
|
-becoming more so all the time. So with all these resources available, why is it that consumers do
|
|
|
-not more control over the computing infrastructure upon which they rely?
|
|
|
-
|
|
|
-The answer is of course obvious. Consumers' don't want to manage servers, networking, routing, and
|
|
|
-backup strategies. Each of these can be a full time job by iteself, so in order for a consumer to
|
|
|
+The cost of computing power, storage, and bandwidth are very cheap. A single board computer
|
|
|
+can provide more than enough computing power for the average web-browsing consumer. A classic rotating magnetic hard drive can hold terrabytes of data, more than enough to hold an individual's
|
|
|
+social media output. Umetered broadband internet access measured in hudreds of megabits per
|
|
|
+second is common, and becoming more so all the time. So with all these resources available,
|
|
|
+why is it that consumers do not more control over the computing infrastructure upon which
|
|
|
+they rely?
|
|
|
+
|
|
|
+The issue is that consumers' don't want to manage servers, networking, routing, and
|
|
|
+backup strategies. Each of these can be a full time job by itself. So in order for a consumer to
|
|
|
be in control of their own infrastructure, the infrastructure needs to be able to take care of
|
|
|
itself.
|
|
|
|
|
@@ -35,41 +36,50 @@ need for insecure techniques, such as passwords.
|
|
|
|
|
|
This document proposes a potential solution. It describes a system for organizing information into
|
|
|
trees of blocks, distributing those blocks over a network of nodes, and a programming interface
|
|
|
-to access this information in a convenient way for a programmer. Because no one piece of hardware
|
|
|
+to access this information in a convenient way. Because no one piece of hardware
|
|
|
is infallible, the system also includes mechanisms for nodes to contract with one another to store
|
|
|
data. This allows data to be backed up and later restored in the case a node is lost. In order to
|
|
|
-ensure the free exchange of data amongst nodes, a currency will be used to account for the
|
|
|
-available computing capacity of the network.
|
|
|
+ensure the free exchange of data amongst nodes, a digital currency is used to account for the
|
|
|
+available storage capacity of the network.
|
|
|
|
|
|
-The remainder of this chapter will give an overview of the different system areas.
|
|
|
+The remainder of this chapter will give an overview of the system, with the remainder of the
|
|
|
+document going into specific details of each of the system's components.
|
|
|
|
|
|
\section{Blocks}
|
|
|
The basis of all trust in the system is a public-private keypair. The secrecy of the private key
|
|
|
is the linchpin of all security in the system. If this key is compromised then all confidentiality
|
|
|
-and authenticity assurances go out the window. Further, if this key is lost, then control of the
|
|
|
-resources over which it has agency over is also lost.
|
|
|
+and authenticity assurances are void. Further, if this key is lost, then control of the
|
|
|
+resources over which it has agency is also lost.
|
|
|
|
|
|
-Because of this, it's very important to take protect this key by storing it in a secure location.
|
|
|
+% Should I remove this paragraph? Seems like this is an implementation details that should
|
|
|
+% be saved for later.
|
|
|
+Because of this, it's very important to protect this key by storing it in a secure location.
|
|
|
It is envisioned that a TPM will be used for this purpose. A TPM will be important for other
|
|
|
system features, as we'll see later.
|
|
|
|
|
|
All data stored in the system is put into data structures called blocks. Each block has a path
|
|
|
which describes it's location in the tree. The root of this path is always a hash (hex encoded)
|
|
|
-of the public key corresponding to the private key which is the root of trust for the tree. The
|
|
|
-root block is encrypted by a symmetric cipher using a randomly generated key, which is referred
|
|
|
-to as the block key. This key is then
|
|
|
-encrypted using the root public key and added to the block. This is a standard key encapsulation
|
|
|
-scheme. For all non-root blocks in the tree, their block key is encrypted using the block key of
|
|
|
-their parent, and then stored in the block. This ensures that we can allow a party access to all
|
|
|
+of the public key corresponding to the private key which is the root of trust for the tree. Each block is encrypted by a symmetric cipher using a randomly generated key, which is referred
|
|
|
+to as the block's key. The block key for the root block is
|
|
|
+encrypted using the root public key and the resulting cipher text is stored in the block itself,
|
|
|
+along with a hash of the public key for later identification. For all non-root blocks in the tree,
|
|
|
+their block key is encrypted using the block key of
|
|
|
+their parent, and the resulting ciphertext is stored in the block.
|
|
|
+This ensures that we can allow a party access to all
|
|
|
blocks in a subtree by simply encrypting the block key at the root of that subtree using the
|
|
|
-party's public key. This mechanism will be used later to give node's that are controlled by the
|
|
|
-root selective access to data stored in the tree.
|
|
|
+party's public key. This mechanism is used to give node's that are controlled by the
|
|
|
+root selective access to data stored in the tree, by encrypting the block key of the root of the
|
|
|
+subtree using the node's public key.
|
|
|
|
|
|
-Integrity assurance of the block's content is assured by a digital signature. A certificate chain
|
|
|
+Integrity assurance of the block's content is achieved by a digital signature which covers all of
|
|
|
+the block's contents (except the signature itself of course). A certificate chain
|
|
|
starting with the root key and ending with the key used by make this signature is included with
|
|
|
-the block. In this way any node which has been issued a certificate using the root key is able to
|
|
|
-write data into the tree. All data in the block is covered by the signature (except the signature itself of course). In particular the path of the block is covered, which means that all
|
|
|
-information needed to verify the authenticity of a block is included in it.
|
|
|
+the block. This ensures that any node which has been issued a certificate using the root key is
|
|
|
+able to write data into the tree. In particular the path of the block is covered, and since the
|
|
|
+path includes a hash of the root key, this means that anyone is able to independently verify
|
|
|
+the authenticity of the block by checking that the certificate chain was indeed signed by
|
|
|
+the root, that all other signatures in the chain are valid, and finally that the signature on
|
|
|
+the block itself is valid.
|
|
|
|
|
|
The size of each block has yet to be determined. It's envisioned that they will be fairly large,
|
|
|
on the order of 4 MB, so as to amortize the overhead of storing a certificate chain, and
|
|
@@ -77,8 +87,8 @@ encapsulated keys as well as the cost of cryptographic operations.
|
|
|
|
|
|
\section{Fragments}
|
|
|
By itself this block structure would be useful for building a secure filesystem, but in order to
|
|
|
-be a durable storage system it needs an efficient way of backing up, or distributing data. This
|
|
|
-is the purpose of fragments.
|
|
|
+be a durable storage system it needs an efficient way of backing up, or rather distributing data.
|
|
|
+This is the purpose of fragments.
|
|
|
|
|
|
Blocks are distributed amongst nodes in the network by using a fountain code. The output symbols
|
|
|
of this code are referred to as fragments. A code with a high performance implementation and good
|
|
@@ -86,19 +96,23 @@ coding efficiency is an important design consideration for the system. For these
|
|
|
envisioned that the RaptorQ code will be used.
|
|
|
|
|
|
After a block is created the creating node will need to distribute the data in the block to other
|
|
|
-nodes to ensure it's persistence in case it fails. It will create fragments as needed and solicit
|
|
|
-other nodes for their storage. Currency controlled by the root key will be exchanged with these
|
|
|
-other nodes in exchange for contracts to store the fragments.
|
|
|
+nodes to ensure its persistence in case the node fails. It will create fragments as needed
|
|
|
+and advertise to other node's its desire to store them. Currency controlled by the root key is
|
|
|
+exchanged with these other nodes in exchange for contracts to store the fragments.
|
|
|
|
|
|
-When a node needs to rebuild data that was previously distributed in fragments, it conects to a
|
|
|
-subset of nodes containing fragments and downloads in parallel enough fragments to reconstruct the
|
|
|
-block. This same mechanism can be used to distribute block data to unaffiliated nodes in the
|
|
|
+When a node needs to rebuild data that was previously distributed in fragments, it connects to a
|
|
|
+subset of nodes containing fragments and, in parallel, downloads enough fragments to reconstruct
|
|
|
+the block. This same mechanism can be used to distribute block data to unaffiliated nodes in the
|
|
|
network. It is a convenient load balancing and performance improvement, as the parallel downloads
|
|
|
spread the load over multiple nodes and are not limited by the bandwidth between any pair.
|
|
|
|
|
|
-Much attention will be given to the system used to keep track of which node has the fragments
|
|
|
-of a given block, and how nodes contract with each other for the storage and distribution of
|
|
|
-fragments.
|
|
|
+We keep track of which nodes hold fragments of a block by storing the IDs of these nodes in the
|
|
|
+block's parent. This list of node IDs can then be resolved to a list of IP addresses by looking
|
|
|
+up data in a shared data structure called the Public Blocktree.
|
|
|
+
|
|
|
+\section{The Public Blocktree}
|
|
|
+The Public blocktree is just another block tree, but one which is controlled by a distinguished
|
|
|
+private key, whose public key is hard-coded into the other node's in the network. This blocktree
|
|
|
|
|
|
\section{Nodes and the Network}
|
|
|
Each node in the network is identified by a public-private keypair and is issued a certificate
|