Securing shared personal data
Building Blocks, Architecture [190801D]
Three Basic Components
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):
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×109 (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:
Examples of UID-strings:
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.
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 165 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:
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.
The PVL is kept in part (D.2) of every block except the genesis block. Part D consists of:
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).
Other than the genesis block and the owner status block below, the layout of each block N is:
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.
The layout of the genesis block is:
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:
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:
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.)
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.]
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