# Supervised Usage of Signature Creation Devices

## Abstract

We propose an effective scheme for controlling usage of secure signature creation devices (SSCD). With cryptographic means we assure that an inspector can check whether an (ordered) list of signatures at hand is the complete list of signatures created by the device. Our scheme is devoted to some applications like automatic creation of invoices or contract signing by a legal representative of a company.

The inspection procedure is probabilistic with no false-negatives and low probability of false-positives. It requires extra private keys known only by the inspector. So it cannot be executed by the holder of an SSCD – this has to prevent testing integrity of the list after list manipulations searching for a false-positive result.

Our solution works for a wide class of signatures based on Discrete Logarithm Problem without any changes of the signature format.

We provide formal security proofs as well as discuss implementation issues.

### Keywords

Secure signature creation device (sscd) Smart card Qualified signature Controlled usage Discrete Logarithm Problem Diffie-Hellman Problem ElGamal signature Schnorr signature DSA ECDSA## 1 Introduction

*advanced electronic signatures*as named by European Directive [8]) is based on three factors:

- 1.
strength of an asymmetric cryptographic signature scheme,

- 2.
security of the private key stored in a dedicated hardware unit, which is called

*secure signature creation device*(SSCD for short) in [8], - 3.
guarding physical access to the SSCD.

In turn, the security of SSCD is mainly in focus of R&D work of the hardware manufacturers. Their approach is quite different: many technical details for securing the chips are kept secret and we have to do with a kind of race between the hardware manufacturers and the attackers. In order to be able to recognize which device is suited (secure enough) for a particular application, *Common Criteria* framework [6] has been introduced. However, a Common Criteria evaluation does not provide security guarantees but only testifies conformance with certain development procedures that should support creating a secure product. Nevertheless, in many cases the manufacturers provide just a declaration of conformance of their products with the rules imposed e.g. by [8], and are liable for any design faults.

As SSCD devices with an integrated input channel are rare, typically the PIN number is entered through a keyboard of a PC. So the PIN can be leaked.

A third person may learn a PIN number by observing the owner of an SSCD during activation of the SSCD. This is a major problem since a large number of smart card users do not follow even fundamental rules of the PIN protection.

Occasionally, some people provide own signature cards together with the PIN to other people for doing some work on behalf of them.

*lunch time attack*: a secretary uses the SSCD left in the office of his or her boss to sign some documents.

One approach to deal with these problems is to provide own input channel for the SSCD. For example, smart cards with two buttons have been developed and studied in the context of the German personal identity card (finally, this solution has not been deployed). However this solves only the first problem. Another approach is biometric identification. In this case the major problems are costs, usability and high false acceptance/rejection rates.

**Problem Statement.** In this paper we do not attempt to provide new techniques that could replace PIN protection. Instead we provide means of monitoring usage of the SSCD devices. Our goal is to provide an effective procedure that would protect against illegitimate use of an SSCD.

Note that our goal is much broader than preventing problems arising from insufficient protection via the PIN. In many application scenarios the adversary is the SSCD owner himself. This may sound strange (as *it makes no sense to steal own money*), however in many cases the SSCD is restricted for use in specific situations and all signed documents must be available to some parties.

One example of this kind is using an SSCD by a representative of a legal person for signing legally binding obligations. There are many legal rules that prohibit hiding documents of this kind. However, the real life is full of violations of the law, just as in the case of ENRON, where the frauds would be prevented if one could easily detect that some documents are missing in the official bookkeeping.

Another application case are all kinds of registries that provide reference data, but where the entries are created and signed by a certain official. In this case an SSCD of the official should be used exclusively in a strictly defined scope and we have to make sure that all documents are indeed included in the registry.

Similar requirements apply for many procedures in the court and law enforcement practice, where all steps of the procedure are strictly regulated and the complete documentation has to be maintained.

the holder of the SSCD enters all signed documents to the system,

the signatures are created in the sequence indicated by the signing time entered on the document.

Our solution is an inspection procedure that takes a list of signatures created by a device within some time – allegedly a complete one – and checks whether some signatures created by the device have been omitted.

### 1.1 Simple Solutions and Related Work

**Counters.** The first possible solution is to add an internal counter to an SSCD and append the counter value to the text before signing. This approach has obvious advantages but also critical disadvantages. The first one is leaking how many messages have been signed by the device to every recipient of a signature. This is unacceptable in most business cases. The second problem is that introducing such a field might be incompatible with the current legal framework. Namely, [8] states that:

