Title:

Countermeasure against fault-based attack on RSA signature verification

Document Type and Number:

United States Patent Application 20080104402

Kind Code:

Abstract:

Methods and apparatuses enable countermeasures to obstruct a fault-based attack on an authentication procedure. A digital message M, a signature S, and a modulus N are received, where the signature S is to sign the digital message M, and the modulus N is a public modulus for modular authentication operations. In one embodiment, the message and signature are compliant with the RSA algorithm. The signature S is validated, and after validation of the signature S, one or more N-based computations are performed that validate N. In one embodiment, N is validated prior to validating the signature S, and a double-validation countermeasure provides for re-validating N after validating S. In one embodiment, N is validated or re-validated in conjunction with validation of S. N can be validated in conjunction with validation of S through the use of computations with intermediate values derived from a trusted copy of N.

Inventors:

Gueron, Shay (Haifa, IL)
Seifert, Jean-pierre (Tirol, AT)

Plaque It!

FIELD

Embodiments of the invention relate to public-key cryptography, and more particularly to authenticating a message signed with a Rivest, Shamir, and Adleman (RSA) compliant signature while reducing the likelihood of success of a fault attack.

BACKGROUND

Public-key cryptography allows two parties to communicate securely without the need for prior access to a shared secret key. Instead, a pair of mathematically related cryptographic keys, one public and widely distributed, and one private, are used. The private key is kept secret and can be used to form a digital signature, while the public key is made public and can be used to verify the digital signature. Public-key cryptography can be applied to digitally sign a message. A digital signature is conceptually similar to a signet and serves to ensure both the identity of the author and authenticity of the message.

One form of public-key cryptography is the Rivest, Shamir, and Adleman (RSA) algorithm. A standard application of the RSA algorithm to digitally sign a message involves using two randomly generated, large prime numbers, P and Q, from which public and private keys are created. The public key consists of a public exponent, E, and modulus, N, and is distributed to any number of signature authentication devices. A signature authentication device is a device that receives and authenticates a message. The private key consists of a private exponent, D, and the same modulus, N.

A digital signature, S, is created by computing S=M ^D(mod N), where M is known as the digest of the message and is the hash-value of a pre-defined hash-function (e.g., Secure Hash Algorithm 1 (SHA-1)) performed on the data to be sent, D is the private exponent of the private key, and N is the modulus of the private key. To digitally sign a message M, a sender computes a hash of M and encrypts the resulting hash with the private key <N, D> to form a signature S, then sends M and the S to a receiver.

To authenticate the message, the authentication device first validates the received public key, consisting of a public exponent, E, and modulus, N, by comparing it to an expected value (e.g., a copy known to be valid). The public key is only validated if it is identical to the expected value. If the public key is found to be valid, then the validity of the signature is tested. To validate the signature, a local message digest, R, is computed as the result of the hash function used by the sender, performed on the received message. The authentication device (i.e., the receiver) computes a hash of M, uses the public key <N, E> to decrypt the signature S and extract an expected value, and compares the result to the hash of M. Note that in practice, a padding scheme is typically used, which will generally be assumed herein. Although it is possible to implement the authentication procedures as described herein without padding, a lack of padding generally increases the risk of insecurity in the system, and may nullify the effectiveness of the entire authentication procedure. If the hash of M and the derived expected value match, the signature S is deemed valid as being generated with the private key, and only a valid sender knows the private key. The message M can be considered authentic and not altered since being signed, because changing M also changes the hash of M, and the hash of the altered message would not match the result of decrypting S with the public key.

If an attacker has physical access to the receiving device and is able to induce data faults during the authentication procedure, the traditional RSA signature scheme is vulnerable to a recently developed fault attack. The security of the RSA algorithm is based on the idea that it is very difficult to factor the modulus N. However, in a successful fault attack, the attacker modifies only a few bits of the public modulus N to generate a factorable fake modulus N _F. With the fake modulus N _F, the attacker uses N _Fto compute a forged signature S _Ffor a false message M _F, and sends S _Fand M _Fto the receiving device. During the authentication procedure, the attacker induces data faults and changes the value of the modulus N to N _F, causing the receiving device to use the key <N _F, E> to decrypt S _F. Because the attacker can control the value of the modulus used to decrypt S _F, the attacker can cause the traditional RSA signature authentication procedure to accept the false message M _Fas an authentic message.

BRIEF DESCRIPTION OF THE DRAWINGS

The following description includes discussion of various figures having illustrations given by way of example of implementations of embodiments of the invention. The drawings should be understood by way of example, and not by way of limitation.

FIG. 1 is a block diagram of an embodiment of an authentication client having an authentication module.

FIG. 2 is a block diagram of an embodiment of an authentication module.

FIG. 3 is a flow diagram of an embodiment of a process for doubly validating a public key.

FIG. 4 is a flow diagram of an embodiment of a process for interleaving validation of a public key with validation of a received signature.

FIG. 5 is a flow diagram of an embodiment of a process for interleaving validation of a public key with validation of a received signature with computations derived from a trusted public key value.

FIG. 6 is a flow diagram of an embodiment of a process for interleaving validation of a public key with validation of a received signature with computations derived from a trusted public key value.

DETAILED DESCRIPTION

As used herein, references to one or more “embodiments” are to be understood as describing a particular feature, structure, or characteristic included in at least one implementation of the invention. Phrases such as “in one embodiment” or “in an alternate embodiment” appearing herein describe various embodiments and implementations of the invention, and do not necessarily all refer to the same embodiment. However, they are also not necessarily mutually exclusive. Descriptions of certain details and implementations follow, with an overview description of embodiments of the invention, followed by a more detailed description with reference to the drawings.

