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˜ oesuu
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 •
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.
Background | Traditional Signature Solutions PKI is a mature field – there are few successful deployments like SSL/TLS for secure web • DKIM (email 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.
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.
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.
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.
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.
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
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
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’. •
Hash-chain One-time hash passwords (Lamport 1981): • Client generates iteratively a list of hash values (in reverse order of index). { 0 , 1 } n z ℓ ← z i ← h ( z i +1 ) for i ∈ { ℓ − 1 , ℓ − 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! •
Hash-chain | Preimage Traversal Lamport’s one-time-password scheme has either O ( ℓ ) storage (whole chain retained) or • O ( ℓ ) preimage generation time (only z ℓ 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 ( ℓ/N ) hash calculations per key.
Hash-chain | Jakobsson Jakobsson (2002): traversal algorithm which amortizes h () calculations. O (log ℓ ) memory and O (log ℓ ) hashing steps to output a key (preimage). Pebbles are placed at positions 2 j , j = 1 .. ⌊ log ℓ ⌋ ; 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.
Hash-chain | Fractal Coppersmith and Jakobsson (2002): “Fractal hash chain • traversal”: if hash chain length ℓ = 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 ↓ )
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 ℓ hashings is too much. •
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.
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 i 2. Check if z i � r 3. Verify S t , extract ( t, x ) 4. Check if t = t 0 + i 5. Check if data hash matches.
Our solution | Compact Signature I Signature size and verification time complexities O ( ℓ ) 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.
Recommend
More recommend
