1. Forward-Secure Signatures (basic + generic schemes)

2. digital signatures Alice has a secret key
Everyone else has the corresponding public key
Alice can sign message with her secret key:
Given a signature and a message, everyone can verify correctness using Alice’s public key:
Desirable property: non-repudiation. If Alice signed a contract, she can’t deny it later.

3. digital signature schemes
This is known as “existential unforgeability under adaptive chosen-message attack”
Three algorithms Key-Gen, Sign, Verify:
Key-Gen inputs: security parameter (“key size”) k output: keys (PK, SK)
Sign inputs: message M, secret key SK output: signature S
Verify inputs: M, signature S, public key PK output: valid/invalid
Strong security notion [GMR84]: even given signatures on messages of its choice, adversary cannot forge signatures on new messages
Multiple implementations exist

4. problem with signatures
Can’t tell when a signature was really generated
Not even if you include current time into the document!

5. problem with signatures
Can’t tell when a signature was really generated
Not even if you include current time into the document!
Therefore,
signing key disclosed Þ all signatures worthless
(even if produced before disclosure)
Inconvenience: your notarized document is no longer valid
Repudiation: Alice gets out of past contracts by anonymously leaking her SK
Key revocation doesn’t help: it merely informs of the leak

6. fixing the problem
Attempt 1: re-sign all the past messages with a new key
Expensive
What if the signer doesn’t cooperate?
Attempt 2: change keys frequently, erasing past SK
Disclosure of current SK doesn’t affect past SK
However, changing PK is expensive, requires certification
Attempt 3: Employ time stamping authority (third party)

7. forward security Idea: change SK but not PK [And97]
Divide the lifetime of PK into T time periods
Each SKj is for a particular time period, erased thereafter
If current SKj is compromised, signatures with previous SKj-t remain secure
Similar to “forward secrecy” for key agreement [Gün89]
Note: can’t be done without assuming secure erasure

8. definitions: key-evolving scheme [BM99]
The usual three algorithms Key-Gen, Sign, Verify:
Key-Gen inputs: security parameter (“key size”) k total number T of time periods output: (PK, SK1)
Sign inputs: message M, current secret key SKj output: signature S (time period j included)
Verify inputs: M, time period j, signature S, public key PK output: valid/invalid

9. definitions: key-evolving scheme [BM99]
The usual three algorithms Key-Gen, Sign, Verify:
Key-Gen inputs: security parameter (“key size”) k total number T of time periods output: (PK, SK1)
Sign inputs: message M, current secret key SKj output: signature S (time period j included)
Verify inputs: M, time period j, signature S, public key PK output: valid/invalid
A new algorithm Update:
Update input: current secret key SKj output: new secret key SKj+1

10. definitions: forward-security [BM99]
Given:
Signatures on messages and time periods of its choice
The ability to “break-in” in any time period b and get SKb
adversary can’t forge a new signature for a time period j<b

11. Simple schemes: efficiency
Our cost is only in the components that are specific to forward security: in the update
Long Public and Long Private Keys
T pairs (p1, s1), (p2,s2),……. (pt, st)
PK= (p1,p2,….,pt)
SK= (s1,s2,…..,st)
Update= erase si for period I
Drawback: public and private key linear in t= number of periods

12. Anderson: long secret key only
T pairs as above and an additonal pair (p,s)
Sig(j)=SIG( j || pj) with key s, j =1,…,t [A “certificate”]
Public key now = p (only)
Secret key = (sj, SIG(j)) j=1,..,t [Still linear]
The public key p is like a CA key and a signature will include the period, the certificate, the message, signature on the message with period’s secret key

13. Long signatures only Have (p,s) In period j get (pj,sj) and
Let Cert(j)= sig_s[j-1] (j || pj)
A signature is the entire certificate chain + signature, it is of the form: (j, sig_sj(m), p1, Cert(1),…pj, Cert(j))
Think about it as a tree of degree one and length t for t periods
(signer memory still linear in t)

14. Replace keys pseudorandomness
Have future keys derived from a forward secure pseudorandom generator [Kra]
Pseudorandom generators which are forward secure are easy: replace the seed with an iteration of the function.

15. Binary Certification tree [BM]
Now (s0,p0)
Each element certifies two children left and right
We have a virtual tree of length log t (for t periods)
At each point only a log branch of certificate is used in the signature
Only leaves are used to sign
Keys that all there children are not going to be used in future periods are erased.
We get O(log t) key sizes, signature size

16. Concrete scheme Use a scheme based on Fiat-Shamir variant
Have the public key be a point x raised to 2^t
Have the initial private key at period zero be x
Sign based on FS paradigm
Update by squaring the current key
The verifier is aware of the period so it knows that currently the private key is raised to the power 2^{t-I} (and the identification proofs are adjusted accordingly).

17. Later schemes Any t unknown a-priori
More efficient non-generic schemes.
Forward-secure enc. Was open for a while