A digital signature can be used to lock a computer system. As used herein, locking a computer system refers to restricting access or use of the system. The manufacturer of the system generates a private key and a public key. The manufacturer keeps the private key secret, and signs messages containing coded instructions with the private key. The manufacturer distributes the public key, which enables a locked system (i.e., an authenticating device restricted by the private key) to authenticate messages signed by the manufacturer with the private key. Generally a locked system only executes code that has been signed with the private key, allowing the manufacturer to regulate and restrict the software that can run on the locked system. For example, the locked system may be a game console that only allows games signed by the console manufacturer to be executed on the console. The console manufacturer can sell licenses to game developers and use the digital signature restrictions to prevent unlicensed or pirated games from running on the console.

The Rivest, Shamir, and Adleman (RSA) algorithm is one form of public-key cryptography that can be used to provide a digital signature. The RSA signature methodology includes three phases: key generation, message signing, and message authentication. Assuming a key owner and an authenticating device as the entities employing the RSA signature methodology, the general flow would be as follows. For key generation, the key owner chooses two secret large prime numbers P and Q, where P≠Q. P and Q can be selected randomly and independently of each other. Methods for selecting P and Q are known, and will not be discussed in detail herein. P and Q are used to compute an authentic modulus N _A(where N _A=PQ), and a totient φ (where φ=(P-1)(Q-1)). The key owner selects a public exponent E, where E is an integer in the range (0, N _A-1). Commonly, E is generated by computing E=2k+1, with k=1, 2, or 8, although other values are possible. The key owner also selects a private exponent D, where D is an integer in the range (0, N _A-1) that satisfies the equation DE=1 (mod φ). A private key <N _A, D> includes the authentic modulus N _Aand the private exponent D, and is kept secret by the key owner. A public key <N _A, E> includes the same authentic modulus N _Aand the public exponent E. The public key <N _A, E> may be widely distributed, or at least stored on authenticating devices that are to receive and decrypt messages from the key owner. An authenticating device may store the entire public key <N _A, E>, or alternatively, store the public exponent E directly, and store only a hash of the authentic modulus hN _A. The hash of the authentic modulus, hN _Ais much smaller than N _A(for example, 160 bits for the hash versus 2048 bits for the modulus).

For message signing, the key owner prepares a message M to be signed. The message M may contain code written by the key owner, or may contain code written by a licensed developer. The key owner computes a hash of the message hM. The hash may be computed using, as one example, a Secure Hash Algorithm (SHA) such as SHA-1, or other known algorithms. The key owner encrypts the resulting hash hM with the private key <N _A, D> to produce a signature S:

S=hM ^Dmod N _A. (1)

The message M and signature S are sent to the authenticating device (e.g., the locked system referred to above). The key owner may also send the authentic modulus N _A, which may be used by the authenticating device if the authenticating device does not store a copy of the authentic modulus.

For message authentication, the authenticating device performs various operations on the message and signature received from the key owner. If the authenticating device does not store a copy of the authentic modulus N _A, the authenticating device first obtains/accesses a copy of the modulus to complete its public key (for example, receiving the modulus with the message, accessing a public key database, etc.). The authenticating device computes a hash of the received modulus N _Rand compares it to the stored hash of the authentic modulus hN _A. If the two hashes match, the authenticating device uses the received modulus N _Rto complete its public key, which is then used to validate the received signature S _R. If, instead, the authenticating device stores a copy of the entire public key, it retrieves the copy from memory/storage and validates the received signature S _R.

To validate the received signature S _R, the authenticating device computes a hash of the received message hM _Rusing the same hash algorithm used by the key owner. The knowledge of the authenticating device of the hash algorithm used by the key owner can be assumed for purposes of the discussion herein, as the sharing of such information is understood in the art. The authenticating device decrypts the received signature S _Rwith the public key <N, E>, generating a decrypted result A by performing:

A=S _R ^E(mod N ), (2)

where S _Ris the received signature, and N is either the received modulus N _R, or the stored authentic modulus N _A, depending on the implementation. The authenticating device compares the decrypted result A to the hash of the received message hM _R(which is typically padded). If the result of the comparison indicates a match, the received message M _Rcan be assumed to have been signed with the key owner's private key <N _A, D>. Because the private key <N _A, D> is assumed to be a secret, the received message M _Rcan be assumed to contain code approved by the key owner, and the authenticating device executes the code in the message. Note that if the message were altered after being signed by the key owner, the change to the message would result in a change to the hash of the message by the authenticating device. Thus, a message that properly authenticates can also be assumed to have not been altered after being signed.

An attacker may have access to the authenticating device, for example, as an owner of the device in physical possession of the device. When an attacker has access to the authenticating device, the traditional RSA signature verification phase may be vulnerable to a fault attack. The fault attack includes two aspects: an off-line false message generation, and an on-line fault generation. With the off-line false message generation, the attacker generates a false message M _Fand computes a hash of the false message hM _F. The false message may be malicious code, as well as being an unauthorized version of code that would otherwise normally be executed on the authenticating device (e.g., a counterfeit game for a console). The security of the RSA algorithm depends on the statistical improbability that the attacker can factor the authentic modulus N _A. However, in the case of a fault attack, rather than factor the authentic modulus N _A, the attacker selects a fake modulus N _Fthat is easily factorable and varies from the authentic modulus by a small number of bits (e.g., four bits), as described in more detail below. The attacker can be assumed to know the values of the authentic modulus N _Aand the public exponent E, which are public by definition. For the attack to succeed, the attacker computes a forged signature S _F, where S _Fsatisfies the equation

