Three Basic Components

1. Hashing - It is straightforward to generate a one-way MD of the unencrypted text. The current industry standard is SHA-2561, that is, Secure Hash Algorithm version 2 that computes a message digest (MD) that is 256 bits long. It is not possible to regenerate the original message from the MD.
    
2. Symmetric encryption keys (EK) - It is easy to establish a Symmetric EK. The same key is used to both encrypt and decrypt the information. The current standard algorithm is Advanced Encryption Standard (AES) using 2048-bit keys2. To keep the data secure, the Symmetric EK cannot be shared as a plain text message - ideally the key is derived during the negotiations to pair the transmission end-points, although other secure protocols exists for the key exchange.
    
3. Asymmetric encryption keys - It is straightforward for users to generate their own private-public key pair, using common Secure Shell (SSH) tools. For readers unfamiliar with asymmetric encryption keys, the owner has two keys generated at the same time. The public key (PK) is well-known to everyone, whereas the private key (or verification key, VK) is known only to the owner. Note the VK should be protected by a pass phrase that the owner must enter every time the VK is used. No pass phrase is required to use the PK.
    
   There are three possible uses for such key pairs. First, if you encrypt text with my PK and send me the encrypted result, then I am the only person who can decrypt it with my VK - providing secure transmission of data. Second, if I encrypt text with my VK, then anyone with my PK can decrypt it - providing non-repudiation, since I am the only person who could have published that text. Third, I can authenticate myself to a web site that has my PK; see user does not need a password.     Normally the public keys are published in a Public Key Infrastructure (PKI) directory, for anyone to find the PK generated for a web-site or a person.

1 SHA-256:
2 AES 2048:

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].

With these three basic components, it is possible for users at myInfo.org to create a private (permissioned) blockchain, following a simple architecture. According to Dr Tet Yeap, each block consists of five parts (B-F), where I have added part (A):

1. Owner UID-string and block number;
2. Previous MD (Transaction MD (F) of previous block);
3. Time-stamp;
4. Payload or transaction list (normally encrypted, see below);
5. Payload MD of the timestamp (C) and payload (D) of the current block; and
6. Transaction MD of the Previous MD (B) and Payload MD (E).

Timestamp is a double number, where the whole number represents a day from Jan 1, 100 AD to Dec 31, 9999 AD, and the decimal value to five places represents the time of day to the nearest second.

According to Dr Tet Yeap, part (E) is MD of parts (C) and (D). Part (F) is MD of parts (B) and (E). Note that a cryptographic nonce is not required to be suffixed to part (D) when generating part (E) Payload MD. Dr Yeap described such blockchains as tamper-resistant, tamper-evident, and immutable (transactions can only be added, and never changed).

In this proposal, part (E) is MD of parts (A), (C) and part of (D). By omitting the second part of (D) from the Payload MD (E), the second part of (D) may be changed by the owner. The second part of (D) contains the permitted viewers list, so that the owner can change who is permitted to view the private data contained in the first part of (D).

Note that blockchain networks often utilize a consensus system that requires owners to expend or maintain resources when attempting to publish blocks. This prevents malicious users from easily subverting the system. See more details under Business Plan.

The blockchains must be permissioned [i.e. only authenticated users signed on to the website can publish blocks], because the website holds the Symmetric EK for each block, and only sends the EK to a particular user who has requested it for a specific block number, after the website validates that user's UID-string is included in the list of permitted viewers.

UID-string and Functional Roles

