0. Asynchronous Proactive Secret Sharing
Fred B. Schneider*
Department of Computer Science
Cornell University
Ithaca, New York
*Joint work with Robbert van Renesse and Lidong Zhou.

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

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

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

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

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

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

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

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

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

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

11. 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 …

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

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

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

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

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

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