Efficient Quantum-Immune Keyless Signatures with Identity

Transcription

1 Efficient Quantum-Immune Keyless Signatures with Identity Risto Laanoja Tallinn University of Technology / Guardtime AS May 17, 2014 Estonian CS Theory days at Narva-Jõesuu

2 TL; DR Built a practical signature scheme without modular arithmetics Lamport one-time-password scheme (preimage traversal of hash-chain) Server-assisted: augment cryptographic time-stamping service Avoid key reuse by limiting its validity period

3 Background We want to introduce identities to linking-based cryptographic time-stamping. It is possible to insert edge server identities to signed data/hash tree, e.g. in case of static Merkle tree the shape points to an entry point to this tree. The server may authenticate clients and add their identities as metadata. Works, but we lack non-repudiaton: the server must be blindly trusted to authenticate all clients with non-specified means, and not impersonate clients. We must use some secrets, known only to clients, so that later it is possible to prove that only someone in possession of a particular secret is able to create a particular signature.

4 Background Traditional Signature Solutions PKI is a mature field there are few successful deployments like SSL/TLS for secure web DKIM ( signing for spam prevention) Estonian National PKI RSA signature algorithm is ubiquitous, reasonably efficient. If key / signature size is an issue then elliptic-curve based cryptography is a good alternative. For long-term digital signatures with non-repudiation we need following trusted services: Certification Authorities, OCSP responders, Cryptographic time-stamping,... Each of these services use trusted time and (RSA) secret keys, security of those is critical.

5 Background Non-repudiation If end-users have some secrets (even on trusted devices) it is possible (to suspect), that these secrets leak. There must be a way to revoke these secrets. After the event of revocation, all signatures must be invalid. Hard to implement offline there must be a trusted way to 1) identify signing time, and 2) if key was valid at this point of time. Traditionally a long-term digital signature has following format: Signature itself Signing certificate All intermediate certificates up to the root CA, which is expected to be pre-distributed Cryptographic time-stamp with signing time, everything necessary to validate it (certificates!) OCSP response or CRL If the signature is archived for long term then repeated re-encapsulation using archival time-stamp is necessary.

6 Background Advances in Quantum Computing Shor, 1997: algorithm for factorizing (breaks RSA), solving discrete logarithm problem. Grover, 1996: quantum algorithm for searching unindexed data in O(N 1/2 ) Brassard, Høyer, Tapp, 1998: collision for n-bit hash functions in 2 n/3 (non-quantum: 2 n/2 steps) We must use 1.5 times larger hash functions. Bernstein, 2009: conjectures that there is no quantum speedup for collision search. Good post-quantum-computer candidates (based on available information): NTRU, hash based signature schemes.

7 Background Hash-based Digital Signature Schemes Lamport (1979): quite inefficient keys have two hash values for each signed bit, one use only. Merkle signature scheme (1980): Binary hash tree of all one-use public keys, root is the new public key.

8 Background Linking-based Cryptographic Time-stamping Goal: protect the integrity of data, provide time when data was first seen. Hash-and publish mechanism: data items are hashed into some data structure, then hash value covering all items is published in widely witnessed medium like printed newspaper. Merkle tree is a good candidate for such a data structure. Leaves (document hashes) are paired and hashed recursively, then root r is published. For each leaf it is possible to extract compact hash chain which is sufficient for proving that this leaf participated in computing the root. This technique is proven to be secure against back-dating, assuming collision-freeness and other security properties of hash functions.

9 Background Data Signatures If some metadata is attached to a document before signing (time-stamping) then it is not possible to change it later, without breaking the signature. If the client is authenticated by signing (time-stamping) server, and client ID added as metadata we get useful signature scheme (minus non-repudiation) Depicted at right: a way to add identities into hierarchical hash-tree aggregation

10 Background Server-Based Signatures Motivation: Offload computational cost to server Servers are usually better protected than PC-s Limit damage on key leak IBE (?) History: Lamport signature (1979): key publishing server is an integral part Even, Goldreich and Micali (1998): on-line/off-line signatures: offline pre-computation, lightweight signing Asokan, Tsudik and Waidner (1996): Server-supported signatures (SSS): server does all public-key crypto, authenticates (lightweight) clients using one-time passwords Perrin, Bruns, Moreh and Olkin (2002): Delegate servers (DS): lots of motivation to trust servers to do public key cryptography

11 Background Server-Based Signatures and Trust Biggest problem with server-based digital signatures is too much trust on servers. But: User PC is usually the weakest link, malware etc, User error is even greater risk! Complicated key management (PGP keys anyone? But DKIM at Gmail?) Blind trust is inevitable. Fragile link between what you see and what you sign.

