Datawallet Encryption (Core Tech Article I)
At Datawallet, we are building the tools for a data-ownership preserving digital economy. Two foundational tools for this new economy allow you to store and use your data. We describe the technology for each in this two-part series detailing how our new Datawallet 3.0 — Developer Edition release gives people the tools to first securely store and then reliably access and deploy their data.
Any storage solution represents a tradeoff between security, transparency, complexity, and usability. In the first development phase at Datawallet, we prioritized security and transparency with an entirely local sourcing, storage, and encryption solution. The resulting solution ensures that once a user sources their data into their Datawallet, Datawallet or any other organization cannot access the data without the active initiation of the user.
TL;DR: Local sourcing, storage, and encryption provides users strong privacy assurances.
In creating a Datawallet, every user creates a private-public key-pair (reducible to a stashable mnemonic à la BIP 39). This master private key provides access to an infinite number of keys (via a BIP 32/44 HD wallet derivation path.) The master private key is stored locally and encrypted by a user’s chosen password. Through this securely stored master private key users can therefore, to granularly encrypt their data.
With these keys we field-level encrypt every locally stored object to ensure that users can provide granular access to data without the computational overhead and potential risk associated with encrypting larger data structures. Each field is encrypted with a random key which can be retrieved by the user once they have unlocked their master key. Specifically, a user, Alice, can:
For a field Fi we derive an Ethereum ECDH secret key Ei using the Hierarchal Deterministic (HD) Wallet derivation path
Ei = HD(i)
We generate a random salt Ni (N = natrium chloride)
From Ei we derive a symmetric key Si for usage with AES-GCM
Si = HKDF(Ni, Ei) or SHA256(Ni, Ei)
Additionally, we generate a random symmetric key Ri
Ri = randomKey()
We generate an initialization vector IVRi
We encrypt Fi using Ri and IVRi yielding ciphertext CFi
CFi = AES-GCM(Ri,IVRi,Fi)
We generate another initialization vector IVSi
We encrypt Ri using Si and IVSi yielding a wrapped key WRi
WRi = AES-GCM(Si,IVSi,Ri)
We store a tuple (Ni, WRi, IVSi,IVRi,CFi)
When Alice wants to personally access a data field Fi, or even share the data with a data requestor or service provider, she merely needs to retrieve the randomly generated key Ri and securely send it to the data requestor, Bob:
Alice derives Ei
Ei = HD(i)
Alice retrieves Ni
Alice derives Si
Si = HDKF(Ni,Ei)
Alice retrieves (WRi, IVSi)
Alice decrypts WRi, using Si and IVSi yielding Ri
Alice encrypts Ri using Bob’s public key B yielding BR
Bob decrypts BR using his private key yielding Ri
Bob retrieves (IVRi, Ci)
Bob decrypts Ci using IVRi and Ri yielding Fi
While this storage implementation supports user-driven data access, it is not suitable for a real-time data marketplace with first-class data requests. To address this kind of data usage it requires a blockchain-based cloud storage solution which will be the subject of a subsequent discussion, research, and development. Beyond this structural limitation, there are a series of desirable features for a storage solution not yet incorporated in the current release, however, this is slotted in our development roadmap. For example, having an encrypted data backup from which a user can restore their Datawallet and from which multiple devices can be synced.
This article describes how the new Datawallet allows users to securely store their data on their own computers. Once data has been sourced into the Datawallet the encrypted storage solution ensures that no third party can access the Datawallet without the user’s active consent. In the next article, we will describe how specific subsets of this encrypted data can be securely accessed and used to power tools to make your data work for you.Datawallet Consumer PrivacyDeep Dives