Publication number | US20010002486 A1 |

Publication type | Application |

Application number | US 09/737,182 |

Publication date | May 31, 2001 |

Filing date | Dec 13, 2000 |

Priority date | Jan 2, 1998 |

Also published as | CA2316227A1, CA2316227C, DE69834431D1, DE69834431T2, DE69834431T3, DE69840782D1, EP1050133A1, EP1050133A4, EP1050133B1, EP1050133B2, US6304658, US6381699, US7506165, US7792287, US20030028771, US20080104400, WO1999035782A1 |

Publication number | 09737182, 737182, US 2001/0002486 A1, US 2001/002486 A1, US 20010002486 A1, US 20010002486A1, US 2001002486 A1, US 2001002486A1, US-A1-20010002486, US-A1-2001002486, US2001/0002486A1, US2001/002486A1, US20010002486 A1, US20010002486A1, US2001002486 A1, US2001002486A1 |

Inventors | Paul Kocher, Joshua Jaffe |

Original Assignee | Cryptography Research, Inc. |

Export Citation | BiBTeX, EndNote, RefMan |

Referenced by (111), Classifications (36), Legal Events (4) | |

External Links: USPTO, USPTO Assignment, Espacenet | |

US 20010002486 A1

Abstract

The present invention provides a method and apparatus for securing cryptographic devices against attacks involving external monitoring and analysis. A “self-healing” property is introduced, enabling security to be continually re-established following partial compromises. In addition to producing useful cryptographic results, a typical leak-resistant cryptographic operation modifies or updates secret key material in a manner designed to render useless any information about the secrets that may have previously leaked from the system. Exemplary leak-proof and leak-resistant implementations of the invention are shown for symmetric authentication, certified Diffie-Hellman (when either one or both users have certificates), RSA, ElGamal public key decryption, ElGamal digital signing, and the Digital Signature Algorithm.

Claims(71)

(a) obtaining a representation of an RSA private key corresponding to an RSA public key, said private key characterized by secret factors p and q;

(b) storing said representation of said private key in a memory;

(c) obtaining a message for use in an RSA cryptographic operation;

(d) computing a first modulus, corresponding to a multiple of p, where the value of said multiple of p and the value of said multiple of p divided by p are both unknown to an attacker of said cryptographic system;

(e) reducing said message modulo said first modulus;

(f) performing modular exponentiation on the result of step (e);

(g) computing a second modulus, corresponding to a multiple of q, where the value of said multiple of q and the value of said multiple of q divided by q are both unknown to an attacker of said cryptographic system;

(h) reducing said message modulo said second modulus;

(i) performing modular exponentiation on the result of step (h);

(j) combining the results of said steps (e) and (h) to produce a result which, if operated on with an RSA public key operation using said RSA public key, yields said message; and

(k) repeating steps (c) through 0) a plurality of times using different values for said multiple of p and for said multiple of q.

claim 1

(i) said step (b) includes storing an exponent d_{p }of said RSA private key in said memory as a plurality of parameters;

(ii) an arithmetic fimction of at least one of said plurality of parameters is congruent to d_{p}, modulo (p−1);

(iii) none of said parameters comprising said stored d_{p }is equal to d_{p};

(iv) an exponent used in said step (f) is at least one of said parameters;

(v) at least one of said parameters in said memory changes with said repetitions of said steps (c) through (j).

claim 2

claim 1

claim 1

claim 1

claim 1

(a) obtaining an RSA private key corresponding to an RSA public key, said RSA public key having an RSA modulus n;

(b) storing said private key in a memory in a form whereby a secret parameter of said key is stored as an arithmetic combination of phi(x) and a first at least one key masking parameter, where

(i) an operand x in said phi(x) is an exact multiple of at least one factor of said modulus n of said RSA public key; and

(ii) said first key masking parameter is unknown to an attacker of said cryptosystem;

(iii) a representation of said first key masking parameter is stored in said memory;

(iv) phi denotes Euler's totient function;

(c) receiving a message;

(d) deriving an RSA input from said message;

(e) performing modular exponentiation to raise said RSA input to a power dependent on said secret parameter, modulo an RSA modulus stored in said memory, to produce an RSA result such that said RSA result raised to the power of the public exponent of said RSA public key, modulo the modulus of said RSA public key, equals said RSA input;

(f) updating said secret parameter in said memory by:

(i) modifing said first key masking parameter to produce a new key masking parameter, where said modification is performed in a manner such that an attacker with partial useful information about said first key masking parameter has less useful information about said new key masking parameter; and

(ii) using said new key masking parameter to update said secret parameter in said memory;

(g) repeating steps (d) through (f) a plurality of times, where the power used for each of said modular exponentiation steps (e) is different.

claim 8

claim 8

(a) obtaining, and storing in a memory, exponential key exchange parameters g and p, and a plurality of secret exponent parameters on which an arithmetic relationship may be computed to produce an exponent x;

(b) using a key update transformation to produce a plurality of updated secret exponent parameters while maintaining said arithmetic relationship thereamong;

(c) receiving a public value y from a party with whom said key exchange is desired;

(d) using said updated secret exponent parameters to perform a cryptographic computation yielding an exponential key exchange result z=y x mod p;

(e) using said result z to secure an electronic communication with said party; and

(f) performing said steps (b), (c), (d), and (e) in a plurality of transactions.

claim 11

claim 11

claim 11

claim 11

claim 15

(a) an interface configured to receive power from a source external to said token;

(b) a memory containing said secret key;

(c) a processor:

(i) configured to receive said power delivered via said interface;

(ii) configured to perform said processing using said secret key from said memory;

(d) said token having a power consumption characteristic:

(i) that is externally measurable; and

(ii) that varies over time in a manner measurably correlated with said cryptographic operations; and

(e) a source of unpredictable information usable in said cryptographic operations to make determination of said secret key infeasible from external measurements of said power consumption characteristic.

claim 17

claim 17

claim 19

claim 19

claim 21

claim 17

claim 23

claim 23

claim 23

claim 23

claim 27

claim 17

claim 17

claim 17

claim 17

claim 17

claim 33

(a) using a first private key, complementary to a public key, to perform first asymmetric cryptographic operation;

(b) reading at least a portion of said first private key from a memory;

(c) transforming said read portion of said first private key to produce a second private key:

(i) said second private key usable to perform a subsequent asymmetric cryptographic operation in a manner that remains complementary to said public key, and

(ii) said transformation enabling said asymmetric cryptographic operations to be performed in a manner such that information leaked during said first asymmetric cryptographic operation does not provide incrementally useful information about said second private key;

(d) obtaining a datum;

(e) using said second private key to perform said subsequent asymmetric cryptographic operation on said datum.

claim 35

claim 36

claim 36

claim 36

claim 35

claim 40

claim 40

claim 35

claim 35

claim 35

claim 35

(a) retrieving a stored private cryptographic key stored in a memory, said stored key having been used in a previous cryptographic transaction;

(b) using a first cryptographic function to derive from said stored key an updated key, about which useful information about said stored key obtained through monitoring of leaked information is effectively uncorrelated to said updated key;

(c) replacing said stored key in said memory with said updated key;

(d) using an asymmetric cryptographic function, cryptographically processing a datum with said updated key; and

(e) sending said cryptographically processed datum to an external device having a public key corresponding to said stored key.

claim 47

claim 48

claim 49

claim 50

claim 51

claim 51

claim 53

claim 47

(a) encoding a portion of a private key as at least two component parts, such that an arithmetic function of said parts yields said portion;

(b) modifing said component parts to produce updated component parts, but where said arithmetic function of said updated parts still yields said private key portion;

(c) obtaining a message for use in an asymmetric private key cryptographic operation;

(d) separately applying said component parts to said message to produce an intermediate result;

(e) deriving a final result from said intermediate result such that said final result is a valid result of applying said private key to said message;

and

(f) repeating steps (b) through (e) a plurality of times.

claim 56

claim 57

claim 57

claim 56

claim 60

claim 56

claim 56

(a) retrieving said stored key from a memory;

(b) cryptographically processing said key, to derive an updated key, by executing a cryptographic update finction that:

(i) prevents partial information about said stored key from revealing useful information about said updated key, and

(ii) also prevents partial information about said updated key from revealing useful information about said stored key;

(c) replacing said stored key in said memory with said updated key;

(d) performing a cryptographic operation using said updated key; and

(e) repeating steps (a) through (d) a plurality of times.

claim 64

claim 64

claim 64

claim 66

claim 66

claim 64

(i) explicitly erasing a region of said memory containing said stored key; and

(ii) storing said updated key in said region of memory.

claim 64

Description