12 Hash-chain One-time hash passwords (Lamport 1981): Client generates iteratively a list of hash values (in reverse order of index). z l {0, 1} n z i h(z i+1 ) for i {l 1, l 2,..., 0} z 0 = h(z 1 ) = h(h(z 2 )) =... is the public key Keys are revealed in opposite order, starting from z 1 Verification of z i : starting from z i verify, if z 0 is indeed i-th hash Keys can be used only once!

13 Hash-chain Preimage Traversal Lamport s one-time-password scheme has either O(l) storage (whole chain retained) or O(l) preimage generation time (only z l retained). Both extremes are not exactly efficient. Naive optimization: mark few elements with pebbles, retain values and use as starting points. If N pebbles are evenly distributed then the worst case is O(l/N) hash calculations per key.

14 Hash-chain Jakobsson Jakobsson (2002): traversal algorithm which amortizes h() calculations. O(log l) memory and O(log l) hashing steps to output a key (preimage). Pebbles are placed at positions 2 j, j = 1.. log l ; preimages are extracted from left. If a pebble is reached it jumps next to another, and leftover calculations at each step are used to move it gradually into position between neighbors.

15 Hash-chain Fractal Coppersmith and Jakobsson (2002): Fractal hash chain traversal : if hash chain length l = 2 k then storage: k + log(k + 1) and computation: k/2 hashings per preimage. Yum et al (2009): figured that a variant of previous is optimal, up to k stored hashes and up to k/2 hashings. Schoenmakers (May 2014): Explicit optimal algorithm for binary pebbling, general framework and algorithms (optimal traversal is depicted at right, time goes )

16 Our solution One-time keys work great if there are only two parties: spent keys are rejected, e.g. by using a counter If last pre-image is cached then the verification cost is only one hashing. Missing components so far: a way to eliminate key replay attack, a way to bind one-time-key to data, efficient verification, up to 2 l hashings is too much.

17 Our solution Time-bound Keys Key reuse problem can be solved by introducing time. Signing with key z i must happen before time t 0 + i, and key owner is responsible for not disclosing the key earlier. Data, key and signing time can be bound by cryptographic time-stamping service. It is not necessary to leak the key to the service. Idea was first introduced in TESLA protocol (2002), in authentication context.

18 Our solution Signature Signing a document M at time t = t 0 + i: 1. Hash data: m = h(m) 2. Compute x = h(m, z i ) 3. Send x to online signing (time-stamping) server, authenticate if necessary 4. Server returns signature token S t for pair (x, ID). Now, the signature for M is ID, i, z i, c i, S t, where c i is compact proof for validating z i (details in a moment), and z i is the i-th element of the key hash chain. Verifying signature with certificate ID, z 0, r, t 0, ID s : 1. match ID-s c 2. Check if z i i r 3. Verify S t, extract (t, x) 4. Check if t = t 0 + i 5. Check if data hash matches.

19 Our solution Compact Signature I Signature size and verification time complexities O(l) are not acceptable. Therefore we introduce a hash-tree data structure: root r is published as part of certificate, and the compact proof of participation c i is necessary data to re-compute the hash-chain from z i to r. Let s look at z 1 : here c 1 = (z 2, r 34 ) this means that we have to disclose z 2 too early. Same happens if tree is not balanced at right.

20 Our solution Secure Tree Extra hashing step helps to avoid disclosing values, so instead of z 2 r 2 is published in c (even not necessary because z 1 = r 2 )

21 Our solution Compact Signature II Key storage in O(l) is also not acceptable. Let s use Jakobsson s pebbles (O(log l) storage and next key) Storage for one pebble, including hash-chain from pebble to r, is also O(log l), therefore total storage is O(log 2 l) If we include weight of a hash tree then cost of moving one pebble by one step is again O(log l), thus computation cost for providing next key is O(log 2 l). (graph theory in paper)

22 Our solution Device In order to mitigate PC-related risks we introduce hardware-based Personal Security Device (e.g. USB token, smartcard), which encloses all secret material. Trivial solution: device has somewhat trusted clock and releases z i only when appropriate; we have to deal with clock drift and potential malware on host computer. Getting rid of the clock (and battery!) is possible if device and server have a shared secret, e.g. MAC key K. 1. host computes m = h(m), sends to device, 2. device computes x = h(m, z i ), x sent to signing service (as before) 3. Server returns with S t and µ = MAC K (t) 4. Device checks µ and reveals z i, c i iff t 0 + i < t Secure if service can be trusted with t and both client and server do not attack in a coordinated way.

23 Our solution Efficiency Example instantiation: SHA2-256, one key (signature) for each second; keys are pre-generated for one year. Key-generation takes considerable time and should be done outside of the signing device Secure storage: 20K bytes Signing time: 625 hashing operations, faster than RSA 1024! Signature size and verification complexity: 25 hashes (+ KSI signature)

24 Our solution Future Ideas Optimize for infrequent / batch use...

25 Thank You! This is a joint work with Ahto Buldas and Ahto Truu Submitted to SCN 2014 Full paper: