Lecturer: Lidong Zhou
Lecture Date: 2/22/00

Today's Topics

• Secret Sharing
• Online Secret Sharing
• Proactive Secret Sharing

Secret Sharing

Given a secret s, we would like n parties to share the secret so that the following properties hold:

1. If we have all n parties, we can recover s.
2. If we have less than n parties, we cannot recover s.

Lets say we have an 8 digit secret. We can split the digits into two sets and give one set to each party as a share. For example, we can give the first 4 digits to party 1 and the next 4 to party 2. This scheme satisfies the two properties listed, however there is a problem. The first share contains the 4 most significant digits, revealing information about the secret.

Partial Information Disclosure

The problem illustrated above is partial information disclosure. A single share may not contain all the information about a secret, but could disclose enough information to compromise the secret.  We can strengthen property 2 to stipulate that no information about the secret will be disclosed from less than n shares.

Suppose two parties are going to share a secret bit string. The two shares are generated as follows:

1. To generate the first bit of the two shares, we flip a coin. If the result of the coin flipping is a head, then the first bit of the first share is 0; if the result of the coin flipping is a tail, then the first bit of the first share is a 1.
2. Now generate the first bit of the second share. If the result of the previous coin flipping was a head, then we copy the first bit of the secret. Else, if result of the previous coin flipping was a tail, then we flip the first bit of the secret and use that.
3. We repeat this random process for each bit of the secret.

Now we have a a secret splitting scheme. But a simple secret splitting scheme with n parties and n shares may not suffice in certain cases.

(n, t) Secret Sharing

We may have n parties, but need a scheme that requires only t (t< n) shares to recover the secret. Given a secret s, to be shared among n parties, that sharing should satisfy the following properties:

1. Availability: greater than or equal to t parties can recover s.
2. Confidentiality: less than t parties have no information about s.

Let's say we want to share a secret s among n parties. We use some basic geometry. Select the point (0, s) on the Y axis, with s corresponding to the secret. Draw a line that goes through this point. Pick n points on that line: (x1, y1), (x2, y2), ..., (xn, yn). Each point represents a share. These n shares constitute an (n,2) sharing of s. Since any 2 points on a line define the line, we can recover the secret with t = 2 shares of the secret.

We can generalize the scheme even further with a construction of an (n, t) secret sharing scheme. Now we use the curve that corresponds to a (t-1) degree polynomial:

y = a_t-1 * x^t-1 + a_t-2 * x^t-2 + ... + a1 * x + a0

We randomly select a curve corresponding to a polynomial that goes through the secret on the y-axis. And then we select n points on the curve. Any t of the points define the curve and we can recover the secret.  (Shamir 1979. The original scheme was defined on a finite field.)

Online Secret Sharing

Suppose now we want to maintain a secret online. We can store the secret on one server. However, the secret may be disclosed if the server is compromised. If the server is corrupted, then the secret may be corrupted or lost.

To address these problems, we can use replication. We split the secret into three shares using (3,2) secret sharing and give one share to each server. Now, assuming that it is unlikely that two servers would be compromised, the secret will remain available and confidential. Even if one server is compromised, the secret remains secure

However, there is another problem: how does a compromised server recover? Traditionally, server recovery is performed by re-starting the server with a clean copy of the code and the up-to-date state. This type of recovery is no longer sufficient if a secret share is stored on this server.

Let's look at what could happen over time. We have these three servers with three shares, a (3, 2) sharing of a secret s. Server 3 was attacked and share s3 is disclosed. We recovered the server immediately. Later, the same attacker successfully broke into server 2 and grabbed share s2. Now, this attacker has two shares and   can recover the secret.

The problem lies in the fact that the recovery of server 3 was not complete. One thing we should have done is to make any possibly exposed shares obsolete.  Share s3 cannot disclose the secret, but it can be used  with share s1 or s2 to recover s. If shares s1 and s2 are deleted or forgotten by the other two servers, then s3 becomes obsolete.

We cannot ask servers 1 and 2 to delete their shares,  we still want the servers to maintain the secret. What we can do,  is to have another (3, 2) sharing of the same secret s to replace the old shares. If we have a trusted entity, then this resharing can be performed as follows. The servers first submit their shares to this trusted entity through secure links. The trusted entity can then recover the secret from these shares and generate a new set of shares for s using a (3, 2) sharing scheme.

Unfortunately, we don't have a trusted entity. In fact, such a trusted entity could become a vulnerability in the system; if the trusted entity is compromised when it performs re-sharing, then the secret could be disclosed. Therefore, we have to rely on the servers themselves to do re-sharing in a distributed manner. Again, no server can ever reconstruct the secret because otherwise the secret could be exposed if the server was compromised.

Proactive Secret Sharing

We need a scheme that allows servers to generate a new set of shares for the same secret from the old shares without reconstructing the secret. Such a scheme is called a proactive secret scheme (PSS). To strengthen the security of a replicated service, we can invoke our PSS periodically (at regular intervals). With PSS no server knows the secret at any time.