hM _F =S _F ^E(mod N _F). (3)

If no suitable S _Fcan be found, the attacker selects a different fake modulus N _Fand tries again. Such operations can be performed offline in preparation for a fault attack on the authenticating device. As used herein, “offline” refers to a state separate from operations on the authenticating device.

With the on-line fault generation, the attacker sends the false message M _Fand the forged signature S _Fto the authenticating device. On-line, in contrast to off-line, is a state of operating on the authenticating device. If the authenticating device did not store a copy of the authentic modulus N _A, the attacker also sends a copy of the authentic modulus N _A. The authenticating device computes a hash of the received modulus N _Rand compares it to the stored hash of the authentic modulus (i.e., a trusted copy). Because the attacker sent the authentic modulus, the two hashes match and the system uses the received modulus to complete its public key <N, E>. If the system stored a copy of the entire public key, it retrieves the public key <N, E>.

For the fault attack, the attacker induces data faults in the authenticating device, changing bits in the modulus N. Data faults can be induced in a computer system, for example, by causing variations in the supply voltage, by exposing a circuit to intense light (for example, white light or a laser) for a brief time period, or by exposing a circuit to X-rays or ion beams. If the attacker successfully changes the authentic modulus N _Ainto the fake modulus N _F, the system uses the key <N _F, E>, instead of <N _A, E>, to decrypt the forged signature S _F. Because S _Fwas chosen to satisfy equation (3), the decrypted result would match the hash of the false message hM _F, and the authenticating device would accept the forged message M _Fas an authentic message.

Inducing data faults in the modulus is a non-deterministic process, meaning that the new value of the modulus is somewhat random. However, the fewer bits that N _Fvaries from N _A, the fewer random changes the attacker would need to make, which would increase the probability the changed modulus will be N _F. If N _Fvaries from N by b bits, then the expected number of fault induction attempts to successfully transform N into N _Fis roughly 2b. Thus, the goal of the off-line phase is to find a suitable fake modulus N _Fthat varies from the authentic modulus by as few bits as possible. If the modulus has 1024 bits, the attacker has a better than 50% chance of finding a suitable N _Fby changing only 4 bits, yielding roughly 8 attempts. If the modulus has 2048 bits, the attacker has a better than 50% chance of finding a suitable N _Fby changing only 6 bits, yielding roughly 12 attempts. Because success can be achieved with a feasible number of attempts, fault attacks are a substantial threat to the traditional RSA authentication procedure.

As described in more detail below, the probability of success of a fault attack can be limited with one or more countermeasures. In one embodiment, a double validation countermeasure limits the probability of success of a fault attack. A double validation countermeasure provides validating the public modulus N multiple times. N can be validated prior to validating the signature S, and again after validating S. The message is deemed valid only if the validation of S is successful, as well as both validations of N. If the attacker were to induce a fault attack and attempt to change the value of N for the validation of S, the second validation of N would fail unless the attacker could also successfully induce a fault attack after validation of S and change N back.

In one embodiment, one or more countermeasures referred to herein as an “interleaving” countermeasures limit the probability of success of a fault attack. An interleaving countermeasure involves the generation of one or more additional variables derived from the authentic modulus N _A, or from the validated modulus N _R. During validation of S, one or more computations are performed with the N-derived variable(s) to validate S. If the value of N has been changed through a fault attack, the validation of S will fail, and so the authentication of M will fail.

The double validation countermeasure is described in more detail with reference to FIG. 3, and the interleaving countermeasures are described in more detail with reference to FIGS. 4-6.

FIG. 1 is a block diagram of an embodiment of an authentication client having an authentication module. System 100 includes authenticating device, which may be, for example, a personal computer, handheld computer, gaming system (e.g., console), set-top box, cell phone, etc. Authenticating device 100 includes one or more processors 112 , which may be, for example, one or more microprocessors, central processing units (CPUs), processing cores, etc., to perform operations related to message authentication. Processor 112 controls the overall operation of authenticating device 100 , and may be, or may include, one or more programmable general-purpose or special-purpose microprocessors, digital signal processors (DSPs), programmable controllers, application specific integrated circuits (ASICs), programmable logic devices (PLDs), or the similar devices, or a combination of such devices.

Processor 112 is coupled to memory 114 , which represents the main memory of authenticating device 100 . Processor 112 can be coupled to memory 114 via a bus (e.g., bus 111 ) common to multiple devices, and/or via a direct connection (e.g., direct memory access (DMA)). Memory 114 provides code and/or data to be executed by processor 112 . Memory 114 may include read-only memory (ROM), flash memory, one or more varieties of random access memory (RAM, e.g., static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), etc.), or a combination of memory technologies. Memory 114 also includes registers that temporarily store the key values (e.g., public modulus N). The changing of values of the bits in the registers is the source of the fault attacks.

