Asynchronous Proactive Secret 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.

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

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

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 … At most 1 server compromised at any instant but secret revealed after server t attacked! Secret erodes over time!!! time

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)!!!!

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

Implementing (n,t) by (m,m) s = s1 + s2 + … + sm (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

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

System Model for APSS Anything weaker unlikely to allow solution. 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.

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

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.

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

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

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.

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.

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.”

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.

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.