The UID-string is 11 hexadecimal digits, consisting of (i) 9-digit User Identification (UID); and (ii) 2-digit role "01..ff" yielding3 239 possible roles. Note the UID must be used in conjunction with the functional role, hence the term UID-string denotes both the UID and the role. Having 9 hexadecimal digits "000000001..fffffffff" yields 68.71×10⁹ (68,719,476,736) possible UIDs [more than the world's population], allowing both people and organizations to be assigned a UID.

3 The role "00" is the default role. Likewise a UID of all zeroes is not allowed, except when specifying a functional role. A UID-string of all zeroes means Everybody. The following are reserved: (1) Special UID "00000000001" (ten zeroes and "1"); (2) member roles “0m”, where m is between 1 and f; and (3) the exception role “f0”; see Permitted Viewers List for details.

The functional roles are divided into three reserved values and two general classes:

• “00” is reserved as default role for owner of the UID
• “01” is reserved to denote ALL members of the UID
• “0m” (m between 2 and f) is class of membership roles
• “rr” (between “10” and “ef”) is class of functional roles – used for specific roles that are validated by the website, for example “05” as hospital
• “f0” is reserved for wildcard of roles “02” to “ef” and excludes other roles above “f0”
• “fn” (n between 1 and f) is class of functional roles – used for general roles that are claimed by the user but not validated by the website, for example: “ff” as researcher.

Examples of UID-strings:

• "fdc123bca00" includes the user’s UID "fdc123bca"4 and the default role "00"
• "fdc123bca9a" indicates this user is assigned functional role "9a"5
• "0000000009a" indicates ALL users assigned to this functional role
• "cba987abc01" indicates ALL users who are members of organization with UID "cba987abc".
• "cba987abcf0" indicates ALL users who are members of organization with UID "cba987abc" with a functional role between “02” and “ef”; it excludes users who have a functional role above “f0”.

See also membership lists.

Note that each user's data uses the default role “00”, no matter to which functional role(s) the user may be assigned. See PVL for more about using UID-strings.

When first registering at myInfo.org users must create their genesis block and their owner status block before they can create any other block of type block N.

4 UID is randomly assigned upon registration. 5 The precise assignment of roles will be discussed later.

Block Number

It is possible for anyone to view a particular block, without having to sign on at the myInfo.org website, although almost the whole of each block is not human readable, except the block number in part (A) and the timestamp in part (C). To read the contents of the PVL in part (D.2) in a particular block N, the user uses the owner's PK from part (D) of the owner’s genesis block, to decrypt part (D.2) of block N. The user should re-compute the Permitted Viewers MD of the decrypted text and compare it to the original MD in part (D.2.b) of block N.

If the user wants to read the PII (or other private data) stored in part (D.1) of block N, then the user must sign on to the website and request the Symmetric EK for the particular block. The website arbitrates whether the user's UID is included in the PVL for the block - refer to PVL. If the user is permitted access, the website encrypts the Symmetric EK for the block using the user's PK, and sends it to the user who will decrypt the Symmetric EK using their VK, and then decrypt part (D.1) of block N using that EK.

The format of the block number is: 11-digit UID-string of the owner, suffixed by the zero-padded hexadecimal number of the block, where the hexadecimal value of block N is in the range "00000" to "fffff", which is 16⁵ or 1,048,576 blocks. The owner's genesis block is always “00000” and the owner status block is always “00001”. The owner therefore has 1,048,574 non-specific blocks (“00010” to “fffff”). There may be legislative reasons yet to be determined that require the first fourteen blocks to be reserved for future use, blocks “00001” to “0000f”. Only the blocks which contain data need to be stored. Refer to Architecture for more details about the genesis and owner status blocks.

Note the data for each user's uses the default role “00”, no matter which functional role(s) the user may claim. Hence the block number of the genesis block for user "fdc123bca" is "fdc123bca0000000", the owner status block has a block number of "fdc123bca0000001", and subsequent blocks N have block number "fdc123bca000000N".

Permitted Viewers List (PVL)

Anyone can locate the particular block belonging to a specific owner. To view the PII in a certain block, users must first sign on at the website and then request the specific block number. The website keeps the Symmetric EK for each block, and only shares it with the authenticated users whose UID-string is included in6 the PVL, which consists of three parts:

• the UID-strings listed in part (D.2.a) of the current block. Note it is possible for the owner to assign Everybody (UID-string of 11 zeroes) to view a certain block, or indeed every block (except the owner status block)
• the members associated with an organization having a given UID, specified as the nine-digit UID of the organization and the member role 0m, where m is between 1 and f. The member role “01” always denotes ALL members of the organization. Note there is a special exception role “f0” that includes users with all functional roles up to “ef” (like a wildcard), but excludes users with a functional role above “f0” unless explicitly allowed in the PVL. See membership list
• If the Special UID (ten zeroes and “1”) is included in part (D.2.a) of the current block, then append the UID-strings that have non-zero functional roles listed in part (D.2.a) of the owner status block. Note it is not possible to assign Everbody to view the owner status block.

6 The website arbitrates which users have UID-strings that are included in the PVL. The website returns either (A) the value NULL if the user is not permitted access; or (B) the symmetric EK encrypted using the user's PK. The website retrieves the list of M permitted UID-strings from the requested block, where each UID-string consists of a given nine-digit UID and a given two-digit role. If the UID-string is the Special UID, then the website appends the list of UID-strings from the owner status block part (D.2.a).

  The website attempts to match the user’s nine digit UID by considering the following logic for each UID-string in the PVL, consisting of a given role and given UID. The website halts further checks after the first match that results in permitted access.

• If the given UID is zero:
  • If the given role is zero, the owner has granted access to Everybody so the website permits the user access.
  • If the given role is non-zero, the website permits access if the user is assigned to that role. [Note that the website verifies any claimed assignment listed in part (D.2.c) of the user's owner status block.]
• If the given UID is non-zero:
  • If the given role is zero, the website permits access if the user matches the given UID.
  • If the given role is “0m” (member of), the website permits access if the user’s UID is listed as a member in the organization with the given UID. The role “01” always denotes ALL members of the organization. Similar logic is used if the given role is “0M” where M is between 2 and f. For the use of member roles (“01” to “0f”), see Membership List.
  • If the given role is any other non-zero value, the website permits access if the user both matches the given UID and is assigned the given role.

The PVL is kept in part (D.2) of every block except the genesis block. Part D consists of:

1. (not important to PVL)
2. Encrypted by owner's private key:
   1. Permitted viewers:
      • 2-digit hexadecimal number in range between 0 and 255, that is number M of permitted UIDs
      • List of M permitted UID-strings
   2. Permitted viewers MD of PVL

It seems highly unlikely that an owner may wish to share the data with more than 255 users, without being able to group those users into one or more organizations, using the member roles.

By separating the PVL and MD from the payload MD, 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. Of course, the length of the data in the PVL may change, so it is necessary to deconstruct the block before modifying the permitted viewers, and to reconstruct the entire block afterwards.

PII or Other Private Data

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. When creating the PII text, the owner encrypts it using the Symmetric EK sent by the website to the owner. In order to read the PII text, the user must sign on to the website and request the Symmetric EK for the particular block N; the website will validate that the user's UID-string is included in the PVL in part (D.2) of that block. Being a symmetric key, the user then uses the same Symmetric EK to decrypt the PII.

It is not necessary to generate a separate MD of the PII text, because the encrypted PII data is included in the payload MD.

Ideally all the private data (including PII) that is related to a specific purpose should be included in the same block. The schema for recording this data should therefore be organized by purpose. Further discussions are needed to decide upon the schema. Note the schema should include the functional role(s) that are expected to be able to view blocks that contain each purpose-centered set of data. All schemas should be published on the website for reference by any user.

The genesis block always contains only the owner’s PK. The private data of the owner status block should contain the following information, and the PVL that includes UID-string "000000000f0" (i.e. all users assigned to any role except those between "f1" and "ff"). [Any resemblance to a person living or dead is purely coincidental.]

		<surname>Smith</surname>
		<name>Jon</name>
		<fullname>Michael Jonathan</fullname>
		<doby>1967</doby>
		<dobm>3</dobm>
		<dobd>1</dobd>
		<bcity>Toronto</bcity>
		<bcountry>Canada</bcountry>
		<bgen>M</bgen>
		<hair>Brown</hair>
		<eyes>Blue</eyes>
		

The following example might be used for research purposes. Assuming “ff” is the functional role for Researchers, the PVL for this block should include the UID-string "000000000ff" (i.e. all users assigned to role "ff"). [Any resemblance to a person living or dead is purely coincidental.]

		<residence/>
		<town>Belleville</town>
		<prov>Ontario</prov>
		<country>Canada</country>
		<influences/>
		<basis>per day</basis>
		<smokes>0</smokes>
		<drinks>2</drinks>
		<inhales>1</inhales>
		<ingests>0</ingests>
		<housing/>
		<own>rent</own>
		<storey>2</storey>
		<sincey>2012</sincey>
		<sincem>6</sincem>
		<heat>gas</heat>
		

As and when this data changes, the owner should create a new block (at the end of the blockchain) and revoke this block number, by adding this block number to part (D.2.b) in the owner status block.

Changing encrypted data

It is possible that the encrypted data may be changed, accidentally or maliciously. It is still possible to decrypt the data, but the resulting text is not the same text that was encrypted; the resulting text may be invalid, or worse, may appear to be valid text. Therefore after decrypting the PVL information, the viewer must re-compute the MD to ensure the decrypted text is the same as the original. (For PII Data, the viewer must re-compute the MD of the encrypted part before decrypting the data.)

For the PVL, this MD is termed Permitted viewers MD in the Architecture. Note the message digest and the original text are encrypted together with the owner's VK; the chances that a change to the encrypted data will result in both incorrect text and the correct MD for the incorrect text are very low indeed.)

The Payload MD includes the PII text (or other private data) in part (D.1), after it is encrypted with the Symmetric EK. It is not necessary to create a MD solely of part (D.1).

Architecture

Other than the genesis block and the owner status block below, the layout of each block N is:

1. Owner UID-string and block number (in range “00002” to “fffff”)
2. Previous MD – that is, the Transaction MD copied from part (F) of block N-1
3. Timestamp (e.g. 43639.515677)
4. Payload:
   1. Encrypted by symmetric EK retrieved for permitted viewers: payload of private data, described in Private Data.
   2. Encrypted by owner's private key:
      1. Permitted Viewers List (PVL):
         • 2-digit hexadecimal number in range between 00 and ff (decimal value 0 to 255), that is number M of permitted UIDs
         • List of M permitted UID-strings
      2. Permitted viewers MD of PVL
5. Payload MD of parts (A), (C) and (D.1) [but not D.2]
6. Transaction MD of parts (B) and (E)

The block numbers allow up to 1,048,574 blocks (“00002” to “fffff”) of type block N.

In a normal blockchain, the use of MDs (both part (E) Payload MD, and part (F) Transaction MD) prevents the payload data from being modified after creation. No-one, including the owner, can modify or delete the data after the owner has created it. In this proposal, part (E) Payload MD includes parts (A), (C), and only part (D.1); part (D.2) is not included in the Payload MD. The UIDs listed in part (D.2) are people whom the owner has specified to read the data.

Note the first few blocks should all include "role-based" UIDs for certain authorities and institutions, where the PVL includes UID of nine zeroes and a functional role between "10" and "ef" (or the wildcard role "f0"). Note if the role is specified as a member role between "02" and "0f", the UID should be non-zero to indicate the organization. The role "01" denoates ALL members of the organization.

Genesis Block

The layout of the genesis block is:

1. Owner UID-string and block number (always "00000")
2. NULL This replaces the Previous MD normally found in part (B)
3. Timestamp (e.g. 43639.51567)
4. Payload:
   1. 2048-bit PK [not encrypted]
   2. Encrypted by owner's private key VK:
      1. MD of PK
5. Payload MD of parts (A), (C) and (D) [both (D.1) and (D.2)]
6. Transaction MD of part (E) only - in the genesis block, part (B) is NULL.

Note that whatever data is encrypted by the owner's VK can only have been written by the owner, although anyone can view it, using the owner's PK published in part (D.1) of the genesis block.

Owner Status Block

The layout of the owner status block is:

1. Owner UID-string and block number (always “00001”)
2. Previous MD that is, Transaction MD copied from part (F) of block 0 (i.e. genesis block)
3. Timestamp (e.g. 43639.51567)
4. Payload:
   1. Encrypted by symmetric key retrieved for permitted viewers: payload of owner status data.
   2. Encrypted by owner's private key:
      1. Permitted viewers:
         • 2-digit hexadecimal number in range between 0 and 255, that is number M of permitted UIDs
         • List of M permitted UID-strings
      2. Block Revocation List (BRL):
         • 7-digit decimal number padded with zeroes in range between 0000000 and 1048574, that is number X of blocks that have been revoked. Again, each user may have up to 16⁵–2 (1,048,574) blocks plus the genesis and owner status blocks.
         • List of X block numbers that have been revoked, where each block number is between “00002” and “fffff”. (Genesis block “00000” and Owner Status block “00001” cannot be revoked).
      3. Claimed functional roles and membership list. This is list of UID-strings (UID and role) separated by semicolons, that are: (A) functional roles, and (B) memberships, that are claimed by the owner. This serves as a starting point for the website engine to decide if the owner’s UID is in the PVL of the requested user’s block.
      4. Special MD of PVL, BRL, and claimed membership list. This replaces the Permitted Viewers MD usually found in part (D.2).
   3. NULL; or Encrypted by myInfo.org's private key: Death Certificate. Just as myInfo.org recognizes and verfies the functional role of users when they sign up, it should also have the ability to gather sufficient proof to issue a Death Certificate.
       
      Note the public key belonging to myInfo.org must be available in a well-known area, so that anyone can view this portion of the owner status block to determine that the owner is deceased. Clearly the owner's private key cannot be used to encrypt the Death Certificate, because access to the owner's private key will be irretrievably lost when the owner dies. The details about what information should be included in the Death Certificate can be discussed later.
5. Payload MD of parts (A), (C) and (D.1) [but not D.2, D.3, or D.4]
6. Transaction MD of parts (B) and (E).

Membership List

An organization (any entity assigned a UID) may have one or more members. These are assigned and managed through the website by the authorized and duly authenticated user(s) for each organization, and can only be viewed by the website engine. No other members of the organization, and no-one outside the organization, can view the membership lists.

The website engine keeps these two separate lists encrypted:

1. List of members of each UID (organization); and
2. List of each symmetric key used for each block.

The functional role “01” always denotes all members of the organization. It is left to the organization to decide how to assign members to each of the other 14 member roles “0m”, where m is between “02” and “0f”. In general, each member list starts with the specific member role “0m” and then lists the UIDs of the members in that role, separated by semicolons. Optionally the UID may be separated from other values using colons, as may be decided upon by the organization.

The special exception role “f0” is reserved, and means any member of the organization with a functional role “02..ef”, but not any member with a role above “f0” unless explicitly included in the PVL. It is useful when you want to include any member in the organization with a given UID, or anyone at all (with UID of all zeroes), having a functional role up to “ef”, without having to include each different role. This is particularly useful in setting the PVL for the owner status block. (Again, the functional role “01” always means all members of the organization with the given UID; the functional role “00” is reserved as the default role for the owner of the UID.)

SSL simplified

This proposal mimics the behaviour of Secure Socket Layer (SSL). It may be helpful to explain how SSL works.

Any site that uses HTTPS requires the user's browser to establish an SSL connection; such as to a bank's website. First there is a three-way handshake to establish the connection. The browser sends a SYN packet to the web server on the specified port (usually 80). The web server responds with an SYN/ACK packet, and a new high-number port that it dynamically assigns. The browser sends an ACK packet to the web server on the high port, completing the three-way handshake.

Second there is the exchange of the Symmetric EK, protected by the asymmetric key pair of the server's public key (PK) and private key (VK). The web server sends its web certificate to the browser. The browser checks the root certificate authority (CA) who issued the web certificate, the expiry date of the certificate, and that the certificate number is not included in the root CA's Certificate Revocation List (CRL). The browser may prompt the user to proceed if any of these conditions fail. The browser then picks a 2048-bit random number, to be used as the Symmetric EK. The browser encrypts it using the PK found in the server's web certificate, and sends it to the web server on the high port. The web server decrypts the number using its own VK. This number is the Symmetric EK for the encryption and decryption (typically using AES) of all subsequent messages for the remainder of the user's session. When the user's session ends, the browser and the web server both delete the Symmetric EK. [Note AES's symmetric encryption is the preferred encryption method for temporary sessions because it uses less resources than RSA's asymmetric encryption.]

Prev page + Next page

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