Efficient Implementation of Hash-Sequence Signatures Ahto Truu, - - PowerPoint PPT Presentation

Efficient Implementation of Hash-Sequence Signatures

Ahto Truu, Guardtime AS / Tallinn University of Technology This is joint work with Ahto Buldas and Risto Laanoja

The presenter has received the Skype and IT Academy PhD Student’s Scholarship for the academic year 2015/16, funded by Estonian Information Technology Foundation and Skype Technologies OÜ January 29, 2016 Estonian Computer Science Theory Days at Käo

Introduction to BLT 1

Quantum Computers

• Most current signature systems will become

inherently insecure with the arrival of quantum computers

• Each user has a private signing key and a

corresponding public verification key

• The two keys are mathematically related
• Using that relationship to derive the private key

from the public one requires solving a problem that is intractable for classical computers

• However, the derivation would be relatively easy

with a quantum computer

Introduction to BLT 2

• Quantum Cryptography
• Solutions that take advantage of quantum effects
• Mostly theoretical research for now, as no general-

purpose quantum computers are available

• Only quantum key distribution possible in practice
• Post-Quantum Cryptography
• Solutions that can be run on classical computers,

but are resistant to attacks by quantum computers

• Our work falls to this category

Adding Non-Repudiation to KSI

• Keyless data signatures (hash-linked time-stamps)

are quantum-resistant, but lack non-repudiation

• KSI is based on one-way hash functions which are

not reversible even by quantum computers (at least according to current knowledge of their capabilities)

• However, a client could contest a signature by

claiming server created it without client’s request

• Because the client-server communication in KSI is

authenticated in symmetric manner, neither client nor server can prove their claims to a third party

• For many use cases, non-repudiation is needed

Introduction to BLT 3

• Repudiation
• Disowning your signature and consequently

denying your responsibility for it

• Non-repudiation
• Property of a signature system that prevents this

denial by a signer

• Usually achieved by designing the system so that

creation of the signature needs something no-one else beside the signer has access to

• Then the existence of the signature means the

signer must have participated in the signing

Hash Functions

• One-way functions that take arbitrarily-sized data as

input and generate unique fixed-size bit sequences as output

• Preimage resistance

Given Y, infeasible to find X such that H(X)=Y

• Second preimage resistance

Given X, infeasible to find X’≠X such that H(X’)=H(X)

• Collision resistance

Infeasible to find X1≠X2 such that H(X1)=H(X2)

• Hash values often used as representatives of data

when the data is too large or confidential to handle directly

Introduction to BLT 4

Message Authentication Codes

• Hash functions can authenticate messages
• Sender and recipient pre-agree on a secret key K
• To send a message M, sender
• Computes X=H(M,K)
• Sends (M,X)
• Recipient, knowing K
• Computes H(M,K) from received M
• If the result matches received X, M is from sender
• An attacker who wants to send M’ would need to also

send matching X’, but can’t do this without knowing K

Introduction to BLT 5

• However…
• Even though hash functions are one-way, the

process is symmetric for sender and recipient

• Recipient, also knowing the key, can make up any

message and compute an authentication code indistinguishable from what would have been computed by the sender

• Sender can use the above to deny messages it

actually did send

• Neither party could prove their claims or disprove

the claims of the other to a third party

Using Time to Break Symmetry

• To commit a set of time-bound keys, sender
• Generates a key sequence

K[N]=random, K[i-1]=H(K[i]) for i=N..1

• Publishes K[0] along with a starting time T, but

keeps the remaining keys secret

• To sign a message M at time T+i, sender
• Computes X=H(M,K[i])
• Gets KSI signature S (time-stamp) on X
• Sends (M,K[i],S)

Introduction to BLT 6

• To either verify the message for itself or to prove it to

a third party, recipient

• Verifies that S correctly signs H(M,K[i])
• Uses iterated hashing to check that K[i] is indeed

i-th member of the sender’s key sequence

• Uses S to check that K[i] was indeed used at the

designated time T+i and not later

• It is safe for sender to reveal K[i] as part of the

signature, as its time slot has passed and it can’t be used for signing any further messages

Hash Trees

• Binary trees of hash values
• Input hash values in leaves
• Each parent is the hash of the

concatenation of the child values

Introduction to BLT 7

L000 L001 L010 L011 L100 L101 L110 L111 N01 N00 N0 R N1 N10 N11

Hash Chains

• Proof of participation of a leaf in

the tree

• Re-computation of the values on

the path from the leaf to the root

• Needs only the sibling values

and concatenation order, taking log2(N) steps for N leaves

Introduction to BLT 8

L011 N00 N1 L R L

