How PAD Works

Developer Documentation
Search…
Introduction
How PAD Works
Applying for a new PAD Instance
Setting up a Trustee
Code Samples for Encryptor and Decryptor
Code Samples for Auditor
API Description
Building a Find Me App With PAD
Glossary
How PAD Works
Here we describe the PAD protocol - the stuff that goes on behind the scenes of the API. This is the place to start if you want to understand the cryptography and mathematics behind the protocol before diving into code.
In this section we take some liberties in describing the protocol to make the main ideas easy to digest quickly. For all of the precise details, please see the comprehensive information in the Code Samples section of the documentation.
Protagonists of the PAD protocol
Alice is a user of the protocol, and she has a secret that she would like to make available to Bob under certain circumstances that are not well-defined in advance. 
Bob is the intended recipient of Alice's secret. 
Trustees respond to decryption requests - they do not judge whether a request is made at appropriate circumstances. To distribute trust and ensure that no secret is decrypted without Alice's knowledge, the PAD protocol makes use of multiple trustees. For any given secret to be decrypted, a threshold number of them must respond to Bob's decryption request.  
The lifecycle of PAD data
Here we describe how data flows through the PAD system.
Secret generation and encryption
Let's imagine that Alice has an application built on the PAD API. She also has a secret, perhaps even a new one every second. There are no constraints on the secret - it could be a location, a passphrase, a document, or any other digital information. With her personal device, Alice generates a fresh symmetric key K and encrypts her secret with it. She then again encrypts that ciphertext using the public key of Bob. Next, the key K is split into shares using a cryptographic secret sharing scheme. This produces shares of the key K - one for each of the trustees. Finally, each share is encrypted using the public key of the trustee that the share is associated with.
Everything is now ready for storage with the PAD service.
PAD-locking a secret
Alice assigns an arbitrary token value to reference her secret. Then, Alice's application sends all of the following to the PAD service using the API:
Ciphertext encrypted with Bob's public key. This contains the encryption of her secret using the new symmetric key K.
Encrypted shares of the key K: one share per trustee, with each share encrypted using a public key of the associated trustee.
The hash of the token value. 
The PAD service stores this data. Of course, Alice's secret remains safe because it is stored only in encrypted form with the PAD service. The trustees only need to store their own personal key pair.
Lastly, Alice sends Bob her token value. This is what he will use to request decryption of Alice's secret.
Updating data
If Alice has a new secret, she can repeat the above process. Alternatively, Alice may wish to update a secret previously secured with PAD and already associated with a token. This is convenient and straightforward as it doesn't require that she be in contact with Bob to provide a new token. To update a secret, Alice simply encrypts the new secret and submits this data to the PAD service again, using the same token hash.
Submitting a decryption request
When Bob wishes to decrypt Alice's secret, he uses his application to send the token and its hash to the PAD service via the API. The PAD server then finds the information provided by Alice that has been associated with the token hash and publishes all of it on the PAD ledger.
The ledger now contains an encryption (under the symmetric key K and again under Bob's public key) of Alice's secret, and one encrypted secret share of K per trustee. This is when trustees participate in the decryption.
The role of trustees
Trustees monitor the PAD ledger for decryption requests that require their action. When they see a ciphertext that has been encrypted with their public key, they decrypt and publish the result back to the ledger.
Each of the trustees publish a secret share of the decryption key K. Once a threshold number of the trustees have published the plaintext share, Alice knows Bob now has access to her secret.
Recovering the original data
When a threshold number of trustees have responded to the data decryption request, Bob can access Alice's secret by taking the following steps:
1.Bob sees the ciphertext, which was encrypted to his public key. He decrypts to the plaintext, which itself is an encryption of Alice's secret using the symmetric key K.
2.Using the secret sharing scheme reconstruction procedure, Bob uses the trustee responses published on the ledger to compute K.
3.Using the ciphertext in (1) and the key in (2), Bob decrypts the ciphertext of Alice's secret. He now knows her secret.
Transparency for Alice
The cornerstone of PAD is the accountability of its decryption: Alice will always know if and when her secret has been accessed. This accountability is provided by PAD's public immutable ledger which makes permanent Bob's decryption requests and the responses from trustees.
The way in which Alice has encrypted her secret requires that at least Bob and a threshold number of trustees are required to uncover her secret. In unusual circumstances, perhaps one or two trustees would be willing to work with Bob to decrypt a secret without checking that Bob's request is on the public immutable ledger. All such malicious efforts reveal nothing about Alice's secret unless a large coalition with a threshold number of trustees all operate maliciously. The threshold parameters can be tuned according to use case, either to emphasise security or high availability.
As long as there does not exist a malicious threshold of trustees, the PAD system provides both positive and negative proofs about whether an encryption has occurred. Ledger entries are proof positive. Their absence is proof that Bob has not decrypted.
Ledger immutability
The PAD ledger is a privately managed Hyperledger Fabric (HLF) blockchain and anyone can use the API to query its state. Future updates of the PAD protocol will enable trustees to operate as a peer on any number of HLF channels. Presently, we use a different mechanism to guarantee and prove that the ledger is being maintained properly and is append-only. In addition to a key pair, trustees maintain a hash value that represents their current view of the PAD ledger based on the requests and responses that they have seen. Everytime a decryption request or trustee response is added to the ledger, trustees receive a hash chain proof that this update represents an append-only modification to the ledger state. To ensure that all trustees agree on the current state, trustees will occasionally attest to their current view by publishing the hash value on the ledger.
PAD reference diagram
Protocol in a nutshell (slightly simplified - see code documentation for full details)
Encrypting a secret
Let Alice's secret be sss
. Alice generates a brand new symmetric encryption key KKK
 and uses it to encrypt her secret: C=EncK(s)C = Enc_K(s)C=EncK​(s)
.
Alice uses Bob's public key pkBpkBpkB
 to encrypt again: C′=EncpkB(C)C' = Enc_{pkB}(C)C′=EncpkB​(C)
.
Suppose that there are nnn
 trustees, holding public keys pkT1,…,pkTnpkT_1,\dots,pkT_npkT1​,…,pkTn​
. Alice's device uses a cryptographic secret sharing scheme to split KKK
 into nnn
 shares s1,…,sns_1, \dots, s_ns1​,…,sn​
. The secret sharing scheme reconstruction threshold is set to ttt
, meaning that at least t-out-of-n shares are necessary and sufficient to reconstruct KKK
.
For each i=1,…,ni = 1, \dots ,ni=1,…,n
, Alice encrypts the share sis_isi​
 using the public key pkTipkT_ipkTi​
.
Alice generates an arbitrary token value tkntkntkn
 that is used to reference her secret. She sends (C′,EncpkT1(s1),…,EncpkTn(sn),hash(tkn))(C', Enc_{pkT_1}(s_1), \dots, Enc_{pkT_n}(s_n), \mathrm{hash}(tkn))(C′,EncpkT1​​(s1​),…,EncpkTn​​(sn​),hash(tkn))
 to the PAD service.
Alice sends tkntkntkn
 to Bob.
Decrypting a secret
Bob posts tkntkntkn
 to the PAD ledger and in response, the PAD service publishes C′C'C′
 and EncpkTi(si)Enc_{pkT_i}(s_i)EncpkTi​​(si​)
 for each i=1,…,ni = 1, \dots, ni=1,…,n
.
For each i=1,…,ni = 1,\dots,ni=1,…,n
, trustee iii
 decrypts EncpkTi(si)Enc_{pkT_i}(s_i)EncpkTi​​(si​)
 and publishes sis_isi​
 to the PAD ledger.
Bob applies the secret sharing reconstruction procedure to at least ttt
 of the published secret shares, deriving KKK
.
Bob can decrypt C′C'C′
 to C=EncK(s)C = Enc_K(s)C=EncK​(s)
 using his private key and decrypt CCC
 to sss
 using KKK
.
Introduction
Applying for a new PAD Instance
Last modified 10mo ago
Copy link
Outline
Protagonists of the PAD protocol
The lifecycle of PAD data
Secret generation and encryption
PAD-locking a secret
Submitting a decryption request
The role of trustees
Recovering the original data
Transparency for Alice
Ledger immutability