Processor 112 and memory 114 are coupled to bus system 111 . Bus system 111 is an abstraction that represents any of one or more separate physical buses, communication lines/interfaces, and/or multi-drop or point-to-point connections, connected by appropriate bridges, adapters, and/or controllers. Therefore, bus system 111 may include, for example, one or more of a system bus, a Peripheral Component Interconnect (PCI) bus, a HyperTransport or industry standard architecture (ISA) bus, a small computer system interface (SCSI) bus, a universal serial bus (USB), or an Institute of Electrical and Electronic Engineers (IEEE) standard 1394-1995 bus, published Aug. 30, 1996, commonly refereed to as “Firewire.”

In one embodiment, authenticating device 110 includes protected memory 130 . Protected memory 130 represents a non-volatile memory that has restricted write access. Protected memory 130 may be strict read-only memory (ROM), a one time programmable read-only memory (OTPROM), a protected electrically erasable programmable read-only memory (EEPROM), Trusted Platform Module (TPM, of the Trusted Computing Group), etc. Protected memory 130 may also have restricted read access. Protected memory 130 may include one or more values stored for the purpose of performing message authentication. For example, protected memory 130 may include a public modulus N _A 134 , or a hash of the public modulus, hN _A 132 , as well as the public exponent E 136 .

Authenticating device 110 also includes storage 116 , which may be or include any conventional medium for storing data in a non-volatile manner. Storage 116 holds data and/or instructions in a persistent state (i.e., the value is retained despite interruption of power to authentication client 200 ). Storage 116 may include any one or more of a conventional magnetic disk (e.g., hard disk), an optical disk (e.g., CD-ROM (compact disk-read only memory), DVD (digital video/versatile disc) based storage), magneto-optical (MO) storage, semiconductor-based storage (e.g., flash), etc.

Also coupled to processor 112 through bus system 111 are one or more I/O (input/output) interface(s) 118 . I/O interfaces 118 may include monitors, displays, audio devices, keyboards, pointer devices, etc. I/O interfaces 118 may include network interfaces to provide hardware and software that connects to devices external to authenticating device 110 , and generally includes a network interface adapter (e.g., Ethernet adapter). The network interface may be coupled to any type of network with associated hardware and software components, for example, a local area network (LAN), wide area network (WAN), metropolitan area network (MAN), global area network (GAN) such as the Internet, or any combination thereof. The connectivity hardware may include Category-5 or other twisted pair cable, coaxial cable, wireless communication transceivers, etc., as well as flow direction hardware (e.g., interface circuits/cards, switches, routers, servers).

Authenticating device 110 also includes authentication module 120 that represents hardware and/or software modules that provide authentication functionality. Authentication module 120 includes countermeasure agent 122 , which provides the double validation countermeasure and/or an interleaving countermeasure referred to above. With countermeasure agent 122 , authentication module 120 can authenticate a received message, while being less susceptible to a fault attack.

Authenticating device 110 may receive a message from authentic source 140 , which represents a device manufacturer or other entity authorized to provide code to be executed on authenticating device 110 . Authentic source 140 generates authentic message M _A 142 , signed with authentic signature S _A 144 . Authentic source 140 may also provide authentic modulus N _A 146 . Authentic source 140 may provide each component to authenticating device 110 , which are received, respectively, as message M 152 , signature S 154 , and modulus N 156 . Authenticating device 110 tests the validity of each component prior to executing the received message.

Attacker 160 may generate fake message M _F 162 and forged signature S _F 164 . Attacker 160 also has access to authentic modulus N _A 166 , which can also be provided to authenticating device 110 . In the fault attack, as described above, attacker 160 attempts to induce a fault to have authenticating device 110 accept fake message M _F 162 as an authentic message M _A 142 .

Attacker 160 generates fake modulus N _F 168 , which is used to generate forged signature S _F 164 . Fake modulus N _F 168 is provided to authenticating device 110 through attack vector 170 , in which attacker 160 attempts to change authentic modulus N _A 134 to fake modulus N _F 168 . Attack vector may be employed at memory 114 , for example, when the modulus is loaded into volatile memory, or at the connection to protected memory 130 as the authentic modulus is accessed from the protected memory.

FIG. 2 is a block diagram of an embodiment of an authentication module. Authentication module 200 can be provided as hardware, software, or a combination. As such, certain elements of FIG. 2 may apply to one implementation, but not another, as will be understood by the context. The components or modules of FIG. 2 are means that provide various functions. Authentication module 200 includes control logic 202 , which implements logical functional control to direct operation of authentication module 200 (in the case of software components), and/or hardware associated with directing operation of authentication module 200 . Logic may be hardware logic circuits and/or software routines. The logic may be instructions executing on a processor of a computing device. In one embodiment, authentication module 200 includes one or more applications 204 , which represent code sequences and/or programs that provide instructions to control logic 202 .

In one embodiment, authentication module 200 includes memory 206 and/or access to memory resource 206 for storing data and/or instructions. In an implementation in software, memory 206 represents the ability of authentication module 200 to store values to main memory of a system in which authentication module 200 resides. Alternatively, memory 206 represents a memory device managed by or shared by authentication module 200 . Memory 206 may include registers, as well as one or more types of RAM.

Authentication module 200 includes storage 208 , which represents storage local to authentication module 200 . For example, storage 208 may be a restricted access storage device, as discussed above with respect to protected memory 130 of FIG. 1. In an implementation with hardware, storage 208 may be a physical device that is part of authentication module 200 , or accessible to authentication module 200 . In a software implementation, storage 208 is accessible to authentication module 200 , and authentication module 200 may be required to present credentials in order to access the information in storage 208 .