Secure signature-creation devices must not alter the data to be signed or prevent such data from being presented to the signatory prior to the signature process.

The third problem is that the smart card gets no document to be signed but its hash value. So the counter value should be appended to the hash value of the document. Then we would have to hash again before applying algebraic signing operations as, in general, these operations should not be applied to plaintexts.

Another approach is to add an encrypted value of the counter. In this case the information is hidden from unauthorized viewers. However, again there are legal concerns. Moreover, in this case the problem is even more acute as the SSCD adds an information field that cannot be inspected by the signatory.

On the other hand, there is an easy implementation in case of RSA-PSS signatures created according to PKCS#1 standard [17]. Recall that the hash value of the document to be signed is augmented by a bit string (*salt*) that might be set arbitrarily – e.g. it may contain the encrypted value of the counter. What is more, this bit string is recoverable during the signature verification process. Note that this approach does not require any change of the standard and of the verification software. However, the solution is limited to the RSA-PSS signatures.

**Mediated Signatures.** Mediated signatures [4] have been proposed for eliminating a single point of trust failure in the system of electronic signatures. Creating a mediated signature requires cooperation of at least two holders of corresponding secret keys. A single key does not even suffice to create a digital proof that this key has been used: the public key of the signatory is useless for this purpose. Elegant constructions for mediated signatures exist for RSA [4] and Schnorr signatures [15].

The main advantage of the mediated signatures is that they provide effective control means over SSCD usage, allowing for instance immediate blocking the SSCD when the owner looses control over it or monitoring detects suspicious activities. Their disadvantage is that some infrastructure is required and no simple solution for signatures such as ECDSA is known.

**Stamp and Extend.** According to [14] the signatures are created and stored in a form of a list with a hidden tree structure. If \(n\) signatures are created, then simultaneously there are \(n\) commitments for the next \(n\) signatures to be created by the device. The scheme enables to check whether a given list of \(n\) signatures is the list of all first \(n\) signatures created by the device. If an attacker replaces one of the signatures of the list with another signature that can be verified positively, then the private signing key gets revealed. So the protection mechanism in [14] is quite aggressive. While it is well suited for time-stamping (*nobody would ruin own business*), in case of regular users instant invalidation of all signatures in case of a forgery is not always welcome.

### 1.2 Design Objectives

If the owner of an SSCD presents an incomplete list of signatures created with it, then the entitled verifier can detect that some signatures have been omitted.

The entitled verifier should be able to recognize positions of missing signatures, if there are any.

the signatures created with the scheme should be standard ones, so that no adjustment of the verification process would be necessary,

the signed values may not contain additional fields such as serial numbers, additional signatures, ciphertexts and so on,

unless some secret keys are used, it should be infeasible to distinguish between the SSCD devices with supervision mechanism from the regular SSCDs.

### 1.3 Some Applications

**Electronic seals:**the primary application field of electronic signatures is authenticating documents created automatically in IT systems. (In this case the term

*electronic seal*is used (see [7]), but exactly the same technology can be used as for electronic signatures.) For instance, an overwhelming majority of invoices is created in the electronic form. Electronic seals may be used to authenticate and protect their integrity. One of important problems is that sometimes the invoices are deleted in order to hide some transactions from the tax authorities. The SSCD devices implementing the mechanism proposed provide an effective inspection mechanism for the tax authorities against certain tax frauds.**Financial records:**Progress in hardware design makes it possible to use asymmetric cryptography for securing the financial transactions. In particular, issuing signatures for transactions would be a great help against frauds. However, the instrument holder could claim that the secret key installed by a financial organization in the electronic authentication device has a copy retained by the organization and that certain signatures have been created with this key. The CTRL-Sign mechanism prevents undetected insertion of new signatures in the list.

**Controlling staff activity:**if a corporation provides SSCD devices to own staff members, then it might be necessary to check whether all signed documents are stored in the data system of the corporation and no documents are created without awareness of the corporation.

## 2 Description of the CTRL-Sign Scheme

### 2.1 Setup

**Algebraic Setup.** Let \(\mathcal G\) be an abelian group of prime order \(q\), in which the Discrete Logarithm Problem is hard. Let us fix an arbitrary generator \(g\) of \(\mathcal G\). We use multiplicative notation for group \(\mathcal G\). Unless otherwise specified the operations are executed in the group \(\mathcal G\). If we are performing algebraic operations on exponents of elements of \(\mathcal G\) we assume silently that the operations are performed modulo \(q\).

