WO2018081668A2

WO2018081668A2 - Systems and methods for message access control

Info

Publication number: WO2018081668A2
Application number: PCT/US2017/058916
Authority: WO
Inventors: Michael A. SEGAL; Neel KRISHNAN
Original assignee: Segal Michael A; Krishnan Neel
Priority date: 2016-10-29
Filing date: 2017-10-29
Publication date: 2018-05-03
Also published as: WO2018081668A3

Abstract

Systems and computer-implemented methods are provided for authorization systems for providing selective access to messages. An authorization system may include at least one processer and at least one non-transitory memory storing instructions. When executed by the at least one processor, the instructions may cause the authorization system to perform operations. The operations may include receiving, from an user device, a message or message request, generating an encrypted message using a message public key generated using a seekable sequential key generator, providing the encrypted message to at least one processing node for incorporation into a data structure comprising an irrevocable record of the encrypted message.

Description

SYSTEMS AND METHODS FOR MESSAGE ACCESS CONTROL

[001] The present application claims the benefit of priority of U.S. Provisional Application No. 62/414,727, filed October 29, 2016, which is incorporated herein by reference.

TECHNICAL FIELD

[002] The envisioned systems and computer-implemented methods concern managing access to messages. As disclosed herein, cryptographic key generation may be used to provide selective access to messages within a set of messages.

BRIEF DESCRIPTION OF THE DRAWINGS

[003] The drawings are not necessarily to scale or exhaustive. Instead, emphasis is generally placed upon illustrating the principles of the inventions described herein. The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments consistent with the disclosure and, together with the description, serve to explain the principles of the disclosure. In the drawings:

[004] Fig. 1 depicts an exemplary high-level representation of a system for granting selective access to cryptographically related messages.

[005] Fig. 2 depicts a schematic of an exemplary system for creating

cryptographically related messages.

[006] Fig. 3 depicts a schematic of another exemplary system for creating

cryptographically related messages.

[007] Fig. 4 illustrates an exemplary process for adding messages to a set of cryptographically related messages.

[008] Fig. 5 illustrates an exemplary process for request selective access to messages in a set of cryptographically related messages. [009] Fig. 6 depicts an exemplary computing system for granting selective access to messages.

DETAILED DESCRIPTION

[010] Reference will now be made in detail to the disclosed embodiments, examples of which are illustrated in the accompanying drawings. Wherever convenient, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

[011] Fig. 1 depicts an exemplary high-level representation of a system for granting selective access to messages, consistent with disclosed embodiments (system 100). In some embodiments, authorization system 110 may be configured to provide message set 122 to processing node(s) 120. Access to messages in message set 122 may be controlled. For example, the messages may be encrypted. Authorization system 110 may be configured to provide messages in message set 122 to processing nodes 120 in response to requests. In various embodiments, authorization system 1 10 may be configured to grant user devices 130 selective access to message(s) in message set 122. For example, authorization system 110 may be configured to provide user device 130 with information enabling user device 130 to decrypt message(s) in messages set 122. User device 130 may be configured to retrieve message(s) in message set 122 from processing nodes 120, and to access the message(s) using the information received from authorization system 110. In this manner system 100 may enable selective access to messages.

[012] Authorization system 110 may include one or more computing systems, such as servers, general purpose computers, or mainframe computers. Authorization system 101 may be standalone; or may be part of a subsystem, which may be part of a larger system. For example, authorization system 101 may include distributed servers that are remotely located and communicate over a public network (e.g., network 140) or a dedicated private network. In some embodiments, authorization system 110 may be implemented at least in part as a virtual system on a cloud-computing infrastructure. Consistent with disclosed embodiments, authorization system 110 may include or communicate with one or more storage devices configured to store data and/or software instructions. The stored data and/or software instructions may include one or more software programs. Authorization system 110 may execute the stored one or more software programs to perform one or more methods consistent with the disclosed embodiments. In certain aspects, authorization system 110 may execute the stored one or more software programs remotely from authorization system 110. For example, authorization system 110 may access one or more remote devices to execute the stored one or more software programs. In certain embodiments, authorization system 110 may be configured as a particular apparatus or system based on the storage, execution, and/or implementation of the software instructions. Authorization system 101 may be configured to expose an application programming interface, or API, for communicating with one or more other components of system 100. For example, central authorization system 101 may be configured to expose an API for communicating with user device 130, and/or publishing messages to message set 120. As an additional example, the API may utilize the short messages service (SMS) protocol for communication.

[013] Processing nodes 120 may be configured to store messages received from authorization system 101. In some embodiments, processing nodes 120 may be configured to maintain a collection of received messages. These messages may include messages received from other systems, or generated by one or more of processing nodes 120. Processing nodes 120 may be configured to incorporate messages in the collection into a data structure. The data structure may comprise a blockchain. As would be appreciated by one of skill in the art, the blockchain may comprise an irrevocable record of the incorporated messages.

[014] Processing nodes 109 may include, but are not limited to, computing devices using on one or more central processing units, graphical processing units, special purpose integrated circuits such as field-programmable gate array (FPGA) or application specific integrated circuits (ASIC), servers, and/or computer clusters for processing entries for the distributed public data structure.

[015] Message set 122 may comprise cryptographically related messages. As described below, authorization system 100, or another system, may be configured to establish the cryptographic relationship between these message. The cryptographically relationship between the messages may enable the messages to be selectively decrypted. For example, different subsets of message set 122 may be decrypted, depending on the information possessed by the device performing the decryption. Message set 122 may include messages in the collection maintained by processing nodes 120, and may include messages incorporated into the data structure by processing nodes 120.

[016] Messages may include information concerning a person or a legal entity. The information may be sensitive, in that the person or legal entity may not want or expect the information to be publically accessible. For example, the information may include identity management, medical, legal, or business information. Identification

management information may include transaction information, such as payments and payment obligations involving the person or a legal entity; documentation concerning the person or legal entity, such as documentation of a residence or business address, tax information, revenue or salary information, asset and debt information; verification information concerning authentication and risk mitigation steps completed by the person or a legal entity, such as "know your customer" verifications; and sanctions, such as records of censure, misconduct, or deficiencies that may affect eligibility for financial services. Identification management information may also include passwords, account numbers, or other identification information for the person or legal entity. System 100 may be configured to associate identification management information with a unique identifier corresponding to the person or a legal entity. For example, messages containing identification management information may include a reference to a central identity record maintained by authorization system 110. This central identity record may act as a unique identifier for the person or a legal entity. Medical information may include data sequences containing encrypted patient medical records. Legal information may include property records, title transfers, contracts, assessing information, or similar information. Business information may include the clinical trial information, sales information, cost information, supplier information, or similar information.

[017] User device 130 may be configured to communicate with authorization system 110 to retrieve information for accessing message(s) in message set 122. User device 130 may be configured to communicate with processing nodes 120 to retrieve the message(s) in message set 122. Using the information retrieved from authorization system 110, user device 130 may be configured to decrypt the message(s). User device 130 may include a cell phone, smart phone, personal digital assistant, tablet, laptop, desktop, workstation, all-in-one system, computer cluster, terminal, mainframe, mobile computing device, or other computing device capable of communicating with authorization system 110. User device 130 may include or communicate with one or more storage devices configured to store data and/or software instructions. The stored data and/or software instructions may include one or more software programs.

[018] User device 130 may execute the stored one or more software programs to perform one or more methods consistent with the disclosed embodiments. For example, user device 130 may be configured to execute a client program for interacting with system 100. The client program may be configured to handle requests for access to authorizing system 110, and generate of keys necessary to decrypt messages in message set 122. In some embodiments, the client program may be configured to prevent other applications from using, recording, or accessing the information provided to user device 130 by authorization system 100.

[019] In certain aspects, user device 130 may execute the stored one or more software programs remotely from user device 130. For example, user device 130 may access one or more remote devices to execute the stored one or more software programs. In certain embodiments, user device 130 may be configured as a particular apparatus or system based on the storage, execution, and/or implementation of the software instructions. User device 130 may be configured to expose an application programming interface, or API, for communicating with one or more other components of system 100. For example, user device 130 may be configured to expose an API for communicating with authorization system 110, and/or processing nodes 120. As an additional example, the API may utilize the short messages service (SMS) protocol for communication. User device 130 may be configured to provide a user interface, such as a graphical user interface.

[020] User 130a may be a person or a legal entity. User 130a may use system 100 by interacting with user device 130 through a user interface. User 130a may use system 100 to access message(s) in message set 122. Additionally or alternatively, user 130a may use system 100 to cause authorization system 110 to provide messages to processing nodes 120 for inclusion in message set 122. In various embodiments, user 130a may be have an account with system 100. [021] Network 140 may be configured to provide communications between authentication system 110, user device 130, and processing nodes 120, as shown in Fig. 1. For example, network 140 may be any type of network (including infrastructure) that provides communications, exchanges information, and/or facilitates the exchange of information between the above components of system 100. For example, network 140 may comprise the Internet, a Local Area Network, or other suitable connection(s). Network 140 may implement different networks for communication between different elements of system 100. For example, network 140 may implement a cellular network for transmitting SMS messages between one or more components of system 100.

[022] Fig. 2 depicts a schematic of an exemplary system for generating

cryptographically related messages. In some embodiments, authorization system 110 may be configured to generate the cryptographically related messages. The messages may be provided to processing nodes 120 for inclusion in message set 122. Generation of the cryptographically related messages may comprise generation of a state set 210. Knowledge of a state in the state set may enable determination of prior states. State set 210 may be used to generate key pairs 220. Key pairs 220 may be used to generate message key pairs 230. The private key in each message key pair may be used to encrypt a message. This message may be decrypted using the corresponding public key in each message key pair. In this manner, knowledge of a state in state set 210 may enable decryption of a selectable number of messages 250.

[023] State set 210 may comprise a sequence of cryptographic keys. A first property of this sequence of cryptographic keys may be that, given a master key and a seekable sequential key generator (SSKG), any key in the sequence may be directly computed without having to compute preceding keys in the sequence. A second property of the sequence of cryptographic keys is that given a key in the sequence, the preceding key may be generated using evolution function 215. Thus given the third key in the sequence, S(3), the second key in the sequence, S(2), may be recovered through a single application of evolution function 215. The first key in the sequence, S(l), may be recovered using two applications of evolution function 215. An exemplary SSKG is disclosed in "Practical Secure Logging: Seekable Sequential Key Generators," by Giorgia Azzurra Marson and Bertram Poettering, which is incorporated herein by reference in its entirety. However, this exemplary SSKG is "forward-secure," meaning that past keys cannot be recreated using current keys. Given the current key, the evolution function disclosed by Marson and Poettering generates the next key in the sequence. Thus the exemplary SSKG achieves the opposite of the desired properties. So to realize the desired behavior of state set 210, the first state in state set 210 is calculated using a predetermined number n, which is then decremented for each additional state, as follows:

[024] si = SSKG(k₀, n - i + 1

[025] Here k₀ is an initial seed. Thus the first three states in a state set including three or more states would be {SSKG (k₀, ri), SSKG (k₀, n— 1), SSKG (k₀, n— 2)}. Authorization system 1 10 may be configured to precompute at least a portion of state set 210, and may compute additional states for state set 210 as needed. The

predetermined number n may be chosen to ensure availability of a sufficient number of states for a particular application.

[026] Authorization system 1 10, or another component of system 100, may be configured to generate key pairs 220 from corresponding states in state set 210.

Authorization system 1 10 may generate key pairs 220 using a master key pair comprising a master private key and a master public key. As shown in Fig. 2, the private key in each key pair may be generated by multiplying the corresponding state by the master private key, while the corresponding public key in each key pair may be generated by multiplying the corresponding state by the master public key. As would be recognized by one of skill in the art, this multiplication may be numerical multiplication or point multiplication as appropriate to yield each of key pairs 220 from the master key pair. Authorization system 110 may be configured to precompute at least a portion of key pairs 220, and may compute additional key pairs for key pairs 220 as needed. In some cases, one or more of the master keys may be the key used as a seed to generate state set 210 (e.g., k₀).

[027] Authorization system 110, or another component of system 100, may be configured to generate message key pairs 230 from key pairs 220. The message key pairs may be generated using the method disclosed in "Hierarchical Deterministic Wallets" by Pieter Wuille, which is incorporated herein by reference in its entirety. According to this method, the message public key and the corresponding message private key may be generated from the private and public key pair, without risking leakage of these keys. Authorization system 110 may be configured to precompute at least a portion of message keys 230, and may compute additional message key pairs for message keys 230 as needed.

[028] Authorization system 110 may be configured to encrypt messages using the message private keys. The messages may be received by authorization system 110 prior to encryption. Authorization system 110 may be configured to generate the messages in response to requests. The messages or requests may be received from another component for system 100, or from another system. Authorization system 110 may be configured to use a precomputed message private key, or may be configured to compute a new message private key. [029] Authorization system 110 may be configured to provide the encrypted messages to processing nodes 120. In some embodiments, processing nodes 120 may be configured to add the encrypted messages to messages 240. As described above, some portion of messages 240 may be incorporated into a data structure, and some portion of messages 240 may be stored in a message pool. The messages may be received by authorization system 110 prior to encryption. Authorization system 1 10 may be configured to generate the messages in response to requests. The messages or requests may be received from another component for system 100, or from another system. Authorization system 110 may be configured to encrypt a message using a precomputed message private key, or may be configured to compute a new message private key for encrypting the message.

[030] As would be appreciated by one of skill in the art, a user device, (e.g., user device 130) that receives a state in state set 210 may generate any prior state in this sequence of states. When user device 130 receives both the state information and the master public key, user device can generate the public message key for any message corresponding to the state received, or an earlier state. For example, as shown in Fig. 2., when a user device receives S(3), the user device can access any of accessible message 250.

[031] In some embodiments, the message associated with the first state in state set 210 may include a reference 260. This reference may enable authentication of the cryptographically related messages. For example, when the data structure is the bitcoin blockchain, the message associated with the first state may comprise a transaction. This transaction may include an input for each party authorizing the message. This input may spend bitcoins from an address that is publicly known to belong to that authority (known as a "green address"). In some aspects, the reference may comprise data associated with a user identity, such as a hash of a cryptographic key associated with the user, such as a public key. In various aspects, the reference may comprise a pointer to some external identification source, such as identifier 270. When user device 130 receives one of the states in state set 210, it will be able to work backward to the initial state. Using the initial state, it may decrypt the first message. Thus any of messages 240 may be authenticated based on the reference in the first transaction. In some

embodiments, each message may include such a reference.

[032] In some embodiments, multiple state sets 210 may be generated using different seeds. The seeds may all be generated from a single key, or the seeds may be distinct from one another. In this manner, multiple sequences of events may be associated with a single user identity.

[033] Fig. 3 depicts a schematic of another exemplary system for creating

cryptographically related messages. In some embodiments, authorization system 110 may be configured to generate the cryptographically related messages. The messages may be provided to processing nodes 120 for inclusion in message set 122. Generation of the cryptographically related messages may comprise generation of a state set 310. Knowledge of a state in the state set may enable determination of a selectable number of other states. Certain states in state set 310 may be used to generate key pairs 320. Key pairs 320 may be used to generate message key pairs 330. The private key in each message key pair may be used to encrypt a message. This message may be decrypted using the corresponding public key in each message key pair. In this manner, knowledge of a state in state set 310 may enable decryption of a selectable number of messages 350.

[034] State set 210 may comprise an ordered multi-dimensional set of cryptographic keys. A first property of state set 310 may be that, given a master key and an SSKG, any key in the set may be directly computed without having to compute preceding keys in the set. A second property of the ordered multi-dimensional set of cryptographic keys is that given a key in the sequence, a preceding key along a particular dimension may be generated using an evolution function for that dimension. Fig. 3 depicts an exemplary two-dimensional ordered set of cryptographic keys parameterized by two indices i and j. According to the methods of Marson and Poettering described above, state set 310 may be generated using a two parameter SSKG as follows:

[035] Sij = SSKG(k₀, i, n - j + l)

[036] Here, k₀ is the key. State set 310 has forward security with respect to index i, but backwards security with respect to index j. Thus evolution function 312 may generates state S(i,j-1) from S(i,j), while evolution function 314 may generates S(i+1, j- 1) from S(i,j). Thus the four states in a state set with index values i E [1,2] and j E

[1,2] would be

{{SSKG (k₀, l, n), SSKG (k₀, l, n - 1)}, {SSKG (k₀, 2, n), SSKG (k₀, 2, n - 1)}}. Given state SSKG (k₀, 1, n— 1), evolution function 312 would generate SSKG (k₀, 1, n), while evolution function 314 would generate SSKG (k₀, 2, n) . Authorization system 1 10 may be configured to precompute at least a portion of state set 310, and may compute additional states for state set 310 as needed. The predetermined number n may be chosen to ensure availability of a sufficient number of states for a particular application.

[037] Authorization system 1 10, or another component of system 100, may be configured to generate key pairs 320 using certain states in state set 310. In some embodiments, only states S(i,0) may be used to generate key pairs 320 (e.g., k(i) and p(i)). Key pairs 320 may be generated as described above with regard to Fig. 2.

Likewise, authorization system 1 10, or another component of system 100, may be configured to generate message keys 330 (e.g., k(i) and p(i)) from key pairs 320 as described above. Authorization system 110 may be configured to encrypt messages using the message private keys, as described above with regard to Fig. 2, to generate messages 340.

[038] Authentication system 110 may be configured to selectively provide access to messages 340. Given a state S(i, j) in state set 310, state S(i,l) to state S(i+j-l,l) may be generated by successive applications of evolution functions 312 and 314. For example, given state S(2,3), state S(2, l) may be generated by applying evolution function 312 twice. State S(3,l) may be generated by applying evolution function 312 once and evolution function 314 once. State S(3, l) may be generated by applying evolution function 314 twice. As depicted in Fig. 3, authorization system 110, or another system, may be able to public generate message keys p'2, p'3, and p'4 from S(2,3) and master public key Po. Therefore, by providing state S(2,3) and master public key Po, authorization system 110 may enable user device 130 to access accessible messages 350. By providing a different state, different messages may become accessible.

[039] As described above, the message in message 240 associated with the first state in state set 210 may include a reference 260 enabling authentication of the

cryptographically related messages. Because the first message in messages 340 may not be accessible, each of messages 340 may include such a reference. As described above, the reference may comprise data associated with a user identity, such as a hash of a cryptographic key associated with the user, such as a public key. In various aspects, the reference may comprise a pointer to some external identification source, such as identifier 370. Thus any of messages 340 may be authenticated based on the reference included in the message. [040] Fig. 4 illustrates an exemplary process for adding messages to a set of cryptographically related messages. In some embodiments, authentication system 110 may be configured to add the messages. In step 405, authentication system 110 may be configured to receive a message, or a request to publish a message. The message or request may concern a person or legal entity, as described above. The message may be received from another component of system 100, or another system.

[041] In optional step 410, authentication system 110 may be configured to create a state set, as described above with regards to Figs. 2 and 3. In some aspects,

authentication system 110 may be configured to create the state set using key k₀. In some aspects, k₀ may be unique to the person or legal entity. In various aspects, the k₀ may be derived from a key specific to the particular person or legal entity.

Authentication system 110 may be configured to initialize a state set when no current state set exists for the person or legal entity, or when the message or request differs from previously received messages or requests for the person or legal entity

[042] In optional step 415, authentication system 110 may be configured to generate at least one key pair, as described above with regards to Figs. 2 and 3. In embodiments using the system of Fig. 3, authentication system 110 may be configured to generate the at least one key pair using k₀. For example, the private key may comprise the state multiplied by k_Q, while the private key may comprise the state multiplied by a generator G times k₀. Alternatively, when generating keys according to the system disclosed above with regard to Fig. 2, authentication system 110 may be configured to generate the current private key and the current public key from the previous private key and public key. In such embodiments, k(i + 1) = S_i+1k(i) and p(i + 1) = S_i+1p(V). In optional step 420, authentication system 110 may be configured to generate at least one message key pair, as described above with regards to Figs. 2 and 3. [043] In step 425, authorization system 110 may be configured to generate an encrypted message using a private message key. The private message key may have been precomputed by authorization system 110, or may have been generated by authorization system 110 in response to receipt of the message or request (e.g., according to one or more of optional steps 410 to 420). Authorization system 110 may be configured to encrypt the received message, or may be configured to generate a message based on the received message or request, and encrypt this generated message. In step 430, authorization system 110 may be configured to provide the encrypted message to processing nodes 120. As described above, processing nodes 120 may be configured to include the encrypted message in message set 122.

[044] Fig. 5 illustrates an exemplary process for requesting selective access to cryptographically related messages. In step 505, user device 130 may provide a request for access to authorization system 110. User device 130 may be configured to provide the request for access in response to indications received from user 130a. The request may indicate the desired message(s), or may comprise a query indicating one or more criteria satisfied by the desired message(s). In some embodiments, as part of the request, user device 130 may interact with authorization system 110 to authenticate at least one of user device 130 and user 130a. User device 130 may also interact with authorization system 110 to determine whether user device 130 and/or user 130a is authorized to access the desired message(s).

[045] In step 510, user device 130 may be configured to receive access information for the desired message(s). When authorization system 110 generated the desired message(s) according to the system of Fig. 2, the access information may comprise the state corresponding to the most recently provided desired message, and the

corresponding public key. In this example, when messages M2 and M4 are requested, the access information may comprise {s(4), p(4)}. Alternatively, the access information may comprise {s(4), p₀}. When authorization system 110 generated the desired message(s) according to the system of Fig. 3, the access information may comprise one or more state(s) selected so that the desired message(s) may be decrypted, and the master public key. The access information provided may not enable other messages to be decrypted. In this example, when messages Ml, M2 and M4 are requested, the access information may comprise {s(l,2), s(4,l), Po)- As described above with regards to Fig. 3, message public keys corresponding to Ml and M2 may be generated from s(l,2) and Po, while only the message public key corresponding to M4 may be generated from s(4,l) and p₀. Thus M3 may not be decrypted using this access information. In some embodiments, the access information may comprise message public key(s) for the desired message(s).

[046] In step 515, user device 130 may be configured to generate message public key(s) for the desired message(s). The message public keys may be generated according to the system described in Figs. 2 and 3. In some embodiments, the public key(s) may be generated using a client application running on user device 130.

[047] In step 520, user device 130 may be configured to request the desired message(s) from processing nodes 120. In step 525, the processing nodes 120 may obtain the desired message(s) from message set 120, for example from the pool of messages or the data structure, and may provide them in response to the request from user device 130. Alternatively, user device 130 may already have the desired

message(s). For example, user device 130 may comprise one of the processing nodes 120.

[048] In step 530, user device 130 may be configured to access the desired message(s). For example, user device 130 may be configured to decrypt the desired message(s) using the message public keys generated in step 515. In some embodiments, decryption may be handled using a client application running on user device 130.

[049] Fig. 6 depicts an exemplary computing system for granting selective access to messages. In some embodiments, computer system 600 includes a processor 601, memory 603, display 605, I/O interface(s) 607, and network adapter 609. These units may communicate with each other via bus 611, or wirelessly. The components shown in Fig. 6 may reside in a single device or multiple devices.

[050] Consistent with disclosed embodiments, processor 601 may be a

microprocessor, central processing unit (CPU), graphical processing unit (GPU), or similar device. Memory 603 may include non-transitory memory containing non- transitory instructions, such as a computer hard disk, random access memory (RAM), removable storage, or remote computer storage. In some aspects, memory 603 may be configured to store software programs. In some aspects, processor 601 may be configured to execute non-transitory instructions and/or programs stored on memory 603 to configure computer system 600 to perform operations of the disclosed systems and methods. In various aspects, as would be recognized by one of skill in the art, processor 601 may be configured to execute non-transitory instructions and/or programs stored on a remote memory to perform operations of the disclosed systems and methods. Display 605 may be any device which provides a visual output, for example, a computer monitor, an LCD screen, etc. I/O interfaces 607 may include means for communicating information to computer system 600 from a user of computer system 600, such as a keyboard, mouse, trackball, audio input device, touch screen, infrared input interface, or similar device. Network adapter 609 may include means for enabling computing system 600 to exchange information with external networks. For example, network adapter 609 may include a wireless wide area network (WW AN) adapter, a Bluetooth module, a near field communication module, or a local area network (LAN) adapter.

[051] The foregoing disclosed embodiments have been presented for purposes of illustration only. This disclosure is not exhaustive and does not limit the claimed subject matter to the precise embodiments disclosed. Those skilled in the art will appreciate from the foregoing description that modifications and variations are possible in light of the above teachings or may be acquired from practicing the inventions. In some aspects, methods consistent with disclosed embodiments may exclude disclosed method steps, or may vary the disclosed sequence of method steps or the disclosed degree of separation between method steps. For example, method steps may be omitted, repeated, or combined, as necessary, to achieve the same or similar objectives. In various aspects, non-transitory computer-readable media may store instructions for performing methods consistent with disclosed embodiments that exclude disclosed method steps, or vary the disclosed sequence of method steps or disclosed degree of separation between method steps. For example, non-transitory computer-readable media may store instructions for performing methods consistent with disclosed embodiments that omit, repeat, or combine, as necessary, method steps to achieve the same or similar objectives. In certain aspects, systems need not necessarily include every disclosed part, and may include other undisclosed parts. For example, systems may omit, repeat, or combine, as necessary, parts to achieve the same or similar objectives. Accordingly, the claimed subject matter is not limited to the disclosed embodiments, but instead defined by the appended claims in light of their full scope of equivalents. ANNEX A

Secret Linking of Blockchain

Michael A. Segal

October 24, 2016

1 I lit rod i uction

We expound a, technique for storing chronologically discrete data on a Bitcoin- like blockchain in a way that permits grajiular access control to chronological segments of the data sequence. The data sequence is forward-extensible and can be appended efficiently in constant time. Access to a particular segment permits verification of that segment's completeness and reveals no information about prior or subsequent, elements of the sequence.

We further demonstrate how this technique can be used to provide a private and auditable identity management system that correlates timestamped records from various sources to provide a consolidated user activity profile.

The Bitcoin protocol uses the Elliptic Curve Digital Signature Algorithm (ECDSA) to identify the owner or owners of assets recorded on a blockchain. By defining a transformation on the public keys used to identify ECDSA signatories that cannot be efficiently inverted, it is possible to derive a hierarchy of public keys which can be publicly followed outward but not toward its root.

1 A construction by Marson and Poettering [l j provides a private key-holder with random access to such a key hierarchy, enabling the construction of a target node in the hierarchy that is far from the root. This technique enables users and publishers alike to share verifiably complete segments of a user's activity record with authorized parties while obscuring the relatedness of future activity.

3 Construction

Given a key space JT, let SSKG : Jf x -> represent a seekable sequential key generator with evolution function £.

Let (G, +) be an elliptic curve group with generator g, k₀ < \G\ a randomly selected key with corresponding public key p₀ := gk₀, and n < \G\ a large constant.

Definition 3.1 (Sequence State). For each integer 1 < i < n, we define the state i of the sequence at position i as follows;

Definition 3.2 (Sequence Key Pair). For each integer 0 < i < n, we derive a, private key:

and its corresponding public key:

Thus, possession of A¾ is sufficient to efficiently compute all fc, Observation 3.3 (Public Key Backtracing). Given (pi₊i, _t+ ) for some i€ (l..n), we can compute (p*,«Si) as:

Pi = ¾p_i+i

By contrast, deriving (p,: i, «¾ j i) from (ρ_ί; 6*) is not possible by construction

Definition 3.4 (Message Key Pair). For each private key ¾, we derive a private key

and corresponding public key:

V ;■ CKDpub(pi,0) where CKDpriv and CKDpub are as defined in [2],

Definition 3.5 (Message). For each integer i £ [l..n|, let the i-th message Mi consist of the i-th chronological datum in our sequence together with p'_j.

MASTER

Figure 1 : Key derivation graph 3 Observation 3.6 (Secrecy). For all i. j G [l..nj such that % φ j. Mi alone is insufficient to determine that _j belongs to the same message sequence. This follows from the construction of CKDpub in |2] .

Observation 3.7 (Derivation of Initial Segments) . For all i 6 [l..n], (pi, Si) is sufficient to derive p'₃ if and only if j < i.

Observation 3.8 (Forward- Extensibility) . As M : does not depend on (p, , S._j, M_j) for any i < j, we can publish M : prior to computing (p,-, S_j) and the publisher can extend the sequence in 0(1) time and space by remembering only the last computed <¾ ,

Using the derived message keys p'_{ from Section 3, we can now publish the messages Mi to the blockchain, one per transaction. The message key can be included in the body of a prunable OP -RETURN output script, or its address hash can be the target of a Pay-to-Pubkey-Hash script. New messages can be generated in response to real- world events and appended to the existing message sequence.

Additionally, by generating multiple SSKG seeds from the same master key, it is possible to maintain several independent message sequences, all of which can be traced back by authorized parties to the master public key or an associated identity record. This is depicted in Figure 2.

As the purpose of publishing to the blockchain is to irrepudiably commit to a public record of transpiring events, it is necessary for authorized users to be capable of verifying the authenticity of the message sequence. This is accomplished by including, in the first transaction in each sequence, an input for each authority who corroborates the message which spends bitcoin from an address that is publicly known to belong to that authority (a "green

4 address" ). If every message among all sequences to which a given authority is party spends from the same green address, then users who trust that authority may also trust that new messages that appear in the memory pool will be recorded on the blockchain without waiting for the message to confirm. The message publisher may therefore pay lower transaction fees without inhibiting the availability or reliability of event records.

Note that care must be taken not to leak information about the sequence to which messages belong nor to their position within a sequence via the set of input addresses that signs each transaction.

m

Figure 2: Event linking

o 5 Extension to Non-Initial Segments

We seek to enable master key-holders to share any chronological segment of an event sequence, rather than only initial segments as described above. Here we present one method of doing so and some of its drawbacks.

Using the construction in [lj, we define a 2-dimerisional SSKG,

SSKG₂■ Jti x N²→ tT with evolution functions £± and £₂ satisfying the following conditions:

S₁{SSKG₂{k,i,j)) = SSKG₂{k,i,j + 1)

£₂{SSKG₂(k,i,j)) = SSKG₂{k,i + l,j + 1)

Definition 5.1 (Lattice State). We then define our lattice state <%.₃· for i G [l..n\,j€- [1..71 — i + lj by:

Definition 5.2 (Key

1], we define lattice key pairs:

P..; ^: <-¾p₀

and message key pairs: k'_j := CKDpriv (f¾,i,0)

p'.^■— CKDpub(pi_t 0)

We can now define messages as in Section 3.

6 Observation 5.3 ( State Graph Navigation) , if given the master public key Po arid any state tS,;_{,1 +}i , we can compute p _j as:

i _j - S, _jpo

and similarly, given p₀ and «_>_i+1j+1, we can compute ρ_{ί ?}· as:

Observation 5.4 (Derivation of Arbitrary-Length Segments). For ail i G \l..n] and j € [\ . :n, — i -j- l j , (p₀, 5^·) is sufficient to derive p'_r if and only if i < r < i + j■

For d £ [ ..j), we compute Si+_ds as:

Observation 5.5. As our state evolution graph is non-linear, public key derivation requires knowledge of the master public key pn. This is in contrast with the method used in Section 3, where only the last-derived public key is needed to determine all previous keys in the sequence.

Observation 5.6, Auditors who are granted access to a non-initial segment of a message sequence cannot rely on the initial message to determine a user's identity. Therefore, this construction requires an additional mechanism to link each segment to the master identity record. Care must be taken that such pointers do not leak information about their reiatedness to unauthorized users.

One method for doing this is to include in ΛΊ,; an ECDSA signature, signed by fc^ , of the master public key or identity record hash. However, implementations that publish messages in 0P_RETURN scripts must contend with space limitations imposed by the Bitcoin network. 6.1 Identity Management

As a motivating use case, we describe a blockchain-based identity management system that stores data about users in four sequences, all linked to a central identity record called the AirlD which acts as a unique identifier for the user.

The four data sequences are:

• Transactions - contains all payments and payment obligations by and to the user

• Documents - contains cryptographic commitments to personal information and supporting documentation provided by the user

• Verifications - contains authentication and risk mitigation steps completed by the user

• Sanctions - contains records of censure, misconduct, or deficiencies that may affect a user's eligibility for financial services

Separating these sequences allows the user to selectively share provably complete segments of each type of information independently of the others.

Figure 3: Four data sequences linked to the same 6.2 Medical Records

The above example can be modified to include data sequences containing encrypted patient medical records, or cryptographic commitments thereto. By providing both the doctor and patient with a master key to these sequences, we give each of them complete control over third-party access to the patient's medical records and granular control over which aspects of the patient's medical records are shared.

6.3 Property Registration

This technique can further be applied to record data that is typically recorded by government entities, either as a more accessible secondary source or as a primary source in jurisdictions that lack the public infrastructure to track such information. This includes property ownership records such as land deeds, title transfers, and other alteration events.

This technology offers information authorities the ability to selectively verify property information without the cost or technical burden of running their own public-facing server, and offers information auditors the ability to independently validate the authenticity and origination timestamp of the shared data.

6.4 Clinical Trials

As a final example, we consider experimental data, such as that collected in pharmaceutical studies on human patients. The technique described in this paper ca be employed to allow trial operators to selectively and auditably share the history of their trial data, including adverse reactions in subjects, without revealing personally identifying information about trial subjects.

9 References

Giorgia Azzurra Marson and Bertram Poettering. Practical Secure Logging: Seekable Sequential Key Generators. Cryptology ePrint Archive, Report 2013/397, http://eprint.iacr.org/2013/397.2013.

Pieter Wuille. Hierarchical Deterministic Wallets.2012. URL: https : / / git hub . com/bitcoin /bips / blob /master /bip- 0032. media iki (visited on 10/03/2016).

10

Claims

What is claimed is:

1. A authorization system for providing selective access to messages, comprising: at least one processer; and at least one non-transitory memory storing instructions that, when

executed by the at least one processor, cause the authorization system to perform operations comprising: receiving, from an user device, a message or message request, generating an encrypted message using a message public key generated using a seekable sequential key generator, providing the encrypted message to at least one

processing node for incorporation into a data structure comprising an irrevocable record of the encrypted message.

2. The authorization system of claim 1, the operations further comprising

generating the message public key using a public key of a key pair.

3. The authorization system of claim 2, the operations further comprising

generating the key pair using an element of a state set, a public key and a private key.

4. The authorization system of claim 3, the operations further comprising

generating a state using the seekable sequential key generator and a

decrementing index.

5. The authorization system of claim 4, wherein the state has a first dimension

index, and wherein the decrementing index comprises a second dimension index.

6. The authorization system of claim 3, wherein the message public key may be generated using a state with a first dimension index less than an index of the message public key. The authorization system of claim 3, wherein the message public key may be generated using a state with a first dimension index less than or equal to an index of the message public key and a sum of the first dimension index and a second dimension index greater than the index of the message public key.

The authorization system of claim 1, wherein the message concerns at least one of identity management, medical, legal, or business information for a person or legal entity.

The authorization system of claim 1, wherein the data structure comprises the bitcoin blockchain.