Authentication module 200 includes validation agent 210 , which represents one or more functional components or means that enable authentication module 200 to provide validation operations with countermeasures, as described herein. The functions or features of the components include, or are provided by, one or more of double validation module 220 and interleaved validation module 230 . Each module may further include other modules to provide specific functionality. In one embodiment modules 220 and 230 are mutually exclusive. As used herein, a module refers to routine, a subsystem, etc., whether implemented in hardware, software, or some combination. One or more modules can be implemented as hardware while other(s) are implemented in software.

Double validation module 220 enables validation agent 210 to provide for a second validation of the public modulus N. The modulus N can be re-confirmed as valid after the validation of the signature S when a fault attack may be suspected to occur. Thus, after validation of S, N can be re-validated to ensure that a proper modulus was used to generate the positive validation of S. Double validation module 220 includes re-computation module 222 that re-calculates the hash or other function used to validate S.

Interleaved validation module 230 enables validation agent 210 to provide a validation of N during the validation of S, which is the signature used to sign the message M. The validation of N during the validation of S may not be a direct validation, as traditionally done. Rather, N may be indirectly validated through the use of computations on values derived from N. In one embodiment, interleaved validation module 230 includes variable generator 232 that generates variables to use in N-based computations not found in traditional authentication routines. The N-based computations with the generated variables validate a received signature, and also validate the public modulus used in the public key. In one embodiment, the variables are generated prior to validation of S. In an alternative embodiment, the variables are generated as part of the S-validation process. For example, variable generator 232 may generate variables that are two check values X and Y, where X and Y satisfy the equation X ^EY (mod N _A)=1, where N _Ais an expected value of the public modulus N. In an embodiment where the check values X and Y may be computed prior to the authentication procedure (e.g., generated at production time and stored on the authenticating device), variable generator 232 accesses the check values X and Y (e.g., reading the values from a storage device), and provides the check values to other modules for performance of N-based computations with the check values.

Interleaved validation module 230 includes signature decryption module 234 to decrypt the signature with the N-based computations mentioned above, with the variables (also referred to as check values or intermediate values) generated by variable generator 232 . More specifically, signature decryption module 234 includes computation module 236 to perform computations associated with the check values. Computation module 236 may perform a computation C=((S·X) ^E·Y) (mod N), where X and Y are the variables, E is the public exponent, N is the public modulus, and S is the signature. The computation C can be performed as a single equation, or a series of mathematical equivalents. For example, a series of mathematical equivalents may be to compute A=S·X (mod N), then compute B=A ^E(mod N), and finally, compute C=B·Y (mod N). Signature decryption module 234 may extract an expected value based on the computation performed.

In an alternate interleaving implementation, interleaved validation module 230 decrypts the signature with N-based computations with a single variable generated by variable generator 232 . More specifically, a variable U is generated for use in the decryption of the signature. The variable U is derived by generating a random number T, and then multiplying T by the public modulus N. U can be derived prior to validation of N (and then discarded if N fails to validate), during the validation of N, or after the validation of N and prior to the validation of S. During the validation of S computation module 236 of signature decryption module 234 may perform the computation A=(S+U) (mod N), then compute B=A ^E(mod N). Finally, signature decryption module 234 extracts an expected value based on the computation performed.

In the two interleaving countermeasures described, additional storage, components, and/or computations may be required as compared to conventional RSA authentication. In the two variable interleaving countermeasure described with the intermediate values X and Y, the numbers X and Y need to be stored, which requires additional storage. Furthermore, the two-variable interleaving countermeasure described, two additional modular operations are performed, which is not a negligible increase in the computational burden. With the single variable interleaving countermeasure described with the intermediate value U, a random number generator (either hardware or software, although hardware is generally considered more robust) would be included. Additionally, in one embodiment, the base used in the modular computations may be increased, which should be accommodated by the computational components.

Interleaved validation module 230 includes match determination module 238 , which determines whether the expected value extracted by signature decryption module 234 is a match to a test value (a hash of M, typically padded). If the values match, the signature can be deemed to be valid.

As described, the descriptions of agents or modules describe components that may include hardware, software, and/or a combination of these. In a case where a component to perform operations described herein includes software, the software data, instructions, and/or configuration may be provided via an article of manufacture by a machine/electronic device/hardware. An article of manufacture may include a machine readable medium having content to provide instructions, data, etc. The content may result in an electronic device as described herein, performing various operations or executions described. A machine readable medium includes any mechanism that provides (i.e., stores and/or transmits) information/content in a form accessible by a machine (e.g., computing device, electronic device, electronic system/subsystem, etc.). For example, a machine readable medium includes recordable/non-recordable media (e.g., read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, etc.). The machine readable medium may further include an electronic device having code loaded on a storage that may be executed when the electronic device is in operation. Thus, delivering an electronic device with such code may be understood as providing the article of manufacture with such content described herein. Furthermore, storing code on a database or other memory location and offering the code for download over a communication medium may be understood as providing the article of manufacture with such content described herein.

FIG. 3 is a flow diagram of an embodiment of a process for doubly validating a public key. A double validation countermeasure can be provided from an authentication module, as described above. The authentication module receives a message M _R, signature S _R, and modulus N _R, 310 . The authentication module validates the received modulus N _R, 320 . Note that validating N _R 320 may be optional in one or more implementations. Double validation of N _Rprovides an additional validation of N _R, with the second validation occurring after the validation of the signature, where a fault attack may occur. Thus, providing only the validation of N _Rafter the validation of the signature may provide sufficient assurance that success in validating the signature is achieved with a proper N _R.