We use independent hash functions \(\textit{Hash}_1\), \(\textit{Hash}_2\), \(\textit{Hash}_3\), \(\textit{Hash}_4\) and \(\textit{Hash}_5\) with appropriate range following from the context. We assume that the hash functions are strong in the cryptographic sense.

**System Actors and their Keys.** There are the following actors in the system: the Card Issuer, the signatories holding SSCDs, the Certification Authority (CA), and the Inspection Authority (IA).

**Inspection Authority:**the IA has a long period secret key \(k_{master}\), the secret inspection key \(\textit{ins}\), and the public inspection key \(\textit{Ins}\). For a user \(U\), the IA determines the control key \(c_U:=\textit{Hash}_1(U,k_{master})\).

**Card Issuer:**for a user \(U\), the Card Issuer obtains the keys \(c_U\) and \(\textit{Ins}\) from the IA and installs them in the SSCD issued for \(U\).

- Signatories:
the SSCD of a user \(U\) holds the preinstalled keys \(c_U\) and \(\textit{Ins}\) as well as the private signature key \(x_U\) created at random by the SSCD, and the public key \(X_U=g^{x_U}\). (Note that the SSCD does not hold the private inspection key \(\textit{ins}\)).

**Certification Authority:**the CA has standard keys for issuing certificates for the public keys of the users, just as in PKI built according to the X.509 framework.

The SSCD of a user \(U\) and the IA share the secret \(c_U\). It serves as a seed for a PRNG, thereby SSCD of the user \(U\) and the IA share a string \(\mathrm{RAND }_U=\mathrm{PRNG }(c_U)\). The string \(\mathrm{RAND }_U\) is divided into \(d\)-bit substrings, where \(d\) is a small integer (e.g. \(d=4\)), say \(\mathrm{RAND }_U=\rho _U^1\rho _U^2\ldots \). The substring \(\rho _U^i\) is a control sequence for the \(i\)th signature created by the SSCD of the user \(U\).

### 2.2 Creating a Signature

In our construction we may use any signature scheme based on the Discrete Logarithm Problem, where one if the components included in the final signature is \(g^k\) for \(k\) chosen at random – as for ElGamal signatures. Alternatively, we may apply a signature scheme where \(r=g^k\) is not included in the final message but can be derived from it. This is the case for DSA, ECDSA [1, 11, 13, 16], Guillou-Quisquater signatures [10]) and Schnorr signatures [18].

- 1.
choose \(k\in [1,q-1]\) uniformly at random,

- 2.
\(r:=g^k\),

- 3.
\(e:=\mathrm{Hash }(M,r)\),

- 4.
\(s:=(k-x\cdot e) \mathrm{{mod}}\ q\).

- 5.
output signature \((e,s)\).

- 1.
generate \(k\) at random,

- 2.
check the

*hidden footprint*of \(k\); if it is incorrect return to step 1, - 3.
proceed signing steps of the basic procedure \(\mathrm{Sign }\) for the parameter \(k\) chosen.

**Generating**\(f_U(k)\)**- a hidden footprint for**\(k\)**and user**\(U\)**.**

input: \(\textit{Ins}, k\)

\(f:=\textit{Hash}_3(\textit{Ins}^k)\);

output \(d\) least significant bits of \(f\)

For the inspection procedure carried out by Inspection Authority there is an alternative way for computing \(f_U(k)\) (this is essential, since \(k\) is an ephemeral value existing only on the SSCD):

**Alternative generation of**\(f_U(k)\)**.**

input: \(\textit{ins}, r=g^k\)

\(f:=\textit{Hash}_3(r^{\textit{ins}})\);

output \(d\) least significant bits of \(f\)

**Creating the**\(i\)**th****signature by SSCD of user**\(U\)**for message**\(M\)**.**

input: a message \(M\), signing key \(x_U\), \(\mathrm{RAND }_U\)

“choose \(k\) at random so that \(f_U(k)= \rho _U^i\)”

proceed with the signing algorithm \(\mathrm{Sign }\) with

the first signature component \(r=g^k\)

Let us explain what does it mean “choose \(k\) at random so that \(f_U(k)= \rho _U^i\)”. We apply the following procedure:

**Choosing**\(k\)**at random so that**\(f_U(k)= \rho _U^i\)**.**

input: \(i\), \(c_U\), \(d\)

