Securing shared personal data
Technical Overview [190801C]
This proposal hinges upon the non-repudiation of text that is created by the owner. The owner of the block uses the asymmetric keys aka verification key (VK) to encrypt both the text and the Hash value of that text). Anyone who has the owner's public key (PK) can decrypt the information.
The owner uses the VK to encrypt certain information in each block. Only the owner can create the encrypted data, that when decrypted reveals the original text. The original text can be read by anyone who has the owner's PK, which is widely available in the owner's genesis block. For this reason, the Personally Identifiable Information (PII) is not stored in these parts of the block; it is stored in a separate part of the block, encrypted by other means (see PII data). The list of permitted viewers is stored in the parts protected by the VK; see permitted viewers list (PVL).
By separating the PVL and MD of the PVL from the MD of the payload, it is possible for the owner to modify the list of permitted viewers without modifying the rest of the block, or interfering with the chaining mechanisms of the block chain.1
When other users want to view a certain block, their UID and/or functional role and/or membership in an organization must be included in the PVL of that block. The website keeps the symmetric EK for each block, and only shares it with the authenticated users whose UID-string is in the PVL. Being a symmetric key, the users can use this symmetric EK to decrypt the PII.
Users (that is, not the owner) cannot change blocks in any way. Owners may modify blocks, insofar as:
The architecture has been designed to permit the owner to make these changes to a block without interfering with the mechanisms that chain the blocks (i.e. the Payload and Transaction MDs).
1Of course, the length of the data in the permitted viewers part may change, so it is necessary to deconstruct the block before modifying the permitted viewers, and to reconstruct the entire block afterwards. Note it is not necessary to generate a MD of the PII text, because the encrypted PII data is included in the Payload MD.
Note that re-computing the MD of the decrypted text and checking if the new MD is the same as the original MD immediately validates that the decrypted text is the same as the original text; see changing encrypted data.
This section lists the ways in which users will use the website.
Currently the domain name myInfo.org is not in use; for simplicity sake we assume we can purchase it, or some other memorable name.
Users must register to sign into the website. The UID-string will be generated and assigned to each new user, with the default role "00". (See UID-string for more details.) The website will validate the functional role of the user. The data collected to ascertain the role, and how it will be processed, will be discussed later. The website tracks the UIDs assigned to each functional role. The user will add the assigned functional role(s) to the owner status block.
New users will receive instructions on how to use SSH (Secure Shell, a widely available application used to administer computers remotely), in order to generate their own PK -- VK pair, with the option to assign a pass phrase to the VK. The PK is stored on the owner's genesis block. The VK is kept by the owner; the website never sees the VK or the pass phrase.
When the user logs on to myInfo.org, the user does not need a password. At the time the owner generates the PK--VK key pair, a pass phrase (more than 32 characters) must be assigned to the VK; it is required to be entered every time the owner uses the VK. The VK and pass phrase must not be shared with anyone. The VK is something the user possesses (first factor), and the pass phrase is something the user knows (second factor). Together this forms two-factor authentication. When the user logs on to the website, the server creates a six-digit alphanumeric code, encrypts it using the user's PK and sends it to the user. The user uses the VK to decrypt the code and types the code into the website (this mirrors SSL methods below).
When users want to generate a new block, they pay a one-time in perpetuity administration fee, to cover the cost of keeping the block in storage and making it and the symmetric EK available to other users who request it. They may also be requested to perform some computations to validate recently added blocks from other users; this is a non-trivial soft cost to contribute to the overall system. To generate a new block (other than genesis and owner status blocks), the owner must:
The website stores two elements, encrypted:
This page is Copyrighted; a patent application has been filed.
[updated manually as comments are received]
Use this form. [On most browsers the form is be too large to fit side by side with the blog text.]
Top (return to list of blog pages)
© 2019, www.piSecAudit.ca