The authentication module computes the hash of the received modulus hN _R, 322 , and compares hN _Rto the stored hash of the authentic modulus hN _A, or to the hash of the stored authentic modulus hN _A, 324 , either the hash or the modulus being stored in protected memory. If the two hashes do not match, validation of the received modulus N _Rfails, 328 , and the received modulus is determined to not be valid. If the two hashes match, the received modulus N _Ris determined to be valid, and the authentication module uses the received modulus N _Rto complete its public key.

After the public modulus is determined by the authenticating device to be valid, the attacker could induce faults in the authenticating device to change the received modulus N _Rto N _F, 330 . If successful, the attacker may be able to cause the authenticating device to use the fake modulus N _Finstead of the authentic modulus N _Ato complete its public key for the validation of S.

The authenticating device validates the received signature S _R, 340 . The authenticating device computes a hash of the received message hM _R, 342 , and decrypts the received signature S _Rwith public key 345 having E and N _Rto extract an expected hash Eh, 344 . Note that as used herein, generating a hash of M may include operations other than simply hashing the message. Specifically, practical implementations of RSA pad the message string to ensure that the message is a full-length message (e.g., padding a 160 bit message to a full 2048 bit string) for security purposes. The sending of a short message can make the transaction very insecure as compared to the sending of a full-length message. Padding schemes include PKCS v1.5 of the Public Key Cryptography Standards group, Optimal Asymmetric Encryption Padding (OAEP), and Probabilistic Signature Scheme for RSA (RSA-PSS), as is understood by those skilled in the art. Other standards may be used. As mentioned above, padding schemes are generally part of a practical implementation of RSA, but will not be discussed in detail herein. Where padding schemes are used, it will be understood that reference herein to operations involving a hash of M may be understood as including the implementation of a padding scheme, if one is used. Thus, for simplicity in description, padding schemes are ignored, and may be implied where appropriate.

Decrypting the received signature S _Rmay be performed by computing a decrypted result A, where

A=S _R ^E(mod N _R). (4)

The authenticating device extracts the expected hash Eh from the results, and compares the expected hash to the hash of the received message hM _R, 346 . If the hashes do not match, 348 , the received signature S _Ris determined to be not valid and the authentication procedure fails, 349 . If the hashes match, 348 , the received signature S _Ris determined to be valid. If the attacker at 330 had been able to change the value of N _Rfrom N _Ato N _F, the authenticating device would likely validate the forged signature S _F.

However, in one embodiment, the authenticating device includes an authentication module with a double validation countermeasure. In such an implementation, the authenticating device doubly validates the received modulus N _R, 360 . The operations to double validate N _Rcan be identical to the operations that originally validated N _R. In one embodiment, the authenticating device re-computes the hash of the received modulus hN _R, 362 , and compares the results to an expected hash, for example, a stored hash of authentic modulus hN _A, 364 . If the hashes do not match, 366 , the authenticating device determines that N _Rhas changed since the original validation of N _R, 320 , and the authentication procedure fails, 368 . If the hashes match, 366 , the authenticating device deems M _Rto be authentic, 370 , because N _Rwould be unchanged since the original validation of N _R, 320 .

For the fault attack to succeed with a double validation countermeasure, the attacker must induce additional data faults and change the value of the received modulus N _Rfrom N _Fback to N _A, 350 , between the time of the validation of S _R, 340 , and the re-validation of N _R, 360 . In order to succeed in such an attempt, the attacker must induce additional data faults, which roughly squares the number of attempts the attacker must make to succeed. Therefore, if N _Fdiffers from N _Aby b bits, a successful attack would statistically require the attacker to make roughly (2b) ², rather than 2b, attempts. Thus, the double validation countermeasure obstructs fault attacks while being relatively inexpensive and easy to implement. To perform double validation 360 , no additional values need to be stored, and the single additional hash calculation and single additional comparison do not significantly increase the authentication computational burden as compared to the standard procedure.

FIG. 4 is a flow diagram of an embodiment of a process for interleaving validation of a public key with validation of a received signature. In one embodiment, the authenticating device includes an authentication module with an interleaved validation countermeasure. The authenticating device receives the message and variables, and the authentication module receives and processes the received information. For the purpose of simplicity in description, the authenticating device will be described as performing various operations, which can be understood as being performed by one or more elements of the authentication module within the authenticating device.

The authenticating device receives message M _Rand signature S _R, 402 . The authenticating device determines whether a copy of the authentic modulus N _Ais stored in memory (e.g., protected memory 130 of FIG. 1), 404 . If the authenticating device has a stored copy of N _Ain memory, 405 , the authenticating device retrieves the public key from memory, 406 . If the authenticating device does not have a copy of N _Ain memory, 405 , the authenticating device receives a modulus N _Rfrom the sender, 408 . For a received modulus N _R, the authenticating device validates the received modulus N _R, 410 , prior to including the received modulus as a part of the public key. To validate N _R, the authenticating device computes the hash of the received modulus hN _R, 412 , and compares the result to a trusted hash of the authentic modulus hN _A, 414 , typically stored in a protected memory on the authenticating device. If the hashes do not match, 416 , the received modulus N _Ris determined to be not valid, and the authentication procedure fails, 418 . If the hashes do match, 416 , the received modulus N _Ris determined to be valid, and the authenticating device compiles the public key <N, E> from the public exponent stored in memory and the received modulus N _R, 420 (from 416 ). Alternatively, the public key <N, E> is compiled from the public exponent stored in memory and the stored modulus N _A, 420 (from 406 ). Note that validating the received modulus N _R, 410 , is optional. The authenticating device may receive modulus N _Rand use it to compile the public key without validating N _R, relying on later computations to validate N _R.