L010 R N0 N01 N00 N1 L011 L000 L001 L010 L011 L100 L101 L110 L111 N01 N00 N0 R N1 N10 N11

More Efficient Commitments

• To commit a set of time-bound keys, sender
• Generates a key sequence K[1..n]
• Builds a hash tree on top of the sequence
• Publishes the root hash R of the tree along with a

starting time T, but keeps the keys secret

• To sign a message M at time T+i, sender
• Computes X=H(M,K[i])
• Gets KSI signature (time-stamp) S on X
• Sends (M,K[i],S,C), where C is the hash chain

connecting K[i] to R

Introduction to BLT 9

• To either verify the message for itself or to prove it to

a third party, recipient

• Verifies that S correctly signs H(M,K[i])
• Uses C to check that K[i] is indeed i-th member of

the sender’s key sequence

• Uses S to check that K[i] was indeed used at the

designated time T+i and not later

• It is safe for sender to reveal K[i] as part of the

signature, as its time slot has passed and it can’t be used for signing any further messages

More Efficient Evidence Extraction

• Need to walk the key sequence in reverse order
• Keep all the keys, O(N) memory
• Re-compute each key from the seed, O(N) time
• Keep a few intermediate values (pebbles)
• Can get by with O(log(N)) memory and O(log(N))

computation time per reverse step

• We generalize the technique to hash trees
• Keep O(log(N)) hash chains, for total O(log2(N))

memory and O(log2(N)) computations per step

Introduction to BLT 10

• Quite efficient signing
• O(log2(N)) memory to keep the key material, of

which only O(log(N)) is really secret

• O(log2(N)) time to extract the next key and the

corresponding hash chain

• Very efficient verification
• O(log(N)) signature size
• O(log(N)) time to verify the hash chain

Optimizing Memory Requirements

• Sparse global sequence
• Dense local sequences whose

keys are generated on the fly and roots signed with keys from the global sequence

• Reduces memory requirement to

approximately half of the original

Introduction to BLT 11

Servers vs Personal Signing Devices

• The protocol as described so far

is suitable for servers that create a lot of signatures and have accurate clocks and no security breaches; personal computers are nothing like that

• Personal signing keys are rarely

used and for security reasons are often managed in dedicated devices like smart cards or dongles

Introduction to BLT 12

Server-type signatures

• The signing device is always on

and has access to reliable time

• Most efficient to pre-assign each

key to a specific time slot

• Multiple items could be signed

with a single key within that time slot Client-type signatures

• The signing device may be

powered only intermittently, may lack independent communication channels and reliable clock

• Most efficient to use server-

supported protocol that ensures each key is used at most once

Server-Supported One-Time Keys

• Both client and server keep track of used keys
• When client wants to sign with key K[i]
• Computes X=H(M,K[i])
• Sends to server (X,i,ID)
• Server responds with a signature on (X,i,ID) to

confirm that K[i] has not been used before

• To keep each other honest, both client and server

keep list of those signed confirmations

Introduction to BLT 13

• To save space, instead of full signatures, hashed

sequence of signing times can be kept

• If K[i] is used at time T[i], then instead of (X,i,ID),

server signs (Y[i-1],X,i,ID), where Y[j] summarizes the sequence of signing times: Y[j]=H(Y[j-1],T[j])

• To further save space on the client, if the server is
• bligated to keep the full time list, the client only need

to keep the last signature

• This indirectly protects the whole sequence of

signing times

Key Generation with Standard Hardware

Iterated hashing

• Generate a random seed S
• Set
• K[n] = S
• K[i] = hash(K[i+1])
• Difficult to navigate the key

sequence

• Not supported by off the shelf

cryptographic hardware

Introduction to BLT 14

Keyed hashing

• Generate a random seed S
• Set K[i] = hash(i, S)

(that is, use S as key to compute HMAC on i)

• Still not supported by off the

shelf cryptographic hardware

• Suitable for software-only

implementations Block cipher based

• Generate a random seed S
• Set K[i] = encrypt(i, S)

(that is, use S as key to encrypt i with a block cipher algorithm such as AES)

• Can use cryptographic hardware
• To generate the key
• To use the key without taking it
• ut of the secure storage

Thank You

Questions?

Introduction to BLT 15

Draft papers

• Efficient Quantum-Immune Keyless Signatures with Identity

http://eprint.iacr.org/2014/321

• Efficient Implementation of Keyless Signatures with Hash Sequence

Authentication http://eprint.iacr.org/2014/689

• Security Proofs for the BLT Signature Scheme

http://eprint.iacr.org/2014/696 All joint work with Ahto Buldas and Risto Laanoja