- [0001]This application claims the benefit of U.S. Provisional application Ser. No. 60/070,344 filed Jan. 2, 1998, and U.S. Provisional application Ser. No. 60/089,529 filed June 15, 1998.
- [0002]The method and apparatus of the present invention relate generally to cryptographic systems and, more specifically, to securing cryptographic tokens that must maintain the security of secret information in hostile environments.
- [0003]Most cryptosystems require secure key management. In public-key based security systems, private keys must be protected so that attackers cannot use the keys to forge digital signatures, modify data, or decrypt sensitive information. Systems employing symmetric cryptography similarly require that keys be kept secret. Well-designed cryptographic algorithms and protocols should prevent attackers who eavesdrop on communications from breaking systems. However, cryptographic algorithms and protocols traditionally require that tamper-resistant hardware or other implementation-specific measures prevent attackers from accessing or finding the keys.
- [0004]If the cryptosystem designer can safely assume that the key management system is completely tamper-proof and will not reveal any information relating to the keys except via the messages and operations defined in the protocol, then previously known cryptographic techniques are often sufficient for good security. It is currently extremely difficult, however, to make hardware key management systems that provide good security, particularly in low-cost unshielded cryptographic devices for use in applications where attackers will have physical control over the device. For example, cryptographic tokens (such as smartcards used in electronic cash and copy protection schemes) must protect their keys even in potentially hostile environments. (A token is a device that contains or manipulates cryptographic keys that need to be protected from attackers. Forms in which tokens may be manufactured include, without limitation, smartcards, specialized encryption and key management devices, secure telephones, secure picture phones, secure web servers, consumer electronics devices using cryptography, secure microprocessors, and other tamper-resistant cryptographic systems.)
- [0005]A variety of physical techniques for protecting cryptographic devices are known, including enclosing key management systems in physically durable enclosures, coating integrated circuits with special coatings that destroy the chip when removed, and wrapping devices with fine wires that detect tampering. However, these approaches are expensive, difficult to use in single-chip solutions (such as smartcards), and difficult to evaluate since there is no mathematical basis for their security. Physical tamper resistance techniques are also ineffective against some attacks. For example, recent work by Cryptography Research has shown that attackers can non-invasively extract secret keys using careful measurement and analysis of many devices' power consumption. Analysis of timing measurements or electromagnetic radiation can also be used to find secret keys.
- [0006]Some techniques for hindering external monitoring of cryptographic secrets are known, such as using power supplies with large capacitors to mask fluctuations in power consumption, enclosing devices in well-shielded cases to prevent electromagnetic radiation, message blinding to prevent timing attacks, and buffering of inputs/outputs to prevent signals from leaking out on I/O lines. Shielding, introduction of noise, and other such countermeasures are often, however, of limited value, since skilled attackers can still find keys by amplifying signals and filtering out noise by averaging data collected from many operations. Further, in smartcards and other tamper-resistant chips, these countermeasures are often inapplicable or insufficient due to reliance on external power sources, impracticality of shielding, and other physical constraints. The use of blinding and constant-time mathematical algorithms to prevent timing attacks is also known, but does not prevent more complex attacks such as power consumption analysis (particularly if the system designer cannot perfectly predict what information will be available to an attacker, as is often the case before a device has been physically manufactured and characterized).
- [0007]The present invention makes use of previously-known cryptographic primitives and operations. For example: U.S. Pat. 5,136,646 to Haber et al. and the pseudorandom number generator used in the RSAREF cryptographic library use repeated application of hash functions; anonymous digital cash schemes use blinding techniques; zero knowledge protocols use hash functions to mask information; and key splitting and threshold schemes store secrets in multiple parts.
- [0008]The present invention introduces leak-proof and leak-resistant cryptography, mathematical approaches to tamper resistance that support many existing cryptographic primitives, are inexpensive, can be implemented on existing hardware (whether by itself or via software capable of running on such hardware), and can solve problems involving secrets leaking out of cryptographic devices. Rather than assuming that physical devices will provide perfect security, leak-proof and leak-resistant cryptographic systems may be designed to remain secure even if attackers are able to gather some information about the system and its secrets. This invention describes leak-proof and leak-resistant systems that implement symmetric authentication, Diffie-Hellman exponential key agreement, ElGamal public key encryption, ElGamal signatures, the Digital Signature Standard, RSA, and other algorithms.
- [0009]One of the characteristic attributes of a typical leak-proof or leak-resistant cryptosystem is that it is “self-healing” such that the value of information leaked to an attacker decreases or vanishes with time. Leak-proof cryptosystems are able to withstand leaks of up to L
_{MAX }bits of information per transaction, where L_{MAX }is a security factor chosen by the system designer to exceed to the maximum anticipated leak rate. The more general class of leak-resistant cryptosystems includes leak-proof cryptosystems, and others that can withstand leaks but are not necessarily defined to withstand any defined maximum information leakage rate. Therefore, any leak-proof system shall also be understood to be leak-resistant. The leak-resistant systems of the present invention can survive a variety of monitoring and eavesdropping attacks that would break traditional (non-leak-resistant) cryptosystems. - [0010]A typical leak-resistant cryptosystem of the present invention consists of three general parts. The initialization or key generation step produces secure keying material appropriate for the scheme. The update process cryptographically modifies the secret key material in a manner designed to render useless any information about the secrets that may have previously leaked from the system, thus providing security advantages over systems of the background art. The final process performs cryptographic operations, such as producing digital signatures or decrypting messages.
- [0011][0011]FIG. 1 shows an exemplary leak-resistant symmetric authentication method.
- [0012][0012]FIG. 2 shows an exemplary leak-resistant Diffie-Hellman exponential key exchange operation.
- [0013][0013]FIG. 3 shows an exemplary leak-resistant RSA private key operation.
- [0014][0014]FIG. 4 shows an exemplary leak-resistant ElGamal signing operation.
- [0015]The sections following will describe an introduction to leak-proof/leak-resistant cryptography, followed by various embodiments of the general techniques of the invention as applied to improve the security of common cryptographic protocols.
- [0016]I. Introduction and Terminology
- [0017]The leakage rate L is defined as the number of bits of useful information about a cryptosystem's secrets that are revealed per operation, where an operation is a cryptographic transaction. Although an attacker may be able to collect more than L bits worth of measurement data, by definition this data yields no more than L bits of useful information about the system's secrets.
- [0018]The implementer of a leak-proof system chooses a design parameter L
_{MAX}, the maximum amount of leakage per operation the system may allow if it is to remain uncompromised. L_{MAX }should be chosen conservatively, and normally should significantly exceed the amount of useful information known to be leaked to attackers about the system's secrets during each transaction. Designers do not necessarily need to know accurately or completely the quantity and type of information that may leak from their systems; the choice of L_{MAX }may be made using estimates and models for the system's behavior. General factors affecting the choice of L_{MAX }include the types of monitoring potentially available to attackers, the amount of error in attacker**3**measurements, and engineering constraints that limit L_{MAX}. (Larger values of L_{MAX }increase memory and performance requirements of the device, and in some cases may increase L.) To estimate the amount of useful information an attacker could collect by monitoring a device's power consumption, for example, a designer might consider the amount of noise in the device's power usage, the power line capacitance, the useful time resolution for power consumption measurements, as well as the strength of the signals being monitored. Similarly, the designer knows that timing measurements can rarely yield more than a few bits of information per operation, since timing information is normally quantized to an integral number of clock cycles. In choosing L_{MAX}, the designer should assume that attackers will be able to combine information gleaned from multiple types of attacks. If the leakage rate is too large (as in the extreme case where L equals the key size because the entire key can be extracted during a single transaction), additional design features should be added to reduce L and reduce the value needed for L_{MAX}. Such additional measures can include known methods, such as filtering the device's power inputs, adding shielding, introducing noise into the timing or power consumption, implementing constant-time and constant execution path algorithms, and changing the device layout. Again, note that the designer of a leak-resistant system does not actually need to know what information is being revealed or how it is leaked; all he or she need do is choose an upper bound for the rate at which attackers might learn information about the keys. In contrast, the designer of a traditional system faces the much harder task of ensuring that no information about the secrets will leak out. - [0019]There are many ways information about secrets can leak from cryptosystems. For example, an attacker can use a high-speed analog-to-digital converter to record a smartcard's power consumption during a cryptographic operation. The amount of useful information that can be gained from such a measurement varies, but it would be fairly typical to gain enough information to guess each of 128 key bits correctly with a probability of 0.7. This information can reduce the amount of effort required for a brute force attack. For example, a brute force attack with one message against a key containing k bits where each bit's value is known with probability p can be completed in
$E\ue8a0\left(k,p\right)=\sum _{i=0}^{k}\ue89e\text{\hspace{1em}}\ue89e\left[\left(\begin{array}{c}k\\ i\end{array}\right)\ue89e{\left(1-p\right)}^{i}\ue89e{p}^{k-i}\ue8a0\left[\left(\sum _{j=0}^{i}\ue89e\text{\hspace{1em}}\ue89e\left(\begin{array}{c}k\\ j\end{array}\right)\right)-\frac{1}{2}\ue89e\left(\begin{array}{c}k\\ i\end{array}\right)\right]+\frac{1}{2}\right]$ - [0020]operations. The reduction in the effort for a brute force attack is equivalent to shortening the key by L=log
_{2}(E(k,{fraction (**1**/**2**)})/E(k,p))=log_{2}(k−E(k,p)−1) bits. (For example, in the case of k=128 and p=0.7, L is estimated to be about 11 bits for the first measurement. With a multiple message attack, the attacker's effort can fall to as low as$E\ue8a0\left(k,p\right)=\frac{1}{{p}^{k}}.)$ - [0021]Attackers can gain additional information about the keys by measuring additional operations; unless leak-resistance is used, finding the key becomes easy after just a few dozen operations.
- [0022]When choosing L
_{MAX, }a system designer should consider the signal-to-noise ratio of an attacker's measurements. For example, if the signal and noise are of roughly equivalent magnitude, the designer knows that an attacker's measurements should be incorrect about 25 percent of the time (e.g., p=0.75 if only one observation per key bit is possible). Many measurement techniques, such as those involving timing, may have signal-to-noise ratios of 1:100 or worse. With such systems, L is generally quite small, but attackers who can make a large number of measurements can use averaging or other statistical techniques to recover the entire key. In extreme cases, attackers may be able to obtain all key bits with virtually perfect accuracy from a single transaction (i.e., L=k), necessitating the addition of shielding, noise in the power consumption (or elsewhere), and other measures to reduce p and L. Of course, L_{MAX }should be chosen conservatively; in the example above where less than 4 useful bits are obtained per operation for the given attack, the designer might select L_{MAX }=64 for a leak-proof design. - [0023]Leak-proof (and, more generally, leak-resistant) cryptosystems provide system designers with important advantages. When designing a traditional (i.e., non-leak-resistant and non-leak-proof) cryptosystem, a careful cryptosystem designer should study all possible information available to attackers if he or she is to ensure that no analytical techniques could be used to compromise the keys. In practice, many insecure systems are developed and deployed because such analysis is incomplete, too difficult even to attempt, or because the cryptographers working on the system do not understand or cannot completely control the physical characteristics of the device they are designing. Unexpected manufacturing defects or process changes, alterations made to the product by attackers, or modifications made to the product in the field can also introduce problems. Even a system designed and analyzed with great care can be broken if new or improved data collection and analysis techniques are found later. In contrast, with leak-proof cryptography, the system designer only needs to define an upper bound on the maximum rate at which attackers can extract information about the keys. A detailed understanding of the information available to attackers is not required, since leak-proof (and leak-resistant) cryptosystem designs allow for secret information in the device to leak out in (virtually) any way, yet remain secure despite this because leaked information is only of momentary value.
- [0024]In a typical leak-proof design, with each new cryptographic operation i, the attacker is assumed to be able to choose any function F
_{i }and determine the L_{MAX}-bit result of computing F_{i }on the device's secrets, inputs, intermediates, and outputs over the course of the operation. The attacker is even allowed to choose a new function F_{i }with each new operation. The system may be considered leak-proof with a security factor n and leak rate L_{MAX }if, after observing a large number of operations, an attacker cannot forge signatures, decrypt data, or perform other sensitive operations without performing an exhaustive search to find an n-bit key or performing a comparable O(2^{n}) operation. In addition to choosing L_{MAX}, designers also choose n, and should select a value large enough to make exhaustive search infeasible. In the sections that follow, various embodiments of the invention, as applied to improve the security of common cryptographic operations and protocols, will be described in more detail. - [0025]II. Symmetric Cryptographic Protocols
- [0026]A. Symmetric Authentication
- [0027]An exemplary cryptographic protocol that can be secured using the techniques of the present invention is symmetric authentication.
- [0028]1. Conventional Symmetric Authentication
- [0029]Assume a user wishes to authenticate herself to a server using an n-bit secret key, K, known to both the server and the user's cryptographic token, but not known to attackers. The cryptographic token should be able to resist tampering to prevent, for example, attackers from being able to extract secrets from a stolen token. If the user's token has perfect tamper resistance (i.e., L=0), authentication protocols of the background art can be used. Typically the server sends a unique, unpredictable challenge value R to the user's token, which computes the value A=H(R||K), where “|” denotes concatenation and H is a one-way cryptographic hash function such as SHA. The user sends A to the server, which independently computes A (using its copy of K) and compares its result with the received value. The user authentication succeeds only if the comparison operation indicates a match.
- [0030]If the function H is secure and if K is sufficiently large to prevent brute force attacks, attackers should not be able to obtain any useful information from the (R,A) values of old authentication sessions. To ensure that attackers cannot impersonate users by replaying old values of A, the server generates values of R that are effectively (with sufficiently high probability) unique. In most cases, the server should also make R unpredictable to ensure that an attacker with temporary possession of a token cannot compute future values of A. For example, R might be a 128-bit number produced using a secure random number generator (or pseudorandom number generator) in the server. The properties of cryptographic hash functions such as H have been the subject of considerable discussion in the literature, and need not be described in detail here. Hash functions typically provide functionality modeled after a random oracle, deterministically producing a particular output from any input. Ideally, such functions should be collision-resistant, non-invertable, should not leak partial information about the input from the output, and should not leak information about the output unless the entire input is known. Hash functions can have any output size. For example, MD5 produces 128-bit outputs and SHA produces 160-bit outputs. Hash functions may be constructed from other cryptographic primitives or other hash functions.
- [0031]While the cryptographic security of the protocol using technology of the background art may be good, it is not leak-proof; even a one-bit leak function (with L=1) can reveal the key. For example, if the leak function F equals bit (R mod n) of K, an attacker can break the system quickly since a new key bit is revealed with every transaction where (R mod n) has a new value. Therefore, there is a need for a leak-proof/leak-resistant symmetric authentication protocol.
- [0032]2. Leak-Resistant Symmetric Authentication
- [0033]The following is one embodiment of a leak-resistant (and, in fact, also leak-proof) symmetric authentication protocol, described in the context of a maximum leakage rate of L
_{MAX }bits per transaction from the token and a security factor n, meaning that attacks of complexity O(2^{n}), such as brute-force attacks against an n-bit key, are acceptable, but there should not be significantly easier attacks. The user's token maintains a counter t, which is initialized to zero, and an (n+2L_{MAX})-bit shared secret K_{t}, which is initialized with a secret K_{0}. Note that against adversaries performing precomputation attacks based on Hellman's time/memory trade-off, larger values of n may be in order. Note also that some useful protocol security features, such as user and/or server identifiers in the hash operation inputs, have been omitted for simplicity in the protocol description. It is also assumed that no leaking will occur from the server. For simplicity in the protocol description, some possible security features (such as user and/or server identifiers in the hash operation inputs) have been omitted, and it is assumed that the server is in a physically secure environment. However, those skilled in the art will appreciate that the invention is not limited to such assumptions, which have been made as a matter of convenience rather than necessity. - [0034]As in the traditional protocol, the server begins the authentication process by generating a unique and unpredictable value R at step 105. For example, R might be a 128-bit output from a secure random number generator. At step 110, the server sends R to the user's token. At step 112, the token receives R. At step 115, the token increments its counter t by computing t ←t+1. At step 120, the token updates K
_{t }by computing K_{t }←H_{K}(t ||K_{t}), where H_{K }is a cryptographic hash finction that produces an (n+2L_{MAX}) bit output from the old value of K_{t }and the (newly incremented) value of t. Note that in the replacement operations (denoted “←”), the token deletes the old values of t and K_{t}, replacing them with the new values. By deleting the old K_{t}, the token ensures that future leak functions cannot reveal information about the old (deleted) value. At step 122, the token uses the new values of t and K_{t }to compute an authenticator A=H_{A}(K_{t}||t||R). At step 125, the token sends both t and the authenticator A to the server, which receives them at step 130. At step 135, the server verifies that t is acceptable (e.g., not too large but larger than the value received in the last successful authentication). If t is invalid, the server proceeds to step 175. Otherwise, at step 140, the server initializes its loop counter i to zero and its key register K_{t}′ to K_{0}. At step 145, the server compares i with the received value of t, proceeding to step 160 if they are equal. Otherwise, at step 150, the server increments i by computing i←i+1. At step 155, the server computes K_{t}′←H_{K}(i||K_{t}), then proceeds back to step 145. At step 160, the server computes A′=H_{A}(K_{t′}||t||R). Finally, at step 165, the server compares A and A′, where the authentication succeeds at step 170 if they match, or fails at 175 if they do not match. - [0035]This design assumes that at the beginning of any transaction the attacker may have L
_{MAX }bits of useful information about the state of the token (e.g., K_{t}) that were obtained using the leak function F in a previous operation. During the transaction, the attacker can gain an additional L_{MAX }bits of useful information from the token. If, at any time, any 2L_{MAX }(or fewer) bits of useful information about the secret are known to the attacker, there are still (n+2L_{MAX})−2L_{MAX}=n or more unknown bits. These n bits of unknown information ensure that attacks will require O(2^{n}) effort, corresponding to the desired security factor. However, the attacker should have no more than L_{MAX }bits of useful information about K_{t }at the end of the transaction. The property that attackers lose useful information during normal operation of the system is a characteristic of the leak-proof or leak-resistant cryptosystem. In general, this information loss is achieved when the cryptosystem performs operations that convert attackers' useful partial information about the secret into useless information. (Information is considered useless if it gives an attacker nothing better than the ability to test candidate values in an O(2^{n}) exhaustive search or other “hard” operation. For example, if exhaustive search of X is hard and H is a good hash function, H(X) is useless information to an attacker trying to find X.) - [0036]Thus, the attacker is assumed to begin with L
_{MAX }bits of useful information about K_{t }before the token's K_{t}←H_{K}(t||K_{t}) computation. (Initial information about anything other than K_{t }is of no value to an attacker because K_{t }is the only secret value in the token. The function H_{K }and the value of t are not assumed to be secret.) The attacker's information can be any function of K_{t }produced from the previous operation's leaks. - [0037]3. Security Characteristics of Leak-Proof Systems
- [0038]The following section provides a technical discussion of the security characteristics of the exemplary leak-proof system described above. The following analysis is provided as an example of how the design can be analyzed, and how a system may be designed using general assumptions about attackers' capabilities. The discussion and assumptions do not necessarily apply to other embodiments of the invention and should not be construed as limiting the scope or applicability of the invention in any way.
- [0039]During the course of a transaction, the leak function F might reveal up to L
_{MAX }information about the system and its secrets. The design assumed that any information contained in the system may be leaked by F, provided that F does not reveal useful new information about values of K_{t }that were deleted before the operation started, and F does not reveal useful information about values of K_{t }that will be computed in future operations. These constraints are completely reasonable, since real-world leaks would not reveal information about deleted or not-yet-existent data. (The only way information about future K_{t }values could be leaked would be the bizarre case where the leak function itself included, or was somehow derived from, the function H_{K}.) In practice, these constraints on F are academic and of little concern, but they are relevant when constructing proofs to demonstrate the security of a leak-proof system. - [0040]If the leak occurs at the beginning of the H
_{K }computation, it could give the attacker up to 2L_{MAX }bits of useful information about the input value of K_{t}. Because K_{t }contains (2L_{MAX}+n) bits of secret information and the attacker may have up to 2L_{MAX }bits of useful information about the initial value of K_{t}, there remain at least (2L_{MAX}+n)−2L_{MAX}=n bits of information in K_{t }that are secret. The hash function H_{K }effectively mixes up these n bits to produce a secure new K_{t }during each transaction such that the attacker's information about the old K_{t }is no longer useful. - [0041]If the leak occurs at the end of the H
_{K }computation, it could give an attacker up to L_{MAX }bits of information about the final value of H_{K}, yielding L_{MAX }bits of information about the input to the subsequent transaction. This is not a problem, since the design assumes that attackers have up to L_{MAX }bits of information about K_{t }at the beginning of each transaction. - [0042]A third possibility is that the attacker's L
_{MAX }bits of information might describe intermediates computed during the operation H_{K}. However, even if the attacker could obtain L_{MAX }new bits of information about the input to H_{K }and also L_{MAX }bits of information about the output from H_{K}, the system would be secure, since the attacker would never have more than 2L_{MAX }bits of information about the input K_{t }or more than L_{MAX }bits of information about the output K_{t}. Provided that L_{MAX }bits of information from within H_{K }cannot reveal more than L_{MAX }bits of information about the input, or more than L_{MAX }bits of information about the output, the system will be secure. This will be true unless H_{K }somehow compresses the input to form a short intermediate which is expanded to form the output. While hash functions whose internal states are smaller than their outputs should not be used, most cryptographic hash functions are fine. - [0043]A fourth possibility is that part or all of the leak could occur during the A=H
_{A}(K_{t}||t||R) calculation. The attacker's total “budget” for observations is L_{MAX }bits. If L_{1 }bits of leak occur during the H_{K }computation, an additional L_{2 }bits of information can leak during the A=H_{A}(K_{t||R) operation, where L}_{2<L}_{MAX}−L_{1. }If the second leak provides information about K_{t}, this is no different from leaking information about the result of the H_{K }computation; the attacker will still conclude the transaction with no more than L_{MAX }bits of information about K_{t }because L_{1 }+L_{2}<L_{MAX}. However, the second leak could reveal information about A. To keep A secure against leaks (to prevent, for example, an attacker from using a leak to capture A and using A before the legitimate user can), the size of A should include an extra L_{MAX }bits (to provide security even if L_{2}=L_{MAX}). Like H_{K}, H_{A }should not leak information about deleted or future values of K_{t }that are not used in or produced by the given operation. As with the similar assumptions on leaks from H_{K}, this limitation is primarily academic and of little practical concern, since real-world leak functions do not reveal information about deleted or not-yet-computed data. However, designers might be cautious when using unusual designs for H_{A }that are based on or derived from H_{K}, particularly if the operation H_{A}(K_{t}||t||R) could reveal useful information about the result of computing H_{K}(t||K_{t}). - [0044]B. Other Leak-Resistant Symmetric Schemes
- [0045]The same basic technique of updating a key (K) with each transaction, such that leakage about a key during one transaction does not reveal useful information about a key in a subsequent (or past) transaction, can be easily extended to other applications besides authentication.
- [0046]1. Symmetric Data Verification
- [0047]For example and without limitation, leak-resistant symmetric data verification is often useful where a device needs to support symmetrically-signed code, data, content, or parameter updates (all of which will, as a matter of convenience, be denoted as “data” herein). In existing systems, a hash or MAC of the data is typically computed using a secret key and the data is rejected if computed hash or MAC does not match a value received with the data. For example, a MAC may be computed as HMAC(K,data), where HMAC is defined in “RFC 2104, HMAC:Keyed-Hashing for Message Authentication” by H. Krawczyk, M. Bellare, and R. Canetti, 1997. Traditional (non-leak-resistant) designs are often vulnerable to attacks including power consumption analysis of MAC finctions and timing analysis of comparison operations.
- [0048]In an exemplary leak-resistant verification protocol, a verifying device (the “verifier”) maintains a counter t and a key K
_{t}, which are initialized (for example at the factory) with t←0 and K_{t}←K_{0}. Before the transaction, the verifier provides t to the device providing the signed data (the “signer”), which also knows K_{0}. The signer uses t to compute K_{t+1}′ (the prime indicating a quantity derived by the signer, rather than at the verifier) from K_{0 }(or K_{t}′ or any other available value of K_{i}′). using the relation K_{i}′=H_{K}(i||K_{i−1}′), computes signature S′=HMAC(K_{t+}**1**′, data), and sends S′ plus any other needed information (such as data or t) to the verifier. The verifier confirms that the received value of t (if any) matches its value of t, and rejects the signature if it does not. If t matches, the verifier increments t and updates K_{t }in its nonvolatile memory by computing t←t+1 and K_{t}←H_{K}(t||K_{t}). In an alternative embodiment, if the received value of t is larger than the internal value but the difference is not unreasonably large, it may be more appropriate to accept the signature and perform multiple updates to K_{t }(to catch up with the signer) instead of rejecting the signature outright. Finally, the verifier computes S=HMAC(K_{t}, data) and verifies that S=S′, rejecting the signature if S does not equal the value of S′ received with the data. - [0049]2. Symmetric Encryption
- [0050]Besides authentication and verification, leak-resistant symmetric cryptography can also be tailored to a wide variety of applications and environments. For example, if data encryption is desired instead of authentication, the same techniques as were disclosed above may be used to generate a key K
_{t }used for encryption rather than verification. - [0051]3. Variations in Computational Implementation
- [0052]In the foregoing, various applications were disclosed for the basic technique of updating a key K
_{t }in accordance with a counter and deleting old key values to ensure that future leakage cannot reveal information about the now-deleted key. Those skilled in the art will realize, however, that the exemplary techniques described above may be modified in various ways without departing from the spirit and scope of the invention. For example, if communications between the device and the server are unreliable (for example if the server uses voice recognition or manual input to receive t and A), then small errors in the signature may be ignored. (One skilled in the art will appreciate that many functions may be used to determine whether a signature corresponds—sufficiently closely—to its expected value.) In another variation of the basic technique, the order of operations and of data values may be adjusted, or additional steps and parameters may be added, without significantly changing the invention. In another variation, to save on communication bandwidth or memory, the high order bits or digits of t may not need to be communicated or remembered. In another variation, as a performance optimization, devices need not recompute K_{t }from K_{0 }with each new transaction. For example, when a transaction succeeds, the server can discard K_{0 }and maintain the validated version of K_{t}. In another variation, if bi-directional authentication is required, the protocol can include a step whereby the server can authenticates itself to the user (or user's token) after the user's authentication is complete. In another variation, if the server needs to be secured against leaks as well (as in the case where the role of “server” is played by an ordinary user), it can maintain its own counter t. In each transaction, the parties agree to use the larger of their two t values, where the device with the smaller t value performs extra updates to K_{t }to synchronize t. In an alternate embodiment for devices that contain a clock and a reliable power source (e.g., battery), the update operation may be performed periodically, for example by computing K_{t}←H_{K}(t||K_{t}) once per second. The token uses the current K_{t }to compute A=H_{A}(K_{t}||t||R) or, if the token does not have any means for receiving R, it can output A=HA(K_{t}). The server can use its clock and local copy of the secret to maintain its own version of K_{t}, which it can use to determine whether received values of A are recent and correct. All of the foregoing show that the method and apparatus of the present invention can be implemented using numerous variations and modifications to the exemplary embodiments described herein, as would be understood by one skilled in the art. - [0053]III. Asymmetric Cryptographic Protocols
- [0054]The foregoing illustrates various embodiments of the invention that may be used with symmetric cryptographic protocols. As will be seen below, still other techniques of the present invention may be used in connection with asymmetric cryptographic operations and protocols. While symmetric cryptosystems are sufficient for some applications, asymmetric cryptography is required for many applications. There are several ways leak resistance can be incorporated into public key cryptosystems, but it is often preferable to have as little impact as possible on the overall system architecture. Most of the exemplary designs have thus been chosen to incorporate leak resistance into widely used cryptosystems in a way that only alters the key management device, and does not affect the certification process, certificate format, public key format, or processes for using the public key.
- [0055]A. Certified Diffie-Heilman
- [0056]Diffie-Hellman exponential key exchange is a widely used asymmetric protocol whereby two parties who do not share a secret key can negotiate a shared secret key. Implementations of Diffie-Hellman can leak information about the secret exponents, enabling attackers to determine the secret keys produced by those implementations. Consequently, a leak-resistant implementation of Diffie-Hellman would be useful. To understand such a leak-resistant implementation, it will be useful to first review a conventional Diffie-Hellman implementation.
- [0057]1. Conventional Certified Diffie-Hellman
- [0058]Typical protocols in the background art for performing certified Diffie-Hellman exponential key agreement involve two communicating users (or devices) and a certifying authority (CA). The CA uses an asymmetric signature algorithm (such as DSA) to sign certificates that specify a user's public Diffie-Heilman parameters (the prime p and generator g), public key (p
^{x }mod g, where x is the user's secret exponent), and auxiliary information (such as the user's identity, a description of privileges granted to the certificate holder, a serial number, expiration date, etc.). Certificates may be verified by anyone with the CA's public signature verification key. To obtain a certificate, user U typically generates a secret exponent (x_{u}), computes his or her own public key y_{u}=g^{x}^{ u }mod p, presents y_{u }along with any required auxiliary identifying or authenticating information (e.g., a passport) to the CA, who issues the user a certificate C_{u }Depending on the system, p and g may be unique for each user, or they may be system-wide constants (as will be assumed in the following description of Diffie-Hellman using the background art). - [0059]Using techniques of the background art, Alice and Bob can use their certificates to establish a secure communication channel. They first exchange certificates (C
_{Alice }and C_{Bob}). Each verifies that the other's certificate is acceptable (e.g., properly formatted, properly signed by a trusted CA, not expired, not revoked, etc.). Because this protocol will assume thatp and g are constants, they also check that the certificate's p and g match the expected values. Alice extracts Bob's public key (y_{Bob}) from C_{Bob }and uses her secret exponent (x_{Alice}) to compute z_{Alice=(Y}_{Bob})^{X}^{ Alice }mod p. Bob uses his secret exponent and Alice's public key to compute Z_{Bob}=(Y_{Alice})^{X}^{ Bob }mod p. If everything works correctly, z_{Alice}=Z_{Bob}, since:$\begin{array}{c}{z}_{\mathrm{Alice}}={\left({y}_{\mathrm{Bob}}\right)}^{{x}_{\mathrm{Alice}}}\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep\\ ={\left({g}^{{x}_{\mathrm{Bob}}}\right)}^{{x}_{\mathrm{Alice}}}\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep\\ ={\left({g}^{{x}_{\mathrm{Alice}}}\right)}^{{x}_{\mathrm{Bob}}}\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep\\ ={\left({y}_{\mathrm{Alice}}\right)}^{{x}_{\mathrm{Bob}}}\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep\\ ={z}_{\mathrm{Bob}}.\end{array}$ - [0060]Thus, Alice and Bob have a shared key z=z
_{Alice}=z=_{Bob}. An attacker who pretends to be Alice but does not know her secret exponent (x_{Alice}) will not be able to compute z_{Alice}=(y_{Bob})^{x}^{ Alice }mod p correctly. Alice and Bob can positively identify themselves by showing that they correctly found z. For example, each can compute and send the other the hash of z concatenated with their own certificate. Once Alice and Bob have verified each other, they can use a symmetric key derived from z to secure their communications. (For an example of a protocol in the background art that uses authenticated Diffie-Hellman, see “The SSL Protocol Version 3.0” by A. Freier, P. Karlton, and P. Kocher, Mar. 1996.) - [0061]2. Leak-Resistant Certified Diffie-Hellman
- [0062]A satisfactory leak-resistant public key cryptographic scheme should overcome the problem that, while certification requires the public key be constant, information about the corresponding private key should not leak out of the token that contains it. In the symmetric protocol described above, the design assumes that the leak function reveals no useful information about old deleted values of K
_{t }or about future values of K_{t }that have not yet been computed. Existing public key schemes, however, require that implementations repeatedly perform a consistent, usually deterministic, operation using the private key. For example, in the case of Diffie-Hellman, a leak-resistant token that is compatible with existing protocols and implementations should be able to perform the secret key operation y^{x }mod p, while ensuring that the exponent x remains secret. The radical reshuffling of the secret provided by the hash finction H_{K }in the symmetric approach cannot be used because the device should be able to perform the same operation consistently. - [0063]The operations used by the token to perform the private key operation are modified to add leak resistance using the following variables:
Register Comment x _{1}First part of the secret key (in nonvolatile updateable memory) x _{2}Second part of the secret key (in nonvolatile updateable memory) g The generator (not secret). p The public prime, preferably a strong prime (not secret). - [0064]The prime p and generator g may be global parameters, or may be specific to individual users or groups of users (or tokens). In either case, the certificate recipient should be able to obtain p and g securely, usually as built-in constants or by extracting them from the certificate.
- [0065]To generate a new secret key, the key generation device (often but not always the cryptographic token that will contain the key) first obtains or generates p and g, where p is the prime and g is a generator mod p. If p and g are not system-wide parameters, algorithms known in the background art for selecting large prime numbers and generators may be used. It is recommended that p be chosen with (p−1)/2 also prime, or at least that ø(p) not be smooth. (When (p−1)/2 is not prime, information about x
_{1 }and x_{2 }modulo small factors of ø(p) may be leaked, which is why it is preferable that ø(p) not be smooth. Note that ø denotes Euler's totient function.) Once p and g have been chosen, the device generates two random exponents x_{1 }and x_{2}. The lowest-order bit of x_{1 }and of x_{2 }is not considered secret, and may be set to 1. Using p, g, x_{1 }and x_{2}, the device can then compute its public key as g^{x}^{ 1 }^{x}^{ 2 }mod p and submit it, along with any required identifying information or parameters needed (e.g., p and g), to the CA for certification. - [0066][0066]FIG. 2 illustrates the process followed by the token to perform private key operations. At step 205, the token obtains the input message y, its own (non-secret) prime p, and its own secret key halves (x
_{1 }and x_{2}). If x_{1}, x_{2}, and p are stored in encrypted and/or authenticated form, they would be decrypted or verified at this point. At this step, the token should verify that 1 <y <−1. At step 210, the token uses a random number generator (or pseudorandom number generator) to select a random integer b_{0}, where 0 < b_{0}<p. At step 215, the token computes b_{1}=b_{0}^{−1 }mod p. The inverse computation mod p may be performed using the extended Euclidean algorithm or the formula b_{1}=b_{0}^{ø(p)-1 }mod p. At step 220, the token computes b_{2 }=b_{1}^{x}^{ 1 }mod p. At this point, b_{1 }is no longer needed; its storage space may be used to store b_{2}. Efficient algorithms for computing modular exponentiation, widely known in the art, may be used to complete step 220. Alternatively, when a fast modular exponentiator is available, the computation b_{2 }may be performed using the relationship b_{2}=b_{0}^{ø(p)-x}^{ 1 }mod p. At step 225, the token computes b_{3}=b_{2}^{x}^{ 2 }mod p. At this point, b_{2 }is no longer needed; its storage space may be used to store b_{3}. At step 230, the token computes z_{0}=b_{0}y mod p. At this point,y and b_{0 }are no longer needed; their space may be used to store r_{1 }(computed at step 235) and z_{0}. At step 235, the token uses a random number generator to select a random integer r_{1}, where 0<r_{1}<ø(p) and gcd(r_{1}, ø(p))=1. (If (p−1/2 is known to be prime, it is sufficient to verify that r_{1 }is odd.) At step 240, the token updates x_{1 }by computing x_{1}←x_{1}r_{1 }mod ø(p). The old value of x_{1 }is deleted and replaced with the updated value. At step 245, the token computes r_{2}=(r_{1}^{−1}) mod ø(p). If (p−1/2 is prime, then r_{2 }can be found using a modular exponentiator and the Chinese Remainder Theorem. Note that r_{1 }is not needed after this step, so its space may be used to store r_{2}. At step 250, the token updates x_{2 }by computing x_{2}←x_{2}r_{2 }mod ø(p). The old value of x_{2 }should be deleted and replaced with the updated value. At step 255, the token computes z_{1}=(z_{0})^{x}^{ 1 }mod p. Note that z_{0 }is not needed after this step, so its space may be used to store z_{1}. At step 260, the token computes z_{2}=(z_{1})^{x}^{ 2 }mod p. Note that z_{1 }is not needed after this step, so its space may be used to store z_{2}. At step 265, the token finds the exponential key exchange result by computing z=z_{2}b_{3 }mod p. Finally, at step 270, the token erases and frees any remaining temporary variables. - [0067]The process shown in FIG. 2 correctly computes z=mod p, where x=x
_{1}x_{2 }mod ø(p), since:$\begin{array}{c}z={z}_{2}\ue89e{b}_{3}\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep\\ =\left({z}_{1}^{{x}_{2}}\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep\right)\ue89e\left({b}_{2}^{{x}_{2}}\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep\right)\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep\\ =\left({\left({z}_{0}^{{x}_{1}}\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep\right)}^{{x}_{2}}\right)\ue89e\left({\left({b}_{1}^{{x}_{1}}\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep\right)}^{{x}_{2}}\right)\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep\\ ={\left({b}_{0}\ue89ey\ue89e\text{\hspace{1em}}\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep\right)}^{{x}_{1}\ue89e{x}_{2}}\ue89e{\left({b}_{0}^{-1}\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep\right)}^{{x}_{1}\ue89e{x}_{2}}\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep\\ ={y}^{{x}_{1}\ue89e{x}_{2}}\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep\\ ={y}^{x}\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep.\end{array}$ - [0068]The invention is useful for private key owners communicating with other users (or devices) who have certificates, and also when communicating with users who do not.
- [0069]If Alice has a certificate and wishes to communicate with Bob who does not have a certificate, the protocol proceeds as follows. Alice sends her certificate (C
_{Alice}) to Bob, who receives it and verifies that it is acceptable. Bob extracts y_{Alice }(along with p_{Alice }and g_{Alice}, unless they are system-wide parameters) from C_{Alice}. Next, Bob generates a random exponent X_{BA}, where 0 <X_{AB}<ø(P_{Alice}). Bob then uses his exponent X_{AB }and Alice's parameters to calculate Y_{BA}=(g_{Alice}^{x}^{ BA })mod p_{Alice }and the session key z=(y_{Alice}^{X}^{ BA })mod p_{Alice}. Bob sends Y_{BA }to Alice, who performs the operation illustrated in FIG. 2 to update her internal parameters and derive z from y_{BA}. Alice then proves that she computed z correctly, for example by sending Bob H(z||C_{Alice}). (Alice cannot authenticate Bob because he does not have a certificate. Consequently, she does not necessarily need to verify that he computed z successfully.) Finally, Alice and Bob can use z (or, more commonly, a key derived from z) to secure their communications. - [0070]If both Alice and Bob have certificates, the protocol works as follows. First, Alice and Bob exchange certificates (C
_{Alice }and C_{Bob}), and each verifies that other's certificate is valid. Alice then extracts the parameters p_{Bob}, g_{Bob}, and Y_{Bob }from C_{Bob, }and Bob extracts p_{Alice}, g_{Alice}, and y_{Alice }from C_{Alice Alice then generates a random exponent X}_{AB }where 0 <X_{AB}<ø(p_{Bob}), computes y_{AB}=(g_{Bob})^{x}^{ AB }mod p_{Bob, and computes z}_{AB}-(Y_{Bob}. Bob generates a random X_{BA }where 0<X_{BA}<ø(p_{Alice}), computes Y_{BA}=(g_{Alice})^{X}^{ BA }mod p_{Alice}, and computes Z_{BA}-(Y_{Alice})^{x}^{ BA }mod p_{Alice}. Bob sen Alice, and Alice sends y_{AB }to Bob. Alice and Bob each perform the operation shown in FIG. 2, where each uses the prime p from their own certificate and their own secret exponent halves (x_{1 }and x_{2}). For the message y in FIG. 2, Alice uses y_{BA }(received from Bob), and Bob uses y_{AB }(received from Alice). Using the process shown in FIG. 2, Alice computes z. Using z and z_{AB }(computed previously), she can find a session key K. This may be done, for example, by using a hash function H to compute K=H(z||z_{AB}). The value of z Bob obtains using the process shown in FIG. 2 should equal Alice's z_{AB}, and Bob's z_{BA }(computed previously) should equal Alice's z. If there were no errors or attacks, Bob should thus be able to find K, e.g., by computing K=H(z_{BA||z). }Alice and Bob now share K. Alice can prove her identity by showing that she computed K correctly, for example by sending Bob H(K||C_{Alice}). Bob can prove his identity by sending Alice H(K||C_{Bob}). Alice and Bob can then secure their communications by encrypting and authenticating using K or a key derived from K. - [0071]Note that this protocol, like the others, is provided as an example only; many variations and enhancements of the present invention are possible and will be evident to one skilled in the art. For example, certificates may come from a directory, more than two parties can participate in the key agreement, key escrow functionality may be added, the prime modulus p may be replaced with a composite number, etc. Note also that Alice and Bob as they are called in the protocol are not necessarily people; they would normally be computers, cryptographic devices, etc.
- [0072]For leak resistance to be effective, attackers should not be able to gain new useful information about the secret variables with each additional operation unless a comparable amount of old useful information is made useless. While the symmetric design is based on the assumption that leaked information will not survive the hash operation H
_{K}, this design uses multiplication operations mod ø(p) to update x_{1 }and x_{2}. The most common variety of leaked information, statistical information about exponent bits, is not of use to attackers in this design, as the exponent update process (x_{1}←x_{1}r_{1 }mod ø(p) and x_{2}←x_{2}r_{2 }mod ø(p)) destroys the utility of this information. The only relevant characteristic that survives the update process is that x_{1}x_{2 }mod ø(p) remains constant, so the system designer should be careful to ensure that the leak function does not reveal information allowing the attacker to find new useful information about x_{1}x_{2 }mod ø(p). - [0073]There is a modest performance penalty, approximately a factor of four, for the leak-resistant design as described. One way to improve performance is to remove the blinding and unblinding operations, which are often unnecessary. (The blinding operations prevent attackers from correlating input values of y with the numbers processed by the modular exponentiation operation.) Alternatively or additionally, it is possible to update and reuse values of b
_{0}, b_{3}, r_{1}, and r_{2 }by computing b_{0}←(b_{0}) mod p, b_{3}←(b_{3})^{v }mod p,r_{1}←(r_{1})^{w }mod ø(p), and r_{2}←(r_{2})^{w }mod ø(p), where v and w are fairly short random exponents. Note that the relationship b_{3}←b_{0}^{-x}^{ 1 }^{x}^{ 2 }mod p remains true when b_{0 }and b_{3 }are both raised to the power v (mod p). The relationship r_{2}=(r_{1}^{-1}) mod ø(p) also remains true when r_{1 }and r_{2 }are exponentiated (mod ø(p)). Other parameter update operations may also be used, such as exponentiation with fixed exponents (e.g., v=w= 3), or multiplication with random values and their inverses, mod p and ø(p). The time per transaction with this update process is about half that of the unoptimized leak-resistant implementation, but additional storage is required and care should be taken to ensure that b_{0}, b_{3}, r_{2 }will not be leaked or otherwise compromised. - [0074]It should also be noted that with this particular type of certified Diffie-Hellman, the negotiated key is the same every time any given pair of users communicate. Consequently, though the blinding operation performed using b
_{0 }and b_{3 }does serve to protect the exponents, the result K can be leaked in the final step or by the system after the process is complete. If storage is available, parties could keep track of the values of y they have received (or their hashes) and reject duplicates. Alternatively, to ensure that a different result is obtained from each negotiation, Alice and Bob can generate and exchange additional exponents, w_{Alice }and w_{Bob}, for example with 0<w<2^{128 }(where 2^{128 }<<p). Alice sets y=(y_{BA})^{w}^{ Alice }^{W}^{ Bob }mod p instead ofjust y=Y_{BA}, and Bob sets y=(y_{AB})^{w}^{ Bob }^{w}^{ Alice }mod p instead of y=y_{AB }before performing the operation shown in FIG. 2. - [0075]B. Leak-Resistant RSA
- [0076]Another asymmetric cryptographic protocol is RSA, which is widely used for digital signatures and public key encryption. RSA private key operations rely on secret exponents. If information about these secret exponents leaks from an implementation, its security can be compromised. Consequently, a leak-resistant implementation of RSA would be useful.
- [0077]To give RSA private key operations resistance to leaks, it is possible to divide the secret exponent into two halves such that information about either half is destroyed with each operation. These are two kinds of RSA private key operations. The first, private key signing, involves signing a message with one's own private key to produce a digital signature verifiable by anyone with one's corresponding public key. RSA signing operations involve computing S=M
^{d }mod n, where M is the message, S is the signature (verifiable using M=S^{e }mod n), d is the secret exponent and equals e^{-1 }mod ø(n), and n is the modulus and equals pq, where n and e are public and p and q are secret primes, and ø is Euler's phi finction. An RSA public key consists of e and n, while an RSA private key consists of d and n (or other representations of them). For RSA to be secure, d, ø(n), p, and q should all be secret. - [0078]The other RSA operation is decryption, which is used to recover messages encrypted using one's public key. RSA decryption is virtually identical to signing, since the decrypted message M is recovered from the ciphertext C by computing M=C
^{d }mod n, where the ciphertext C was produced by computing C=M^{e }mod n. Although the following discussion uses variable names from the RSA signing operation, the same techniques may be applied similarly to decryption. - [0079]An exemplary leak-resistant scheme for RSA implementations may be constructed as illustrated in FIG. 3. At step 300, prior to the commencement of any signing or decryption operations, the device is initialized with (or creates) the public and private keys. The device contains the public modulus n and the secret key components d
_{1}, d_{2}, and z, and k, where k is a prime number of medium-size (e.g., 0<k<2^{128}) chosen at random, z=kø(n), d_{1 }is a random number such that 0<d_{1}<z and gcd(d_{1}z)=1, and d_{2 }=(e^{-1 }mod ø(n))(d_{1}^{-1 }mod z) mod z. In this invention, d_{1 }and d_{2 }replace the usual RSA secret exponent d. Techniques for generating the initial RSA primes (e.g., p and q) and modulus (n) are well known in the background art. At step 305, the device computes a random prime k′ of medium size (e.g., 0<k′<2^{128}). (Algorithms for efficiently generating prime numbers are known in the art.) - [0080]At step 303, the device (token) receives a message M to sign (or to decrypt). At step 310, the device updates z by computing z←k′z. At step 315, the device updates z again by computing z←z/k. (There should be no remainder from this operation, since k divides z.) At step 320, k is replaced with k′ by performing k←k′. Because k′will not be used in subsequent operations, its storage space may be used to hold R (produced at step 325). At step 325, the device selects a random R where 0<R<z and gcd(R,z)=1. At step 330, the device updates d
_{1 }by computing d_{1}R mod z. At step 335, the device finds the inverse of R by computing R′←R^{-1 }mod z using, for example, the extended Euclidean algorithm. Note that R is no longer needed after this step, so its storage space may be erased and used to hold R′. At step 340, the device updates d_{2 }by computing d_{2}←d_{2}R′ mod z. At step 345, the device computes S_{0}=M^{d}^{ 1 }mod n, where M is the input message to be signed (or the message to be decrypted). Note that M is no longer needed after this step, so its storage space may be used for S_{0}. At step 350, the device computes S=S_{0}^{d}^{ 2 }mod n, yielding the final signature (or plaintext if decrypting a message). Leak-resistant RSA has similar security ch Characteristics as normal RSA; standard message padding, post-processing, and key sizes may be used. Public key operations are also performed normally (e.g., M=S^{e }mod n). - [0081]A simpler RSA leak resistance scheme may be implemented by splitting the exponent d into two halves d
_{1 }and d_{2 }such that d_{1}+d_{2}=d. This can be achieved during key generation by choosing d_{1 }to be a random integer where 0<d_{1}<d, and choosing d_{2 }←d-d_{1}. To perform private key operations, the device needs d_{1 }and d_{2}, but it does not need to contain d. Prior to each private key operation, the cryptographic device identifies which of d_{1 }and d_{2 }is larger. If d_{1>d}_{2}, then the device computes a random integer r where 0<r<d_{1}, adds r to d_{2 }(i.e., d_{2}←d_{2}+r), and subtracts r from d_{1}, (i.e., d_{1←d}_{1}-r). Otherwise, if d_{1<d}_{2}, then the device chooses a random integer r where 0<r<d_{2}, adds r to d_{1}(i.e., d_{1←d}_{1}+r), and subtracts r from d_{2 }(i.e., d_{2}←d_{2}-r). Then, to perform the private key operation on a message M, the device computes s_{1=M}^{d}^{ 1 }mod n, s_{2}=M^{d}^{ 2 }modn, and computes the signature S=s_{1}s_{2}mod n. While this approach of splitting the exponent into two halves whose sum equals the exponent can also be used with Diffie-Hellman and other cryptosystems, dividing the exponent into the product of two numbers mod ø(p) is usually preferable since the assumption that information about d_{1}+d_{2 }will not leak is less conservative than the assumption that information about x_{1}x_{2 }mod ø(p) will not leak. In the case of RSA, updates mod ø(n) cannot be done safely, since ø(n) must be kept secret. - [0082]When the Chinese Remainder Theorem is required for performance, it is possible to use similar techniques to add leak resistance by maintaining multiples of the secret primes (p and q) that are updated every time (e.g., multiplying by the new multiple then dividing by the old multiple). These techniques also protect the exponents (dp and dq) as multiples of their normal values. At the end of the operation, the result S is corrected to compensate for the adjustments to dp, dq, p, and q.
- [0083]An exemplary embodiment maintains state information consisting of the values n, B
_{i}, B_{f},_{pk},_{qk}, d_{pk}, d_{qk},_{PInv}, and f. To convert a traditional RSA CRT private key (consisting of p, q, d_{p}, and d_{q }with p<q) into the new representation, a random value for k is chosen, where 0<k<2^{64}. The value B_{i }is chosen at random where 0<B_{i}<n, and R_{l }and R_{2 }are chosen at random where 0<R_{l}<2^{64 }and 0<R_{2}<2^{64}. (Of course, constants such as 2^{64 }are chosen as example values. It is possible, but not necessary, to place constraints on random numbers, such as requiring that they be prime.) The leak-resistant private key state is then initialized by setting n←pq,B_{f}←B_{i}^{-d }p_{k }mod n,_{pk}←(k)(p),_{qk}←(k)(q),d_{pk}←d_{p}+(R_{l})(p)-R_{l}d_{qk}←d_{q}+(R_{2})(q)-R_{2},_{PInv}←k(p^{-1}mod q), and f←0. - [0084]To update the system state, first a random value α may be produced where 0<α< 2
^{64}. Then compute p_{k}←((α)(qk))/k,_{PInv}←((α)(_{PInv}))/k,k←αThe exponents d_{pk }and d_{qk }may be updated by computing d_{pk}←d_{pk}±(R_{3p}-R_{3}k) and d_{qk}←d_{qk}±(R_{4qk}-R_{4}k), where R_{3 }and R_{4 }can be random or constant values (even 1). The blinding factors B_{i }and B_{f }may be updated by computing B_{i}=B_{i}^{2 }mod n and B_{f}=B_{f}^{2 }mod n, by computing new blinding factors, by exponentiating with a value other than 2, etc. Update processes should be performed as often as practical, for example before or after each modular exponentiation process. Before the update begins, a failure counter f is incremented, and when the update completes fis set to zero. If f ever exceeds a threshold value indicating too many consecutive failures, the device should temporarily or permanently disable itself. Note that if the update process is interrupted, memory values should not be left in intermediate states. This can be done by using complete reliable memory updates. If the total set of variable changes is too large for a single complete update, it is possible to store α first then do each variable update reliably which keeping track of how many have been completed. - [0085]To perform a private key operation (such as decryption or signing), the input message C is received by the modular exponentiator. Next, the value is blinded by computing C′←(C)(B
_{i}) mod n. The blinded input message is then used to compute modified CRT intermediates by computing m_{pk}←(C′)^{d}^{ pk }P_{k }mod p_{k }and m_{qk}←(C′)^{d}^{ qk }mod q_{k}. Next in the exemplary embodiment, the CRT intermediates are multiplied by k, e.g. m_{pk}←(k)(m_{pk}) mod p_{k }and m_{qk}←(k)(m_{qk}) mod qk. The CRT difference is then computed as m_{pqk}=(m_{pk}[+qk]-m_{qk) [mod }_{qk], where the addition of }_{qk }and/or reduction mod_{qk }are optional. (The addition of_{qk }ensures that the result is non-negative.) The blinded result can be computed as${M}^{\prime}=\frac{\left({m}_{\mathrm{pk}}\right)\ue89ek+{p}_{k}[\left(\frac{\left({p}_{\mathrm{Inv}}\right)\ue89e\left({m}_{\mathrm{pqk}}\right)}{k}\right)\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89e{q}_{k}}{{k}^{2}},$ - [0086]As one of ordinary skill in the art will appreciate, variant forms of the invention are possible. For example, the computational processes can be re-ordered or modified without significantly changing the invention. Some portions (such as the initial and blinding steps) can be skipped. In another example, it is also possible to use multiple blinding factors (for example, instead of or in addition to the value k).
- [0087]In some cases, other techniques may also be appropriate. For example, exponent vector codings may be rechosen frequently using, for example, a random number generator. Also, Montgomery arithmetic may be performed mod j where j is a value that is changed with each operation (as opposed to traditional Montgomery implementations where j is constant with j=2
^{k}). The foregoing shows that the method and apparatus of the present invention can be implemented using numerous variations and modifications to the exemplary embodiments described herein, as would be known by one skilled in the art. - [0088]C. Leak-Resistant ElGamal Public Key Encryption and Digital Signatures Sti
- [0089]Still other asymmetric cryptographic protocols that may be improved using the techniques of the invention. For example, ElGamal and related cryptosystems are widely used for digital signatures and public key encryption. If information about the secret exponents and parameters leaks from an ElGamal implementation, security can be compromised. Consequently, leak-resistant implementations of ElGamal would be useful.
- [0090]The private key in the ElGamal public key encryption scheme is a randomly selected secret α where 1 <α<p−2. The non-secret parameters are a prime p, a generator α, and α
^{α}mod p. To encrypt a message m, one selects a random k (where 1<k<p−2) and computes the ciphertext (γ, δ) where γ=α^{k }mod p and δ=m(α^{α}mod p)^{k }mod p. Decryption is performed by computing m=δ(γ^{p−1α}) mod p. (See the Handbook of Applied Cryptography by A. Menezes, P. van Oorschot, and S. Vanstone, 1997, pages 294-298, for a description of ElGamal public-key encryption). - [0091]To make the ElGamal public-key decryption process leak-resistant, the secret exponent (p−1-α) is stored in two halves α
_{1 }and α_{2}, such that α_{1}α_{2}=(ø(p)−α) mod ø(p). - [0092]When generating ElGamal parameters for this leak-resistant implementation, it is recommended, but not required, that p be chosen with (p−1)/2 prime so that ø(p)/2 is prime.
- [0093]The variables α
_{1 }and α_{2 }are normally chosen initially as random integers between 0 and ø(p). Alternatively, it is possible. to generate a first, then choose α_{1 }and α_{2}, as by selecting a, relatively prime to ø(p) and computing α_{2}= (α^{-1 }mod ø(p))(α_{1}^{-1 }mod ø(p)) mod ø(p). - [0094][0094]FIG. 4 illustrates an exemplary leak-resistant ElGamal decryption process. At step 405, the decryption device receives an encrypted message pair (γ, δ). At step 410, the device selects a random r
_{1 }where 1<r_{1}<ø(p) and gcd(r_{1}, ø(p))=1. At step 415, the device updates α_{1 }by computing α←α_{1}r_{1 }, mod ø(p), over-writing the old value of α_{1 }with the new value. At step 420, the device computes the inverse of r_{1 }by computing r_{2 }=(r_{1})^{-1 }mod ø(p). Because r_{1 }is not used after this step, its storage space may be used to hold r_{2. }Note that if (p−1)/2 is prime, then r_{2 }may also be found by finding r_{2}′=r_{1}^{(P−1)/2-2 }mod (p−1)/2 and using the CRT to find r_{2 }(mod p−1). At step 425, the device updates a_{2 }by computing a_{2}←α_{2}r_{2 }mod ø(p). At step 430, the device begins the private key (decryption) process by computing m′=γ^{α}^{ 1 }mod p. At step 435, the device computes m=δ(m′)^{α}^{ 2 }mod p and returns the message m. If verification is successful, the result equals the original message because:$\begin{array}{c}\left(\delta \right)\ue89e{\left({m}^{\prime}\right)}^{{a}_{2}}\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep=\left({m\ue8a0\left({\alpha}^{a}\right)}^{k}\right)\ue89e{\left({\gamma}^{{a}_{1}}\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep\right)}^{{a}_{2}}\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep\\ =\left(m\ue89e\text{\hspace{1em}}\ue89e{\alpha}^{\mathrm{ak}}\right)\ue89e\left({\gamma}^{{a}_{1}\ue89e{a}_{2}\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89e\phi \ue8a0\left(p\right)}\right)\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep\\ =\left(m\ue89e\text{\hspace{1em}}\ue89e{\alpha}^{\mathrm{ak}}\right)\ue89e\left({\left({\alpha}^{k}\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep\right)}^{-a\ue89e\text{\hspace{1em}}\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89e\phi \ue8a0\left(p\right)}\right)\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep\\ =\left(m\ue89e\text{\hspace{1em}}\ue89e{\alpha}^{\mathrm{ak}}\right)\ue89e\left({\alpha}^{-\mathrm{ak}}\right)\ue89e\mathrm{mod}\ue89e\text{\hspace{1em}}\ue89ep\\ =m\end{array}$ - [0095]As with the ElGamal public key encryption scheme, the private key for the ElGamal digital signature scheme is a randomly-selected secret α, where 1<α<p−2. The public key is also similar, consisting of a prime p, a generator α, and public parameter y where y=α
^{α}mod p. To sign a message m, the private key holder chooses or precomputes a random secret integer k (where 1<k<p−2 and k is relatively prime to p−1) and its inverse, k^{-1 }mod ø(p). Next, the signer computes the signature (r, s), where r= α^{k }mod p, s=((k^{-1 }modø(p))[H(m)−αr])mod ø(p), and H(m) is the hash of the message. Signature verification is performed using the public key (p, α, y) by verifying that 1<r< p and by verifying that y^{r}r^{s }mod p=α^{h(m) }mod p. - [0096]To make the ElGamal digital signing process leak-resistant, the token containing the private key maintains three persistent variables, α
_{k}, w, and r. Initially, αa_{k}=α(the private exponent), w=1, and r=α. When a message m is to be signed (or during the precomputation before signing), the token generates a random number b and its inverse b^{-1 }mod ø(p), where b is relatively prime to ø(p) and 0 <b<ø(p). The token then updates a_{k}, w, and r by computing a_{k}←(a_{k})(b^{-1}) mod 526 (p), w←(w)(b^{-1}) mod ø(p), and r←(r^{b}) mod p. The signature (r, s) is formed from the updated value of r and s, where s=(w(H(m)−a_{k}r))modø(p). Note that a_{k}, w, and r are not randomized prior to the first operation, but should be randomized before exposure to possible attack, since otherwise the first operation may leak more information than subsequent ones. It is thus recommended that a dummy signature or parameter update with a_{k}←(a_{k})(b^{-1}) mod ø(p), w←(w)(b^{-1}) mod ø(p), and r←(r^{b}) mod p be performed immediately after key generation. Valid signatures produced using the exemplary tamper-resistant ElGamal process may be checked using the normal ElGamal signature verification procedure. - [0097]It is also possible to split all or some the ElGamal variables into two halves as part of the leak resistance scheme. In such a variant, α is replaced with α
_{1 }and α_{2}, w with w_{1 }and w_{2}, and r with r_{1 }and r_{2}. It is also possible to reorder the operations by performing, for example, the parameter updates as a precomputation step prior to receipt of the enciphered message. Other variations and modifications to the exemplary embodiments described herein will be evident to one skilled in the art. - [0098]D. Leak-Resistant DSA
- [0099]Another commonly used asymmetric cryptographic protocol is the Digital Signature Algorithm (DSA, also known as the Digital Signature Standard, or DSS), which is defined in “Digital Signature Standard (DSS),” Federal Information Processing Standards Publication 186, National Institute of Standards and Technology, May 19, 1994 and described in detail in the
*Handbook of Applied Cryptography,*pages 452 to 454. DSA is widely used for digital signatures. If information about the secret key leaks from a DSA implementation, security can be compromised. Consequently, leak-resistant implementations of DSA would be useful. - [0100]In non-leak-proof systems, the private key consists of a secret parameter α, and the public key consists of (p, q, α, y), where p is a large (usually 512 to 1024 bit) prime, q is a 160-bit prime, α is a generator of the cyclic group of order q mod p, and y=α
^{α}mod p. To sign a message whose hash is H(m), the signer first generates (or precomputes) a random integer k and its inverse k^{-1 }mod q, where 0<k<q. The signer then computes the signature (r, s), where r=(a^{k }mod p) mod q, and s=(k^{-1 }mod q)(H(m)+αr) mod q. - [0101]In an exemplary embodiment of a leak-resistant DSA signing process, the token containing the private key maintains two variables in nonvolatile memory, a
_{k }and k, which are initialized with a_{k}=αand k=1. When a message m is to be signed (or during the precomputation before signing), the token generates a random integer b and its inverse b^{-1 }mod q, where 0 <b<q. The token then updates ak and k by computing a_{k}←(α_{kb}^{-1 }mod q)(k) mod q, followed by k←b. The signature (r, s) is formed from the updated values of a_{k }and k by computing r=α^{k }mod p (which may be reduced mod q), and s=[(b^{-1}H(m) mod q)+(α_{k}r) mod q] mod q. As indicated, when computing s, b^{-1}H(m) mod q and (a_{k}r) mod q are computed first, then combined mod q. Note that a_{k }and k should be randomized prior to the first operation, since the first update may leak more information than subsequent updates. It is thus recommended that a dummy signature (or parameter update) be performed immediately after key generation. Valid signatures produced using the leak-resistant DSA process may be checked using the normal DSA signature verification procedure. - [0102]IV. Other Algorithms and Applications
- [0103]Still other cryptographic processes can be made leak-proof or leak-resistant, or may be incorporated into leak-resistant cryptosystems. For example, cryptosystems such as those based on elliptic curves (including elliptic curve analogs of other cryptosystems), secret sharing schemes, anonymous electronic cash protocols, threshold signatures schemes, etc. be made leak resistant using the techniques of the present invention.
- [0104]Implementation details of the schemes described may be adjusted without materially changing the invention, for example by re-ordering operations, inserting steps, substituting equivalent or similar operations, etc. Also, while new keys are normally generated when a new system is produced, it is often possible to add leak resistance retroactively while maintaining or converting existing private keys.
- [0105]Leak-resistant designs avoid performing repeated mathematical operations using non-changing (static) secret values, since they are likely to leak out. However, in environments where it is possible to implement a simple function (such as an exclusive OR) that does not leak information, it is possible use this finction to implement more complex cryptographic operations.
- [0106]While the exemplary implementations assume that the leak functions can reveal any information present in the system, designers may often safely use the (weaker) assumption that information not used in a given operation will not be leaked by that operation. Schemes using this weaker assumption may contain a large table of precomputed subkey values, from which a unique or random subset are selected and/or updated for each operation. For example, DES implementations may use indexed permutation lookup tables in which a few table elements are exchanged with each operation.
- [0107]While leak resistance provides many advantages, the use of leak resistance by itself cannot guarantee good security. For example, leak-resistant cryptosystems are not inherently secure against error attacks, so operations should be verified. (Changes can even be made to the cryptosystem and/or leak resistance operations to detect errors.) Similarly, leak resistance by itself does not prevent attacks that extract the entire state out of a device (e.g., L=L
_{MAX}). For example, traditional tamper resistance techniques may be required to prevent attackers from staining ROM or EEPROM memory cells and reading the contents under a microscope. Implementers should also be aware of interruption attacks, such as those that involve disconnecting the power or resetting a device during an operation, to ensure that secrets will not be compromised or that a single leaky operation will not be performed repeatedly. (As a countermeasure, devices can increment a counter in nonvolatile memory prior to each operation, and reset or reduce the counter value when the operation completes successfully. If the number of interrupted operations since the last successful update exceeds a threshold value, the device can disable itself.) Other tamper resistance mechanisms and techniques, such as the use of fixed-time and fixed-execution path code or implementations for critical operat conjunction with leak resistance, particularly for systems with a relatively low self-healing rate (e.g., L_{MAX }is small). - [0108]Leak-resistant algorithms, protocols, and devices may be used in virtually any application requiring cryptographic security and secure key management, including without limitation: smartcards, electronic cash, electronic payments, funds transfer, remote access, timestamping, certification, certificate validation, secure e-mail, secure facsimile, telecommunications security (voice and data), computer networks, radio and satellite communications, infrared communications, access control, door locks, wireless keys, biometric devices, automobile ignition locks, copy protection devices, payment systems, systems for controlling the use and payment of copyrighted information, and point of sale terminals.
- [0109]The foregoing shows that the method and apparatus of the present invention can be implemented using numerous variations and modifications to the exemplary embodiments described herein, as would be known by one skilled in the art. Thus, it is intended that the scope of the present invention be limited only with regard to the claims below.

Referenced by

Citing Patent | Filing date | Publication date | Applicant | Title |
---|---|---|---|---|

US6938050 | Apr 23, 2002 | Aug 30, 2005 | International Business Machines Corporation | Content management system and methodology employing a tree-based table hierarchy which accomodates opening a dynamically variable number of cursors therefor |

US6944627 | Apr 23, 2002 | Sep 13, 2005 | International Business Machines Corporation | Content management system and methodology employing a tree-based table hierarchy featuring arbitrary information retrieval from different locations in the hierarchy |

US6947948 | Apr 23, 2002 | Sep 20, 2005 | International Business Machines Corporation | Version-enabled, multi-typed, multi-targeting referential integrity relational database system and methodology |

US6950815 | Apr 23, 2002 | Sep 27, 2005 | International Business Machines Corporation | Content management system and methodology featuring query conversion capability for efficient searching |

US6950937 * | May 30, 2001 | Sep 27, 2005 | Lucent Technologies Inc. | Secure distributed computation in cryptographic applications |

US6973271 | Jul 5, 2001 | Dec 6, 2005 | Wave7 Optics, Inc. | System and method for communicating optical signals between a data service provider and subscribers |

US6999966 | Apr 23, 2002 | Feb 14, 2006 | International Business Machines Corporation | Content management system and methodology for implementing a complex object using nested/recursive structures |

US7035854 | Apr 23, 2002 | Apr 25, 2006 | International Business Machines Corporation | Content management system and methodology employing non-transferable access tokens to control data access |

US7039329 | Jun 23, 2003 | May 2, 2006 | Wave7 Optics, Inc. | System and method for increasing upstream communication efficiency in an optical network |

US7058260 | Oct 15, 2003 | Jun 6, 2006 | Wave7 Optics, Inc. | Reflection suppression for an optical fiber |

US7082455 | Apr 23, 2002 | Jul 25, 2006 | International Business Machines Corporation | Method and apparatus of parameter passing of structured data for stored procedures in a content management system |

US7085281 | Oct 26, 2001 | Aug 1, 2006 | Wave7 Optics, Inc. | Method and system for processing upstream packets of an optical network |

US7130541 | Oct 4, 2001 | Oct 31, 2006 | Wave7 Optics, Inc. | System and method for communicating optical signals upstream and downstream between a data service provider and subscriber |

US7142670 * | Aug 31, 2001 | Nov 28, 2006 | International Business Machines Corporation | Space-efficient, side-channel attack resistant table lookups |

US7146104 | Apr 17, 2003 | Dec 5, 2006 | Wave7 Optics, Inc. | Method and system for providing a return data path for legacy terminals by using existing electrical waveguides of a structure |

US7184664 | Jan 8, 2002 | Feb 27, 2007 | Wave7 Optics, Inc. | Method and system for providing a return path for signals generated by legacy terminals in an optical network |

US7190901 | Mar 14, 2003 | Mar 13, 2007 | Wave7 Optices, Inc. | Method and system for providing a return path for signals generated by legacy terminals in an optical network |

US7197244 | Oct 26, 2001 | Mar 27, 2007 | Wave7 Optics, Inc. | Method and system for processing downstream packets of an optical network |

US7218735 * | Apr 18, 2001 | May 15, 2007 | Gemplus | Cryptography method on elliptic curves |

US7218855 | May 20, 2002 | May 15, 2007 | Wave7 Optics, Inc. | System and method for communicating optical signals to multiple subscribers having various bandwidth demands connected to the same optical waveguide |

US7254600 | Sep 18, 2003 | Aug 7, 2007 | Stmicroelectronics S.A. | Masking of factorized data in a residue number system |

US7269350 | Aug 19, 2004 | Sep 11, 2007 | Wave7 Optics, Inc. | System and method for communicating optical signals between a data service provider and subscribers |

US7313238 * | Jan 31, 2003 | Dec 25, 2007 | Hewlett-Packard Development Company, L.P. | Method and system for relating cryptographic keys |

US7333726 | Oct 30, 2003 | Feb 19, 2008 | Wave7 Optics, Inc. | Method and system for supporting multiple service providers within a single optical network |

US7392246 | Feb 14, 2003 | Jun 24, 2008 | International Business Machines Corporation | Method for implementing access control for queries to a content management system |

US7467386 | Jan 16, 2004 | Dec 16, 2008 | International Business Machines Corporation | Parameter passing of data structures where API and corresponding stored procedure are different versions/releases |

US7474748 | May 13, 2003 | Jan 6, 2009 | Giesecke & Devrient Gmbh | Modular inversion that is protected against espionage |

US7477741 | Oct 1, 2004 | Jan 13, 2009 | The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration | Analysis resistant cipher method and apparatus |

US7536564 | Apr 29, 2002 | May 19, 2009 | Stmicroelectronics S.A. | Method for encrypting a calculation using a modular function |

US7594116 | Apr 28, 2005 | Sep 22, 2009 | Proofpoint, Inc. | Mediated key exchange between source and target of communication |

US7596704 | Oct 6, 2004 | Sep 29, 2009 | Jing-Jang Hwang | Partition and recovery of a verifiable digital secret |

US7697690 | Jul 21, 2003 | Apr 13, 2010 | Hewlett-Packard Development Company, L.P. | Windowed backward key rotation |

US7761443 | May 20, 2008 | Jul 20, 2010 | International Business Machines Corporation | Implementing access control for queries to a content management system |

US7764785 | Nov 8, 2004 | Jul 27, 2010 | King Fahd University Of Petroleum And Minerals | Method for communicating securely over an insecure communication channel |

US7877014 | Dec 6, 2004 | Jan 25, 2011 | Enablence Technologies Inc. | Method and system for providing a return path for signals generated by legacy video service terminals in an optical network |

US7953325 | Aug 26, 2009 | May 31, 2011 | Enablence Usa Fttx Networks, Inc. | System and method for communicating optical signals between a data service provider and subscribers |

US7974409 * | Sep 4, 2007 | Jul 5, 2011 | Samsung Electronics Co., Ltd. | Changing the order of public key cryptographic computations |

US7986880 | Oct 10, 2008 | Jul 26, 2011 | Enablence Usa Fttx Networks Inc. | Method and system for providing a return path for signals generated by legacy terminals in an optical network |

US8059814 * | Sep 28, 2007 | Nov 15, 2011 | Emc Corporation | Techniques for carrying out seed or key derivation |

US8127135 * | Sep 28, 2006 | Feb 28, 2012 | Hewlett-Packard Development Company, L.P. | Changing of shared encryption key |

US8160245 * | Feb 29, 2008 | Apr 17, 2012 | Research In Motion Limited | Methods and apparatus for performing an elliptic curve scalar multiplication operation using splitting |

US8161495 | May 8, 2008 | Apr 17, 2012 | International Business Machines Corporation | Parameters passing of data structures where API and corresponding stored procedure are different versions/releases |

US8243920 * | Oct 28, 2005 | Aug 14, 2012 | Telecom Italia S.P.A. | Method for scalar multiplication in elliptic curve groups over binary polynomial fields for side-channel attack-resistant cryptosystems |

US8379844 | Jan 20, 2012 | Feb 19, 2013 | Research In Motion Limited | Methods and apparatus for performing an elliptic curve scalar multiplication operation using splitting |

US8401190 * | Oct 5, 2004 | Mar 19, 2013 | Nagra France Sas | Portable security module pairing |

US8498617 * | Aug 20, 2004 | Jul 30, 2013 | Telecom Italia S.P.A. | Method for enrolling a user terminal in a wireless local area network |

US8539254 | Jun 1, 2010 | Sep 17, 2013 | Xilinx, Inc. | Method and integrated circuit for protecting against differential power analysis attacks |

US8583944 | Aug 4, 2010 | Nov 12, 2013 | Xilinx, Inc. | Method and integrated circuit for secure encryption and decryption |

US8621577 | Aug 10, 2006 | Dec 31, 2013 | Samsung Electronics Co., Ltd. | Method for performing multiple pre-shared key based authentication at once and system for executing the method |

US8650408 | Sep 8, 2010 | Feb 11, 2014 | Xilinx, Inc. | Protecting against differential power analysis attacks on decryption keys |

US8682162 | Jun 19, 2011 | Mar 25, 2014 | Aurora Networks, Inc. | |

US8712038 | Jun 15, 2010 | Apr 29, 2014 | Morpho | Cryptography on a simplified elliptical curve |

US8718276 * | Jun 15, 2010 | May 6, 2014 | Morpho | Cryptography on a elliptical curve |

US8832462 | Sep 8, 2010 | Sep 9, 2014 | Xilinx, Inc. | Protecting against differential power analysis attacks on sensitive data |

US8909941 | Mar 31, 2011 | Dec 9, 2014 | Xilinx, Inc. | Programmable integrated circuit and a method of enabling the detection of tampering with data provided to a programmable integrated circuit |

US8966253 | Jun 1, 2010 | Feb 24, 2015 | Xilinx, Inc. | Method and apparatus for authenticating a programmable device bitstream |

US9176707 * | Dec 27, 2010 | Nov 3, 2015 | Mitsubishi Electric Corporation | Arithmetic apparatus, elliptic scalar multiplication method of arithmetic apparatus, elliptic scalar multiplication program, residue operation method of arithmetic apparatus, and residue operation program |

US20020089725 * | Oct 4, 2001 | Jul 11, 2002 | Wave7 Optics, Inc. | System and method for communicating optical signals upstream and downstream between a data service provider and subscribers |

US20030016692 * | Oct 26, 2001 | Jan 23, 2003 | Wave7 Optics, Inc. | Method and system for processing upstream packets of an optical network |

US20030044003 * | Aug 31, 2001 | Mar 6, 2003 | International Business Machines Corporation | Space-efficient, side-channel attack resistant table lookups |

US20030044014 * | Sep 6, 2002 | Mar 6, 2003 | Pierre-Yvan Liardet | Method for scrambling a calculation with a secret quantity |

US20030046547 * | May 30, 2001 | Mar 6, 2003 | Jakobsson Bjorn Markus | Secure distributed computation in cryptographic applications |

US20030072059 * | Sep 10, 2002 | Apr 17, 2003 | Wave7 Optics, Inc. | System and method for securing a communication channel over an optical network |

US20030086140 * | Oct 26, 2001 | May 8, 2003 | Wave7 Optics, Inc. | Method and system for processing downstream packets of an optical network |

US20030152218 * | Apr 18, 2001 | Aug 14, 2003 | Jean-Sebastien Coron | Cryptography method on elliptic curves |

US20030200202 * | Apr 23, 2002 | Oct 23, 2003 | International Business Machines Corporation | Content management system and methodology employing non-transferable access tokens to control data access |

US20030200218 * | Apr 23, 2002 | Oct 23, 2003 | International Business Machines Corporation | Content management system and methodology featuring query conversion capability for efficient searching |

US20030200224 * | Apr 23, 2002 | Oct 23, 2003 | International Business Machines Corporation | Content management system and methodology employing a tree-based table hierarchy featuring arbitrary information retrieval from different locations in the hierarchy |

US20030200256 * | Apr 23, 2002 | Oct 23, 2003 | International Business Machines Corporation | Method and apparatus of parameter passing of structured data for stored procedures in a content management system |

US20030204537 * | Apr 23, 2002 | Oct 30, 2003 | International Business Machines Corporation | Content management system and methodology for implementing a complex object using nested/recursive structures |

US20030223750 * | Mar 14, 2003 | Dec 4, 2003 | Farmer James O. | |

US20040131357 * | Dec 18, 2003 | Jul 8, 2004 | Wave7 Optics, Inc. | Method and system for supporting multiple services with a subscriber optical interface located outside a subscriber's premises |

US20040141747 * | Oct 30, 2003 | Jul 22, 2004 | Wave7 Optics, Inc. | Method and system for supporting multiple service providers within a single optical network |

US20040151310 * | Jan 31, 2003 | Aug 5, 2004 | Fu Kevin E. | Method and system for relating cryptographic keys |

US20040179680 * | Apr 29, 2002 | Sep 16, 2004 | Pierre-Yvan Liardet | Method for encrypting a calculation using a modular function |

US20050018842 * | Jul 21, 2003 | Jan 27, 2005 | Fu Kevin E. | Windowed backward key rotation |

US20050053350 * | Oct 15, 2003 | Mar 10, 2005 | Wave7 Optics, Inc. | Reflection suppression for an optical fiber |

US20050081041 * | Oct 6, 2004 | Apr 14, 2005 | Jing-Jang Hwang | Partition and recovery of a verifiable digital secret |

US20050125837 * | Dec 6, 2004 | Jun 9, 2005 | Wave7 Optics, Inc. | Method and system for providing a return path for signals generated by legacy video service terminals in an optical network |

US20050157870 * | May 13, 2003 | Jul 21, 2005 | Sven Bauer | Modular inversion that is protected against espionage |

US20050160432 * | Jan 16, 2004 | Jul 21, 2005 | International Business Machines Corporation | Parameter passing of data structures where API and corresponding stored procedure are different versions/releases |

US20060020975 * | Jul 1, 2005 | Jan 26, 2006 | Wave7 Optics, Inc. | System and method for propagating satellite TV-band, cable TV-band, and data signals over an optical network |

US20060039699 * | Aug 10, 2005 | Feb 23, 2006 | Wave7 Optics, Inc. | Countermeasures for idle pattern SRS interference in ethernet optical network systems |

US20060075428 * | Oct 4, 2005 | Apr 6, 2006 | Wave7 Optics, Inc. | Minimizing channel change time for IP video |

US20060092251 * | Nov 4, 2004 | May 4, 2006 | Hewlett-Packard Development Company, L.P. | Inkjet compositions |

US20060159457 * | Dec 1, 2005 | Jul 20, 2006 | Wave7 Optics, Inc. | System and method for communicating optical signals between a data service provider and subscribers |

US20060187863 * | Dec 21, 2005 | Aug 24, 2006 | Wave7 Optics, Inc. | System and method for operating a wideband return channel in a bi-directional optical communication system |

US20060248336 * | Apr 28, 2005 | Nov 2, 2006 | Secure Data In Motion, Inc. | Mediated key exchange between source and target of communication |

US20060251373 * | May 8, 2006 | Nov 9, 2006 | Wave7 Optics, Inc. | Reflection suppression for an optical fiber |

US20060269285 * | Mar 27, 2006 | Nov 30, 2006 | Wave7 Optics, Inc. | Optical network system and method for supporting upstream signals propagated according to a cable modem protocol |

US20070047959 * | Aug 14, 2006 | Mar 1, 2007 | Wave7 Optics, Inc. | System and method for supporting communications between subcriber optical interfaces coupled to the same laser transceiver node in an optical network |

US20070077069 * | Oct 5, 2006 | Apr 5, 2007 | Farmer James O | System and method for communicating optical signals upstream and downstream between a data service provider and subscribers |

US20070253551 * | Oct 5, 2004 | Nov 1, 2007 | Canal + Technologies | Portable Security Module Pairing |

US20070292133 * | Apr 5, 2007 | Dec 20, 2007 | Whittlesey Paul F | System and method for communicating optical signals to multiple subscribers having various bandwidth demands connected to the same optical waveguide |

US20080082824 * | Sep 28, 2006 | Apr 3, 2008 | Ibrahim Wael M | Changing of shared encryption key |

US20080085117 * | Aug 3, 2007 | Apr 10, 2008 | Farmer James O | System and method for communicating optical signals between a data service provider and subscribers |

US20090003606 * | Sep 4, 2007 | Jan 1, 2009 | Samsung Electronics Co., Ltd. | Changing the order of public key cryptographic computations |

US20090052657 * | Oct 28, 2005 | Feb 26, 2009 | Telecom Italia S.P.A. | Method for Scalar Multiplication in Elliptic Curve Groups Over Binary Polynomial Fields for Side-Channel Attack-Resistant Cryptosystems |

US20090164796 * | Dec 21, 2007 | Jun 25, 2009 | Daon Holdings Limited | Anonymous biometric tokens |

US20100296654 * | Oct 8, 2009 | Nov 25, 2010 | Terence Wilson | Configuring a network connection |

US20100299198 * | May 20, 2010 | Nov 25, 2010 | M-Dot, Inc. | Message Broker for Redemption of Digital Incentives |

US20100299266 * | May 20, 2010 | Nov 25, 2010 | M-Dot, Inc. | Digital Incentives Issuance, Redemption, and Reimbursement |

US20120082307 * | Jun 15, 2010 | Apr 5, 2012 | Morpho | Cryptography on a elliptical curve |

US20130218937 * | Dec 27, 2010 | Aug 22, 2013 | Mitsubishi Electric Corporation | Arithmetic apparatus, elliptic scalar multiplication method of arithmetic apparatus, elliptic scalar multiplication program, residue operation method of arithmetic apparatus, and residue operation program |

US20130279692 * | Sep 29, 2011 | Oct 24, 2013 | Nagravision S.A. | Protecting modular exponentiation in cryptographic operations |

US20140331051 * | Jun 9, 2014 | Nov 6, 2014 | Koolspan, Inc. | Localized network authentication and security using tamper-resistant keys |

US20150222422 * | Jan 31, 2014 | Aug 6, 2015 | Google Inc. | Systems and methods for faster public key encryption using the associated private key portion |

EP1815411A2 * | Sep 23, 2005 | Aug 8, 2007 | American Express Travel Related Services Company, Inc. | System and method for authenticating a rf transaction using a radio frequency identification device including a transactions counter |

WO2003098429A2 * | May 13, 2003 | Nov 27, 2003 | Giesecke & Devrient Gmbh | Modular inversion that is protected against espionage |

WO2006115996A2 * | Apr 20, 2006 | Nov 2, 2006 | Logan O'sullivan Bruns | Mediated key exchange between source and target of communication |

WO2008106792A1 * | Mar 6, 2008 | Sep 12, 2008 | Research In Motion Ltd | Methods and apparatus for performing an elliptic curve scalar multiplication operation using splitting |

Classifications

U.S. Classification | 713/171, 380/30 |

International Classification | G06F7/72, H04L9/08, H04L9/30, H04L9/10, H04L9/32 |

Cooperative Classification | H04L9/0891, H04L9/302, H04L9/3013, H04L9/0841, G06F2207/7219, G06Q20/367, G06Q20/401, G06F2207/7257, H04L9/3247, H04L63/1441, G06F21/556, G06F21/558, G06F7/723, G06F21/602, H04L9/002, H04L2209/56 |

European Classification | G06F21/60A, G06F21/55C, H04L9/30B2, G06F21/55C2, G06Q20/401, H04L9/30B4, G06Q20/367, H04L9/08T, H04L9/08F4B, H04L63/14D, H04L9/32, H04L9/32S, G06F7/72E |

Legal Events

Date | Code | Event | Description |
---|---|---|---|

May 4, 2005 | FPAY | Fee payment | Year of fee payment: 4 |

Sep 22, 2009 | FPAY | Fee payment | Year of fee payment: 8 |

Apr 29, 2011 | AS | Assignment | Effective date: 19981228 Owner name: CRYPTOGRAPHY RESEARCH, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KOCHER, PAUL C.;JAFFE, JOSHUA M.;REEL/FRAME:026204/0649 |

Oct 30, 2013 | FPAY | Fee payment | Year of fee payment: 12 |

Rotate