After receipt of, and potential authentication of N _A, an attacker may attempt to induce data faults to change the value of the modulus N from N _A(or N _R) to N _F, 430 . With a successful data fault attack, the attacker could cause the authenticating device to use the fake modulus N _Finstead of the authentic modulus N _Ain the public key, which could cause the authenticating device to accept a false message M _F. Note that if no authentication of N _Ris performed, the attacker could cause the authenticating device to use N _Fwithout inducing data faults, by sending N _Fto the authenticating device directly.

Interleaved validation occurs in the validation of the received signature S _R, 440 . The authenticating device computes a hash of the received message hM _R, 442 , and decrypts the received signature S _R, 450 . The authenticating device decrypts S _Rwith one or more computations that rely on an authentic value of the public modulus N. If the public modulus N is not valid (i.e., N has been changed to N _Fthrough a data fault attack by the attacker), the authentication of S _Rwill fail. Thus, the message or the signature is validated with computations that validate N. This could also be stated as performing one or more N-based computations that validate or re-validate N. In one embodiment, the authenticating device has pre-computed values X and Y stored in the device. Alternatively, the authenticating device could compute the values X and Y on the fly for use in the validation of S _R. X and Y are values selected to satisfy the equation

X ^E Y (mod N _A)=1. (4)

The values could be referred to as intermediate values, and are used in conjunction with the public key <N, E> to decrypt the received signature S _R, 440 . Note that the values are derived from N _Aas selected with equation (4), 454 , 456 . To decrypt S _R, 450 , the authenticating device computes

C= ( S _R ·X ) ^E ·Y (mod N ), (5)

or a mathematical equivalent. The authenticating device also extracts from the computation an expected hash Eh, 452 . The authentication device compares the expected hash Eh extracted from the computation of equation (5) to the hash hM _R, 444 . If the hashes do not match, 446 , S _Ror N is determined to be invalid, and the authentication procedure fails, 448 . If the hashes match, 446 , the authenticating device determines that M _Ris authentic, 460 .

FIG. 5 is a flow diagram of an embodiment of a process for interleaving validation of a public key with validation of a received signature with computations derived from a trusted public key value. In one embodiment, the authenticating device includes an authentication module with an interleaved validation countermeasure. The authenticating device receives message M _R, signature S _R, and modulus N _R, 510 . As noted in FIG. 4, the modulus may not be received, and the process of validating N _Ris optional. Assuming the modulus N _Ris received, and validated, 520 , the authenticating device computes the hash of the received modulus hN _R, 522 , and compares the result to a trusted hash of the authentic modulus hN _A, 524 . If the hashes do not match, 526 , the received modulus N _Ris determined to be not valid, and the authentication procedure fails, 528 . If the hashes do match, 526 , the received modulus N _Ris determined to be valid, and the authenticating device proceeds to validate S _R, 540 , with the received modulus N _R.

An attacker may attempt to induce data faults to change the value of the modulus N from N _A(or N _R) to N _F, 530 . As described previously, a successful data fault attack may enable the attacker to cause the authenticating device to accept a false message M _F. Interleaved validation occurs in the validation of the received signature S _R, 540 . The authenticating device computes a hash of the received message hM _R, 542 , and then performs various operations to decrypt the received signature S _Rand concurrently test the validity of the received modulus N _R.

As above in FIG. 4, the values X and Y can be pre-computed or generated on the fly. The values can be referred to as intermediate values, and are derived from N. Operations with the intermediate values X and Y are N-based computations. X and Y are values selected to satisfy the equation

X ^E Y (mod N _A)=1. (4)

The values X and Y are thus derived from N, 546 , 552 . As illustrated in FIG. 5, the authenticating device decrypts S _Rby performing operations that are the mathematical equivalent of equation (5), which is described as being computed in FIG. 4 to decrypt S _R. The computation performed in equation (5) may be broken into multiple separate computations. For example, the authenticating device may compute

A=S·X (mod N ), (6)

with the intermediate value X, 544 , and use A to compute

B=A ^E(mod N ), (7)

which is based on the intermediate value, 548 . The authenticating device completes the series of computations by using B to compute

C=B·Y (mod N ), (8)

which uses the intermediate value of Y, 550 , and provide the equivalent of multiplying the equation by 1.

If N equals N _A, then equation (5) is mathematically equivalent to the traditional decryption calculation of equation (2). However, if the value of N does not equal N _A, equation (5) will not yield the same result as the traditional decryption calculation of equation (2). Consider the following:

( S _R ·X ) ^E ·Y (mod N ) =S _R ^E(mod N ), (9)

because

( S _R ·X ) ^E ·Y (mod N ) =[X ^E Y (mod N )] ·[S _R ^E(mod N )], (10)

and if N=N _A, then

X ^E Y (mod N )=1, (11)

because X and Y were selected to satisfy equation (11) where N=N _A, and therefore

[X ^E Y (mod N )] ·[S _R ^E(mod N ) ]=S _R ^E(mod N ). (12)

However, if N has been changed from N _Ato N _Fby the attacker, then

( S _R ·X ) ^E ·Y (mod N ) ≠S _R ^E(mod N ), (13)

because of a very high statistical probability that