compute \(\rho _U^i\) as the \(i\)th \(d\)-bit block of \(\mathrm{PRNG }(c_U)\);

choose \(k\) at random;

\(R:=\textit{Ins}^k\);

while \(\textit{Hash}_3(R) \ne \rho _U^i\) do

\(k=:k+1\);

\(R:=R\cdot \textit{Ins}\)

**Signature verification.**

We apply the standard verification procedure of \(\mathrm{Sign }\).

### 2.3 Inspection Procedure of CTRL-Sign

- 1.
User \(U\) presents a list \(S_1,S_2, \ldots , S_t\) of allegedly all signatures created with his SSCD, according to the order in which they have been created.

- 2.
Apart from the regular verification of each signature \(S_i\), the Inspection Authority checks all footprints. Namely, for each signature \(S_j=(r_j, s_j)\), \(j\le t\), the IA computes the footprint \(\omega _j:= f_U(r_j)\).

- 3.
If \((\omega _1, \omega _2, \ldots , \omega _t)= (\rho _U^1, \rho _U^2, \ldots , \rho _U^t)\), then inspection result is positive.

### 2.4 Inspection Result in Case of Manipulations

Below we consider diverse cases of manipulations of the list of signatures. We assume that the SSCD is secure so we do not discuss here what happens if the adversary can manipulate or clone the SSCD.

