CALYPSO: Auditable Sharing of Private Data over Blockchains
Page content transcription
If your browser does not render page correctly, please read the page content below
C ALYPSO: Auditable Sharing of Private Data over Blockchains Eleftherios Kokoris-Kogias∗ , Enis Ceyhun Alp∗ , Sandra Deepthy Siby∗ , Nicolas Gailly∗ , Linus Gasser∗ , Philipp Jovanovic∗ , Ewa Syta† , Bryan Ford∗ ∗ École polytechnique fédérale de Lausanne, Switzerland † Trinity College, USA Abstract—Securely sharing confidential data over a distributed ledger with a fully decentralized and efficient access-control mechanism is a non-trivial challenge to solve. Current blockchain systems either do not support such a functionality or fall back to semi-centralized solutions that provide storage and access control for sensitive data off-chain. In this work we present C ALYPSO, the first fully decentralized, auditable access-control framework for secure blockchain-based data sharing which builds upon two abstractions. First, on-chain secrets enable collective management of (verifiably shared) secrets under a Byzantine adversary where an access-control blockchain enforces user-specific access rules and a secret-management cothority administrates encrypted data. Second, skipchain-based identity and access management enables efficient administration of dynamic, sovereign identities and access policies and, in particular, permits clients to maintain long- term relationships with respect to evolving user identities thanks to the trust-delegating forward links of skipchains. The evaluation Fig. 1. Private, auditable data sharing in C ALYPSO: (1) Wanda encrypts data of our C ALYPSO implementation shows that the latency for pro- under the secret-management cothority’s key, specifying Ron as the authorized cessing read and write requests scales linearly with the number reader in the policy, and sends it to the access-control cothority which verifies of secret-management trustees and is in the range of 0.2 to 8 and logs the information. (2) Ron downloads the encrypted secret from the seconds for 16 to 128 trustees. Lastly, three specific deployments blockchain and then requests access to it from the access-control cothority of C ALYPSO illustrate its feasibility and applicability to data- which logs the query if valid. (3) Ron asks the secret-management cothority sharing problems faced by real-world organizations. for the secret shares of the key needed to decrypt the secret by proving that the previous authorization was successful. (4) Ron decrypts the secret. I. I NTRODUCTION The massive aggregation of user-generated data by central- tion and hashes of the data are put on-chain but the secret ized service providers combined with the lack of mechanisms data itself is not only stored but also managed off-chain in for users to audit and control the usage of their data presents centralized or distributed storage  systems, creating single a continuous threat to the privacy of billions . This threat points of compromise or failure. can turn into concrete perils for democracy itself as illustrated From these observations, we identified the following key by the Facebook scandal , where Cambridge Analytica challenges that a secure blockchain-based data sharing system allegedly exploited personally identifiable information from with access-control support should address: (1) Enable data millions of Facebook users to influence voter opinion in the owners to share and maintain control over their data and, in 2016 US presidential election. New data privacy legislation, particular, enable them to update access-control rules, e.g., such as the European Union General Data Protection Regu- to add or revoke access rights, retroactively. (2) Provide lation (GDPR) , is an important step towards addressing auditability of all data accesses, e.g., to be able to hold data abuses, however, it needs to be complemented by modern misbehaving users accountable. (3) Allow users to update their technological solutions that put users back into control. identities without losing access to already shared data. (4) Decentralized trust technologies have gained significant Ensure atomic execution of data access requests as well as traction due to the success of cryptocurrencies such as Bit- identities and access rights updates, e.g., to prevent participants coin  and Ethereum . While they present a promising from exploiting race conditions to gain unauthorized access path forward to address the above data sharing challenges, they to confidential data. (5) Support efficient data sharing with are not without issues. Blockchain-based applications , individual users and groups of users. (6) Prevent any single , ,  often assume a shared access to sensitive point of compromise or failure in the system. data between independent and mutually distrustful parties In this paper we introduce C ALYPSO, a new secure but unfortunately fail to manage private data securely over blockchain-based data sharing framework with access-control the blockchain. These applications either ignore the problem support that addresses the above challenges. Figure 1 provides altogether , , fall back to naive solutions  of an overview of C ALYPSO which consists of two main com- simply publishing encrypted data on Bitcoin, or utilize semi- ponents called on-chain secrets (OCS) and skipchain-based centralized approaches , , , where access informa- identity and access (control) management (SIAM).
On-chain secrets combine threshold cryptography , , II. BACKGROUND  and blockchain technology ,  to enable clients to securely share their encrypted data and the corresponding A. Blockchains and Skipchains access-control policies with collective authorities (cothorities) A blockchain is a distributed, append-only and tamper- responsible for enforcing access-control policies and deliv- evident log that is composed of blocks which are joined ering data to authorized readers. When a reader requests together via cryptographic hashes. Blockchains are used in access to an on-chain secret, he provides a cryptographic many decentralized applications , . C ALYPSO can be authorization proof. C ALYPSO atomically logs both request deployed on top of any blockchain that supports programma- and proof to guarantee auditability and then delivers the bility (e.g., smart contracts , , ) which enables us information necessary for the reader to access the secret. We to perform custom validation of transactions before logging. present two specific implementations of on-chain secrets, one- time secrets and long-term secrets, which have different trade- In Section V, we introduce identity skipchains which are offs with respect to computational and storage overheads as based on the skipchains data structure  that is similar to a well as the functionality they provide. Finally, we present two simple blockchain but doubly-linked. Skipchains (Figure 3) extensions to on-chain secrets that ensure user anonymity and track configuration changes of a well-known decentralized provide post-quantum security, respectively. authority (a cothority ) by using every block as a rep- resentation of all public keys of the cothority necessary to Skipchain-based identity and access management supports authenticate the next block. When the cothority wants to alter both personal and federated identities and fine-grained re- its configuration, it creates a new block that includes the new source access policies. It enables users to verifiably update set of public keys and signs it with the old set of public keys their identities (public keys) and to efficiently share secrets delegating the authority to the new set. This signature is a even with large groups of people under custom rules with- forward link  which clients follow through the skipchain out the need to create individual transactions. SIAM uses to get up-to-date with the current authoritative group. skipchains  to securely and efficiently enable dynamic identity and policy updates and revocation. Lastly, SIAM protects against race conditions by serializing identity and B. Threshold Cryptosystems policy updates with data access requests over the blockchain. A (t, n)-secret sharing scheme ,  enables a dealer To evaluate C ALYPSO, we implemented a prototype in Go to share a secret s among n trustees such that any subset of and ran experiments on commodity servers. We implemented t trustees can reconstruct s, whereas smaller subsets cannot. both versions of on-chain secrets and show that they have a Hence, the sharing scheme can withstand up to t−1 malicious moderate overhead of 0.2 to 8 seconds for cothorities of 16 participants. The downside of simple secret sharing schemes and 128 trustees, respectively, overall scaling linearly in the is that they assume an honest dealer. Verifiable secret sharing number of trustees in the cothorities. We also implemented (VSS)  solves the problem by enabling the trustees to SIAM and show that the overheads of dynamic identities and verify that the shares distributed by the dealer are consistent. access policies are negligible compared to the static versions. VSS has a wide range of applications such as threshold signing Finally, we also discuss several deployments of C ALYPSO that and threshold encryption, described below. Finally, publicly address the data sharing needs of real-world organizations. verifiable secret sharing (PVSS)  is a variation of VSS that In summary, this paper makes the following contributions. enables any external third-party to verify distributed shares. • We introduce C ALYPSO , a decentralized framework for Once we are able to securely share and hold a collective auditable access control of protected resources over a secret, we can construct more complex systems out of it. distributed ledger that maintains confidentiality of the A distributed key generation (DKG)  protocol allows shared data and enables participants to update access rules to create a collective public-private key pair without any for their resources even after they have been released. dependence on a trusted dealer. Each trustee runs their own • We present on-chain secrets and its two concrete imple- secret sharing protocol in parallel to contribute their own secret mentations, one-time and long-term secrets, that enable towards the key pair. The trustees validate each run, reach a fully transparent and efficient management of secret data consensus on validly shared secrets, and finally combine all over a blockchain via threshold cryptography. shares to generate a private-public key pair (sk, g sk ) such that • We introduce skipchain-based identity and access man- the public key pk = g sk is known to everyone whereas the agement for third-party verifiable, dynamic and sovereign private key sk is not known to any single trustee and can only identities and updateable access policies. be used when a threshold of them collaborates. • We demonstrate the feasibility of using C ALYPSO to After the key pair is generated, anyone can encrypt data un- address the data sharing needs of actual organizations der the collective public key, for example, by using a threshold by presenting three concrete deployments, auditable in- version of ElGamal . For C ALYPSO we use this threshold voice issuing, clearance-enforcing document sharing, and ElGamal cryptosystem in combination with non-interactive patient-centric medical data sharing. We also provide an zero knowledge (NIZK) proofs ,  (see Appendix B) open-source implementation and evaluation results. to protect against chosen ciphertext and malleability attacks.
III. C ALYPSO OVERVIEW 3) Atomic Data Delivery: A client is guaranteed to receive a secret they are authorized for if any only if they posted In this section we present an overview of C ALYPSO. We an access request for that secret on the blockchain. start with a strawman solution called S IMPLE S HARE to moti- 4) Dynamic Sovereign Identities: Users or organizations vate the challenges that any secure, decentralized data sharing fully control their identities (public keys) and can update system with access control like C ALYPSO should address. them in a third-party verifiable way. We then outline the system goals that we derive from our 5) Decentralization: No single point of compromise or observations about S IMPLE S HARE, describe system and threat failure. models, and finally present a high-level overview on the secret sharing process in C ALYPSO as outlined in Figure 1. C. System Model A. Strawman Data Sharing Solution There are four main entities in C ALYPSO: writers who put secrets on-chain, readers who retrieve secrets, an access- S IMPLE S HARE consists of a tamper-resistant public log, control collective authority who is responsible for logging such as Bitcoin’s blockchain, and a centralized identity write and read transactions on-chain enforcing access control provider, such as a PGP key server. As a motivation, consider for secrets, and a secret-management collective authority who a situation where Wanda wants to asynchronously share some is responsible for managing and delivering secrets. In the rest secret data with Ron, i.e., Wanda and Ron do not have to be of the paper we use Wanda and Ron to refer to a (generic) online concurrently for the exchange and to guarantee that the writer and reader, respectively. A collective authority or data is available for Ron to retrieve at any point. cothority is an abstract decentralized entity that is responsible In S IMPLE S HARE, Wanda first needs to get Ron’s public for some authoritative action. For example, the set of Bitcoin key from Ron’s identity provider (a PGP server), then encrypt miners can be considered a cothority that is maintaining the the secret under Ron’s key, and finally post the ciphertext on consistency of Bitcoin’s state. We call the nodes of a cothority the public blockchain to ensure availability. Later on, Ron can trustees and remark that these nodes do not need to be agreed download the ciphertext from the blockchain and decrypt the upon and individually publicly known. data using his private key. The access-control cothority requires a Byzantine fault- S IMPLE S HARE already provides functionality similar to tolerant consensus , , , . There are various what we envision for C ALYPSO but has several drawbacks. (1) ways to implement an access-control cothority, e.g., as a set of Once the encrypted data gets published, Wanda loses control permissioned servers that maintain a blockchain through BFT over its access policy, e.g., she cannot revoke access later since consensus or as an access-control enforcing smart contract the ciphertext is encrypted under Ron’s public key and publicly on top of a permissionless cryptocurrency such as Ethereum. available. (2) Wanda does not know if Ron ever accessed the In our implementation, see Section VIII, we use BFT-based data, i.e., there is no accountability of data accesses and hence consensus due to its performance benefits . Ron has plausible deniability should the data be misused. (3) If The secret-management cothority may be set up on a per- Wanda wants to share the same data with multiple people, she secret basis or in a more persistent manner, the differences would need to encrypt it under each individual public key and of which are discussed in Section IV. The secret-management publish all resulting ciphertexts. (4) If Ron wants to change his trustees maintain their private keys and may need to maintain public key, e.g., if his private key is compromised, he would additional secret state, such as private key shares. They do not lose access to the previously posted ciphertexts unless Wanda run consensus for every transaction. re-publishes the data using Ron’s new key. (5) The identity We denote private and public key pairs of Wanda and provider is a single point of compromise or failure. Ron by (skW , pkW ) and (skR , pkR ). Analogously, we write To address these issues, we introduce two components to (ski , pki ) to refer to the key pair of trustee i. To denote a list S IMPLE S HARE thereby transforming it into C ALYPSO. of elements we use angle brackets, e.g., we write ⟨pki ⟩ to refer 1) To enable auditability of data accesses and ensure atomic to a list of public keys pk1 , . . . , pkn . We assume that there is a data delivery, we introduce on-chain secrets (OCS) in registration mechanism through which writers have to register Section IV. their public keys pkW with the blockchain before they can 2) To enable decentralized, dynamic user-sovereign identi- start any secret-sharing processes. We denote an access-control ties and access policies, we introduce skipchain-based label by policy, with policy = pkR being the simplest case identity and access management (SIAM) in Section V. where Ron is the only intended reader of Wanda’s secret. B. System Goals D. Threat Model C ALYPSO has the following primary goals. We make the usual cryptographic assumptions, namely 1) Confidentiality of Secrets: Secrets stored on-chain can that the adversary is computationally bounded, that crypto- only be decrypted by authorized clients. graphically secure hash functions exist, and that there is a 2) Auditability: All access transactions are third-party veri- cyclic group G (with generator g) in which the decisional fiable and recorded in a tamper-resistant log (blockchain). Diffie-Hellman assumption holds. We assume that participants,
including cothority trustees, verify the signatures of the mes- Access-control Secret-management Writer Reader sages they receive and process those that are correctly signed. cothority cothority In the respective cothorities, we denote the total number of Write transaction txw Verify trustees by n and those that are malicious by f . Depending (1) ACK / NACK and log on the consensus mechanism that is used for the blockchain underlying the access-control cothority, we either require an Read transaction txr Verify (2) and honest majority n = 2f +1 for Nakamoto-style consensus  ACK / NACK log or n = 3f + 1 for classic BFT consensus . In the secret- Share request reqshare management cothority, we require n = 2f + 1 and set the (3) Verify Share reply repshare / Error threshold to recover a secret to t = f + 1. To ensure a proper ratio of honest and dishonest trustees, C ALYPSO can Recover use unbiasable publicly verifiable randomness  to select (4) and decrypt trustees from a larger pool of available nodes. We emphasize the importance of ensuring consensus on any transaction included in the blockchain before the trustees hand out the corresponding inclusion proofs. This is especially Fig. 2. On-chain secrets protocol steps: (1) Write transaction, (2) Read important for Nakamoto-style consensus where forks might transaction, (3) Share retrieval, (4) Secret reconstruction. still occur within the last few blocks. We assume that readers and writers do not trust each other. previous section apply to both protocols. We also present two We assume that writers encrypt the correct data and share the protocol extensions: an on-chain blinded key exchange that correct symmetric key with the secret-management cothority, allows to conceal the identities of the readers as well as a as readers can release a protocol transcript and prove the post-quantum secure version of on-chain secrets. misbehavior of writers. Conversely, readers might try to get One-time secrets uses PVSS and employs a per-secret access to a secret and claim later that they have never received secret-management cothority. One-time secrets’ simplicity en- it. Additionally, writers might try to frame readers by claiming ables each txw to define a fresh, ad hoc group of secret- that they shared a secret although they have never done so. management trustees without any setup or coordination. This We guarantee data confidentiality up to the point where an simplicity, however, comes at a price. The txw size and the authorized reader gains access. To maintain confidentiality af- encryption/decryption overhead are linear in the size of the ter this point, writers may rely on additional privacy-preserving secret-management cothority because all encrypted shares are technologies such as differential privacy  or homomorphic included in the transaction and the number of secret shares is encryption . Combining these techniques with C ALYPSO equal to the size of the secret-management cothority. is beyond the scope of this paper. Long-term secrets, the second approach to implementing on-chain secrets, requires the secret-management cothority to E. Architecture Overview perform a coordinated setup phase to generate a collective key On a high level C ALYPSO’s enables Wanda, the writer, to (DKG) and to maintain a minimal state of their DKG secret share a secret with Ron, the reader, under a specific access- shares. As a result, however, long-term secrets offers a con- control policy. Figure 1 shows the general steps of sharing stant encryption overhead and a flexible secret-management and retrieving secrets. When Wanda wishes to put a secret cothority membership through re-sharing the shared key or on-chain, she prepares an access-control policy, encrypts the re-encrypting existing secrets to a new shared key. secret and then sends a write transaction (txw ) to the access- The on-chain private key exchange protocol can be applied control cothority. The access-control cothority verifies and to both on-chain secrets protocols and hide the reader’s identity then logs txw making the secret available for retrieval by by blinding the reader’s public key in the write and read trans- the authorized reader Ron. To request access to a secret, actions. Lastly, the post-quantum on-chain secrets describe the Ron downloads the secret from the blockchain and then modifications needed to achieve post-quantum security. sends a read transaction (txr ) to the access-control cothor- ity. If Ron is authorized to access the requested secret, the A. One-Time Secrets access-control cothority logs txr . Subsequently, Ron contacts One-time secrets is based on PVSS . Wanda, the writer, the secret-management cothority to recover the secret. The first prepares a secret she wants to share along with a policy secret-management trustees verify Ron’s request against the that lists the public key of the intended reader. She then blockchain and then deliver the secret shares of the key needed generates a symmetric encryption key by running PVSS for to decrypt Wanda’s secret as shared in txw . the secret-management cothority members, encrypts the secret with the key she shared and then stores the resulting cipher- IV. O N -C HAIN S ECRETS text either on-chain or off-chain. Finally, she sends a write In this section we introduce two on-chain secrets protocols, transaction txw containing the information necessary for the one-time secrets and long-terms secrets. Figure 2 provides an verification and retrieval of her secret to the access-control overview of on-chain secrets. The assumptions listed in the cothority to have it logged. Ron, the reader, creates and sends
to the access-control cothority a read transaction txr for a 2) If the signature is valid and Ron is authorized to access specific secret. The trustees check txr against the secret’s the secret, log txr in block br . access policy and if Ron is authorized to access the secret, Share retrieval protocol: After the read transaction has they log the transaction creating a proof of access. Ron sends been logged, Ron can recover the secret message m by running this proof together with the encrypted secret shares from txw first the share retrieval protocol with the secret-management to each secret-management (PVSS) trustee and gets the secret cothority to obtain shares of the encryption key used to secure key shares. Once Ron has received a threshold of valid shares, m. To do so, Ron initiates the protocol as follows. he recovers the symmetric key and decrypts the original data. 1) Create and sign a secret-sharing request Write transaction protocol: Wanda, the writer and each reqshare = [txw , txr , πtxr ]sigsk trustee of the access-control cothority perform the following R protocol to log the write transaction txw on the blockchain. where πtxr proves that txr has been logged on-chain. Wanda initiates the protocol as follows. 2) Send reqshare to each secret-management trustee to obtain 1) Compute h = H(policy) to map the access-control policy the decrypted shares. to a group element h to be used as the base point for the Each trustee i of the secret-management cothority responds PVSS polynomial commitments. ∑t−1 to Ron’s request as follows. 2) Choose a secret sharing polynomial s(x) = j=0 aj xj 1) Use pkR in txw to verify the signature of reqshare and of degree t − 1. The secret to be shared is s = g s(0) . πtxr to check that txr has been logged on-chain. −1 3) For each secret-management trustee i, compute the en- 2) Compute the decrypted share si = (sbi )ski , create a s(i) crypted share sbi = pki of the secret s and create the NIZK proof πsi that the share was decrypted correctly corresponding NIZK proof πsbi that each share is correctly (see Appendix A), and derive ci = encpkR (si ) to ensure encrypted (see Appendix A). Create the polynomial com- that only Ron can access it. mitments bj = haj , for 0 ≤ j ≤ t − 1. 3) Create and sign the secret-sharing reply 4) Set k = H(s) as the symmetric key, encrypt the secret repshare = [ci , πsi ]sigski message m to be shared as c = enck (m), and compute Hc = H(c). Set policy = pkR to designate Ron as the and send it back to Ron. intended reader of the secret message m. Secret reconstruction protocol: To recover the secret key 5) Finally, prepare and sign the write transaction k and decrypt the secret m, Ron performs the following steps. 1) Decrypt each si = decpkR (ci ) and verify it against πsi . si ⟩ , ⟨bj ⟩ , ⟨πsbi ⟩ , Hc , ⟨pki ⟩ , policy]sigsk txw = [⟨b W 2) If there are at least t valid shares, use Lagrange interpo- and send it to the access-control cothority. lation to recover s. The access-control cothority then logs the write transaction 3) Recover the encryption key as k = H(s) and use it to de- on the blockchain as follows. crypt the ciphertext c to obtain the message m = deck (c). 1) Derive the PVSS base point h = H(policy). Achieving system goals: The one-time secrets protocol 2) Verify each encrypted share sbi against πsbi using ⟨bj ⟩ and achieves all goals except for dynamic sovereign identities. h (see Appendix A). This step guarantees that Wanda Confidentiality of Secrets. The secret message m is en- correctly shared the encryption key. crypted under a symmetric key k which is securely secret- 3) If all shares are valid, log txw in block bw . shared using PVSS among the secret-management trustees Read transaction protocol: After the write transaction such that t = f + 1 shares are required to reconstruct it. has been recorded, Ron needs to log the read transaction txr The access-control trustees verify and log on the blockchain through the access-control cothority before he can request the the encrypted secret shares which, based on the properties of secret. To do so, Ron performs the following steps. PVSS, do not leak any information about k. After the secret- 1) Retrieve the ciphertext c and bw , which stores txw , from management trustees receive a valid request reqshare , they the access-control cothority. respond with their secret shares encrypted under the public 2) Check that H(c) is equal to Hc in txw to ensure that the key listed in policy from the respective write transaction txw . ciphertext c of Wanda’s secret has not been altered. Further, a dishonest reader cannot obtain access to someone 3) Compute Hw = H(txw ) as the unique identifier for the else’s secret through a new write transaction that uses a policy secret that Ron requests access to and determine the proof that lists him as the reader but copies secret shares from πtxw showing that txw has been logged on-chain. another transaction in hopes of having them decrypted by the 4) Prepare and sign the transaction secret-management cothority. This is because each transaction is bound to a specific policy which is used to derive the txr = [Hw , πtxw ]sigsk R base point for the PVSS NIZK consistency proofs. Without and send it to the access-control cothority. the knowledge of the decrypted secret shares (and the key k), The access-control cothority then logs the read transaction the malicious reader cannot generate correct proofs and all on the blockchain as follows. transactions without valid proofs are rejected. This means that 1) Retrieve txw using Hw and use pkR , as recorded in only the intended reader obtains a threshold of secret shares policy, to verify the signature on txr . necessary to recover k and then access m.
Auditability. Under the assumption that the access-control instead of individual shares. Ron, the reader, recovers the sym- cothority provides Byzantine consensus guarantees, all prop- metric key by obtaining a threshold of securely blinded shares erly created read and write transactions are logged by the of the collective private key and reconstructing the symmetric access-control cothority on the blockchain. Once a transaction key himself or with the help of a trustee he selects. Further- is logged, anyone can verify this fact and obtain a third-party more, the configuration of the secret-management cothority verifiable transaction inclusion proof. can change by re-sharing the shared key or re-encrypting all Atomic Data Delivery. Once a read transaction txr is logged the secrets to a new secret-management cothority. by the access-control cothority, the reader can run the share Protocol setup: Before any transactions can be created retrieval protocol with the secret-management cothority. Under and processed, the secret-management cothority needs to run the assumption that n = 2f + 1, the reader receives at least a DKG protocol to generate a shared private-public key t = f + 1 shares of the symmetric encryption key k from the pair. There exist a number of DKG protocols that are syn- honest trustees. This guarantees that the reader has enough chronous  or asynchronous . Given the rarity of the shares to reconstruct k and access the secret message m using setup phase, we assume a pessimistic synchrony assumption the secret reconstruction protocol. for the DKG (e.g., every message is posted to the access- Dynamic Sovereign Identities. While all participants main- control cothority blockchain) and implement the DKG by tain their own private keys and hence their identities, the Gennaro et al.  because of its simplicity and the fact that identities used in write transactions cannot be updated without it permits a higher threshold of corruptions. re-encrypting the secrets and posting new write transactions. The output of the setup phase is a collective public key Decentralization. The protocols do not assume a trusted pksmc = g sksmc , where sksmc is the unknown collective private third party and they tolerate up to t − 1 failures. key. Each server i holds a share of the secret key denoted as Protocol advantages and shortcomings: The one-time ski and all servers know the public counterpart pki = g ski . secrets protocol uses existing and proven to be secure building The secret key can be reconstructed by combining a threshold blocks and its design is simple to implement and analyze. t = f + 1 of the individual shares. We assume that pksmc is Further, it does not require a setup phase among the secret- registered on the blockchain of the access-control cothority. management members, e.g., to generate a collective private- Write transaction protocol: Wanda and each trustee of the public key pair. It also enables the use of a different secret- access-control cothority perform the following protocol to log management cothority for each secret, without requiring the the write transaction txw on the blockchain. Wanda initiates servers to maintain any protocol state. the protocol through the following steps. However, one-time secrets has a few shortcomings too. First, 1) Retrieve the collective public key pksmc of the secret- it incurs high PVSS setup and share reconstruction costs as management cothority. Wanda needs to evaluate the secret sharing polynomial at n 2) Choose a symmetric key k and encrypt the secret mes- points, create n encrypted shares and NIZK proofs, along sage m to be shared as cm = enck (m) and compute with t polynomial commitments. Similarly, Ron has to verify Hcm = H(cm ). Set policy = pkR to designate Ron as up to n decrypted shares against the NIZK proofs and to the intended reader of the secret message m. reconstruct the secret on his device. Second, the transaction 3) Encrypt k towards pksmc using a threshold variant of the size increases linearly with the secret-management cothority ElGamal encryption scheme . To do so, embed k as size. Because the secret-management trustees do not store a point k ′ ∈ G, pick a value r uniformly at random, any per-secret protocol state making them nearly stateless, compute ck = (pkrsmc k ′ , g r ) and create the NIZK proof the write transaction txw must contain the encrypted shares, πck to guarantee that the ciphertext is correctly formed, NIZK proofs and the polynomial commitments. Lastly, one- CCA-secure and non-malleable (see Appendix B). time secrets does not enable re-encryption of the shares to 4) Finally, prepare and sign the write transaction another set of trustees, preventing the possibility of moving txw = [ck , πck , Hcm , policy]sigsk shares from one set of secret-management trustees to another. W and send it to the access-control cothority. B. Long-Term Secrets The access-control cothority then logs the write transaction. Long-term secrets address the above limitations through a 1) Verify the correctness of the ciphertext ck using the NIZK dedicated secret-management cothority that persists over a proof πck . long period of time and that maintains a collective private- 2) If the check succeeds, log txw in block bw . public key pair used to secure access to the secrets. Read transaction protocol: After txw has been recorded, After a one-time distributed key generation (DKG) phase Ron needs to log a read transaction txr through the access- (see Section II for details) performed by the secret- control cothority before he can request the decryption key management cothority, Wanda, the writer, prepares her secret shares. To do so, Ron performs the following steps. message, encrypts it with a symmetric key and then encrypts 1) Retrieve the ciphertext cm and the block bw , which stores that key with the shared public key of the secret-management txw , from the access-control cothority. cothority. As a result, the overhead of encrypting secrets is 2) Check that H(cm ) is equal to Hcm in txw to ensure that constant as each write transaction contains a single ciphertext the ciphertext cm of Wanda’s secret has not been altered.
3) Compute Hw = H(txw ) as the unique identifier for the Evolution of the secret-management cothority: The secret that Ron requests access to and determine the proof secret-management cothority is expected to persist over a long πtxw showing that txw has been logged on-chain. period of time and to remain secure and available. However, 4) Prepare and sign the read transaction a number of issues can arise over its lifetime. First, servers can join and leave the cothority resulting in churn. Second, txr = [Hw , πtxw ]sigsk even if the secret-management cothority membership remains R static, the private shares of the servers should be regularly and send it to the access-control cothority. (e.g., every month) refreshed to thwart an attacker who can The access-control cothority then logs txr as follows. attempt to collect a threshold of shares over a period of time. 1) Retrieve txw using Hw and use pkR , as recorded in Lastly, the collective private key of the secret-management policy, to verify the signature on txr . cothority should be rotated periodically e.g., once every year 2) If the signature is valid and Ron is authorized to access or two. Any change of the current collective private-public key the secret, log txr in block br . pair would require re-encrypting all of the long-lived secrets, Share retrieval protocol: After the read transaction has however, if done by simply choosing a new key pair. been logged, Ron can recover the secret data by running the We address the first two problems by periodically re- share retrieval protocol with the secret-management cothority. sharing  the existing collective public key when a server To do so Ron initiates the protocol as follows. joins or leaves the secret-management cothority, or when 1) Create and sign a secret-sharing request servers wants to refresh their private key shares. Lastly, when the secret-management cothority wants to rotate the collective reqshare = [txw , txr , πtxr ]sigsk R public/private key pair (pksmc , sksmc ), C ALYPSO needs to where πtxr proves that txr has been logged on-chain. collectively re-encrypt each individual secret under the new 2) Send reqshare to each secret-management trustee to re- collective public key. To achieve this, we can generate and quest the blinded shares. use translation certificates  such that the secrets can be re- Each trustee i of the secret-management cothority responds encrypted without the involvement of their writers and without to Ron’s request as follows. exposing the underlying secrets to any of the servers. 1) Get g r and pkR from txw and prepare a blinded share Achieving system goals: Long-term secrets achieves its ui = (g r pkR )ski with a NIZK correctness proof πui . goals similarly to one-time secrets with these differences. 2) Create and sign the secret-sharing reply Confidentiality of Secrets. In long-term secrets, the secret message m is encrypted under a symmetric key k which is repshare = [ui , πui ]sigski subsequently encrypted under a collective public key of the secret-management cothority such that at least t = f + 1 and send it back to Ron. trustees must cooperate to decrypt it. The ciphertext is bound Secret reconstruction protocol: To retrieve the decryption to a specific policy through the use of NIZK proofs  so it key k and recover the secret m, Ron performs as follows. cannot be reposted in a new write transaction with a malicious 1) Wait to receive at least t valid shares ui = g (r+skR )ski = reader listed in its policy. The access-control trustees log the ′ g r ski and then use Lagrange interpolation to recover the write transaction txw that includes the encrypted key which, blinded decryption key based on the properties of the encryption scheme, does not leak any information about k. After the secret-management ′ ∏ t ′ pkrsmc = (g r ski )λi , trustees receive a valid request reqshare , they respond with the k=0 blinded shares of the collective private key encrypted under the public key in policy from the respective txw . Based on th where λi is ′the i Lagrange element. the properties of the DKG protocol, the collective private key 2) Unblind pkrsmc to get the decryption key pkrsmc for ck via is never known to any single entity and can only be used if t ′ R −1 skR −1 trustees cooperate. This means, only the intended reader gets a (pkrsmc )(pksk smc ) = (pkrsmc )(pksk smc )(pksmc ) R threshold of secret shares necessary to recover k and access m. 3) Retrieve the encoded symmetric key k ′ from ck via C. On-chain Blinded Key Exchange (ck )(pkrsmc )−1 = (pkrsmc k ′ )(pkrsmc )−1 , In both on-chain secrets protocols, Wanda includes the public key of Ron in a secret’s policy to mark him as the decode it to k, and finally recover m = deck (cm ). authorized reader. Once Wanda’s write transaction is logged, Ron may delegate the costly verification and combination everyone knows that she has shared a secret with Ron and of shares to a trustee, i.e., the first step of the above protocol. correspondingly, once his read transaction is logged, everyone The trustee is assumed to be honest-but-curious and to not knows that he has obtained the secret. While this property is DoS Ron. The trustee cannot access the secret,′ as he does not desirable for many deployment scenarios we envision, certain know skR and hence cannot unblind pkrsmc . Ron can detect if application may benefit from concealing the reader’s identity. the trustee carries out the recovery incorrectly. See Section VII for a discussion of C ALYPSO’s deployment.
We introduce an on-chain blinded key exchange protocol, does not prevent a malicious writer from distributing bad secret an extension that can be applied to both on-chain secrets pro- shares because the shares cannot be verified publicly. tocols. This protocol allows the writer to conceal the intended To mitigate this problem, we add a step to provide account- reader’s identity in the write transaction and to generate a ability of the secret sharing phase by (1) requiring the writer blinded public key for the reader to use in his read transaction. to commit to the secret shares she wishes to distribute and (2) The corresponding private key can only be calculated by the requesting that each secret-management trustee verifies and reader and the signature under this private key is sufficient for acknowledges that the secret share they hold is consistent with the writer to prove that the intended reader created the read the writer’s commitment. As a result, assuming n = 3f + 1 transaction. The protocol works as follows. and secret sharing threshold t = f + 1, the reader can hold 1) Public Key Blinding. Wanda generates a random blinding the writer accountable for producing a bad transaction should factor b and uses it to calculate a blinded version of Ron’s he fail to correctly decrypt the secret message. public key pkRe = pkbR = g b skR . Write transaction protocol: Wanda prepares her write 2) Write Transaction. Wanda follows either the one-time transaction txw with the help of the secret-management and secrets or long-term secrets protocol to create txw with access-control cothorities, where each individual trustee car- the following modifications. Wanda encrypts b under ries out the respective steps. Wanda initiates the protocol by pkR to enable Ron to calculate the blinded version of preparing a write transaction as follows. ∑t−1 his public key by picking a random number b′ and 1) Choose a secret sharing polynomial s(x) = j=0 aj xj ′ ′ encrypting b as (cb1 , cb2 ) = (g skR b b, g b ). Then, she of degree t − 1. The secret to be shared is s = s(0). uses pkRe instead of pkR in the policy. Wanda includes 2) Use k = H(s) as the symmetric key to compute the cb = (cb1 , cb2 ) and policy in txw . After txw is logged, she ciphertext c = enck (m) for the secret message m and notifies Ron on a separate, secure channel that she posted set Hc = H(c). txw such that he knows which transaction to retrieve. 3) For each trustee i, generate a commitment qi = H(vi ∥ 3) Read Transaction. When Ron wants to read Wanda’s s(i)), where vi is a random salt value. secret, he first decrypts cb using skR to retrieve b = 4) Specify the access policy and prepare and sign txw . ′ ′ R −1 (cb1 )(csk b2 ) = (g skR b b)(g b skR )−1 . Then, he can com- pute skRe = b skR and use this blinded private key to txw = [⟨qi ⟩ , Hc , ⟨pki ⟩ , policy]sigsk W anonymously sign his txr . 5) Send the share s(i), salt vi , and txw to each secret- 4) Auditing. If Wanda wants to prove that Ron generated management trustee using a post-quantum secure channel. the txr , she can release b. Then, anyone can unblind The secret-management cothority verifies txw as follows. Ron’s public key pkR = pk−b e , verify the signature on the R 1) Verify the secret share by checking that (s(i), vi ) corre- transaction and convince themselves that only Ron could sponds to the commitment qi . If yes, sign txw and send have validly signed the transaction as he is the only one it back to Wanda as a confirmation that the share is valid. who could calculate skRe . The access-control cothority finally logs Wanda’s txw . The on-chain blinded key exchange protocol enables Wanda 1) Wait to receive txw signed by Wanda and the secret- to protect the identity of the intended reader of her secrets management trustees. Verify that at least 2f + 1 trustees without forfeiting any of the on-chain secrets’s guarantees, signed the transaction. If yes, log txw . however, it requires the knowledge of the reader’s public key. Read transaction, share request, and reconstruction As a consequence, this protocol does not support dynamic protocols: The other protocols remain unchanged except that identities discussed in Section V, as we cannot predict and the secret-management trustees are already in possession of blind an unknown, future public key. Nonetheless, this protocol their secret shares and the shares need not be included in txr . provides a viable option for applications where relationship Once Ron receives the shares from the trustees, he recovers the privacy is more important than dynamic identity evolution. symmetric key k as before and decrypts c. If the decryption An extension of this protocol that allows blinding of dynamic fails, then the information shared by Wanda (the key, the identities remains an open challenge to be addressed in future ciphertext, or both) was incorrect. Such an outcome would work. indicate that Wanda is malicious and did not correctly execute the txw protocol. In response, Ron can release the transcript D. Post-Quantum On-chain Secrets of the txr protocol in order to hold Wanda accountable. The security of both on-chain secrets implementations relies on the hardness of the discrete logarithm (DL) problem. An V. S KIPCHAIN I DENTITY AND ACCESS M ANAGEMENT efficient quantum algorithm  for solving the DL problem The C ALYPSO protocols described so far do not provide dy- exists, however. One solution to provide post-quantum security namic sovereign identities. They only support static identities in C ALYPSO is to use post-quantum cryptography (e.g., lattice- (public keys) and access policies as they provide no mecha- based cryptography ). Alternatively, we can implement on- nisms to update these values. These assumptions are rather chain secrets using the Shamir’s secret sharing  scheme unrealistic though, as the participants may need to change which is information theoretically secure. Unlike the publicly- or add new public keys to revoke a compromised private verifiable scheme we previously used, Shamir’s secret sharing key or to extend access rights to a new device, for example.
sigsk and their public keys, policy skipchains include access-control doc id: idPaper id: idPaper rules allowing to enforce fine-grained update conditions for admin: idRon admin: idRon ∨ idAna write transactions. Section VIII describes a simple access- access: idRon access: idLab control list (ACL) we created for our implementation. hash The main insight is that skipchains securely maintain a Resource policy skipchain verifiable timeline of changes to the identities and policies they sigsk lab represent. This means that these identities or polices can evolve id: idLab id: idLab admin: idRon dynamically and independently of the specific applications that admin: idRon members: idRon , idEve members: idRon , idEve , make use of them and that at any point the applications can idAna hash verfiably obtain the most up-to-date version of each. Federated identity skipchain The SIAM skipchains are under the self-sovereign control of individual users or groups of users. To track administrative sigsk1 ∧sk2 id: idRon rights, each SIAM skipchain includes in its skipblocks the id: idRon admin: pk1 ∧ pk2 (public) admin keys of users authorized to make updates and admin: pk1 ∧ pk2 service: pklab , pkdoc service: pklab , pkdoc pkssh the policy under which a skipchain can be updated. These hash update policies can be expressed as arbitrary boolean circuits, Personal identity skipchain e.g., requiring approvals from just a single administrator or a certain set of them. Since the admin keys are used only for Fig. 3. Skipchain-based identity and access management (SIAM): First, Ron skipchain updates, they should be stored in cold wallets, such updates his personal identity skipchain idRon to include pkssh . Afterwards, he uses sklab to extend the federated identity skipchain idlab to add idAna as as hardware security modules, for increased security. a member. Finally, he adds idAna as an admin and idlab as authorized readers To evolve a SIAM skipchain and consequently the iden- to the resource policy skipchain idpaper by using skdoc . tities or access policies it represents, its admins follow the skipchain’s update policies and create a new skipblock that reflects the necessary changes, and then publicly announce Similarly, it should be possible to change access polices so it, e.g., by pushing the update to the storage provider(s) that access to resources can be extended, updated or revoked maintaining a public interface to the SIAM skipchain. Users and to define access-control rules for individual identities and and services that follow SIAM skipchains can get notified groups of users for greater flexibility and efficiency. Finally, automatically about those updates and accept them if they any access-control system that supports the above properties are proposed by authorized users and adhere to the update should be efficient as well as secure to prevent freeze and policies. Since the latest skipblock represents the current state replay attacks , and race conditions between applying of a skipchain, i.e., identities of all currently authorized users changes to access rights and accessing the resources. or all current access rules, revocation is trivially supported In order address these challenges and achieve dynamic as the admins simply push a new skipblock to the respective sovereign identities, we introduce the skipchain-based identity skipchain that omits the public key or access rule that needs and access management (SIAM) subsystem for C ALYPSO that to be revoked. Figure 3 provides an overview on SIAM. provides the following properties: (1) Enable users to specify and announce updates to resource access keys and policies. B. Integration Into C ALYPSO (2) Support identities for both individual users and groups of To integrate SIAM with C ALYPSO, the long-term secrets users. (3) Protect against replay and freeze attacks. (4) Enforce protocols described in Section IV-B are adapted as follows. atomicity of accessing resources and updating resource access Assume that Ron has logged the unique identifier idR of his rights to prevent race conditions. personal identity skipchain on the access-control blockchain. If Wanda wants to give Ron access to a resource, she simply A. Architecture sets policy = idR instead of policy = pkR in txw . In SIAM, we introduce three types of skipchains , struc- This means that instead of defining access rights in terms tures similar to a blockchain but doubly-linked, see Section II of Ron’s static public pkR , she does so in terms of Ron’s for details. Personal identity skipchains store the public keys skipchain and consequently, any public key(s) specified in that individual users control and use to access resources. A the most current most current block of idR . Then, the re- user can maintain a number of public keys that correspond source is encrypted under the shared public key of the secret- to his identity that are used for access to resources on management cothority as before. To request access, Ron different devices, for example. Federated identity skipchains creates the read transaction specify identities and public keys of a collective identity that encompasses users that belong to some group, such as txr = [Hw , πtxw , pkR′ ]sigsk R′ employees of a company, members of a research lab, a board of directors, etc. Resource policy skipchains track access rights where Hw = H(txw ) is the unique identifier for the secret of identities, personal or federated, to certain resources and that Ron requests access to, πtxw is the blockchain inclusion enable dynamic access control. In addition to listing identities proof for txw , and pkR′ is one of Ron’s public keys that
he wishes to use from the latest block of the idR skipchain. ities as decentralized equivalents of trusted third parties that After receiving txr , the access-control cothority follows the mediate interactions between readers and writers. idR skipchain to retrieve the latest skipblock and verifies The access-control cothority logs a write transaction on the pkR′ against it. Then, the access-control cothority checks the blockchain only after it successfully verifies the encrypted signature on txr using pkR′ and, if valid, logs txr . Once data against the corresponding consistency proof. This en- txr is logged, the rest of the protocol works as described sures that a malicious writer cannot post a transaction for a in Section IV-B, where the secret-management cothority uses secret that cannot be recovered. Further, as each txw binds pkR′ for re-encryption to enable Ron to retrieve the resource. its contents to its policy, it protects against attacks where malicious writers naively extract contents of already posted C. Achieving SIAM Goals transactions and submit them with a different policy listing When SIAM is used, Ron is able to evolve the idR skipchain themselves as the authorized readers. Similarly, before logging arbitrarily, e.g., rotate existing access keys or add new devices, a read transaction, the access-control cothority verifies that it and still retain access to the encrypted resource without need- refers to a valid txw and it is sent by an authorized reader ing Wanda to update the initial write transaction. Analogously, as defined in the policy of txw . A logged read transaction Wanda can efficiently provide a group of users access to a serves as an access approval. The secret-management cothority resource by using a federated identity idF that these users are releases the decryption shares to the authorized reader only a part of, instead of adding each user individually, by setting after confirming the reader presents an auditable proof of txr . policy = idF in txw . This approach outsources the resource Malicious trustees: Our threat model permits a fraction access maintenance to the admins of the idF skipchain as they of the access-control and secret-management cothority trustees are in charge of the federated identity’s membership and can to be dishonest. The thresholds (t = f + 1) used in on-chain add and remove members at will. Alternatively, Wanda can secrets, however, prevent the malicious trustees from being set up a resource policy skipchain idP she is in charge of able to pool their secret shares and access writers’ secrets or to and include idF as non-administrative members along with prevent an an authorized reader from accessing their secret by any other rules she wants to have enforced. Then, Wanda withholding the secret shares. Further, even if some individual would use policy = idP in txw authorizing idF to access malicious trustees refuse to accept requests from the clients or the respective resource under the specified rules. to participate in the protocols altogether, the remaining honest In order for users to defend against freeze and replay attacks trustees are be able to carry out all protocols by themselves we require them to generate freshness proofs of their SIAM thereby ensuring service availability. skipchains. To do this they submit in regular time periods (e.g., Malicious storage providers: Wanda may choose to store every hour) the head of their skipchain for timestamping on the actual encrypted data either on-chain or off-chain by the blockchain. This prevents freeze and replay attacks as an choosing to outsource the storage to external providers. Be- adversary that managed to subvert an old SIAM skipblock cause the data is encrypted, it can be shared with any number cannot convince a client to accept the adversarial actions as of possibly untrusted providers. Before Ron creates a txr he authoritative, given that the skipblock the adversary refers to needs to retrieve and verify the encrypted data against the hash is different from the fresh one appearing on the blockchain. posted in txw . If Ron cannot obtain the encrypted data from This practice further ensures the atomicity of read, write, and the provider, he can contact Wanda to expose the provider as (skipchain) update operations, as the moment a SIAM update dishonest and receive the encrypted data directly from Wanda happens the client should send the new SIAM skipblock for or an alternative storage provider. timestamping. This effectively serializes reads, writes, and VII. C ALYPSO IN THE W ILD updates and therefore prevents race conditions. Below we describe three real-world deployments, two com- VI. F URTHER S ECURITY C ONSIDERATION pleted and one in-progress, of C ALYPSO that resulted from collaborations with companies that needed a flexible, secure, Our contributions are mainly pragmatic rather than theoret- and decentralized solution to share data. ical as we employ only existing, well-studied cryptographic algorithms. We already discussed achieving C ALYPSO’s secu- A. Auditable Online Invoice Issuing rity goals in the previous sections. On-chain secrets protocols Together with the main invoice regulator of a European achieve all goals but dynamic sovereign identities which is country, we built an auditable online invoice issuing system. It addressed by SIAM. In this section, we discuss the effect of uses HyperLedger Fabric v1.0 as the access-control blockchain malicious parties on C ALYPSO. together with long-term secrets. While the system uses static Malicious readers and writers: C ALYPSO’s functionality identities, they are blinded as needed using the protocol resembles a fair-exchange protocol  in which a malicious described in Section IV-C. reader may try to access a secret without paying for it and Problem definition: The system consists of a set of a malicious writer may try to get paid without revealing potentially mutually distrustful sellers and buyers as well as the secret. In C ALYPSO, we protect against such attacks by a regulator, who are all part of a dynamic ecosystem. To employing the access-control and secret-management cothor- keep track of all business relationships without the need for
You can also read
NEXT SLIDES ... Cancel