X ^E Y (mod N _F)≠1. (14)

Therefore, even if the attacker is able to change the value of N from N _Ato N _F, the authenticating device will not validate forged signature S _Fwith the validation provided in 540 .

To provide the statistical improbability that a fault attack could work when the authenticating device validates S _Raccording to 540 , the values X and Y must be kept private. If the attacker knows the values of X and Y, a fake modulus N _F, and a forged signature S _Fmay be found that satisfy the equation

hM _F=( S _F ·X ) ^E ·Y (mod N _F), (15)

and defeat the interleaved validation countermeasure. In one embodiment, X and Y are computed at production time and stored in a protected memory with the public key components. Among other possible methods of selecting X and Y, the following is one example. A random value X is selected. After selecting X, a corresponding value for Y can be derived by computing the two equations

V=X ^Emod N, (16)

and then

Y=V ⁻¹mod N. (17)

Thus, as described above, the authenticating device computes equation (6), 544 , equation (7), 548 , and equation (8), from which an expected hash value Eh is extracted from B, 552 . As noted above, X is derived from N _A, 546 , and Y is derived from N _A, 552 . The expected hash Eh and the hash of M hM _Rare compared, 554 . If the values do not match, 556 , the authentication procedure fails, 558 . If the values match, 556 , M _Ris determined to be authentic, 560 .

FIG. 6 is a flow diagram of an embodiment of a process for interleaving validation of a public key with validation of a received signature with computations derived from a trusted public key value. In one embodiment, the authenticating device includes an authentication module with an interleaved validation countermeasure. The authenticating device receives message M _R, signature S _R, and modulus N _R, 610 . For the interleaving implementation of FIG. 6, a variable U is generated, 620 . Note that the variable U may be generated prior to, during, or after validation of N _R, 630 , assuming N _Ris validated. Otherwise, U may be generated any time prior to validation of S _R, 650 , but prior to a time that the attacker may attempt to change N _Rto N _F.

To generate U, the authenticating device selects a random number T, 622 . T may be selected with any of a number of known techniques or random number generation engines. The authenticating device then computes U based upon N, 624 . For example the authenticating device may compute

U=T·N. (18)

where N is either N _Ror N _A, depending on which value the authenticating device is using.

As noted in FIG. 4, the modulus may not be received, and the process of validating N _Ris optional. Assuming the modulus N _Ris received, and validated, 630 , the authenticating device computes the hash of the received modulus hN _R, 632 , and compares the result to a trusted hash of the authentic modulus hN _A, 634 . If the hashes do not match, 636 , the received modulus N _Ris determined to be not valid, and the authentication procedure fails, 638 . If the hashes do match, 636 , the received modulus N _Ris determined to be valid, and the authenticating device proceeds to validate S _R, 650 , with the received modulus N _R.

An attacker may attempt to induce data faults to change the value of the modulus N from N _A(or N _R) to N _F, 640 . As described previously, a successful data fault attack may enable the attacker to cause the authenticating device to accept a false message M _F. Interleaved validation occurs in the validation of the received signature S _R, 650 . The authenticating device computes a hash of the received message hM _R, 652 , and then performs various operations to decrypt the received signature S _Rand concurrently test the validity of the received modulus N _R.

As illustrated in FIG. 6, the authenticating device decrypts S _Rby performing operations that also validate N by using computation terms that are derived from N. In this example, the authenticating device computes

A= ( S+U )(mod N ), (19)

which is dependent upon the value U, 654 . The authenticating device uses A to compute

B=A ^E(mod N ), (20)

If N equals N _A, then equation (20) is mathematically equivalent to the traditional decryption calculation of equation (2). However, if the value of N does not equal N _A, equation (20) will not yield the same result as the traditional decryption calculation of equation (2). Consider the following:

U (mod N )=( T·N )(mod N )=0. (21)

Thus,

( S _R +U )(mod N ) =S _Rmod N+U mod N=S _Rmod N. (22)

However, it is very unlikely that

U (mod N _F)=0, (23)

and therefore

( S _F +U )(mod N _F) =S _Fmod N _F +U mod N _F ≠S _Fmod N _F, (24)

with very high statistical probability. Therefore, even if the attacker is able to change the value of N from N _Ato N _F, the authenticating device will not validate forged signature S _Fwith the validation provided in 650 .

Thus, B is computed, and an expected hash value Eh is extracted from B, 656 . The expected hash Eh and the hash of M hM _Rare compared, 658 . If the values do not match, 660 , the authentication procedure fails, 662 . If the values match, 660 , M _Ris determined to be authentic, 670 .

Flow diagrams as illustrated herein provide examples of sequences of various operations. Although shown in a particular sequence or order, unless otherwise specified, the order of the operations can be modified. Thus, the illustrated implementations should be understood only as examples, and operations can be performed in a different order, and some operations may be performed in parallel or alternatively performed only implicitly by way of logical simplification. Other operations, orders of operations, flowcharts and embodiments are also within the scope of the present invention.

Besides what is described herein, various modifications may be made to the disclosed embodiments and implementations of the invention without departing from their scope. Therefore, the illustrations and examples herein should be construed in an illustrative, and not a restrictive sense. The scope of the invention should be measured solely by reference to the claims that follow.

Previous Patent: System, Apparatus, Method, And Program Product For Authenticating Communication Partner Using Electr...

Next Patent: METHODS AND APPARATUS FOR DATA AUTHENTICATION WITH MULTIPLE KEYS