1 / 30

PROACTIVE SECRET SHARING Or: How to Cope With Perpetual Leakage

PROACTIVE SECRET SHARING Or: How to Cope With Perpetual Leakage. Herzberg et al. Presented by: Avinash Ravi Kevin Skapinetz. Outline. Motivation Model and Assumptions Cryptographic Tools Share Renewal Protocol Share Recovery Protocol Private Key Renewal Protocol

Télécharger la présentation

PROACTIVE SECRET SHARING Or: How to Cope With Perpetual Leakage

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. PROACTIVE SECRET SHARINGOr:How to Cope With Perpetual Leakage Herzberg et al. Presented by: Avinash Ravi Kevin Skapinetz

  2. Outline • Motivation • Model and Assumptions • Cryptographic Tools • Share Renewal Protocol • Share Recovery Protocol • Private Key Renewal Protocol • Total Protocol for Proactive Secret Sharing • Conclusion

  3. Motivation • Secret Sharing • Protect secrets by distributing secret across different locations • K out of N secret sharing schemes • Security assured as long as fewer than K out of N locations are compromised • With enough time an adversary can compromise K nodes • Bad for long-lived, secret data! (legal documents, medical records, trade secrets)

  4. Motivation • Can we just refresh the secret by decrypting the secret and then re-encrypting it with a different key? • Does not protect integrity of the secret • Exposes the secret to adversaries if attack is made during refresh process • Need to renew the shares without changing the secret • Also need to recover lost and corrupted shares periodically

  5. Motivation • Solution: Proactive Secret Sharing • Periodically renew the shares such that information gained during the previous time period is useless • Now an adversary must compromise all K locations in the same time period • Destruction of secret requires N-K locations to be compromised • Periodically recover lost and corrupted shares

  6. Model and Assumptions • System of N servers share a secret, x through a (k+1,n) scheme • Compromising K shares does nothing, but K+1 shares yields the secret • Goal: Prevent adversary from learning and/or destroying the secret

  7. Model and Assumptions • Each server is connected through a synchronous common medium with zero transmission delay • Time is divided into arbitrary “time periods” • Servers engage in “update” at the beginning of each time period • At the end of the update the servers hold new shares of the secret, x

  8. Model and Assumptions • An adversary can corrupt a server at any moment during the time period • If server is corrupted during an update, then both time periods are considered compromised • A server can be corrupted through data modification, data destruction, altered server behavior, or server fault • Adversary is computationally bounded • It cannot break the underlying cryptographic primitives that make up the verifiable secret sharing mechanism upon which this is based • VSS is similar to Shamir’s secret sharing except that participants can detect when dealers are giving inconsistent data to participants

  9. Model and Assumptions • Adversary can be detected and removed (by reboot) • Reboot takes less time than a “time period” • Secret sharing servers can reliably erase local data (not just cache, but main memory and disk as well) • To prevent adversaries from using persistent information from previous time periods to reform the secret

  10. Cryptographic Tools • Secret Sharing • Dealer chooses a function f of degree k over a finite field where f(0) = secret • Dealer calculates vi = f(i) and secretly sends vi to the server i. • The secret can now be reconstructed with k+1 vi pieces and polynomial interpolation

  11. Cryptographic Tools • Verifiable Secret Sharing • g is an element of a the finite field the equation k was chosen from • Values gfi are broadcast to every server before the secret share is broadcast • When a server receives a secret share it checks: • If the equation holds, the share is a valid share.

  12. Share Renewal Protocol • Initial Assumption: Servers have public and private keys with property that it is impossible for an adversary to learn the private key, even during a break-in. • This prevents adversary from being able to impersonate a server or modify a private key • Maintains authenticated communication between the servers

  13. Share Renewal Protocol • Initialization • Secret is encoded into n pieces using k-threshold Shamir’s secret sharing • Pieces are distributed securely • Update Phase • Servers perform Share Renewal • This is the beginning step for each “time period” • Time period is arbitrary and is determined by administrator

  14. Share Renewal Protocol • The goal is to renew the shares without the Dealer’s involvement. (as the Dealer might not exist anymore). • The shareholders should agree on a new polynomial with the same secret s without revealing the secret, the old polynomial or the new polynomial. At the end of this protocol, each shareholder will obtain a new share on the new t-1 polynomial. The assumption in this protocol is that each shareholder remembers his/her old share.

  15. Share Renewal Protocol • A simple (2,2) example of the Share Renewal Protocol: • Server 1 generates two subshares s11 and s12 from s1 using the same secret sharing scheme as the one used to generate s1 and s2 from s; Server 1 randomly selects two subshares s11 and s12, so that s1 = s11 + s12,. Server 2 selects two subshares s21 and s22, so that s2 = s21 + s22. • Server 1 sends s12 to Server 2 through a certain secure channel. Server 2 sends s21 to Server 1. • Server 1 has both s11 and s21 and can add them up to get a new share s1' = s11 + s21. Server 2has both s12 and s22 and can generate a new share s2' = s12 + s22. Now we show that s1' and s2' constitute a (2,2) sharing. The sum of these two shares is the sum of all the four subshares, which is the sum of s1 and s2, which is s.

  16. Proactive Secret Sharing • These two shares are independent from the old ones because these subshares are generated randomly. • Also, no server knows the secret during the entire process. • Server 1 generates s11 and s12 and receives s21 from Server 2. • Server 1 never knows s22 and thus does not know s2' or s. • Server 2never knows s11, and thus does not know s1' or s.

  17. Share Renewal Protocol • Each server Pi picks k random numbers from the finite field and creates a polynomial of degree k in Zq, where i(0)=0 • For all other servers Pj, Pi secretly sends out uij= (mod q) to Pj • Pi computes the new share by: • Pi updates its share and erases all other data

  18. Share Renewal Protocol • Solves share renewal in the face of a passive adversary • If all of the servers follow the protocol, then the share renewal protocol is correct, robust and secret • Each new round produces a valid set of secret shares • Any k+1 servers can re-create the secret at any time • With k or less shares, no information is learned • What if a server sends out inconsistent data?

  19. Share Renewal Protocol • Add verifiability • Each server Pi picks k random numbers from the finite field and creates a polynomial of degree k Each Pi also computes for each k • Pi computes and securely broadcasts the set of ε’s and δ signed with Pi’s signature

  20. Share Renewal Protocol • Pi computes the new share by: • and checks the validity by computing: • If the messages are correct, Pi broadcasts an accept message • If not Pi broadcasts an accusation against the misbehaving server(s)

  21. Share Renewal Protocol • If the faulty server is recognized • Do not use the polynomial broadcast by the server • Reset the server to “expel” the adversary • Three types of possible faults: • Incorrect message format • Zero or more correct message from a server • Verifiability equations do not match • 3rd type of fault requires extra effort to handle

  22. Share Renewal Protocol • If Pi accuses Pj of cheating, Pj must “defend” itself • If Pj sent a correct , then it exposes this value and all servers can check with the ε values already published during the protocol. • If Pj defends itself, then Pi is marked as the faulty server, else Pj is marked. • The share renewal equation becomes (exclude Bad Server):

  23. Share Recovery Protocol • Severs must make sure other servers have not had their keys compromised. Otherwise an adversary could cause the secret to be lost by destroying n-k keys. • Without recovery, we lose security • For practical schemes: • During reboot, a server will lose its share and need recovery

  24. Share Recovery Protocol • During initialization, each server stores the set of for all the server’s current shares. • During the secret share update, this set of exponents is also updated in a similar fashion. • If during the update phase, the value of the new x received and the one calculated do not match, the server needs to have its share recovered.

  25. Share Recovery Protocol For every failed server r • Every valid Pi picks a random k-degree polynomial such that f(r) = 0 • Every Pi broadcasts f(r) • Each Pi then creates a new share for r, and sends it to r • r receives the shares and interpolates them to find its secret share xr

  26. Share Recovery Protocol • Verifiability can be added using same technique as earlier • Used to detect incorrect reconstructions • Multiple shares can be recovered in parallel by treating each share as its own secret.

  27. Private Key Renewal Protocol • Refresh private keys at the beginning of every time period (in the update phase) • Server chooses new public/private keys and broadcasts the new public key authenticated by its signature using its previous private key • The other servers can verify this signature using public key from previous time period • Now we do not have to assume attacker can not tamper with public/private communication keys

  28. Total Protocol for Proactive Secret Sharing At the beginning of every time period: • Private Key Renewal protocol • Share Recovery Protocol (including lost shares detection) • Share Renewal Protocol

  29. Questions?

  30. References • Zaged.ppt • Herzberg, Jarecki, Krawczyk. Proactive Secret Sharing. 1995. NY. IBM T.J. Watson Research Center.

More Related