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:

• owner status block to change:
  1. default users in the PVL in part (D.2.a);
  2. block numbers in the Block Revocation List (BRL) in part (D.2.b)
  3. claimed membership in organization(s), in part (D.2.c)
• block N part (D.2.a), to change the PVL for that block.

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.

Terms:

text

plain-text or unencrypted form of the information

data

encrypted form of the information

message digest (MD)

result of computing the Hash value of the text, using SHA-256 [i.e. Secure Hash Algorithm version 2 to compute the MD that is 256 bits long].

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.

myInfo.org website

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:

• Request the website assign a new symmetric EK. This symmetric EK is stored by the website for each block (except the genesis and owner status blocks). The website assigns a new symmetric EK, encrypts it using the owner's PK, and sends it. The owner decrypts it with the VK.
• Generate the PII text to be stored in the block. The PII data should be in the form of tagged fields like HTML, <fieldname>field value</fieldname> according to some schema yet to be determined (see PII data).
• Encrypt the PII text using the symmetric EK.
• Generate the list of permitted viewers (see PVL).
• Generate permitted viewers MD.
• Encrypt the PVL and MD using the owner's VK.
• Generate Payload MD and Transaction MD, as described in Architecture.
• Send the completed block to the website.
• Pay the administration cost, and validate recently added blocks from other users, as described above and in the Business Plan.

The website stores two elements, encrypted:

1. Symmetric EK for each block part (D.1). When the owner or another user who claims to be permitted requests this key, the website validates the user's UID is included in the PVL, then encrypts the EK with the user's PK; the user decrypts it with her/his VK and decrypts part (D.1) of the block with the EK.
2. Membership list for each organization (any entity assigned a UID); refer to Membership Lists. When the owner registers the organization, the owner may specify by UID the users who are authorized to manage the membership list, or by default just the owner. These specific users can use the website interface to add or remove the UIDs of members, along with the member role ("02..0f") or functional role ("10..ef"); the website validates the user's claimed role against this recorded data. Functional roles ("f1..ff") may be claimed by users but are not validated by the website. Three functional roles ("00, 01, f0") are reserved.

Prev page + Next page

This page is Copyrighted; a patent application has been filed.