170 likes | 271 Views
Forward-Secure Signatures (basic + generic schemes). 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:
E N D
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.
digital signature schemes • 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
problem with signatures • Can’t tell when a signature was really generated • Not even if you include current time into the document!
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
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)
forward security • Idea: change SK but not PK [And97] • Divide the lifetime of PK into Ttime 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
definitions: key-evolving scheme [BM99] • The usual three algorithms Key-Gen, Sign, Verify: Key-Gen inputs: security parameter (“key size”) ktotal 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
definitions: key-evolving scheme [BM99] • The usual three algorithms Key-Gen, Sign, Verify: Key-Gen inputs: security parameter (“key size”) ktotal 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
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
Simple schemes: efficiency • 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
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
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)
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.
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
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).
Later schemes • Any t unknown a-priori • More efficient non-generic schemes. • Forward-secure enc. Was open for a while