Asynchronous Proactive Secret Sharing

1. Asynchronous ProactiveSecret Sharing Fred B. Schneider* fbs@cs.cornell.edu Department of Computer Science Cornell University Ithaca, New York 14853 *Joint work with Robbert van Renesse and Lidong Zhou.

2. Problem:Replication versus Confidentiality State replication provides: • Increased availability • Increased vulnerability to compromised secrets. Secure services invariably keep secrets (viz keys). Servers Client

3. Solution:Threshold Cryptography • (n,t) secret sharing [Shamir, Blakely]: • Secret s is divided into n shares. • Any t or more shares suffice for reconstructing s. • Fewer shares convey no information about s. • Threshold cryptography: • Perform cryptographic operations piecewise using shares of secret key; result is as if secret key was used. Example: Threshold digital signatures

4. Problem:Mobile Virus Attacks [Ostrovsky] • Attack server 1 and learn its secret shares … attacker evicted, server returned to operation. • Attack server 2 and learn its secret shares … attacker evicted, server returned to operation. … At most 1 server compromised at any instant but secret revealed after server t attacked! Secret erodes over time!!! time

5. Solution:Share Refreshing For an (n,t) sharing of a secret s: • Start with set of old shares. • Compute set of new shares. such that t or fewer old shares cannot be combined with t or fewer new shares to recover s. Proactive Secret Sharing (PSS)!!!!

6. Proactive Secret Sharing:Share Refreshing for (m,m) sharing old share: si reconstruct split: =si1+si2+si3 … s3’ new sharing s2’ split reconstruct: s1i+s2i+s3i … s1’ s1 s2 s3 =new share: si’ old sharing

7. s = s1 + s2 + … + sm Implementing (n,t) by (m,m) (m,m) sharing suffices [Ito] for getting (n,t) sharing • Each (n,t) share of s is a set of (m,m) shares of s • Only with enough (=m) of the (m,m) shares, is s derived. P1: {s2, s3, s4} P2: {s1, s3, s4} P3: {s1, s2, s4} P4: {s1, s2, s3} an (n,t) share (4,1) sharing of s: an (m,m) share

8. Problem:Denial of Service Attacks • Assumptions = Vulnerabilities. • Denial of service attacks violate assumptions about: • Execution timing • Message delivery delay Weak system models are preferable!

9. System Model for APSS • Asynchronous System. No bounds on: • message delivery delays • process execution speeds • Byzantine Servers. At most t servers are compromised within a window of vulnerability, 3t < n. Total of n servers. • Fair Links. A message sent often enough will be delivered. Anything weaker unlikely to allow solution.

10. From Strong to Weak Assumptions Servers Links Additional Omission Secure 1 Fault-free Coordinator Omission Fair 1 Fault-free Coordinator Omission Fair t+1 Omission Coordinators Malicious Fair • Weak assumptions = Strong adversary

11. Steps toward APSS Protocol • Each (m,m) share stored at multiple sites. • Soln: Fault-free coordinator chooses one subsharing for each (m,m) share. • Message loss due to fair links. • Soln: Repeated sends, awaiting semantic ack. • Coordinator faulty. • Soln: With t+1 coordinators, one is correct. • Compromised processors send bogus msgs. • Soln: Messages are made self-checking, so receivers can reject those messages that are not valid.

12. s13+t13+r13 s23+t23+r23 Steps toward APSS:Multiple Subsharings P1: {s2, s3, s4} P2: {s1, s3, s4} Coordinator chooses: split of share s1: … split of share s2: … split of share s3: P1 …

13. Steps toward APSS:Handling Fair Links Send M repeatedly to P untilreceive Msgs from Q. Note: - P, Q might be sets of processors - Msgs might be sets of messages sender receiver

14. Steps toward APSS:Coordinator Faulty Having t+1 coordinators ensures one is correct. Implications: • t+1 new sharings might be produced. • Associate a label with each share and sharing. • Different sharings not necessarily independent. • Multiple sharings built from same subshares if different coordinators select same process for split of given share. • But all related subshares produce shares stored together, so combining all shares at a given server is not productive.

15. Steps toward APSS:Arbitrary Processor Compromise • Messages convey predicates (not values!). Examples: • “If sender r is correct then all shares stored at r.” • “Share is stored by t+1 or more correct processors.” • Valid message: Predicate is true when msg sent. • Compromised processors may send messages that convey false predicates. • Sender adds content to msgs, so receiver can test whether msg is valid. • Always possible? • Possible for messages employed in APSS.

16. Steps toward APSS:Making Messages Self-Verifying • Some messages are always valid: • “If r is correct then A(r) holds” -- r is sender • For predicates involving shares and subshares: • Employ redundancy with one-way, trap-door functions • Digital signatures • Validity checks on shares and subshares • < s > = vcConst( < s1 >, < s2 >, … < sm > ) • < s > = oneWay( s ) • For predicates involving consistency of values across servers: • Attach 2t+1 messages; at least t+1 are correct. • Make inference from predicates for t+1 valid messages. • E.g., “Share stored at some correct server.”

17. Optimization: Absent Attacks • In normal environment: • Coordinators correct: no need to replicate. • No denial of service: system is synchronous. • In any protocol for asynchronous systems: Delay of actions permitted. Allows optimized protocol: • Delay all but one coordinator Cp for T secs. • Run other coordinators only after T secs pass and new sharing still unavailable.

18. APSS Status, Plans, Lessons • Implemented, running, performance data. • Used in Cornell On-line Certification Authority (COCA). • Design for JBI encryption-based access control. • Stand-alone APSS package now being built: • (m,m) secret sharing. • (n,t) secret sharing without (m,m) reduction. Composing fault-tolerance and security? • Need protocols for weak computational models. • Need secret sharing for replicated secrets.