1 / 31

Two -Efficient and Provably Secure Schemes for Server-Assisted Threshold Signatures

Explore two efficient and provably secure schemes for server-assisted threshold signatures: TPAKE-HTSig and LW-TSig. Learn how to protect private signing keys conveniently and cheaply in modern cryptography.

lhuffman
Download Presentation

Two -Efficient and Provably Secure Schemes for Server-Assisted Threshold Signatures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Two-Efficient and Provably Secure Schemes for Server-Assisted Threshold Signatures Ravi Sandhu Joint work with Shouhuai Xu

  2. Roadmap • Motivation • Cryptographic preliminaries • First scheme: TPAKE-HTSig • Second scheme: LW-TSig • Related work

  3. Motivation • Modern cryptography is “key-centric” • Rivest-Shamir-Adleman have no “short cut” in breaking RSA • But you can generate Rivest’s digital signatures once you compromised his private key • This has no counterpart in handwriting signatures • Since compromise will inevitably happen, one can only expect “second to the best” • Minimize the damage

  4. Motivation • So how to protect the private signing keys (or functions) • conveniently • cheaply • efficiently

  5. Our Approach • Assume a set of (>2) servers provide service (e.g., for economic incentives) like threshold signing • Differ from standard threshold signing • only a user can invoke her signing function • compromise of a user’s machine does not necessarily mean her signing function is compromised (i.e., the adversary may still unable to invoke the servers) • compromise of a threshold number of servers does not necessarily mean her signing function is compromised

  6. Our Approach • The core underlying our approach is some convenient, cheap, efficient mechanisms whereby the servers collaboratively authenticate a user • threshold password authenticated key exchange (e.g., [MacKenzie et al. Crypto’02]) • symmetric key-based authentication (e.g., MAC) • Don’t confuse “server-added signature” (which is motivated to provide better efficiency) with our “server-assisted signature” (which is motivated to provide better security) • though they do overlap sometimes

  7. Roadmap • Motivation • Cryptographic preliminaries • First scheme: TPAKE-HTSig • Second scheme: LW-Tsig • Related work

  8. Cryptographic Preliminaries • Message authentication code (MAC) • secure against adaptive chosen message attack • Signature scheme (Sig.Init, Sig.Sig, Sig.Ver) • secure against adaptive chosen message attack • we are interested in a class of signature schemes that have efficient distributed version

  9. Cryptographic Preliminaries • Threshold Signature scheme (TSig.Init, TSig.Sig, TSig.Ver) • secure against adaptive chosen message attack • 2-party Signature scheme (2Sig.Init, 2Sig.Sig, 2Sig.Ver) • secure against adaptive chosen message attack • Hybrid-Threshold Signature scheme, which is a composition of TSig and 2Sig, consists of (HTSig.Init, HTSig.Sig, HTSig.Ver) • a user splits her private key X into two shares X1, X2 • the user holds X1 as in 2Sig • the user shares X2 among the servers as in TSig

  10. Cryptographic Preliminaries • Threshold Password-Authenticated Key Exchange scheme (TPAKE.Init, TPAKE.Login) • a user shares her password among servers via TPAKE.Init • a user authenticates herself to the servers via TPAKE.Login, which may also output a fresh session key with each server • TPAKE.Login is secure against off-line dictionary attack • compromise of no more than a threshold number of servers does not make the password subject to off-line dictionary attack • the first TPAKE is due to [MacKenzie et al. Crypto’02]

  11. Roadmap • Motivation • Cryptographic preliminaries • First scheme: TPAKE-HTSig • Second scheme: LW-Tsig • Related work

  12. First Scheme: TPAKE-HTSig • TPAKE-HTSig is a composition of TPAKE and HTSig • Idea is simple • Run a TPAKE to authenticate a user and generate a fresh session key that is common to the user and each individual server • The servers authenticate signing requests using the session keys; the signing operation is similar to TSig.Sig • The user obtains a signature as in 2Sig.Sig

  13. TPAKE.Login outputs key1 MACkey1(m) partial signature 1 server 1 TPAKE.Login outputs key2 MACkey2(m) partial signature 2 server 2 … TPAKE.Login outputs keyn MACkeyn(m) partial signature n server n TPAKE-HTSig

  14. TPAKE-HTSig: another look HTSig glue: session key based authentication TPAKE

  15. TPAKE-HTSig • Some comments • We give a specification of TPAKE, so any scheme (e.g., more efficient than [MSJ02]) satisfying it can plug-and-play • DLOG based HTSig can pug-and-play in TPAKE-HTSig • RSA-based HTSig is more subtle • [Shoup Eurocrypt’00] scheme cannot be used unless one assume that no threshold number of servers are compromised • [Rabin Crypto’98] scheme can be used, but need additional care

  16. Roadmap • Motivation • Cryptographic preliminaries • First scheme: TPAKE-HTSig • Second scheme: LW-TSig • Related work

  17. Second Scheme: LW-TSig • LW-TSig stands for Light-Weight server-assisted Threshold Signatures • Idea is simple • a user holds (say) a smartcard • she shares her private key among the servers, as in TSig • she shares a symmetric key with each server • invocation of signing function is based on MACs

  18. MACkey1(m) partial signature 1 server 1 MACkey2(m) partial signature 2 server 2 … MACkeyn(m) partial signature n server n LW-TSig

  19. LW-TSig • Some comments • a smartcard does not need a cryptographic co-processor • communication between a smartcard and the servers can be done via a signature receiver

  20. Roadmap • Motivation • Cryptographic preliminaries • First scheme: TPAKE-HTSig • Second scheme: LW-Tsig • Related work

  21. Related Work • Instead of comparing our work with the related works one-by-one, we present a taxonomy of systems protecting private signing functions • The taxonomy is based on • user storage media: human-memory (for password), soft-token, hard-token, soft- & hard-token • number of runtime key-shares: 1, 2, >2

  22. Taxonomy number of runtime key-shares >2 • a user downloads (say, to a public computer) her private key stored at some remote server(s) • password-based authenticated key exchange (for session key) 2 1 downloading user storage media human-memory soft- & hard-token soft-token hard-token

  23. Taxonomy number of runtime key-shares >2 special case of TPAKE-HTSig a user utilizes a password to activate multiple remote servers to generate a threshold signature downsized (password, >2) 2 1 downloading user storage media human-memory soft- & hard-token soft-token hard-token

  24. Taxonomy number of runtime key-shares • Two types of systems: • password-protected private key (a variant can block off-line dictionary attack if public keys are kept secret) • forward-security: compromising today’s private key does not mean compromising yesterday's private key >2 special case of TPAKE-HTSig downsized (password, >2) 2 1 downloading (soft-token,1) user storage media human-memory soft- & hard-token soft-token hard-token

  25. Taxonomy number of runtime key-shares >2 special case of TPAKE-HTSig TPAKE-HTSig • password-based authentication • composition of two-party and threshold signatures downsized (password, >2) downsized TPAKE-HTSig 2 1 downloading (soft-token,1) user storage media human-memory soft- & hard-token soft-token hard-token

  26. Taxonomy a user invokes a set of remote servers via symmetric authentication number of runtime key-shares >2 special case of TPAKE-HTSig TPAKE-HTSig LW-TSig downsized (password, >2) downsized TPAKE-HTSig downsized LW-TSig 2 1 downloading traditional (soft-token,1) user storage media human-memory soft- & hard-token soft-token hard-token

  27. Taxonomy number of runtime key-shares >2 special case of TPAKE-HTSig • compromise of today’s private key does not mean compromise of yesterday’s or tomorrow’s private key • even if soft-token and hard-token are compromised simultaneously, forward-security is still ensured TPAKE-HTSig LW-TSig downsized (password, >2) downsized TPAKE-HTSig downsized LW-TSig 2 key-insulation/ intrusion-resilience 1 traditional downloading (soft-token,1) user storage media human-memory soft- & hard-token soft-token hard-token

  28. Taxonomy number of runtime key-shares >2 special case of TPAKE-HTSig extension to TPAKE-HTSig and LW-TSig TPAKE-HTSig LW-TSig downsized (password, >2) downsized TPAKE-HTSig downsized LW-TSig 2 two-party signatures key-insulation/ intrusion-resilience 1 traditional downloading (soft-token,1) user storage media human-memory soft- & hard-token soft-token hard-token

  29. Questions?

  30. Q & A • Our constructions are obtained via modular composition, but our security analysis method is more specific • Canetti’s is more general • Why [Shoup Eurocrypt’00] cannot be used? • An adversary compromising a threshold number of servers can obtain X2. Since [S00] requests that the public exponent corresponding to X2 be public, the adversary can factor the user’s RSA modulus.

  31. Q & A • What care we need for [Rabin Crypto’98]? • If [MSJ02] TPAKE is used, we need another layer of invocation that a threshold number of servers activates all the servers. This is specific to [MSJ02], though. • Denial-of-service attack is appropriately dealt with; otherwise, the secret share of a server under denial-of-service attack is interpolated and could make the threshold protection meaningless.

More Related