The general observation is the following: if the original list is \(S_1, \ldots , S_t\) while the signatory presents for inspection a list \(S'_1, \ldots , S'_w\) of valid signatures, then the fraud remains undetected with probability approximately \(2^{-dN}\), where \(N\) is the number of indexes \(j\le w\) such that \(S_j\ne S'_j\). This follows from the fact that it is infeasible to guess the footprint with probability non-negligibly higher than \(2^{-d}\) (see Sect. 4), while on the other hand the probability that an SSCD ever creates two signatures with the same component \(r=g^k\) is negligible and therefore we may assume that the signatory never gets two signatures that he *knows* that they have the same fingerprint.

Below we discuss some chosen manipulation scenarios.

**Omitting a Signature:***a user*\(U\)*takes the list of signatures*\(S_1\), \(S_2\), ..., \(S_t\)*created by his SSCD and removes at least one of signatures before the inspection.*

Assume that the omitted signatures are \(S_{j_1}\), ..., \(S_{j_b}\), where \(j_1<j_2<\ldots < j_b<t\). Assume that the inspection procedure yields the positive result for the reduced list of signatures. Hence in particular \(f_U(S_{j_1+i})= \rho _U^{j_1+i-1}\) for \(j_1+i<j_2\). On the other hand, \(f_U(S_{j_1+i})= \rho _U^{j_1+i}\) due to the construction. So \(\rho _U^{j_1}=\rho _U^{j_1+1}=\ldots = \rho _U^{j_2-1}\).

We see that an attack of this kind requires a very careful choice of the signatures removed. However, the user does not see the footprints, so it is hard to make decisions which signatures can be removed.

As we see, the only safe choice for the signatory is to truncate the list of signatures. Then of course no irregularities will be detected. However, then the extended inspection procedure helps a lot and we are back in the previous scenario where omissions occur not at the end of the list. If \(m\) extra signatures are added, then we have at least \(m\) equations on \(d\)-bit values to be satisfied. Probability of an undetected fraud is then \(2^{-dm}\). So for \(d=4\) and \(m=15\) we get probability \(2^{-60}\), which is much better than we need.

**Changing the Order of the Signatures:** Assume that an adversary permutes the signatures using a permutation \(\pi \). As \(\pi \) is a superposition of disjoint cycles, the attack succeeds if in each cycle the values of the footprints are fixed. So if the attacker fails to guess a footprint in at least one position, then the attack becomes detected.

**Adding Forged Signatures:** adding signatures without removing the old ones causes the same problems for the adversary as removing signatures and requires fulfilling quite many equations between the footprints. The analysis is similar as in the first case.

## 3 Security of CTRL-Sign Scheme

The proposed scheme CTRL-Sign changes substantially the signature creation process, since the choice of the parameter \(k\) is not fully random, since the footprint created with \(k\) has to satisfy certain conditions. Potentially, this may convert a secure signature scheme into an insecure one. We show that this is not the case. For the proof we apply the security games framework from [19].

### 3.1 Key Privacy

**Model 1:**a list of signatures \(S_1,\ldots , S_t\), the inspection key \(\textit{ins}\) and \(\mathrm{RAND }_U\),

**Model 2:**a list of signatures \(S_1,\ldots , S_t\), the inspection key \(\textit{ins}\) and \(c_U\).

**Model 1.** First we define a game describing an attack for breaking the signing key:

**Game 0**

choose \(x_U\), \(\textit{ins}\) at random

choose \(c_U\) at random

\(\mathrm{RAND }_U:= \mathrm{PRNG }(c_U)\)

create \(S_1,\ldots , S_t\) with \(x_U\), \(\textit{ins}\), \(\mathrm{RAND }_U\)

\(b:= F(x_U)\)

\(\bar{b}:= {\mathcal A}(S_1,\ldots , S_t, \mathrm{RAND }_U, \textit{ins})\)

The adversary wins, if \(\bar{b}=b\), i.e. if the property \(F\) of \(x_U\) has been correctly derived. If \(\Pr (F(x_U)=1)=p\), then in case of a random answer \(\bar{b}\) the probability to win is \(2p(1-p)\). Hence the advantage of the adversary may be defined as \(|\Pr (\bar{b}=b) - 2p(1-p)|\).

Note that the Game 2 creates \(\mathrm{RAND }_U\) with exactly the same probability distribution as the Game 1. Therefore the advantage of the adversary does not change.

Note that the Game 3 describes the security of the signing key in the regular model.

**Theorem 1**

If the adversary has a non-negligible chance to break the signing key in the Model 1 for CTRL-Sign, then the same applies for the underlying signature scheme, provided that the \(\mathrm{PRNG }\) creates strings indistinguishable from the random strings.

**Model 2.** We show that given a set of signatures \(S_1, \ldots , S_t\) we can create a case for the Model 2. However, during the reduction the number of signatures decreases. Let us describe the reduction:

choose \(\textit{ins}\) at random

choose \(c_U\) at random

\(\mathrm{RAND }_U:= \mathrm{PRNG }(c_U)\), put \(\mathrm{RAND }_U=(\rho _U^1,\rho _U^2,\ldots )\),

choose a sequence \(v_1<v_2<\ldots < v_m \le t\) such that \(\rho _U^j\) equals the last

\(d\) bits of \(\textit{Hash}_3(r_{v_j}^{\textit{ins}})\) for \(j\le m\), where \(S_{v_j}=(r_{v_j},s_{v_j})\)

For finding \(v_1, v_2,\ldots , v_m\) we apply the greedy procedure. After finding \(v_{j-1}\) we look for the smallest \(l>v_{j-1}\) such that the last \(d\) bits of \(\textit{Hash}_3(r_{l}^{\textit{ins}})\) are equal to \(\rho _U^j\).

*lazy*random process, that is, after finding \(v_{j-1}\) we generate \(\rho _U^j\) at random. Then we generate the next signatures \(S=(r,\ldots )\) with \(r\) generated at random. The process of finding a match behaves in the same way for each value of \(\rho _U^j\), so we may assume without loss of generality that each \(\rho _U^j\) is an all-zero string. Thereby, the probability distribution of \(m\) is the same as for the number of zeroes in a string of length \(t\), where the entries are chosen at random from the set \(0, 1, \ldots , 2^{d}-1\). The expected number of zeroes in such a string equals \(t/2^d\), and according to the Chernoff Bounds

**Theorem 2**

The advantage of an adversary attacking the basic signature scheme for a list of signatures of length \(t\) is not lower then the advantage of an adversary attacking in Model 2 for a list of signatures of length \(m\) where \(m\) is a random variable denoting the number of zeroes in a random string of length \(t\) consisting of elements chosen uniformly at random from the set \(\{0,1,\ldots , 2^d-1\}\).

### 3.2 Forging a Signature

As the process of signature creation is based on the regular signature creation (with some signatures dropped) forging a signature is not easier than in the regular case.

## 4 Secrecy of Footprints – an Enhanced CTRL-Sign Scheme

The aim of the construction is to make a SSCD implementing CTRL-Sign indistinguishable from a regular SSCD under the assumption that the SSCD is a black box device. This implies in particular that no guess about footprint values can be obtained.

Intuitively, a signature \(S=(r,s)\), where \(r=g^k\), reveals no information about \(\textit{Ins}^k\). Computing any information about \(\textit{Ins}^k\) is closely related to the Decisional Diffie-Hellman Problem: one could take an instance \((g,\)\(g^a\),\(g^b\), \(z)\) of the Decisional Diffie-Hellman Problem, assign \(r=g^a\), \(\textit{Ins}=g^b\), derive some information about \(\textit{Ins}^k=g^{ab}\), and compare it with the same information related to \(z\). However, this argument is not formally correct, since the adversary is also given the second component \(s\) of the signature \(S\), which depends on the private signing key \(x_U\) and the exponent \(k\). So in the reduction argument it would be necessary to construct the signature component \(s\). However, the reduction cannot use a signing key \(x_U\) chosen by the reduction algorithm, as it would enable to compute \(k\) from \(s\). On the other hand, if \(x_U\) is unknown for the reduction algorithm, then such a construction would create electronic signatures without the secret key \(x_U\), which is infeasible.

The problem that we are faced with is whether it is possible to derive any information about \(y^k\), given \(r=g^k\) and a signature, say \(s=k+H(M,r)\cdot x\) (the Schnorr signature), and the public key \(g^x\). The parameter \(y\) is here random and independent from \(g^x\) – the public verification key for the signatures. It seems that a Schnorr signature does not enable to derive any information about \(y^k\). However, in order to be on the safe side we present below a slight modification of CTRL-Sign scheme for which there is a formal indistinguishability argument.

Note that a somewhat related problem arises in [2], where \(Y_A=g^{y_A}\) from the Diffie-Hellman key exchange is reused for creating a Schnorr signature authenticating the smart card executing the protocol. The workaround used in [2] for security of the session key is that it is derived as a hash of the key obtained via the Diffie-Hellman algorithm. Thereby, one can apply Random Oracle Model arguments and hide the problem via application of this model.

**Main Idea.** The main concern is the second component of the signature. To make the hidden footprint completely independent from the second component of the signature we use a decomposition trick. Namely, for the \(i\)th signature we use \(k=k_1+k_2^{(i)}\), where \(k_2^{(i)}\) is derived from a key shared by the SSCD and the IA; the key \(k_1\) is chosen at random. On the other hand, for the footprint the exponent \(k_1\) is used. Note that Inspection Authority will be able to derive \(g^{k_1}\), since \(g^{k_1}= r/g^{k_2^{(i)}}\).

**Enhanced CTRL-Sign Scheme.** There is another key \(b_U\) shared by the Inspection Authority and a SSCD of user \(U\). For instance, we may set \(b_U= \textit{Hash}_4(U, k_{master})\).

**Creation of the**\(i\)**th signature by user**\(U\)**with Enhanced CTRL-Sign**

input: \(i\), message \(M\), secret keys \(b_U\), \(c_U\), \(x_U\), public key \(\textit{Ins}\)

recompute \(\mathrm{RAND }_U:=\mathrm{PRNG }(c_U)\) and extract \(\rho _U^i\) from \(\mathrm{RAND }_U\)

\(k_2^{(i)}:= \textit{Hash}_5(b_U,i)\)

choose \(k_1\) at random

\(z:=\textit{Ins}^{k_1}\)

while the last \(d\) bits of \(\rho _U^i\) and \(\textit{Hash}_3(z)\) are not the same do

\(k_1=:k_1+1\),

\(z:=z\cdot \textit{Ins}\)

\(k:=k_1+k_2^{(i)}\)

\(r:=g^k\)

generate a signature \(S=(r,s)\) for the message \(M\) using \(k\) and \(r\)

**Sketch of the Indistinguishability Proof.** Again we consider a sequence of games, where the starting game describes the enhanced CTRL-Sign scheme. The adversary is given \(\textit{Ins}\) and the whole string \(\mathrm{RAND }_U\) – as it can facilitate the attack trying to recover the footprints.

**Game 0** this is the same as the original procedure for creating the \(i\)th signature by Enhanced CTRL-Sign, appended with the extra step representing information extraction by the adversary:

\(out:= {\mathcal A}(M,S,i, X_U, \textit{ins}, \mathrm{RAND }_U)\)

Only the key \(b_U\) is not given to the adversary.

Now observe that the Game 2 describes the adversary holding an SSCD that implements electronic signatures in a regular way, without the inspection features and adjusting the exponents \(k\). So we may conclude that the output \(out\) is indistinguishable between the cases of a regular SSCD and the case of an enhanced CTRL-Sign SSCD.

The above proof can be easily extended to the case that the adversary is given multiple signatures and may ask a device to sign messages of his choice. Thereby we get the following theorem:

**Theorem 3**

Assume that \(\textit{Hash}_4(b,i)\) is a PRNG with seed \(b\) which produces outputs indistinguishable from the random numbers in the range of the order of group \(\mathcal G\) used for creating electronic signatures. Then it is infeasible to distinguish an SSCD implementing the enhanced CTRL-Sign scheme from the regular SSCD implementing the same signature scheme, given all public values (the signatures and the public key \(X_U\)) as well as the secret inspection parameter \(\textit{ins}\).

**Corollary 1**

Assume that the assumptions of Theorem 3 hold. Then given a list of signatures created by the enhanced CTRL-Sign SSCD, it is infeasible to derive any non-negligible amount of information about the footprints for the signatures.

*Proof*

Assume conversely that there is an algorithm \(\mathcal A\) that can derive such information. Then we use \(\mathcal A\) to construct an adversary \(\mathcal A'\) that contradicts the claim of Theorem 3. Indeed, given \(\mathrm{RAND }_U\) and a sequence of signatures, we can present the signatures to \(\mathcal A\), get the output from \(\mathcal A\) and compare the data obtained for compliance with \(\mathrm{RAND }_U\). If the data do not fit to each other, then \(\mathcal A'\) says that the SSCD is a regular device. Otherwise \(\mathcal A'\) claims that SSCD implements enhanced CTRL-Sign scheme. Obviously, if the information obtained by \(\mathcal A\) is non-negligible, then \(\mathcal A'\) is a distinguisher with a non-negligible advantage. \(\square \)

## 5 Chosen Implementation Issues

generating the current footprint \(\rho _U^i\),

computing \(R:=\textit{Ins}^k\) for the exponent \(k\) chosen at random,

some number of iterations of the following loop:

while\(\textit{Hash}_3(R) \ne \rho _U^i\)do

\(k=:k+1\);

\(R:=R\cdot \textit{Ins}\)

*while*loop are necessary in order to find a \(k\) yielding the correct value. If we treat \(\textit{Hash}_3\) according to the Random Oracle Model, then the probability that in \(N=2^d\cdot h\) executions of the loop we do not get an appropriate \(k\) equals

The best way to check the efficiency of CTRL-Sign would be to implement it directly on a smart card using an open architecture such as Java Card with the efficient elliptic curve arithmetic. However, the problem is that the cryptographic functions are implemented in a secure way and there is no access to modify their code or get access to intermediate values such as the exponent \(k\) of \(r=g^k\). Moreover, there is no direct way of adding two points of the elliptic curve. Implementing such operations on application layer is usually too slow and a good solution is to find a workaround – an implementation using hardware supported operations (see e.g. [3]). However, an implementation of CTRL-Sign has to use point addition in the protected section of the card for the sheer reason that \(k\) must not leave this section (otherwise the signing key might be exposed). So a reasonable implementation must use the native code in the protected section.

Some experimental results on Gemalto Java cards and 256-bit elliptic curve

Operation | MultiApp ID Dual Citizen | MultiApp ID |
---|---|---|

144 K CC v2.0 (Infineon) | 144 K ECC v2.1 (NXP) | |

Scalar multiplication | 186 ms | 104 ms |

ECDSA signature with SHA1 | 191 ms | 111 ms |

ECDSA signature with SHA256 | 194 ms | 112 ms |

Verification of ECDSA with SHA1 | 140 ms | 112 ms |

Verification of ECDSA with SHA256 | 141 ms | 115 ms |

SHA-1 computation | 4 ms | 4 ms |

SHA-256 computation | 8.6 ms | 6.4 ms |

One can see that computing the hash functions in the while loop is not very costly concerning the execution time. The question is how long it take to add points of an elliptic curve.

The longer computation times for a signature creation than for a signature verification may follow from countermeasures against side channel time analysis. This indicates that for the signature creation the Montgomery ladder algorithm might have been used. In this case the computation consists of *add* operations and *double* operations, and the number of these operations is logarithmic in the scalar. This in turn would suggest that the addition of elliptic curve points takes a few milliseconds on the cards inspected. Thereby, the whole execution would take about half a second at average, and less than 1.5 s with probability \(0.99997\). Of course, due to time analysis attacks, a fixed number of iterations of the loop should be executed. If no appropriate \(k\) is found in this time, then the card should restart with a fresh \(k\).

## 6 Conclusions and Future Work

CTRL-Sign has to be implemented in the protected areas of a smart card. Today, the smart card manufacturers give no access to these areas for the third parties, so an implementation attempt would be technically difficult and would violate intellectual property rights.

Particularly interesting would be choosing the best implementation of CTRL-Sign against time analysis. However this depends very much on the card specific data.

Finally, let us note that similar constructions are possible for some other schemes, like for instance Feige-Fiat-Shamir [9] and Nyberg-Rueppel [12] schemes. Thereby, we see that with an exception for RSA all algorithms recommended by German authorities for practical use (see the list [5]) admit control mechanisms proposed in this paper.

### References

- 1.ANSI: X9.62:2005 public key cryptography for the financial services industry: The elliptic curve Digital Signature Algorithm (ECDSA) (2005)Google Scholar
- 2.Bender, J., Dagdelen, Ö., Fischlin, M., Kügler, D.: The PACE\(|\)AA protocol for machine readable travel documents, and its security. In: Keromytis, A.D. (ed.) FC 2012. LNCS, vol. 7397, pp. 344–358. Springer, Heidelberg (2012)CrossRefGoogle Scholar
- 3.Bichsel, P., Camenisch, J., Groß, T., Shoup, V.: Anonymous credentials on a standard Java card. In: Al-Shaer, E., Jha, S., Keromytis, A.D. (eds.) ACM Conference on Computer and Communications Security, pp. 600–610. ACM (2009)Google Scholar
- 4.Boneh, D., Ding, X., Tsudik, G., Wong, C.M.: Instantenous revocation of security capabilities. In: USENIX Security Symposium (2001)Google Scholar
- 5.Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen: Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung (Übersicht über geeignete Algorithmen). Draft, 10 October 2013Google Scholar
- 6.Common Criteria. http://www.commoncriteriaportal.org
- 7.European Commision: Proposal for a regulation of the European Parliament and of the Council on electronic identification and trust services for electronic transactions in the internal market, 4 June 2012Google Scholar
- 8.European Parliament and of the European Council: Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures. Official Journal of the European Communities L(13), 19 Jan 2000Google Scholar
- 9.Feige, U., Fiat, A., Shamir, A.: Zero-knowledge proofs of identity. J. Cryptol.
**1**(2), 77–94 (1988)MathSciNetCrossRefMATHGoogle Scholar - 10.Guillou, L.C., Quisquater, J.-J.: A practical zero-knowledge protocol fitted to security microprocessor minimizing both transmission and memory. In: Günther, C.G. (ed.) EUROCRYPT 1988. LNCS, vol. 330, pp. 123–128. Springer, Heidelberg (1988)CrossRefGoogle Scholar
- 11.IEEE: IEEE P1363: Standard specification for public key cryptography (2000)Google Scholar
- 12.ISO: ISO/IEC 9796–3:2006 Information technology - Security techniques - Digital signature schemes giving message recovery - Part 3: Discrete logarithm based mechanisms (2006)Google Scholar
- 13.ISO/IEC: 14888–3:2006 Information technology - Security techniques - Digital signatures with appendix - Part 3: Discrete logarithm based mechanisms (2006)Google Scholar
- 14.Krzywiecki, Ł., Kubiak, P., Kutyłowski, M.: Stamp and extend – instant but undeniable timestamping based on lazy trees. In: Mitchell, C.J., Tomlinson, A. (eds.) INTRUST 2012. LNCS, vol. 7711, pp. 5–24. Springer, Heidelberg (2012)CrossRefGoogle Scholar
- 15.Nicolosi, A., Krohn, M.N., Dodis, Y., Mazières, D.: Proactive two-party signatures for user authentication. In: NDSS, The Internet Society (2003)Google Scholar
- 16.NIST: FIPS publication 186–4: Digital Signature Standard (DSS) (2013)Google Scholar
- 17.RSA Laboratories: PKCS#1 v2.1 – RSA Cryptography Standard + Errata (2005)Google Scholar
- 18.Schnorr, C.-P.: Efficient identification and signatures for smart cards. In: Brassard, G. (ed.) CRYPTO 1989. LNCS, vol. 435, pp. 239–252. Springer, Heidelberg (1990)Google Scholar
- 19.Shoup, V.: Sequences of games: a tool for taming complexity in security proofs. IACR Cryptology ePrint Archive 332 (2004)Google Scholar
- 20.Young, A., Yung, M.: Kleptography: using cryptography against cryptography. In: Fumy, W. (ed.) EUROCRYPT 1997. LNCS, vol. 1233, pp. 62–74. Springer, Heidelberg (1997)CrossRefGoogle Scholar