Intrusion-Resilient Signatures - Semantic Scholar
Intrusion-Resilient Signatures: Generic Constructions, or Defeating Strong Adversary with Minimal Assumptions Gene Itkis Boston University Computer Science Dept. 111 Cummington St. Boston, MA 02215, USA [email protected]
Abstract. Signer-Base Intrusion-Resilient (SiBIR) signature schemes were defined in [IR02]. In this model, as in the case of forward security, time is divided into predefined time periods (e.g., days); each signature includes the number of the time period in which it was generated; while the public key remains the same, the secret keys evolve with time. In addition, in SiBIR model, the user has two modules, signer and home base: the former generates all signatures on its own, and the latter is needed only to help update the signer’s key from one time period to the next. The main strength of the intrusion-resilient schemes, is that they remain secure even after arbitrarily many compromises of both modules, as long as the compromises are not simultaneous. Moreover, even if the intruder does compromise both modules simultaneously, she will still be unable to generate any signatures for the previous time periods (i.e., the forward security is guaranteed even in the case of simultaneous exposures). This paper provides the first generic implementation, called gSiBIR, of the intrusion-resilient signature schemes: it can be based on any ordinary signature scheme used as a black-box. gSiBIR is also the first SiBIR scheme secure against fully-adaptive adversary and does not require random oracle. Our construction does require one-way (and cryptographic hash) functions. Another contribution of this paper is a new mechanism extending treebased constructions such as gSiBIR and that of [BM99] to avoid the limit on the total number of periods (required by [IR02] and many forwardsecure ones). This mechanism is based on explicit use of prefixless (or selfdelimiting) encodings. Applied to the generic forward-secure singature constructions of [BM99,MMM02], it extends the first and yields modest but noticable improvements to the second. With this mechanism, gSiBIR becomes the first generic intrusion-resilient signature scheme with no limit on the number of periods.
1
Introduction
Key exposures appear to be inevitable. Limiting their negative impacts is extremely important. A number of approaches for dealing with this problem have S. Cimato et al. (Eds.): SCN 2002, LNCS 2576, pp. 102–118, 2003. c Springer-Verlag Berlin Heidelberg 2003
Generic Intrusion-Resilient Signatures
103
been explored; some of their benefits have recently been combined in the following new approach. Intrusion-Resilience. Signer-Base Intrusion-Resilient (SiBIR) security model, introduced in [IR02], combines some benefits of the previously proposed key-insulated [DKXY02], forward-secure [And97,BM99], and proactive [OY91,HJJ+ 97] security models. A detailed discussion of relationships among all these models is included in [IR02], and we therefore omit it here. Intuitively, SiBIR model divides time into time periods, and augments each signature with a “time-stamp” (the time period number, during which the signature was generated). Verification is essentially similar to the ordinary signature schemes, except it includes the time period as input — if the time period is changed, the signature becomes invalid. These extensions to ordinary signatures are the same as for forward-secure [And97,BM99] and key-insulated models [DKXY02]. In addition, the ordinary signer is replaced in SiBIR model —similarly to the key-insulated model of [DKXY02]— with two modules: signer and home base (thus, the name of the model: Signer-Base Intrusion-Resilient, or SiBIR for short). The signer, using its secret key, can generate signatures, but only for the current time period (unlike forward-secure signer, which can also generate signatures for all the future periods). At the end of the current period, the signer must update its secret key for the next period — this requires an update message from the base. Thus, intrusion-resilient schemes, as the key-insulated ones [DKXY02], preserve security of both past and future time periods, when the signer is compromised. Moreover —unlike in the key-insulated model— for intrusion-resilient schemes this security is preserved even if both signer and base are compromised, as long as the compromises are not simultaneous. In the case of simultaneous compromise, the security of past (but not the future) periods is preserved — this is the best that can be achieved. To achieve such security, SiBIR model, much as proactive schemes [OY91,HJJ+ 97], provides a refresh mechanism: base changes its key and sends a refresh message to the signer, which uses it to refresh its key as well. This can be done at arbitrary times and as many times as desired (unlike update, which is done only at the pre-arranged times, and typically has a limit on the total number of updates); refresh is transparent to the verifier (in contrast, update changes the time period number and is therefore visible to the verifier). Refresh prevents the attacker from learning anything by breaking into the base. Specifically, learning the base secrets at arbitrary times by itself does not help attacker in any way. Only if the attacker compromises both signer and base simultaneously, does she learn all the system’s secrets and can therefore generate — just as the system itself — valid signatures for all the future periods. But if the attacker misses at least one refresh message between the compromising of the base and signer secrets, then compromising the base does not add anything useful to her knowledge Thus, SiBIR model minimizes the impact of the key compromises, which explains the Intrusion-Resilient part of its name.
104
Gene Itkis
Previous Scheme. The only currently known SiBIR signature scheme, called SiBIR1 [IR02], builds on the techniques from [IR01]. SiBIR1 is closely based on a specific ordinary signature scheme of Guillou-Quisquater [GQ88], and as such requires random oracle and specific number-theoretic complexity assumptions (including a version of the strong RSA assumption). Though no attacks are known, SiBIR1 is proven in [IR02] to be secure only against partially restricted adversaries (partially adaptive or partially synchronous)1 . SiBIR1 signing and verifying costs are exactly the same as in [IR01], which are essentially the same as for the underlying ordinary Guillou-Quisquater signatures: two exponentiations with short (typically, 128-160 bits) exponents. SiBIR1 requires O(T ) modular exponentiations per update and a single modular multiplication per refresh, both for the signer and for the base. Both the signer and the base each store only two secret values (similar to GQ secret keys). New Results. We present a new SiBIR signature construction. This scheme is generic: it requires only a one-way function and an ordinary signature scheme — both can be given as black-boxes2 . In particular, it does not require a random oracle. Due to generic nature of our new scheme, we call it gSiBIR. We also prove gSiBIR to be secure against fully-adaptive adversary. Finally, while the previous SiBIR scheme requires the total number of periods T to be pre-set at the key-generation stage, our scheme can be easily adjusted to support unbounded number of periods. Our construction achieving this feature is of independent interest. It draws on the tree-based forward-secure constructions of [BM99,MMM02], and our technique of removing the bound on T can be applied back to [MMM02,BM99] to yield modest improvement3 . In fact, our mechanism can be presented as a generalization of these previous methods: casting them explicitly as using self-delimiting encodings4 . Once the use of the self-delimiting encodings is explicit, it is easy to find more efficient encodings.
2
Intrusion-Resilient Security Model
The definitions in this section are from [IR02] and are included here for selfcontainment. 1
2
3
4
A modification of SiBIR1, provably secure against the strongest —fully adaptive— adversary, has being obtained by the author and will be published separately. We also use a cryptographic hash function and a one-time signature scheme: both can be efficiently constructed from the given one-way function, e.g., using [NY89] for hash function and [Lam79,Mer89] for the one-time signatures. The previous method of removing the bound did not really remove it completely. Instead, it allowed the bound to be so large that reaching it would conflict with the security parameters of the scheme. In contrast, our method makes the number of periods really unbounded by anything, including security parameters. As a result, in our method, it is in principle possible to change the security parameters “on the fly”. The self-delimiting encodings are an important and well-known concept, playing an important role, in particular, in Kolmogorov Complexity [Lev73,Lev74,LV93], and in some scheduling issues, e.g., in [IL89].
Generic Intrusion-Resilient Signatures
2.1
105
Functional Definition
We first define the functionality of the system components; security definition is given in the subsequent subsection. The system’s secret keys may be modified in two different ways, called update and refresh. Updates change the secrets from one time period to the next (e.g. from one day to the next), changing also the period number in the signatures. In contrast, refreshes affect only the internal secrets and messages of the system, and are transparent to the verifier. Thus, we use notation SK t.r for secret key SK , where t is the time period (the number of times the key has been updated) and r is the “refresh number” (the number of times the key has been refreshed since the last update). We say t.r = t .r when t = t and r = r . Similarly, we say t.r < t .r when either t < t or t = t and r < r . We follow the convention of [BM99], requiring a key update immediately after key generation: to obtain the keys for t = 1 (this is done merely for notational convenience, in order to make the number of time periods T equal to the number of updates, and need not affect the efficiency of an actual implementation). Similarly, we require a key refresh immediately after key update: to obtain keys for r = 1 (this is also done for convenience, and need not affect efficiency of an actual implementation; in particular, the update and refresh information sent by the base to the signer can be combined into a single message). Definition 1. Signer-Base key-evolving signature scheme is a septuple of probabilistic polynomial-time algorithms (Gen, Sign, Ver ; US, UB; RB, RS) 5 : 1. Gen, the key generation algorithm. In: security parameter(s) (in unary), the total number T of time periods Out: initial signer key SKS 0.0 , initial home base key SKB 0.0 , and the public key PK . 2. Sign, the signing algorithm. In: current signer key SKS t.r , message m Out: signature (t, sig) on m for time period t 3. Ver , the verifying algorithm In: message m, signature (t, sig) and public key PK Out: “valid” or “invalid” (as usual, signatures generated by Sign must verify as “valid”) 4. UB, the base key update algorithm In: current base key SKB t.r Out: new base key SKB (t+1).0 and the key update message SKU t 5. US, the signer update algorithm In: current signer secret key SKS t.r and the key update message SKU t Out: new signer secret key SKS (t+1).0 5
Intuitively (and quite roughly), the first three correspond to the ordinary signatures; the first four correspond to forward-secure ones, the first five (with some restrictions) correspond to key-insulated ones; and all seven are needed to provide the full power of the intrusion-resilient signatures.
106
Gene Itkis
6. RB, the base key refresh algorithm In: current base key SKB t.r Out: new base key SKB t.(r+1) and the corresponding key refresh message SKR t.r 7. RS, the signer refresh algorithm In: current signer key SKS t.r and the key refresh message SKR t.r Out: new signer key SKS t.(r+1) (corresponding to the base key SKB t.(r+1) ) 2.2
Security Definition
In order to formalize security, we need a notation for the number of refreshes in each period: Let RN (t) denote the number of times the keys are refreshed in the period t: i.e., there will be RN (t)+1 instances of signer and base keys. Recall that each update is immediately followed by a refresh; thus, keys with refresh index 0 are never actually used. RN is used only for notational convenience: it need not be known; security is defined below in terms of RN (among other parameters). Now, consider all the keys generated during the entire run of the signature scheme. They can be generated by the following “thought experiment” (we do not need to actually run it — it is used just for definitions). Experiment Generate-Keys(k, T, RN ) t ← 0; r ← 0 (SKS t.r , SKB t.r , PK ) ← Gen(1k , T ) for t = 1 to T (SKB t.0 , SKU t−1 ) ← UB(SKB (t−1).r ) SKS t.0 ← US(SKS (t−1).r , SKU t−1 ) for r = 1 to RN (t) (SKB t.r , SKR t.(r−1) ) ← RB(SKB t.(r−1) ) SKS t.r ← RS(SKS t.(r−1) , SKR t.(r−1) ) Let SKS ∗ , SKB ∗ , SKU ∗ and SKR ∗ be the sets consisting of, respectively, signer and base keys and update and refresh messages, generated during the above experiment. We want these sets to contain all the secrets that can be directly stolen (as opposed to computed) by the adversary. Thus, we omit from these sets the keys SKS t.0 , SKB t.0 for 0 ≤ t ≤ T , SKU 0 and SKR 1.0 , which are never actually stored or sent (because key generation is immediately followed by update, and each update is immediately followed by refresh). Note that SKR t.0 for t > 1 is used (it is sent together with SKU t−1 to the signer), and thus is included into SKR ∗ . To define security, let F , the adversary (or “forger”), be a probabilistic polynomial-time oracle Turing machine with the following oracles: – Osig, the signing oracle (constructed using SKS ∗ ), which on input (m, t, r) (1 ≤ t ≤ T , 1 ≤ r ≤ RN (t)) outputs Sign(SKS t.r , m)
Generic Intrusion-Resilient Signatures
107
– Osec, the key exposure oracle (based on the sets SKS ∗ , SKB ∗ , SKU ∗ and SKR ∗ ), which 1. on input (“s”, t.r) for 1 ≤ t ≤ T, 1 ≤ r ≤ RN (t) outputs SKS t.r ; 2. on input (“b”, t.r) for 1 ≤ t ≤ T, 1 ≤ r ≤ RN (t) outputs SKB t.r ; 3. on input (“u”, t) for 1 ≤ t ≤ T − 1 outputs SKU t and SKR t+1 .0; and 4. on input (“r”, t.r) for 1 ≤ t ≤ T, 1 ≤ r < RN (t), outputs SKR t.r . Queries to Osec oracle correspond to intrusions, resulting in the corresponding secrets exposures. Exposure of an update key SKU t−1 automatically exposes the subsequent refresh key SKR t.0 , because they are sent together in one message. Adversary’s queries to Osig and Osec must have the t.r values within the appropriate bounds. It may be reasonable to require the adversary to “respect erasures” and prohibit a value that should have been erased from being queried (or used for signature computation). However, this restriction is optional, and in fact we do not require it here. Note, that respecting erasures is local to signer and base and is different from requiring any kind of global synchronization. For any set of valid key exposure queries Q, time period t ≥ 1 and refresh number r, 1 ≤ r ≤ RN (t), we say that key SKS t.r is Q-exposed : [directly] if (“s”, t.r) ∈ Q; or [via refresh] if r > 1, (“r”, t.(r−1)) ∈ Q, and SKS t.(r−1) is Q-exposed; or [via update] if r = 1, (“u”, t−1) ∈ Q, and SKS (t−1).RN (t−1) is Q-exposed. Replacing SKS with SKB throughout the above definition yields the definition of base key exposure (or more precisely, of SKB t.r being Q-exposed ). Both definitions are recursive, with direct exposure as the base case. Clearly, exposure of a signer key SKS t.r for the given t and any r enables the adversary to generate legal signatures for this period t. Similarly, simultaneous exposure of both base and signer keys (SKB t.r , SKS t.r , for some t, r) allows the adversary to run the algorithms of definition 1 to generate valid signatures for any messages for all later periods t ≥ t. Thus, we say that the scheme is (t, Q)-compromised, if either – SKS t.r is Q-exposed for some r, 1 ≤ r ≤ RN (t); or – SKS t .r and SKB t .r are both Q-exposed for some t < t. In other words, a particular time period has been rendered insecure if either the signer was broken into during that time period, or, during a previous time period, the signer and the base were compromised without a refresh in between. Note that update and refresh messages by themselves do not help the adversary in our model—they only help when combined, in unbroken chains, with signer or base keys6 . If the scheme is (j, Q)-compromised, then clearly adversary, pos6
Interestingly, and perhaps counter-intuitively, a secret that has not been exposed might still be deduced by adversary. For example, it may be possible in some implementations to compute SKB t.r from SKB t.r+1 and SKR t.r (similarly for update and for the signer). The only case we cannot allow —in order to stay consistent with our definition— is that of adversary computing SKS t.r without Q-exposing some SKS t.r . So, it may be possible to compute SKS t.r from SKS t.r+1 and SKR t.r , but not from SKS t+1.0 and SKU t.r (even if r = RN (t)).
108
Gene Itkis
sessing the secrets returned by Osec in response to queries in Q, can generate signatures for the period t. The following experiment captures adversary’s functionality. Intuitively, adversary succeeds if she generates a valid signature without “cheating”: not obtaining this signature from Osig, asking only legal queries (e.g. no out of bounds queries), and not compromising the scheme for the given time period. We call this adversary (fully) adaptive because she is allowed to decide which keys and signatures to query based on previous answers she receives. Experiment Run-Adaptive-Adversary(F, k, T, RN ) Generate-Keys(k, T, RN ) (m, j, sig) ← F Osig,Osec (1k , T, PK , RN ) Let Q be the set of key exposure queries F made to Osec; if Ver (m, j, sig) =“invalid” or (m, j) was queried by F to Osig or there was an illegal query or the scheme is (j, Q)-compromised then return 0 else return 1 We now define security for the intrusion resilient signature schemes. Definition 2. Let SiBIR[k, T, RN ] be a signer-base key-evolving scheme with security parameter k, number of time periods T , and table RN of T refresh numbers. For adversary F , define adversary success function as SuccSiBIR (F, SiBIR[k, T, RN ]) = Pr[Run-Adaptive-Adversary(F, k, T, RN ) = 1] def
Let insecurity InSecIR−fa (SiBIR[k, T, RN ], τ, qsig ) be the maximum of SuccSiBIR (F, SiBIR[k, T, RN ]) over all fully adaptive adversaries F that run in time at most τ and ask at most qsig signature queries. Finally, SiBIR[k, T, RN ] is (τ, , qsig )-intrusion-resilient if InSecIR−fa (SiBIR[k, T, RN ], τ, qsig ) < . Although the notion of (j, Q)-compromise depends only the set Q, it is important how Q is generated by the adversary. Allowing the adversary to decide her queries based on previous answers gives her potentially more power. Our scheme is the first SiBIR scheme shown to be secure against such a fully adaptive adversary.
3
Intrusion-Resilient Scheme: Generic Construction
Our scheme, gSiBIR, builds on the generic forward-secure signatures techniques of [BM99,MMM02]. In fact, it can be viewed as an intrusion-resilient implementation of their tree-based forward-secure constructions (T-schemes, in terminology of [MMM02]). However, since intrusion-resilient model is more complex, and exacts stronger security requirements, such an implementation is not trivial.
Generic Intrusion-Resilient Signatures
109
At an intuitive level, all these tree-based schemes (including ours), construct a certificate hierarchy, where the root is included in the public key of the main scheme, and the leaves are the public keys of the underlying ordinary signature scheme, used for the individual time periods. As in all certificate hierarchies, authentication must include all the certificates in the certification path7 . Such a certificate hierarchy is (re-)constructed, as time evolves. The challenge for intrusion-resilience is that the information, enabling further (re-)construction of the hierarchy, must be stored and used in such a way that adversary cannot subvert it in order to extend the hierarchy beyond the periods of her control, or to learn any secret keys for any additional time periods (even if she fully controlled both modules, just not at the same times). Our scheme uses any ordinary signature scheme, denoted as Σ. An instance of Σ is denoted as S; the corresponding public and secret keys are S.PK , S.SK , respectively. Each time period t uses a separate instance S t of Σ. Σ signatures are used only in the leaves, to sign actual messages. For certification, gSiBIR uses specific one-time signature mechanisms8 . We adjust these mechanisms to address the above mentioned challenge: to prevent adversary from extending the hierarchy beyond the compromised periods. In the simplest case, we base our certification mechanism on Diffie-Lamport one-time signatures [Lam79,Mer89] (which require only any one-way function, given as a black-box). For each internal node of the certification hierarchy, the secret keys corresponding to this node are used to sign only the (hashed) public keys of its children nodes. Denote an instance of the certification mechanism as C, and the corresponding public and private keys as C.PK , C.SK , respectively. 3.1
Bounded T Schemes
First, we consider the case when the total number of periods T is pre-set a priori (in section 3.2 we generalize it to the unbounded number of periods). Wlog, let T be an exact power of 2. Trees, Labels, Keys and Signatures Trees. Consider a complete balanced binary tree with T leaves. Let each leaf correspond to a time period; the periods t are arranged in increasing order from left to right from 0 to T − 1. 7
8
As observed by [Kra00] for forward-secure signatures, this certification can be optimized using the standard Merkle tree construction [Mer89]. Unfortunately, this optimization appears hard to realize in the intrusion-resilient model. It was observed in [Mer87] for standard, and in [AR00] for the forward-secure schemes that use similar certificates (such as [BM99,MMM02]), that each certifying public key, is used only for authenticating a single message — the corresponding certificate of the children’s public keys, and thus one-time signatures are sufficient for this purpose. In our scheme, however, the specific one-time signature (or similar) mechanisms are deeply integrated with rest of the scheme to assure intrusion resilience, and not just forward security.
110
Gene Itkis
Labels. Label each node with a string representing its path from the root (denoting left edge with 0 and right with 1). Then, all nodes in a subtree of some v contain v as prefix (and vice versa: all nodes with prefix v are in v’s subtree). The root is labeled with the empty string λ, and each leaf has full lg T bits in its label t, padded with leading 0s, if needed. Right Path. For a node v define the right path of v to be the set ρ(v) of the right children of the nodes on the path from v to the root. All nodes on the right path of a node v can be obtained by replacing one of the 0s in the v’s label with 1 and truncating the label to the right of it. So, there are ≤ lg T nodes in any right path (equality is achieved only for the leftmost node: 00...0). For example, a node labeled 0101010 has the following nodes as its right path: {1, 011, 01011, 0101011}. Define right path successor ρ+ (v) to be the longest element of ρ(v). In the above example ρ+ (0101010) = 0101011; as another example, ρ+ (1010111) = 1011. Keys. As in the case of forward-secure schemes of [BM99,MMM02], associated with each period t is an instance S t of the underlying ordinary signature scheme Σ. The keys S t .PK , S t .SK for period t are generated during the update preceding the period t, and destroyed during the following update. All signatures during the period t are signed using S t . In addition, with each node v we associate an instance C v of a one-time signature scheme similar to [Lam79,Mer89] (we’ll specify details later, but for now the differences with [Lam79,Mer89] can be ignored). The C λ .PK is the root public key gSiBIR.PK . Generating and Sharing. All the values we will be discussing below are generated and stored at base and signer. Here we introduce the notation for denoting the origin and location of the values: A value X is denoted as X (b) if it was generated at the base, and X (s) if generated at the signer. In our construction we actively utilize secret sharing (we use the simple XOR sharing). Thus, for a value X, b[X] denotes its share stored at the base, and s[X] its share stored at the signer. Then, b[X] ⊕ s[X] = X. Note: b[X (s) ] can be computed at the base independently, and even before generation of X (s) at the signer: in this case, when signer generates X (s) , it can use b[X (s) ] to compute s[X (s) ] = X (s) ⊕ b[X (s) ]. Then the signer deletes both X (s) and b[X (s) ] — this results in generating and sharing X (s) between the base and signer, without violating the one-directional communication restriction of our model. Signatures. Each gSiBIR signature during period t consists of the S t signature, plus the certification path of S t .PK . The certification path consists of the C signatures, each parent in the tree certifying its children; C λ .PK is the root certification authority’s public key and is thus the whole scheme’s public key. Key Management. At time t, gSiBIR maintains S t .SK in the signer, and all C v∈ρ(t) .SK values distributed between signer and base (i.e., s[C v .SK ], b[C v .SK ] respectively). In addition, the signer stores both the public key S t .PK and its certification path. The details of update procedure will be discussed below.
Generic Intrusion-Resilient Signatures
111
Certification Mechanism. gSiBIR uses certification, just as [BM99,MMM02], to allow keys for future periods to be generated at later times as needed, but still be tied in to the root — the scheme’s public key. However, in the case of forward security, these future-enabling certification keys are not considered a security risk at break-ins: forward-secure schemes protect only the past keys, while the keys obtained at a break-in can, by design and necessity, generate all future periods’ signatures. This is not the case for intrusion-resilient schemes. Here, a break-in of any one module must not expose any secret keys useful outside the current period. So, a natural solution is to distribute the secret keys, which will be used in the future, between the signer and base (using proactively secure secret sharing). This protects the future keys from break-ins. However the problem remains: how to use these certification keys without compromising not only the next period (which requires the use of such a key) but also all other future periods that may rely on the same certification keys? We solve this problem by making sure that the certification keys can be reconstructed from the shares in such a way that the reconstructed (partial) secret key is good only for certifying the proper child certificates. The onetime signatures of [Lam79,Mer89] (reviewed below) provide a simple certification mechanism allowing just such a “targeted” reconstruction. Still, even this is not enough: the above requires each secret key to be generated in only one of the modules (computing public key requires evaluating the one-way function on the secret key9 ). This makes the secret key vulnerable to exposure by a break-in into single module. To address this issue, we use two similar mechanisms C (b) , C (s) : one using keys originally generated at the base (and then shared with the signer); and the other generating its secret keys at the signer (these too are shared upon generation between the signer and the base, as outlined above). The secrets for C (b) , C (s) are generated simultaneously at the base and the signer respectively. As a result, to subvert the certification mechanism, both signer and base must be simultaneously compromised by the adversary: to either collect all shares of the certification secrets or to expose them immediately at creation, before they are shared. But such a simultaneous exposure forfeits the security of all the future signatures anyways (again by design and necessity). So, our security goal is achieved. One-Time Signatures. C, signing k bits, randomly generates its secret key C.SK = x : xi.β |0 ≤ i ≤ k − 1; β = 0, 1. The public key is then computed as C.PK = y : yi.β = f (xi.β )|0 ≤ i ≤ k − 1; β = 0, 1. The signature for message m = m0 m1 . . . mk−1 is then σ : σi = xi.mi . It is verified by checking that f (σi ) = yi.mi for all 0 ≤ i ≤ k − 1. Forging such a signature is equivalent to 9
In principle, it might be possible generate the secrets distributively and customize the general two party function evaluation [Yao82] (and other general secure multiparty computation methods) to suit our model and purpose. But we do not explore this direction, as our goal is much more restricted and we seek much more efficient solutions.
112
Gene Itkis
inverting f for one of the 2k public values yi.β . For convenience, we occasionally denote the above signature σ of m as σ = C.SK (m). Generating, Sharing and Refreshing C-Secrets. Putting together the above methods we achieve sharing and reconstructing of C secret keys, satisfying the requirements of our model: For a node v in the certification tree, when C v must be created, the base gen(b) (s) (b) erates at random C (b) v .SK , b[C v .SK ], and b[C v .SK ]; computes C v .PK from (s) (b) (b) (b) C (b) v .SK ; sends to the signer b[C v .SK ] and s[C v .SK ] = C v .SK ⊕ b[C v .SK ]. (b) The secret C v .SK (it was only present at the base) and local copy of s[C (b) v .SK ] are then destroyed. At the same time, the signer, similarly, generates at random C (s) v .SK ; com(s) (s) (s) putes from it C (s) .PK and s[C .SK ] = C .SK ⊕ b[C .SK ] and destroys v v v v (s) C v .SK . (b) (s) Now, for node v the base has only C (b) v .PK , b[C v .SK ] and b[C v .SK ]; simi(s) (b) (s) larly, the signer has C v .PK , s[C v .SK ] and s[C v .SK ]. To refresh any of the secrets SK , the base generates a random value r, changes its share b[SK ] ← b[SK ]⊕r, and sends r to the signer. Upon receiving r the signer changes his of SK : s[SK ] ← s[SK ] ⊕ r. The r is destroyed at both immediately upon completion of the above local operations. Key Certification and Pro-certification. The public key C (b) v .PK and (b) (s) (∗) .PK will each be used for certification C .SK (h(C .PK )||h(C C (s) v v v0 v0 .PK )|| (b) (s) (b) (s) (b) (s) h(C v1 .PK )||h(C v1 .PK )) of C v0 .PK , C v0 .PK , C v1 .PK , and C v1 .PK , whenever these are generated. Since all the public keys are of the same length and are used to sign a much shorter string, we use the standard technique of compressing the keys being certified with a cryptographic hash function10 h. In our case, we compress each of the keys to be signed separately. Thus to each public key of a child corresponds a portion of the public (and thus secret) key of the parent. When a child’s public key is generated, only a half of the parent’s corresponding key portion is required for the certification. Thus the shares of that portion’s half, which are not needed for the certification, can be destroyed — doing this also guarantees that at a later time no other public key can be certified. Specifically, as soon as C (b) v .PK is generated at the base (as described above), the base destroys its shares not needed for the certification of (b)
(b) C (b) v .PK : namely, the bases securely erases b[C par(v) .SK (. . . h(C v .PK ) . . .)] (s)
and b[C par(v) .SK (. . . h(C (b) v .PK ) . . .)]. The base keeps the remaining shares (b)
(s)
(b) b[C par(v) .SK (. . . h(C (b) v .PK ) . . .)], and b[C par(v) .SK (. . . h(C v .PK ) . . .)] to be used at a later time for the certification. (b) The signer similarly destroys s[C par(v) .SK (. . . h(C (s) and v .PK ) . . .)] (s)
(b)
(s) s[C par(v) .SK (. . . h(C (s) v .PK ) . . .)], and keeps s[C par(v) .SK (. . . h(C v .PK ) . . .)] (s)
and s[C par(v) .SK (. . . h(C (s) v .PK ) . . .)]. 10
Such cryptographic hash functions can be constructed from any one-way functions, e.g., using the classical construction of [NY89].
Generic Intrusion-Resilient Signatures
113
Note, that after the above is done, no key C.PK , such that h(C.PK ) = (s) h(C (s) v .PK ), can be certified in place of C v .PK , even after the total and simultaneous exposure of all the secrets of both the signer and the base. Similarly, for C (b) v .PK . In order to be able to perform such a certification, the signer needs (b) (s) to either obtain both C par(v) .SK and C par(v) .SK when these are created, or obtain their shares at the same time — in both cases this requires a simultaneous exposure of the signer and the base. We say, that these keys are now pro-certified. Updates and Refreshes. The update for period t securely erases S t .SK in the signer and initiates updating the right path successor v = ρ+ (t) of t: UpdateNode(v). Prior to UpdateNode(v), no keys for any nodes in the subtree of v had existed. For v itself, signer already contains C v .PK and its certification path; and C v .SK is shared between signer and base, for both C (b) , C (s) (i.e., signer (s) (b) (s) already contains s[C (b) v .SK ], s[C v .SK ] and base has b[C v .SK ], b[C v .SK ]). UpdateNode(v) generates, shares, and pro-certifies the keys as described above the children of v and all its left descendents: i.e. nodes of the form v0∗ , up to length lg T (the longest of these is t+1). For the leaf t + 1, its certification path is reconstructed from the shares (no internal nodes’ keys can be modified in this path due to pro-certification): the base sends its shares to the signer, which does the reconstruction. The base also sends b[C t+1 .SK ] to the signer, and the signer generates S t+1 and uses C t+1 .SK to certify its public key. The outline of the node update is as follows: UpdateNode(v) if |v| < |T | then % if not at the leaf yet (b) (b) in Base: C v0 .(PK , SK ) ← C.Gen; C v1 .(PK , SK ) ← C.Gen; (b) (b) (s) (s) Randomly generate b[C v0 .SK ], b[C v1 .SK ], b[C v0 .SK ], b[C v1 .SK ] ; (b) (b) (b) Set s[C v0 .SK ] ← C v0 .SK ⊕ b[C v0 .SK ], (b) (b) (b) s[C v1 .SK ] ← C v1 .SK ⊕ b[C v1 .SK ]; (b) (b) Securely erase C v0 .SK , C v1 .SK , (b)
(b)
b[C (∗) v .SK (h(C v0 .PK ) . . . h(C v1 .PK ) . . .)]; (b) (s) (s) Base send to Signer: C v{0,1} .PK ; b[C v0 .SK ], b[C v1 .SK ], (b)
(b)
s[C v0 .SK ], s[C v1 .SK ]; (s)
(s)
in Signer: C v0 .(PK , SK ) ← C.Gen; C v1 .(PK , SK ) ← C.Gen; (s) (s) (s) Set s[C v0 .SK ] ← C v0 .SK ⊕ b[C v0 .SK ], (s) (s) (s) s[C v1 .SK ] ← C v1 .SK ⊕ b[C v1 .SK ]; (b) (b) Store s[C v0 .SK ], s[C v1 .SK ]; (s) (s) (s) (s) Securely erase C v0 .SK , C v1 .SK , b[C v0 .SK ], b[C v1 .SK ], (s)
(s)
s[C (∗) v .SK (. . . h(C v0 .PK ) . . . h(C v1 .PK ))]; else % if at the leaf Base send to Signer: shares of the certification path from v to the root (i.e. remaining shares of C (s,b) .SK for all prefixes w of v) w % no C.PK outside this path can be certified by the recoverable secrets
114
Gene Itkis
in Signer: securely erase S t .SK ; S t+1 .(SK , PK ) ← S.Gen; recover (from the available shares) the certification path of S t+1 .PK algorithm gSiBIR.Gen(l, T ) Generate C λ .(SK , PK ) ← C.Gen(l); PK ← (C λ .PK , T ) Share C λ .SK between signer and base; UpdateNode(λ); % SKS 0 now contains the certification path for S 0 .PK % and all C v .PK , for ∀v ∈ ρ(0lg T ) % Also, SKS 0 , SKB 0 contain corresponding shares % of C v .SK , for ∀v ∈ ρ(0lg T ) return (SKS 0 , SKB 0 , PK ) Fig. 1. Key generation algorithm. Refresh index on the keys is omitted to simplify notation algorithm gSiBIR.Sign(M, SK t ) return (σ = S t .Sign(M ), t, S t .PK , ψt = certification path of S t .PK ) algorithm gSiBIR.Ver (M, PK , (σ, t, PK , ψ)) return Σ.Ver (M, PK ) (ψ is a correct certification path t of PK )
Fig. 2. Signing and verifying algorithms
Refreshes are straight-forward: the base generates a random value Rt.r for each secret SK t.r whose share it is currently holding, xor’s those random values with the corresponding secrets to obtain the new secret values SK t.(r+1) ← SK t.r ⊕ Rt.r , and sends all the Rt.r to the signer (who refreshes his secret keys the same way). Proof Sketch. The idea of the proof is to force the adversary to either forge a new signature for some S t used by the simulator, or to diverge from the simulator’s certification tree, resulting in adversary inverting a one way function used for the certification. In either case, the simulator must guess where adversary success will take place. The case of adversary forging a signature for some S t is straight-forward. Suppose the adversary diverges from the simulator’s certification tree at node v (meaning that the C v .PK used by adversary is not equal C v .PK of the simulator, while for the parent w of v both adversary and simulator use the same value C w .PK ). Then in order to certify C v .PK the adversary (s) must find inverses of some values in C (b) w .PK and C w .PK . The adversary can find one of these from the simulator, by exposing the appropriate keys. But in order to find from the simulator both, the adversary would require a simultaneous compromise (which would eliminate adversary’s success). Without such a compromise, the simulator can simulate the queries for one of these inverses
Generic Intrusion-Resilient Signatures
115
(randomly guessed by the simulator), thus forcing the adversary to invert the corresponding one-way function. 3.2
Unbounded T Scheme
Now, we extend the above scheme to the case where no bound on the number of periods is preset. Prefixless Notation. The main idea is that instead of using the binary representation of t as the path to the proper leaf in the tree, we use t˜ which is a monotone prefixless (or self-delimiting) encoding of t: for no two strings t, t the encoding of one is a prefix of the encoding of the other: t˜ = t˜ {0, 1}∗ . Setting the length of all strings to have the same length is one way to guarantee prefixlessness, albeit only for a finite set of strings. This is indeed the way the prefixless property is assured in [BM99] and the above construction. Other prefixless encodings abound. The simplest one handling infinite sets of inputs is probably to view each string t as an integer represented in unary (using only 1s), and delimited with a single 0: t˜ = 1t 0. Of course, such an encoding is very inefficient: |t˜| = 2t . However, a simple bootstrapping strategy can make it much more efficient: t˜ can consist of the length |t| of t, encoded in a prefixless notation, followed by t itself. In this case |t˜| = 2|t| = 2 lg t. Iterating this one more time we can get a prefixless encoding for which |t˜| = lg t+2 lg lg t = (1+o(1)) lg t. For practical purposes, it probably makes sense to stop here, though further iteration may yield better asymptotics (e.g. iterating lg∗ t times, we can get ∗ |t˜| = lg t + lg lg t + ... + lglg t t + lg∗ t). Another approach to achieve prefixless encoding, (instead of using unary notation at the base step) can represent each bit as two bits, 0 as 00, 1 as 01, and use 11 to mark the end of the string. Clearly this encoding can be easily improved by encoding t in ternary and using 10 to represent the ternary digit 2. Then |t˜| = 2 log3 t < 1.6 lg t. Further reductions are possible: essentially, for any monotone function f such that 1/f ≤ 1 it is possible to achieve an encoding such that t˜ ≤ f (t). In particular, for any > 0 there exists a prefixless encoding such that |t˜| ≤ (1 + ) lg t + O(1). These methods can also be used in the same bootstrapping strategy. Future-Enabling Keys. Representing the leaves in a prefixless notation helps only in part. In addition, at any time we need to maintain (distributively) some future-enabling key, which are used to extend the certification hierarchy to the future time periods. In the fixed T scheme above, at time t these are the secret keys corresponding to the nodes of the right path ρ(t). Using a generic prefixless encoding, e.g. as the second one in the paragraphs above, may not provide us with a small future-enabling key set. The first encoding scheme, using unary encoding as the base for bootstrapping, however, does this very well. In fact, just as before, the same right path for it provides exactly the desired future-enabling key set. And the number of nodes in the right path |ρ(t˜)| = (1 + o(1)) lg t, i.e. increases only marginally compared to the fixed T scheme above (much less than by a factor of 2 — or by additive o(lg t) nodes,
116
Gene Itkis
more precisely). At the same time, the early periods t : (1 + o(1)) lg t < lg T ) (i.e. t : t1+o(1) < T ) would actually even benefit from using the unbounded T scheme, compared to the fixed T scheme above. Other methods for constructing prefixless encodings with small right path sets exist as well. The two level construction in [MMM02] can be viewed as such. It is somewhat in between the unbounded and fixed T approaches: it uses fixed string length to achieve prefixlessness of the length of t (listed in logarithmic scale). As such, it still handles only bounded T , though the bound can easily be arranged to include all T that might be even remotely realistic in our universe (or match the security parameter requirements). Indeed, from the practical point it achieves a good compromise and offers good performance. Still, our methods can achieve almost a factor of two improvement in some cases. For example, for t = 300, using [MMM02] construction, |t˜| = 21, while using methods such as above, we can easily achieve |t˜| = 13 bits11 (the cost for [MMM02] method depends on the upper bound on T in the [MMM02], which the authors proposed to be T ≈ 2128 ; we use a more favorable limit of ≈ 232 — the next smaller T would be 216 , which seems a bit too low for at least some cases; using the higher bound of T ≈ 2128 would increase |t˜| by additional 2 bits for all t in the [MMM02] constructions). Finding other prefixless encodings which would keep the future-enabling key set small is a possible future research direction. 3.3
Optimizations
There are a number of improvements one can achieve for the above scheme. For example, for reasons of its simplicity, we have used the original Diffie-Lamport one-time signature scheme which requires 2k secrets (and as long a public key) to sign k bits. An obvious improvement to the scheme is to use more efficient one-time signature schemes such as the Merkle scheme [Mer89] requiring k + lg k + 1 values. Other even more efficient schemes are also possible but they may 11
The prefixless encoding we use in these calculations encodes t as: t in binary with the leading bit dropped (it’s always 1 anyways); prefixed by the length of t minus 1 (for the dropped bit), and with its leading bit dropped as well; that prefixed with the length of the previous segment, again with the leading bit dropped; and finally that all is prefixed with the length of the previous segment, but this time in unary, terminated with 0, and again the leading 1 dropped. So, t = 300 is encoded as 10 11 1000 100101100, with the dropped 1s crossed out, but kept for clarity. Other comparisons with [MMM02]: For t in approximately 65,000–109 (i.e. up to a billion) range using [MMM02] gives |t˜| = 37 bits for all t vs. 20-37 bits using our method (with the smaller t˜ using 20 bits and the encoding length increasing as t grows — approximately 1 bit per doubling of t). At the smaller end, for t in the approximate range of 25-250, [MMM02] construction results in |t˜| being 13 for all of them, while our construcitons would give 8 for t in 16-31 range; 9 for 32-63; 10 for 64-127; and 11 for 128-255. In comparing these bits two considerations should be kept in mind: on the one hand, each bit in the discussion above results in one extra C signature and/or key in our gSiBIR costs; on the other hand, it may be possible to take a bit or a couple off either encoding by further fine-tuning of the corresponding methods.
Generic Intrusion-Resilient Signatures
117
involve some trade-offs between computation and signature/key sizes (e.g. the Winternitz modification, also described in [Mer89]) and/or may conflict with pro-certification. It is also easy to significantly reduce the size of the secret keys — since C.SK are just random values, they can be replaced with pseudo-random ones (using a seed per node, so they can be deleted easily; or use some alternative techniques, e.g. based on storing the right path of the classic pseudo-random function tree [GGM86]). But this technique can easily be applied only to C (s) .SK ; for C (b) .SK it conflicts with the pro-certification. Other optimizations are less obvious: it may be possible to reuse some of the keys by using some collusion-resilience, set-cover, and/or frameproof codes techniques. Finally, it may be possible to apply the Merkle certification tree, just as in [MMM02], but without loosing the intrusion-resilience.
Acknowledgments The author thanks Leo Reyzin and Jonathan Katz for very helpful discussions.
References And97.
Ross Anderson. Invited lecture. Fourth Annual Conference on Computer and Communications Security, ACM (see http://www.ftp.cl.cam.ac.uk/ ftp/users/rja14/forwardsecure.pdf), 1997. AR00. Michel Abdalla and Leonid Reyzin. A new forward-secure digital signature scheme. In Tatsuaki Okamoto, editor, Advances in Cryptology– ASIACRYPT 2000, volume 1976 of Lecture Notes in Computer Science, pages 116–129, Kyoto, Japan, 3–7 December 2000. Springer-Verlag. Full version available from the Cryptology ePrint Archive, record 2000/002, http://eprint.iacr.org/. BM99. Mihir Bellare and Sara Miner. A forward-secure digital signature scheme. In Michael Wiener, editor, Advances in Cryptology–CRYPTO ’99, volume 1666 of Lecture Notes in Computer Science, pages 431–448. Springer-Verlag, 15–19 August 1999. Revised version is available from http://www.cs.ucsd.edu/˜mihir/. DKXY02. Yevgeniy Dodis, Jonathan Katz, Shouhuai Xu, and Moti Yung. Keyinsulated public key cryptosystems. In Knudsen [Knu02]. GGM86. Oded Goldreich, Shafi Goldwasser, and Silvio Micali. How to construct random functions. Journal of the ACM, 33(4):792–807, October 1986. GQ88. Louis Claude Guillou and Jean-Jacques Quisquater. A “paradoxical” indentity-based signature scheme resulting from zero-knowledge. In Shafi Goldwasser, editor, Advances in Cryptology–CRYPTO ’88, volume 403 of Lecture Notes in Computer Science, pages 216–231. Springer-Verlag, 1990, 21–25 August 1988. HJJ+ 97. Amir Herzberg, Markus Jakobsson, Stanislaw Jarecki, Hugo Krawczyk, and Moti Yung. Proactive public key and signature systems. In Fourth ACM Conference on Computer and Communication Security, pages 100– 110. ACM, April 1–4 1997.
118
Gene Itkis
IL89.
IR01.
IR02.
Knu02. Kra00.
Lam79. Lev73.
Lev74.
LV93. Mer87.
Mer89.
MMM02.
NY89.
OY91.
Yao82.
G. Itkis and L. A. Levin. Power of fast VLSI models is insensitive to wires’ thinness. In 30th Annual Symposium on Foundations of Computer Science, pages 402–407, Research Triangle Park, North Carolina, 30 October–1 November 1989. IEEE. Gene Itkis and Leonid Reyzin. Forward-secure signatures with optimal signing and verifying. In Joe Kilian, editor, Advances in Cryptology–CRYPTO 2001, volume 2139 of Lecture Notes in Computer Science, pages 332–354. Springer-Verlag, 19–23 August 2001. Gene Itkis and Leonid Reyzin. Intrusion-resilient signatures, or towards obsoletion of certificate revocation. In Moti Yung, editor, Advances in Cryptology–CRYPTO 2002, Lecture Notes in Computer Science. SpringerVerlag, 18–22 August 2002. Available from http://eprint.iacr.org/2002/054/. Lars Knudsen, editor. Advances in Cryptology–EUROCRYPT 2002, Lecture Notes in Computer Science. Springer-Verlag, 28 April–2 May 2002. Hugo Krawczyk. Simple forward-secure signatures from any signature scheme. In Seventh ACM Conference on Computer and Communication Security. ACM, November 1–4 2000. Leslie Lamport. Constructing digital signatures from a one way function. Technical Report CSL-98, SRI International, October 1979. Leonid A. Levin. On the concept of a random sequence, in Russian). Doklady Akademii Nauk SSSR (Proceedings of National Academy of Science of USSR), 5(14):1413–1416, 1973. Leonid A. Levin. Laws of information conservation (non-growth) and aspects of the foundations of probability theory, in Russian). Problemy Peredachi Informatsii, 3(10):206–210, 1974. Ming Li and Paul Vit´ anyi. An Introduction to Kolmogorov Complexity and Its Applications. Springer-Verlag, 1993. Ralph C. Merkle. A digital signature based on a conventional encryption function. In Carl Pomerance, editor, Advances in Cryptology–CRYPTO ’87, volume 293 of Lecture Notes in Computer Science, pages 369–378. SpringerVerlag, 1988, 16–20 August 1987. Ralph C. Merkle. A certified digital signature. In G. Brassard, editor, Advances in Cryptology–CRYPTO ’89, volume 435 of Lecture Notes in Computer Science, pages 218–238. Springer-Verlag, 1990, 20–24 August 1989. Tal Malkin, Daniele Micciancio, and Sara Miner. Effcient generic forwardsecure signatures with an unbounded number of time periods. In Knudsen [Knu02]. Moni Naor and Moti Yung. Universal one-way hash functions and their cryptographic applications. In Proceedings of the Twenty First Annual ACM Symposium on Theory of Computing. (May 15–17 1989: Seattle, WA, USA), pages 33–43, New York, NY 10036, USA, 1989. ACM Press. Rafail Ostrovsky and Moti Yung. How to withstand mobile virus attacks. In 10-th Annual ACM Symp. on Principles of Distributed Computing, pages 51–59, 1991. A.C. Yao. Protocols for secure computations. In 23rd Annual Symposium on Foundations of Computer Science, pages 160–164, Chicago, Illinois, 3–5 November 1982. IEEE.
Abstract. Signer-Base Intrusion-Resilient (SiBIR) signature schemes were defined in [IR02]. In this model, as in the case of forward security, time is divided into predefined time periods (e.g., days); each signature includes the number of the time period in which it was generated; while the public key remains the same, the secret keys evolve with time. In addition, in SiBIR model, the user has two modules, signer and home base: the former generates all signatures on its own, and the latter is needed only to help update the signer’s key from one time period to the next. The main strength of the intrusion-resilient schemes, is that they remain secure even after arbitrarily many compromises of both modules, as long as the compromises are not simultaneous. Moreover, even if the intruder does compromise both modules simultaneously, she will still be unable to generate any signatures for the previous time periods (i.e., the forward security is guaranteed even in the case of simultaneous exposures). This paper provides the first generic implementation, called gSiBIR, of the intrusion-resilient signature schemes: it can be based on any ordinary signature scheme used as a black-box. gSiBIR is also the first SiBIR scheme secure against fully-adaptive adversary and does not require random oracle. Our construction does require one-way (and cryptographic hash) functions. Another contribution of this paper is a new mechanism extending treebased constructions such as gSiBIR and that of [BM99] to avoid the limit on the total number of periods (required by [IR02] and many forwardsecure ones). This mechanism is based on explicit use of prefixless (or selfdelimiting) encodings. Applied to the generic forward-secure singature constructions of [BM99,MMM02], it extends the first and yields modest but noticable improvements to the second. With this mechanism, gSiBIR becomes the first generic intrusion-resilient signature scheme with no limit on the number of periods.
1
Introduction
Key exposures appear to be inevitable. Limiting their negative impacts is extremely important. A number of approaches for dealing with this problem have S. Cimato et al. (Eds.): SCN 2002, LNCS 2576, pp. 102–118, 2003. c Springer-Verlag Berlin Heidelberg 2003
Generic Intrusion-Resilient Signatures
103
been explored; some of their benefits have recently been combined in the following new approach. Intrusion-Resilience. Signer-Base Intrusion-Resilient (SiBIR) security model, introduced in [IR02], combines some benefits of the previously proposed key-insulated [DKXY02], forward-secure [And97,BM99], and proactive [OY91,HJJ+ 97] security models. A detailed discussion of relationships among all these models is included in [IR02], and we therefore omit it here. Intuitively, SiBIR model divides time into time periods, and augments each signature with a “time-stamp” (the time period number, during which the signature was generated). Verification is essentially similar to the ordinary signature schemes, except it includes the time period as input — if the time period is changed, the signature becomes invalid. These extensions to ordinary signatures are the same as for forward-secure [And97,BM99] and key-insulated models [DKXY02]. In addition, the ordinary signer is replaced in SiBIR model —similarly to the key-insulated model of [DKXY02]— with two modules: signer and home base (thus, the name of the model: Signer-Base Intrusion-Resilient, or SiBIR for short). The signer, using its secret key, can generate signatures, but only for the current time period (unlike forward-secure signer, which can also generate signatures for all the future periods). At the end of the current period, the signer must update its secret key for the next period — this requires an update message from the base. Thus, intrusion-resilient schemes, as the key-insulated ones [DKXY02], preserve security of both past and future time periods, when the signer is compromised. Moreover —unlike in the key-insulated model— for intrusion-resilient schemes this security is preserved even if both signer and base are compromised, as long as the compromises are not simultaneous. In the case of simultaneous compromise, the security of past (but not the future) periods is preserved — this is the best that can be achieved. To achieve such security, SiBIR model, much as proactive schemes [OY91,HJJ+ 97], provides a refresh mechanism: base changes its key and sends a refresh message to the signer, which uses it to refresh its key as well. This can be done at arbitrary times and as many times as desired (unlike update, which is done only at the pre-arranged times, and typically has a limit on the total number of updates); refresh is transparent to the verifier (in contrast, update changes the time period number and is therefore visible to the verifier). Refresh prevents the attacker from learning anything by breaking into the base. Specifically, learning the base secrets at arbitrary times by itself does not help attacker in any way. Only if the attacker compromises both signer and base simultaneously, does she learn all the system’s secrets and can therefore generate — just as the system itself — valid signatures for all the future periods. But if the attacker misses at least one refresh message between the compromising of the base and signer secrets, then compromising the base does not add anything useful to her knowledge Thus, SiBIR model minimizes the impact of the key compromises, which explains the Intrusion-Resilient part of its name.
104
Gene Itkis
Previous Scheme. The only currently known SiBIR signature scheme, called SiBIR1 [IR02], builds on the techniques from [IR01]. SiBIR1 is closely based on a specific ordinary signature scheme of Guillou-Quisquater [GQ88], and as such requires random oracle and specific number-theoretic complexity assumptions (including a version of the strong RSA assumption). Though no attacks are known, SiBIR1 is proven in [IR02] to be secure only against partially restricted adversaries (partially adaptive or partially synchronous)1 . SiBIR1 signing and verifying costs are exactly the same as in [IR01], which are essentially the same as for the underlying ordinary Guillou-Quisquater signatures: two exponentiations with short (typically, 128-160 bits) exponents. SiBIR1 requires O(T ) modular exponentiations per update and a single modular multiplication per refresh, both for the signer and for the base. Both the signer and the base each store only two secret values (similar to GQ secret keys). New Results. We present a new SiBIR signature construction. This scheme is generic: it requires only a one-way function and an ordinary signature scheme — both can be given as black-boxes2 . In particular, it does not require a random oracle. Due to generic nature of our new scheme, we call it gSiBIR. We also prove gSiBIR to be secure against fully-adaptive adversary. Finally, while the previous SiBIR scheme requires the total number of periods T to be pre-set at the key-generation stage, our scheme can be easily adjusted to support unbounded number of periods. Our construction achieving this feature is of independent interest. It draws on the tree-based forward-secure constructions of [BM99,MMM02], and our technique of removing the bound on T can be applied back to [MMM02,BM99] to yield modest improvement3 . In fact, our mechanism can be presented as a generalization of these previous methods: casting them explicitly as using self-delimiting encodings4 . Once the use of the self-delimiting encodings is explicit, it is easy to find more efficient encodings.
2
Intrusion-Resilient Security Model
The definitions in this section are from [IR02] and are included here for selfcontainment. 1
2
3
4
A modification of SiBIR1, provably secure against the strongest —fully adaptive— adversary, has being obtained by the author and will be published separately. We also use a cryptographic hash function and a one-time signature scheme: both can be efficiently constructed from the given one-way function, e.g., using [NY89] for hash function and [Lam79,Mer89] for the one-time signatures. The previous method of removing the bound did not really remove it completely. Instead, it allowed the bound to be so large that reaching it would conflict with the security parameters of the scheme. In contrast, our method makes the number of periods really unbounded by anything, including security parameters. As a result, in our method, it is in principle possible to change the security parameters “on the fly”. The self-delimiting encodings are an important and well-known concept, playing an important role, in particular, in Kolmogorov Complexity [Lev73,Lev74,LV93], and in some scheduling issues, e.g., in [IL89].
Generic Intrusion-Resilient Signatures
2.1
105
Functional Definition
We first define the functionality of the system components; security definition is given in the subsequent subsection. The system’s secret keys may be modified in two different ways, called update and refresh. Updates change the secrets from one time period to the next (e.g. from one day to the next), changing also the period number in the signatures. In contrast, refreshes affect only the internal secrets and messages of the system, and are transparent to the verifier. Thus, we use notation SK t.r for secret key SK , where t is the time period (the number of times the key has been updated) and r is the “refresh number” (the number of times the key has been refreshed since the last update). We say t.r = t .r when t = t and r = r . Similarly, we say t.r < t .r when either t < t or t = t and r < r . We follow the convention of [BM99], requiring a key update immediately after key generation: to obtain the keys for t = 1 (this is done merely for notational convenience, in order to make the number of time periods T equal to the number of updates, and need not affect the efficiency of an actual implementation). Similarly, we require a key refresh immediately after key update: to obtain keys for r = 1 (this is also done for convenience, and need not affect efficiency of an actual implementation; in particular, the update and refresh information sent by the base to the signer can be combined into a single message). Definition 1. Signer-Base key-evolving signature scheme is a septuple of probabilistic polynomial-time algorithms (Gen, Sign, Ver ; US, UB; RB, RS) 5 : 1. Gen, the key generation algorithm. In: security parameter(s) (in unary), the total number T of time periods Out: initial signer key SKS 0.0 , initial home base key SKB 0.0 , and the public key PK . 2. Sign, the signing algorithm. In: current signer key SKS t.r , message m Out: signature (t, sig) on m for time period t 3. Ver , the verifying algorithm In: message m, signature (t, sig) and public key PK Out: “valid” or “invalid” (as usual, signatures generated by Sign must verify as “valid”) 4. UB, the base key update algorithm In: current base key SKB t.r Out: new base key SKB (t+1).0 and the key update message SKU t 5. US, the signer update algorithm In: current signer secret key SKS t.r and the key update message SKU t Out: new signer secret key SKS (t+1).0 5
Intuitively (and quite roughly), the first three correspond to the ordinary signatures; the first four correspond to forward-secure ones, the first five (with some restrictions) correspond to key-insulated ones; and all seven are needed to provide the full power of the intrusion-resilient signatures.
106
Gene Itkis
6. RB, the base key refresh algorithm In: current base key SKB t.r Out: new base key SKB t.(r+1) and the corresponding key refresh message SKR t.r 7. RS, the signer refresh algorithm In: current signer key SKS t.r and the key refresh message SKR t.r Out: new signer key SKS t.(r+1) (corresponding to the base key SKB t.(r+1) ) 2.2
Security Definition
In order to formalize security, we need a notation for the number of refreshes in each period: Let RN (t) denote the number of times the keys are refreshed in the period t: i.e., there will be RN (t)+1 instances of signer and base keys. Recall that each update is immediately followed by a refresh; thus, keys with refresh index 0 are never actually used. RN is used only for notational convenience: it need not be known; security is defined below in terms of RN (among other parameters). Now, consider all the keys generated during the entire run of the signature scheme. They can be generated by the following “thought experiment” (we do not need to actually run it — it is used just for definitions). Experiment Generate-Keys(k, T, RN ) t ← 0; r ← 0 (SKS t.r , SKB t.r , PK ) ← Gen(1k , T ) for t = 1 to T (SKB t.0 , SKU t−1 ) ← UB(SKB (t−1).r ) SKS t.0 ← US(SKS (t−1).r , SKU t−1 ) for r = 1 to RN (t) (SKB t.r , SKR t.(r−1) ) ← RB(SKB t.(r−1) ) SKS t.r ← RS(SKS t.(r−1) , SKR t.(r−1) ) Let SKS ∗ , SKB ∗ , SKU ∗ and SKR ∗ be the sets consisting of, respectively, signer and base keys and update and refresh messages, generated during the above experiment. We want these sets to contain all the secrets that can be directly stolen (as opposed to computed) by the adversary. Thus, we omit from these sets the keys SKS t.0 , SKB t.0 for 0 ≤ t ≤ T , SKU 0 and SKR 1.0 , which are never actually stored or sent (because key generation is immediately followed by update, and each update is immediately followed by refresh). Note that SKR t.0 for t > 1 is used (it is sent together with SKU t−1 to the signer), and thus is included into SKR ∗ . To define security, let F , the adversary (or “forger”), be a probabilistic polynomial-time oracle Turing machine with the following oracles: – Osig, the signing oracle (constructed using SKS ∗ ), which on input (m, t, r) (1 ≤ t ≤ T , 1 ≤ r ≤ RN (t)) outputs Sign(SKS t.r , m)
Generic Intrusion-Resilient Signatures
107
– Osec, the key exposure oracle (based on the sets SKS ∗ , SKB ∗ , SKU ∗ and SKR ∗ ), which 1. on input (“s”, t.r) for 1 ≤ t ≤ T, 1 ≤ r ≤ RN (t) outputs SKS t.r ; 2. on input (“b”, t.r) for 1 ≤ t ≤ T, 1 ≤ r ≤ RN (t) outputs SKB t.r ; 3. on input (“u”, t) for 1 ≤ t ≤ T − 1 outputs SKU t and SKR t+1 .0; and 4. on input (“r”, t.r) for 1 ≤ t ≤ T, 1 ≤ r < RN (t), outputs SKR t.r . Queries to Osec oracle correspond to intrusions, resulting in the corresponding secrets exposures. Exposure of an update key SKU t−1 automatically exposes the subsequent refresh key SKR t.0 , because they are sent together in one message. Adversary’s queries to Osig and Osec must have the t.r values within the appropriate bounds. It may be reasonable to require the adversary to “respect erasures” and prohibit a value that should have been erased from being queried (or used for signature computation). However, this restriction is optional, and in fact we do not require it here. Note, that respecting erasures is local to signer and base and is different from requiring any kind of global synchronization. For any set of valid key exposure queries Q, time period t ≥ 1 and refresh number r, 1 ≤ r ≤ RN (t), we say that key SKS t.r is Q-exposed : [directly] if (“s”, t.r) ∈ Q; or [via refresh] if r > 1, (“r”, t.(r−1)) ∈ Q, and SKS t.(r−1) is Q-exposed; or [via update] if r = 1, (“u”, t−1) ∈ Q, and SKS (t−1).RN (t−1) is Q-exposed. Replacing SKS with SKB throughout the above definition yields the definition of base key exposure (or more precisely, of SKB t.r being Q-exposed ). Both definitions are recursive, with direct exposure as the base case. Clearly, exposure of a signer key SKS t.r for the given t and any r enables the adversary to generate legal signatures for this period t. Similarly, simultaneous exposure of both base and signer keys (SKB t.r , SKS t.r , for some t, r) allows the adversary to run the algorithms of definition 1 to generate valid signatures for any messages for all later periods t ≥ t. Thus, we say that the scheme is (t, Q)-compromised, if either – SKS t.r is Q-exposed for some r, 1 ≤ r ≤ RN (t); or – SKS t .r and SKB t .r are both Q-exposed for some t < t. In other words, a particular time period has been rendered insecure if either the signer was broken into during that time period, or, during a previous time period, the signer and the base were compromised without a refresh in between. Note that update and refresh messages by themselves do not help the adversary in our model—they only help when combined, in unbroken chains, with signer or base keys6 . If the scheme is (j, Q)-compromised, then clearly adversary, pos6
Interestingly, and perhaps counter-intuitively, a secret that has not been exposed might still be deduced by adversary. For example, it may be possible in some implementations to compute SKB t.r from SKB t.r+1 and SKR t.r (similarly for update and for the signer). The only case we cannot allow —in order to stay consistent with our definition— is that of adversary computing SKS t.r without Q-exposing some SKS t.r . So, it may be possible to compute SKS t.r from SKS t.r+1 and SKR t.r , but not from SKS t+1.0 and SKU t.r (even if r = RN (t)).
108
Gene Itkis
sessing the secrets returned by Osec in response to queries in Q, can generate signatures for the period t. The following experiment captures adversary’s functionality. Intuitively, adversary succeeds if she generates a valid signature without “cheating”: not obtaining this signature from Osig, asking only legal queries (e.g. no out of bounds queries), and not compromising the scheme for the given time period. We call this adversary (fully) adaptive because she is allowed to decide which keys and signatures to query based on previous answers she receives. Experiment Run-Adaptive-Adversary(F, k, T, RN ) Generate-Keys(k, T, RN ) (m, j, sig) ← F Osig,Osec (1k , T, PK , RN ) Let Q be the set of key exposure queries F made to Osec; if Ver (m, j, sig) =“invalid” or (m, j) was queried by F to Osig or there was an illegal query or the scheme is (j, Q)-compromised then return 0 else return 1 We now define security for the intrusion resilient signature schemes. Definition 2. Let SiBIR[k, T, RN ] be a signer-base key-evolving scheme with security parameter k, number of time periods T , and table RN of T refresh numbers. For adversary F , define adversary success function as SuccSiBIR (F, SiBIR[k, T, RN ]) = Pr[Run-Adaptive-Adversary(F, k, T, RN ) = 1] def
Let insecurity InSecIR−fa (SiBIR[k, T, RN ], τ, qsig ) be the maximum of SuccSiBIR (F, SiBIR[k, T, RN ]) over all fully adaptive adversaries F that run in time at most τ and ask at most qsig signature queries. Finally, SiBIR[k, T, RN ] is (τ, , qsig )-intrusion-resilient if InSecIR−fa (SiBIR[k, T, RN ], τ, qsig ) < . Although the notion of (j, Q)-compromise depends only the set Q, it is important how Q is generated by the adversary. Allowing the adversary to decide her queries based on previous answers gives her potentially more power. Our scheme is the first SiBIR scheme shown to be secure against such a fully adaptive adversary.
3
Intrusion-Resilient Scheme: Generic Construction
Our scheme, gSiBIR, builds on the generic forward-secure signatures techniques of [BM99,MMM02]. In fact, it can be viewed as an intrusion-resilient implementation of their tree-based forward-secure constructions (T-schemes, in terminology of [MMM02]). However, since intrusion-resilient model is more complex, and exacts stronger security requirements, such an implementation is not trivial.
Generic Intrusion-Resilient Signatures
109
At an intuitive level, all these tree-based schemes (including ours), construct a certificate hierarchy, where the root is included in the public key of the main scheme, and the leaves are the public keys of the underlying ordinary signature scheme, used for the individual time periods. As in all certificate hierarchies, authentication must include all the certificates in the certification path7 . Such a certificate hierarchy is (re-)constructed, as time evolves. The challenge for intrusion-resilience is that the information, enabling further (re-)construction of the hierarchy, must be stored and used in such a way that adversary cannot subvert it in order to extend the hierarchy beyond the periods of her control, or to learn any secret keys for any additional time periods (even if she fully controlled both modules, just not at the same times). Our scheme uses any ordinary signature scheme, denoted as Σ. An instance of Σ is denoted as S; the corresponding public and secret keys are S.PK , S.SK , respectively. Each time period t uses a separate instance S t of Σ. Σ signatures are used only in the leaves, to sign actual messages. For certification, gSiBIR uses specific one-time signature mechanisms8 . We adjust these mechanisms to address the above mentioned challenge: to prevent adversary from extending the hierarchy beyond the compromised periods. In the simplest case, we base our certification mechanism on Diffie-Lamport one-time signatures [Lam79,Mer89] (which require only any one-way function, given as a black-box). For each internal node of the certification hierarchy, the secret keys corresponding to this node are used to sign only the (hashed) public keys of its children nodes. Denote an instance of the certification mechanism as C, and the corresponding public and private keys as C.PK , C.SK , respectively. 3.1
Bounded T Schemes
First, we consider the case when the total number of periods T is pre-set a priori (in section 3.2 we generalize it to the unbounded number of periods). Wlog, let T be an exact power of 2. Trees, Labels, Keys and Signatures Trees. Consider a complete balanced binary tree with T leaves. Let each leaf correspond to a time period; the periods t are arranged in increasing order from left to right from 0 to T − 1. 7
8
As observed by [Kra00] for forward-secure signatures, this certification can be optimized using the standard Merkle tree construction [Mer89]. Unfortunately, this optimization appears hard to realize in the intrusion-resilient model. It was observed in [Mer87] for standard, and in [AR00] for the forward-secure schemes that use similar certificates (such as [BM99,MMM02]), that each certifying public key, is used only for authenticating a single message — the corresponding certificate of the children’s public keys, and thus one-time signatures are sufficient for this purpose. In our scheme, however, the specific one-time signature (or similar) mechanisms are deeply integrated with rest of the scheme to assure intrusion resilience, and not just forward security.
110
Gene Itkis
Labels. Label each node with a string representing its path from the root (denoting left edge with 0 and right with 1). Then, all nodes in a subtree of some v contain v as prefix (and vice versa: all nodes with prefix v are in v’s subtree). The root is labeled with the empty string λ, and each leaf has full lg T bits in its label t, padded with leading 0s, if needed. Right Path. For a node v define the right path of v to be the set ρ(v) of the right children of the nodes on the path from v to the root. All nodes on the right path of a node v can be obtained by replacing one of the 0s in the v’s label with 1 and truncating the label to the right of it. So, there are ≤ lg T nodes in any right path (equality is achieved only for the leftmost node: 00...0). For example, a node labeled 0101010 has the following nodes as its right path: {1, 011, 01011, 0101011}. Define right path successor ρ+ (v) to be the longest element of ρ(v). In the above example ρ+ (0101010) = 0101011; as another example, ρ+ (1010111) = 1011. Keys. As in the case of forward-secure schemes of [BM99,MMM02], associated with each period t is an instance S t of the underlying ordinary signature scheme Σ. The keys S t .PK , S t .SK for period t are generated during the update preceding the period t, and destroyed during the following update. All signatures during the period t are signed using S t . In addition, with each node v we associate an instance C v of a one-time signature scheme similar to [Lam79,Mer89] (we’ll specify details later, but for now the differences with [Lam79,Mer89] can be ignored). The C λ .PK is the root public key gSiBIR.PK . Generating and Sharing. All the values we will be discussing below are generated and stored at base and signer. Here we introduce the notation for denoting the origin and location of the values: A value X is denoted as X (b) if it was generated at the base, and X (s) if generated at the signer. In our construction we actively utilize secret sharing (we use the simple XOR sharing). Thus, for a value X, b[X] denotes its share stored at the base, and s[X] its share stored at the signer. Then, b[X] ⊕ s[X] = X. Note: b[X (s) ] can be computed at the base independently, and even before generation of X (s) at the signer: in this case, when signer generates X (s) , it can use b[X (s) ] to compute s[X (s) ] = X (s) ⊕ b[X (s) ]. Then the signer deletes both X (s) and b[X (s) ] — this results in generating and sharing X (s) between the base and signer, without violating the one-directional communication restriction of our model. Signatures. Each gSiBIR signature during period t consists of the S t signature, plus the certification path of S t .PK . The certification path consists of the C signatures, each parent in the tree certifying its children; C λ .PK is the root certification authority’s public key and is thus the whole scheme’s public key. Key Management. At time t, gSiBIR maintains S t .SK in the signer, and all C v∈ρ(t) .SK values distributed between signer and base (i.e., s[C v .SK ], b[C v .SK ] respectively). In addition, the signer stores both the public key S t .PK and its certification path. The details of update procedure will be discussed below.
Generic Intrusion-Resilient Signatures
111
Certification Mechanism. gSiBIR uses certification, just as [BM99,MMM02], to allow keys for future periods to be generated at later times as needed, but still be tied in to the root — the scheme’s public key. However, in the case of forward security, these future-enabling certification keys are not considered a security risk at break-ins: forward-secure schemes protect only the past keys, while the keys obtained at a break-in can, by design and necessity, generate all future periods’ signatures. This is not the case for intrusion-resilient schemes. Here, a break-in of any one module must not expose any secret keys useful outside the current period. So, a natural solution is to distribute the secret keys, which will be used in the future, between the signer and base (using proactively secure secret sharing). This protects the future keys from break-ins. However the problem remains: how to use these certification keys without compromising not only the next period (which requires the use of such a key) but also all other future periods that may rely on the same certification keys? We solve this problem by making sure that the certification keys can be reconstructed from the shares in such a way that the reconstructed (partial) secret key is good only for certifying the proper child certificates. The onetime signatures of [Lam79,Mer89] (reviewed below) provide a simple certification mechanism allowing just such a “targeted” reconstruction. Still, even this is not enough: the above requires each secret key to be generated in only one of the modules (computing public key requires evaluating the one-way function on the secret key9 ). This makes the secret key vulnerable to exposure by a break-in into single module. To address this issue, we use two similar mechanisms C (b) , C (s) : one using keys originally generated at the base (and then shared with the signer); and the other generating its secret keys at the signer (these too are shared upon generation between the signer and the base, as outlined above). The secrets for C (b) , C (s) are generated simultaneously at the base and the signer respectively. As a result, to subvert the certification mechanism, both signer and base must be simultaneously compromised by the adversary: to either collect all shares of the certification secrets or to expose them immediately at creation, before they are shared. But such a simultaneous exposure forfeits the security of all the future signatures anyways (again by design and necessity). So, our security goal is achieved. One-Time Signatures. C, signing k bits, randomly generates its secret key C.SK = x : xi.β |0 ≤ i ≤ k − 1; β = 0, 1. The public key is then computed as C.PK = y : yi.β = f (xi.β )|0 ≤ i ≤ k − 1; β = 0, 1. The signature for message m = m0 m1 . . . mk−1 is then σ : σi = xi.mi . It is verified by checking that f (σi ) = yi.mi for all 0 ≤ i ≤ k − 1. Forging such a signature is equivalent to 9
In principle, it might be possible generate the secrets distributively and customize the general two party function evaluation [Yao82] (and other general secure multiparty computation methods) to suit our model and purpose. But we do not explore this direction, as our goal is much more restricted and we seek much more efficient solutions.
112
Gene Itkis
inverting f for one of the 2k public values yi.β . For convenience, we occasionally denote the above signature σ of m as σ = C.SK (m). Generating, Sharing and Refreshing C-Secrets. Putting together the above methods we achieve sharing and reconstructing of C secret keys, satisfying the requirements of our model: For a node v in the certification tree, when C v must be created, the base gen(b) (s) (b) erates at random C (b) v .SK , b[C v .SK ], and b[C v .SK ]; computes C v .PK from (s) (b) (b) (b) C (b) v .SK ; sends to the signer b[C v .SK ] and s[C v .SK ] = C v .SK ⊕ b[C v .SK ]. (b) The secret C v .SK (it was only present at the base) and local copy of s[C (b) v .SK ] are then destroyed. At the same time, the signer, similarly, generates at random C (s) v .SK ; com(s) (s) (s) putes from it C (s) .PK and s[C .SK ] = C .SK ⊕ b[C .SK ] and destroys v v v v (s) C v .SK . (b) (s) Now, for node v the base has only C (b) v .PK , b[C v .SK ] and b[C v .SK ]; simi(s) (b) (s) larly, the signer has C v .PK , s[C v .SK ] and s[C v .SK ]. To refresh any of the secrets SK , the base generates a random value r, changes its share b[SK ] ← b[SK ]⊕r, and sends r to the signer. Upon receiving r the signer changes his of SK : s[SK ] ← s[SK ] ⊕ r. The r is destroyed at both immediately upon completion of the above local operations. Key Certification and Pro-certification. The public key C (b) v .PK and (b) (s) (∗) .PK will each be used for certification C .SK (h(C .PK )||h(C C (s) v v v0 v0 .PK )|| (b) (s) (b) (s) (b) (s) h(C v1 .PK )||h(C v1 .PK )) of C v0 .PK , C v0 .PK , C v1 .PK , and C v1 .PK , whenever these are generated. Since all the public keys are of the same length and are used to sign a much shorter string, we use the standard technique of compressing the keys being certified with a cryptographic hash function10 h. In our case, we compress each of the keys to be signed separately. Thus to each public key of a child corresponds a portion of the public (and thus secret) key of the parent. When a child’s public key is generated, only a half of the parent’s corresponding key portion is required for the certification. Thus the shares of that portion’s half, which are not needed for the certification, can be destroyed — doing this also guarantees that at a later time no other public key can be certified. Specifically, as soon as C (b) v .PK is generated at the base (as described above), the base destroys its shares not needed for the certification of (b)
(b) C (b) v .PK : namely, the bases securely erases b[C par(v) .SK (. . . h(C v .PK ) . . .)] (s)
and b[C par(v) .SK (. . . h(C (b) v .PK ) . . .)]. The base keeps the remaining shares (b)
(s)
(b) b[C par(v) .SK (. . . h(C (b) v .PK ) . . .)], and b[C par(v) .SK (. . . h(C v .PK ) . . .)] to be used at a later time for the certification. (b) The signer similarly destroys s[C par(v) .SK (. . . h(C (s) and v .PK ) . . .)] (s)
(b)
(s) s[C par(v) .SK (. . . h(C (s) v .PK ) . . .)], and keeps s[C par(v) .SK (. . . h(C v .PK ) . . .)] (s)
and s[C par(v) .SK (. . . h(C (s) v .PK ) . . .)]. 10
Such cryptographic hash functions can be constructed from any one-way functions, e.g., using the classical construction of [NY89].
Generic Intrusion-Resilient Signatures
113
Note, that after the above is done, no key C.PK , such that h(C.PK ) = (s) h(C (s) v .PK ), can be certified in place of C v .PK , even after the total and simultaneous exposure of all the secrets of both the signer and the base. Similarly, for C (b) v .PK . In order to be able to perform such a certification, the signer needs (b) (s) to either obtain both C par(v) .SK and C par(v) .SK when these are created, or obtain their shares at the same time — in both cases this requires a simultaneous exposure of the signer and the base. We say, that these keys are now pro-certified. Updates and Refreshes. The update for period t securely erases S t .SK in the signer and initiates updating the right path successor v = ρ+ (t) of t: UpdateNode(v). Prior to UpdateNode(v), no keys for any nodes in the subtree of v had existed. For v itself, signer already contains C v .PK and its certification path; and C v .SK is shared between signer and base, for both C (b) , C (s) (i.e., signer (s) (b) (s) already contains s[C (b) v .SK ], s[C v .SK ] and base has b[C v .SK ], b[C v .SK ]). UpdateNode(v) generates, shares, and pro-certifies the keys as described above the children of v and all its left descendents: i.e. nodes of the form v0∗ , up to length lg T (the longest of these is t+1). For the leaf t + 1, its certification path is reconstructed from the shares (no internal nodes’ keys can be modified in this path due to pro-certification): the base sends its shares to the signer, which does the reconstruction. The base also sends b[C t+1 .SK ] to the signer, and the signer generates S t+1 and uses C t+1 .SK to certify its public key. The outline of the node update is as follows: UpdateNode(v) if |v| < |T | then % if not at the leaf yet (b) (b) in Base: C v0 .(PK , SK ) ← C.Gen; C v1 .(PK , SK ) ← C.Gen; (b) (b) (s) (s) Randomly generate b[C v0 .SK ], b[C v1 .SK ], b[C v0 .SK ], b[C v1 .SK ] ; (b) (b) (b) Set s[C v0 .SK ] ← C v0 .SK ⊕ b[C v0 .SK ], (b) (b) (b) s[C v1 .SK ] ← C v1 .SK ⊕ b[C v1 .SK ]; (b) (b) Securely erase C v0 .SK , C v1 .SK , (b)
(b)
b[C (∗) v .SK (h(C v0 .PK ) . . . h(C v1 .PK ) . . .)]; (b) (s) (s) Base send to Signer: C v{0,1} .PK ; b[C v0 .SK ], b[C v1 .SK ], (b)
(b)
s[C v0 .SK ], s[C v1 .SK ]; (s)
(s)
in Signer: C v0 .(PK , SK ) ← C.Gen; C v1 .(PK , SK ) ← C.Gen; (s) (s) (s) Set s[C v0 .SK ] ← C v0 .SK ⊕ b[C v0 .SK ], (s) (s) (s) s[C v1 .SK ] ← C v1 .SK ⊕ b[C v1 .SK ]; (b) (b) Store s[C v0 .SK ], s[C v1 .SK ]; (s) (s) (s) (s) Securely erase C v0 .SK , C v1 .SK , b[C v0 .SK ], b[C v1 .SK ], (s)
(s)
s[C (∗) v .SK (. . . h(C v0 .PK ) . . . h(C v1 .PK ))]; else % if at the leaf Base send to Signer: shares of the certification path from v to the root (i.e. remaining shares of C (s,b) .SK for all prefixes w of v) w % no C.PK outside this path can be certified by the recoverable secrets
114
Gene Itkis
in Signer: securely erase S t .SK ; S t+1 .(SK , PK ) ← S.Gen; recover (from the available shares) the certification path of S t+1 .PK algorithm gSiBIR.Gen(l, T ) Generate C λ .(SK , PK ) ← C.Gen(l); PK ← (C λ .PK , T ) Share C λ .SK between signer and base; UpdateNode(λ); % SKS 0 now contains the certification path for S 0 .PK % and all C v .PK , for ∀v ∈ ρ(0lg T ) % Also, SKS 0 , SKB 0 contain corresponding shares % of C v .SK , for ∀v ∈ ρ(0lg T ) return (SKS 0 , SKB 0 , PK ) Fig. 1. Key generation algorithm. Refresh index on the keys is omitted to simplify notation algorithm gSiBIR.Sign(M, SK t ) return (σ = S t .Sign(M ), t, S t .PK , ψt = certification path of S t .PK ) algorithm gSiBIR.Ver (M, PK , (σ, t, PK , ψ)) return Σ.Ver (M, PK ) (ψ is a correct certification path t of PK )
Fig. 2. Signing and verifying algorithms
Refreshes are straight-forward: the base generates a random value Rt.r for each secret SK t.r whose share it is currently holding, xor’s those random values with the corresponding secrets to obtain the new secret values SK t.(r+1) ← SK t.r ⊕ Rt.r , and sends all the Rt.r to the signer (who refreshes his secret keys the same way). Proof Sketch. The idea of the proof is to force the adversary to either forge a new signature for some S t used by the simulator, or to diverge from the simulator’s certification tree, resulting in adversary inverting a one way function used for the certification. In either case, the simulator must guess where adversary success will take place. The case of adversary forging a signature for some S t is straight-forward. Suppose the adversary diverges from the simulator’s certification tree at node v (meaning that the C v .PK used by adversary is not equal C v .PK of the simulator, while for the parent w of v both adversary and simulator use the same value C w .PK ). Then in order to certify C v .PK the adversary (s) must find inverses of some values in C (b) w .PK and C w .PK . The adversary can find one of these from the simulator, by exposing the appropriate keys. But in order to find from the simulator both, the adversary would require a simultaneous compromise (which would eliminate adversary’s success). Without such a compromise, the simulator can simulate the queries for one of these inverses
Generic Intrusion-Resilient Signatures
115
(randomly guessed by the simulator), thus forcing the adversary to invert the corresponding one-way function. 3.2
Unbounded T Scheme
Now, we extend the above scheme to the case where no bound on the number of periods is preset. Prefixless Notation. The main idea is that instead of using the binary representation of t as the path to the proper leaf in the tree, we use t˜ which is a monotone prefixless (or self-delimiting) encoding of t: for no two strings t, t the encoding of one is a prefix of the encoding of the other: t˜ = t˜ {0, 1}∗ . Setting the length of all strings to have the same length is one way to guarantee prefixlessness, albeit only for a finite set of strings. This is indeed the way the prefixless property is assured in [BM99] and the above construction. Other prefixless encodings abound. The simplest one handling infinite sets of inputs is probably to view each string t as an integer represented in unary (using only 1s), and delimited with a single 0: t˜ = 1t 0. Of course, such an encoding is very inefficient: |t˜| = 2t . However, a simple bootstrapping strategy can make it much more efficient: t˜ can consist of the length |t| of t, encoded in a prefixless notation, followed by t itself. In this case |t˜| = 2|t| = 2 lg t. Iterating this one more time we can get a prefixless encoding for which |t˜| = lg t+2 lg lg t = (1+o(1)) lg t. For practical purposes, it probably makes sense to stop here, though further iteration may yield better asymptotics (e.g. iterating lg∗ t times, we can get ∗ |t˜| = lg t + lg lg t + ... + lglg t t + lg∗ t). Another approach to achieve prefixless encoding, (instead of using unary notation at the base step) can represent each bit as two bits, 0 as 00, 1 as 01, and use 11 to mark the end of the string. Clearly this encoding can be easily improved by encoding t in ternary and using 10 to represent the ternary digit 2. Then |t˜| = 2 log3 t < 1.6 lg t. Further reductions are possible: essentially, for any monotone function f such that 1/f ≤ 1 it is possible to achieve an encoding such that t˜ ≤ f (t). In particular, for any > 0 there exists a prefixless encoding such that |t˜| ≤ (1 + ) lg t + O(1). These methods can also be used in the same bootstrapping strategy. Future-Enabling Keys. Representing the leaves in a prefixless notation helps only in part. In addition, at any time we need to maintain (distributively) some future-enabling key, which are used to extend the certification hierarchy to the future time periods. In the fixed T scheme above, at time t these are the secret keys corresponding to the nodes of the right path ρ(t). Using a generic prefixless encoding, e.g. as the second one in the paragraphs above, may not provide us with a small future-enabling key set. The first encoding scheme, using unary encoding as the base for bootstrapping, however, does this very well. In fact, just as before, the same right path for it provides exactly the desired future-enabling key set. And the number of nodes in the right path |ρ(t˜)| = (1 + o(1)) lg t, i.e. increases only marginally compared to the fixed T scheme above (much less than by a factor of 2 — or by additive o(lg t) nodes,
116
Gene Itkis
more precisely). At the same time, the early periods t : (1 + o(1)) lg t < lg T ) (i.e. t : t1+o(1) < T ) would actually even benefit from using the unbounded T scheme, compared to the fixed T scheme above. Other methods for constructing prefixless encodings with small right path sets exist as well. The two level construction in [MMM02] can be viewed as such. It is somewhat in between the unbounded and fixed T approaches: it uses fixed string length to achieve prefixlessness of the length of t (listed in logarithmic scale). As such, it still handles only bounded T , though the bound can easily be arranged to include all T that might be even remotely realistic in our universe (or match the security parameter requirements). Indeed, from the practical point it achieves a good compromise and offers good performance. Still, our methods can achieve almost a factor of two improvement in some cases. For example, for t = 300, using [MMM02] construction, |t˜| = 21, while using methods such as above, we can easily achieve |t˜| = 13 bits11 (the cost for [MMM02] method depends on the upper bound on T in the [MMM02], which the authors proposed to be T ≈ 2128 ; we use a more favorable limit of ≈ 232 — the next smaller T would be 216 , which seems a bit too low for at least some cases; using the higher bound of T ≈ 2128 would increase |t˜| by additional 2 bits for all t in the [MMM02] constructions). Finding other prefixless encodings which would keep the future-enabling key set small is a possible future research direction. 3.3
Optimizations
There are a number of improvements one can achieve for the above scheme. For example, for reasons of its simplicity, we have used the original Diffie-Lamport one-time signature scheme which requires 2k secrets (and as long a public key) to sign k bits. An obvious improvement to the scheme is to use more efficient one-time signature schemes such as the Merkle scheme [Mer89] requiring k + lg k + 1 values. Other even more efficient schemes are also possible but they may 11
The prefixless encoding we use in these calculations encodes t as: t in binary with the leading bit dropped (it’s always 1 anyways); prefixed by the length of t minus 1 (for the dropped bit), and with its leading bit dropped as well; that prefixed with the length of the previous segment, again with the leading bit dropped; and finally that all is prefixed with the length of the previous segment, but this time in unary, terminated with 0, and again the leading 1 dropped. So, t = 300 is encoded as 10 11 1000 100101100, with the dropped 1s crossed out, but kept for clarity. Other comparisons with [MMM02]: For t in approximately 65,000–109 (i.e. up to a billion) range using [MMM02] gives |t˜| = 37 bits for all t vs. 20-37 bits using our method (with the smaller t˜ using 20 bits and the encoding length increasing as t grows — approximately 1 bit per doubling of t). At the smaller end, for t in the approximate range of 25-250, [MMM02] construction results in |t˜| being 13 for all of them, while our construcitons would give 8 for t in 16-31 range; 9 for 32-63; 10 for 64-127; and 11 for 128-255. In comparing these bits two considerations should be kept in mind: on the one hand, each bit in the discussion above results in one extra C signature and/or key in our gSiBIR costs; on the other hand, it may be possible to take a bit or a couple off either encoding by further fine-tuning of the corresponding methods.
Generic Intrusion-Resilient Signatures
117
involve some trade-offs between computation and signature/key sizes (e.g. the Winternitz modification, also described in [Mer89]) and/or may conflict with pro-certification. It is also easy to significantly reduce the size of the secret keys — since C.SK are just random values, they can be replaced with pseudo-random ones (using a seed per node, so they can be deleted easily; or use some alternative techniques, e.g. based on storing the right path of the classic pseudo-random function tree [GGM86]). But this technique can easily be applied only to C (s) .SK ; for C (b) .SK it conflicts with the pro-certification. Other optimizations are less obvious: it may be possible to reuse some of the keys by using some collusion-resilience, set-cover, and/or frameproof codes techniques. Finally, it may be possible to apply the Merkle certification tree, just as in [MMM02], but without loosing the intrusion-resilience.
Acknowledgments The author thanks Leo Reyzin and Jonathan Katz for very helpful discussions.
References And97.
Ross Anderson. Invited lecture. Fourth Annual Conference on Computer and Communications Security, ACM (see http://www.ftp.cl.cam.ac.uk/ ftp/users/rja14/forwardsecure.pdf), 1997. AR00. Michel Abdalla and Leonid Reyzin. A new forward-secure digital signature scheme. In Tatsuaki Okamoto, editor, Advances in Cryptology– ASIACRYPT 2000, volume 1976 of Lecture Notes in Computer Science, pages 116–129, Kyoto, Japan, 3–7 December 2000. Springer-Verlag. Full version available from the Cryptology ePrint Archive, record 2000/002, http://eprint.iacr.org/. BM99. Mihir Bellare and Sara Miner. A forward-secure digital signature scheme. In Michael Wiener, editor, Advances in Cryptology–CRYPTO ’99, volume 1666 of Lecture Notes in Computer Science, pages 431–448. Springer-Verlag, 15–19 August 1999. Revised version is available from http://www.cs.ucsd.edu/˜mihir/. DKXY02. Yevgeniy Dodis, Jonathan Katz, Shouhuai Xu, and Moti Yung. Keyinsulated public key cryptosystems. In Knudsen [Knu02]. GGM86. Oded Goldreich, Shafi Goldwasser, and Silvio Micali. How to construct random functions. Journal of the ACM, 33(4):792–807, October 1986. GQ88. Louis Claude Guillou and Jean-Jacques Quisquater. A “paradoxical” indentity-based signature scheme resulting from zero-knowledge. In Shafi Goldwasser, editor, Advances in Cryptology–CRYPTO ’88, volume 403 of Lecture Notes in Computer Science, pages 216–231. Springer-Verlag, 1990, 21–25 August 1988. HJJ+ 97. Amir Herzberg, Markus Jakobsson, Stanislaw Jarecki, Hugo Krawczyk, and Moti Yung. Proactive public key and signature systems. In Fourth ACM Conference on Computer and Communication Security, pages 100– 110. ACM, April 1–4 1997.
118
Gene Itkis
IL89.
IR01.
IR02.
Knu02. Kra00.
Lam79. Lev73.
Lev74.
LV93. Mer87.
Mer89.
MMM02.
NY89.
OY91.
Yao82.
G. Itkis and L. A. Levin. Power of fast VLSI models is insensitive to wires’ thinness. In 30th Annual Symposium on Foundations of Computer Science, pages 402–407, Research Triangle Park, North Carolina, 30 October–1 November 1989. IEEE. Gene Itkis and Leonid Reyzin. Forward-secure signatures with optimal signing and verifying. In Joe Kilian, editor, Advances in Cryptology–CRYPTO 2001, volume 2139 of Lecture Notes in Computer Science, pages 332–354. Springer-Verlag, 19–23 August 2001. Gene Itkis and Leonid Reyzin. Intrusion-resilient signatures, or towards obsoletion of certificate revocation. In Moti Yung, editor, Advances in Cryptology–CRYPTO 2002, Lecture Notes in Computer Science. SpringerVerlag, 18–22 August 2002. Available from http://eprint.iacr.org/2002/054/. Lars Knudsen, editor. Advances in Cryptology–EUROCRYPT 2002, Lecture Notes in Computer Science. Springer-Verlag, 28 April–2 May 2002. Hugo Krawczyk. Simple forward-secure signatures from any signature scheme. In Seventh ACM Conference on Computer and Communication Security. ACM, November 1–4 2000. Leslie Lamport. Constructing digital signatures from a one way function. Technical Report CSL-98, SRI International, October 1979. Leonid A. Levin. On the concept of a random sequence, in Russian). Doklady Akademii Nauk SSSR (Proceedings of National Academy of Science of USSR), 5(14):1413–1416, 1973. Leonid A. Levin. Laws of information conservation (non-growth) and aspects of the foundations of probability theory, in Russian). Problemy Peredachi Informatsii, 3(10):206–210, 1974. Ming Li and Paul Vit´ anyi. An Introduction to Kolmogorov Complexity and Its Applications. Springer-Verlag, 1993. Ralph C. Merkle. A digital signature based on a conventional encryption function. In Carl Pomerance, editor, Advances in Cryptology–CRYPTO ’87, volume 293 of Lecture Notes in Computer Science, pages 369–378. SpringerVerlag, 1988, 16–20 August 1987. Ralph C. Merkle. A certified digital signature. In G. Brassard, editor, Advances in Cryptology–CRYPTO ’89, volume 435 of Lecture Notes in Computer Science, pages 218–238. Springer-Verlag, 1990, 20–24 August 1989. Tal Malkin, Daniele Micciancio, and Sara Miner. Effcient generic forwardsecure signatures with an unbounded number of time periods. In Knudsen [Knu02]. Moni Naor and Moti Yung. Universal one-way hash functions and their cryptographic applications. In Proceedings of the Twenty First Annual ACM Symposium on Theory of Computing. (May 15–17 1989: Seattle, WA, USA), pages 33–43, New York, NY 10036, USA, 1989. ACM Press. Rafail Ostrovsky and Moti Yung. How to withstand mobile virus attacks. In 10-th Annual ACM Symp. on Principles of Distributed Computing, pages 51–59, 1991. A.C. Yao. Protocols for secure computations. In 23rd Annual Symposium on Foundations of Computer Science, pages 160–164, Chicago, Illinois, 3–5 November 1982. IEEE.
