Common modulus RSA key pairs for signature generation and encryption/decryption转让专利
申请号 : US14616552
文献号 : US09949115B2
文献日 : 2018-04-17
发明人 : Roberto Avanzi
申请人 : QUALCOMM Incorporated
摘要 :
权利要求 :
What is claimed is:
说明书 :
This application claims priority based on U.S. Provisional Patent Application Ser. No. 62/010,400, filed Jun. 10, 2014, for “Common Modulus RSA Key Pairs for Signature Generation and Encryption/Decryption,” which is assigned to the assignee hereof and incorporated by reference herein in its entirety.
Field of the Disclosure
Various features relate to encryption/decryption and digital signature generation, particularly asymmetric cryptography involving public and private keys.
Description of Related Art
Asymmetric cryptographic systems such as public key systems (also referred to as public-key/private-key systems) typically have advantages over other cryptographic systems in terms of key management and distribution. However, public key systems often may be computationally difficult and may involve large digital signatures. The key generation process may be computationally expensive. Accordingly, asymmetric cryptographic systems may require a powerful processor or may require additional processing time, which may cause delays, use more energy and/or drain batteries or other resources.
Furthermore, it is generally considered good cryptographic practice to have separate keys for different applications/protocols. In particular, if an asymmetric cryptographic system needs to receive encrypted messages and decrypt them, and also generate digital signatures, it is often advisable to have distinct keys for the two protocols. However, when using asymmetric cryptographic systems such as Rivest-Shamir-Adleman (RSA) systems, it is often too computationally expensive to generate two keys (e.g., in general twice as burdensome as generating just one key.) This can be especially problematic in embedded devices of key provisioning systems with limited resources, such as smartphones or the like. Note that herein, for brevity, the term key provisioning system generally refers to a system capable of generating and/or provisioning keys. It should be understood that, in practice, separate systems may be employed to generate the RSA keys while other systems provision the keys.
In view of the foregoing, it would be helpful to provide improved key generation and provisioning techniques and systems, particularly for use with embedded key provisioning systems.
A method operational in a cryptographic device for decrypting and signing messages includes: obtaining first and second public-key/private-key pairs, wherein the first and second public-key/private-key pairs share a common modulus; decrypting a message using a private key of the first public-key/private-key pair; obtaining a digital signature for the message by signing the message using a private key of the second public-key/private-key pair; and sending the digital signature from the cryptographic device.
In another aspect, a device includes: a processing circuit configured to obtain first and second public-key/private-key pairs, wherein the first and second public-key/private-key pairs share a common modulus; decrypt a message using a private key of the first public-key/private-key pair; obtain a digital signature for the message by signing the message using a private key of the second public-key/private-key pair; and a transmitter device configured to send the digital signature from the cryptographic device.
In yet another aspect, a method operational in a system for encrypting and verifying messages includes: receiving first and second public keys of first and second public-key/private-key pairs from a separate device, wherein the first and second public-key/private-key pairs share a common modulus; encrypting a message using the first public key of the first and second public-key/private-key pairs that share the common modulus; sending the encrypted message to the separate device; receiving a signed reply to the message from the separate device, wherein the message has been signed with a signature obtained using a private key of the second public-key/private-key pair; and verifying the signature of the signed reply using the second public key of the first and second public-key/private-key pairs that share the common modulus.
In still yet another aspect, a device includes: a receiver device configured to receive first and second public keys of first and second public-key/private-key pairs from a separate device, wherein the first and second public-key/private-key pairs share a common modulus; a transmitter device; and a processing circuit configured to encrypt a message using the first public key of the first and second public-key/private-key pairs that share the common modulus; send the encrypted message to the separate device using the transmitter device; receive a signed reply to the message from the separate device using the receiver device, wherein the message has been signed with a signature obtained using a private key of the second public-key/private-key pair; and verify the signature of the signed reply using the second public key of the first and second public-key/private-key pairs that share the common modulus.
In the following description, specific details are given to provide a thorough understanding of the various aspects of the disclosure. However, it will be understood by one of ordinary skill in the art that the aspects may be practiced without these specific details. For example, circuits may be shown in block diagrams in order to avoid obscuring the aspects in unnecessary detail. In other instances, well-known circuits, structures and techniques may not be shown in detail in order not to obscure the aspects of the disclosure.
The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any implementation or aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects of the disclosure. Likewise, the term “aspects” does not require that all aspects of the disclosure include the discussed feature, advantage or mode of operation.
Overview
Several novel features pertain to devices and methods for use with embedded key provisioning systems, such as systems installed within smartphones for generating RSA public-key/private-key pairs for use in encryption/decryption and digital signature generation/verification. Briefly, in at least some examples, an embedded key provisioning system is provided that generates two public-key/private-key pairs—one for encryption/decryption and the other for signature generation/verification—wherein the two public-key/private-key pairs share a common modulus but are otherwise distinct or uncorrelated. This allows the two key pairs to be generated much more efficiently than if two entirely separate key pairs were generated, i.e. each one with its own distinct modulus, and yet, at least in the context of embedded key provisioning systems, satisfactory integrity and confidentiality is achieved. Herein, cryptographic systems and methods that generate two public-key/private-key pairs—one for encryption/decryption and the other for signature generation/verification—wherein the two public-key/private-key pairs share a common modulus but are otherwise distinct are broadly and generally referred to as “common modulus key provisioning systems/methods.”
In this regard, the use of separate RSA public/private key pairs (e1,d1) and (e2,d2) to the same modulus (N=pq) obtained using the common modulus key provisioning systems/methods described herein is believed to provide a secure, sensible and performance-efficient solution for embedded key provision systems such as the Macchiato™ system of Qualcomm Incorporated. Moreover, to implement the common modulus key provisioning system requires relatively modest modifications to existing key provisioning systems. For example, during the generation of the primes p, q for use in generating keypairs, the system can check that p−1 and q−1 are coprime to both e1 and e2—instead of checking that they are coprime to just one public exponent (as would be the case if entirely separate RSA key pairs were generated). Thereafter, in at least some examples, the embedded system inverts e1 modulo (p−1)(q−1) to obtain d1 and inverts e2 modulo (p−1)(q−1) to obtain d2. Note that, by distinct or uncorrelated, it is meant that neither of e1, e2 is a multiple of the other or, depending on the application, that e1 is not a multiple of e2 or e2 is not a multiple of e1, where e1 and e2 refer to public keys.
Traditionally, there are two main reasons for providing entirely separate keys for encryption/decryption and for signing: security and key management. Insofar as security is concerned, two general types of attacks are of concern: a) loss of integrity on a signature scheme due to issues with the decryption oracle; and b) loss of confidentiality on an encryption scheme due to issues with the signature oracle. However, in the context of embedded key provisioning systems, these vulnerabilities are not believed to present a problem when using the common modulus key provisioning systems/methods described herein. For example, loss of integrity should not be a problem if all encrypted messages are signed with a distinct manufacturer key (provided by the manufacturer of the embedded system) that chains back to a certificate in the embedded device. It is unlikely that an attacker would have access to the decryption oracle of the embedded device as it would be implemented within a trusted execution environment of the device, or the device itself may be tamper proof
Insofar as loss of confidentiality on the encryption scheme owing to the signature oracle is concerned, an attacker would likely need to be able to use the signature oracle to decrypt a message and then leak the output. This appears to be very low risk, at least within embedded systems, because different padding can be used for the purposes of encryption and signing. Any padding generation or verification, hashing, and signing is done inside the operating kernel of the Trusted Execution Environment (short TEE; for instance, a TrustZone Operating Environment (TZBSP) in the case of TrustZone), and not in the application using these services, such as a Trusted Application (TA.) (Note that in public key cryptography, padding refers to a process for preparing a message for encryption or signing using a scheme such as optimal asymmetric encryption padding (OAEP), Public-Key Cryptography Standards #1 (PKCS#1) v1.5, Probabilistic Signature Scheme (PSS), PSS with Recovery (PSSR), Institute of Electrical and Electronics Engineers (IEEE) P1363, Encoding Method for Signature with Appendix (EMSA2 or EMSA5.) Therefore the attacker would likely need to: compromise a TA application; call into the kernel routines of the TEE at “wrong” addresses or with wrong parameters so as to pass a message as a signature and decrypt it; then output the result as well. Although not impossible, this is believed to be quite difficult and hence this form of attack is likewise believed to be low risk.
Turning now to key management, in most systems signature and encryption keys have different requirements, e.g., in terms of backup, access, escrow, repudiation, etc. Typically a signature key must be destroyed in case it is compromised, but an encryption key usually must be kept to decrypt older messages. They may have different life spans by policy or by regulation. These concerns however generally do not apply to embedded devices, particularly for use in smartphones and the like, because the life span of such devices is typically much shorter than all key lifecycles. Moreover, generic methods to reveal the factorization of one modulus would most likely also be used to reveal the factorization of two moduli. That is, if the common modulus key provisioning systems/methods described herein are vulnerable by means of methods that reveal the factorization of the modulus, the pairs of keys would most likely also be vulnerable if generated separately using otherwise conventional techniques. For example, an unexpected mathematical breakthrough in factorization techniques could render both types of systems vulnerable, but such a breakthrough would likely render non-common modulus techniques vulnerable as well.
It is believed that using two “mathematically uncorrelated” exponent pairs (i.e. distinct exponent pairs) with a single modulus is sufficient to address the above concerns. Consider an example of an RSA modulus N=pq and two public/private key pairs (e1, d1) and (e2, d2). The first keypair is to be used for encryption only; whereas the second is to be used for signing purposes exclusively. Consider that a message c=me1 arrives encrypted with e1 and a hacker has a decryption oracle for (e2, d2), which can be an exploitable decryption oracle or an exploitable signature oracle. Then the attacker is generally limited to computing cd2=m(e1d2)=m(e1/e2 mod φ(N)) and the relation to the original message can then only be computed if the relation e1/e2 mod φ(N)) can be determined where φ refers to the Euler function or Euler totient function. (Note that the value of the function φ(N) is unknown to an attacker.) This is generally equivalent to computing an RSA problem, as long as the mathematical relation between e1 and e2 is not an obvious one. For instance, e1 (resp. e2) should not be a multiple of e2 (resp. e1) modulo φ(N). Since the latter cannot be known by an attacker (lest the attacker can factorize RSA moduli), this amounts to: e1 (resp. e2) should not be a power of e2 (resp. e1) as integers. Using for e1 and e2 two small primes (small w.r.t. the modulus) is therefore more than sufficient in most practical cases. See, for example, techniques described in Chaum, “Blind Signatures for Untraceable Payments.” Advances in Cryptology Proceedings of Crypto 82 (3): 199-203 (1983.)
In at least some examples, a Trusted Application (TA) runs in a Trusted Execution Environment (TEE) on a device (mobile device, computer, etc.) where the TA needs to authenticate itself to a server. To do this a RSA key pair (or a pair of key pairs with common modulus) is generated in the kernel of the TEE and kept there: the TA does not have access to these keys and typically must call into the kernel to get cryptographic operations done. The messages sent from the TA to the server are either in clear or are encrypted for the server (so the encryption may use a key of the server, which has nothing to do with the RSA keys). The messages from the server to the TA are encrypted with a device's key. The usual two situations are: a single RSA key (one modulus, one single public/private exponent pair) for both encryption and signing; or two completely distinct RSA keys (each with its own modulus and single public/private exponent pair). The RSA key generation is fundamental to create a device-unique set of keys that is then used by a server to encrypt some data for the device, data that is TA specific. The key provisioning is the act of bringing data from the server to the TA. To save time—and exploiting the fact that there are no external policies on these keys—the embedded devices described herein generate one modulus N and two different public/private exponent pairs (e1,d1) and (e2,d2), the first pair is used for encrypting messages to the device (using e1) and decrypting them on the device (using d1)—the second pair is used to sign messages on the device (using d2) and to allow external parties to verify the signature (using e2). With the usual meaning of d,e in the RSA literature, d1,d2 are the secret exponents and e1,e2 are the public ones.
In at least some examples, key generation operates as follows: generate two distinct random prime numbers p,q (for instance using a pseudorandom number generator (PRNG) to generate numbers, and testing whether they are primes); compute N=pq, t=(p−1)(q−1)=φ(N); verify whether the chosen public exponents e1, e2 are coprime to t. If they are not, start over; if e1, e2 are coprime to t, let d1, resp d2 be the modular inverses of e1, e2 modulo t; and verify whether some random value x raised to the power of t is x itself If not start over; otherwise the embedded device has successfully generated a key.
Insofar as the uncorrelated public exponents are concerned, the following considerations apply. The numbers should be distinct, otherwise the scheme would be reduced to the classical RSA scheme. One should not be a multiple of the other. If e2=k e1, then d1=k d2 (modulo φ(N)) and if an attacker intercepts a message encrypted by the server (by raising it to the e1-th power), and the attacker has access to a decryption oracle for d2 (for instance an exploited signature oracle on the device, that can leak the result of the operation—as it should, as it is a signing device), then the attacker could use the decryption oracle to raise the intercepted message to the power of d2, thus decrypting the message (because k is known, as it is the trivial factor between e1 and e2). An important consideration is that, as integers, e2 should not be a multiple of e1 (and vice versa, for the case that one intends to compromise the signature scheme using a decryption oracle—for this case e1 should not be a multiple of e2). If the ratios e1/e2 and e2/e1 are not integers, then breaking the system requires solving a RSA problem (which is believed to be equivalent to factoring.)
Note that modulo φ(N) e1 is always a multiple of e2 (and vice versa) but since the attacker cannot compute φ(N) (this “impossibility” is a standard RSA security assumption), the attacker cannot determine the factor—so the multiplicative relation that must be prevented holds by necessity over the integers, and not integers modulo φ(N). Using the same modulus and separating the exponent pairs as above makes it substantially impossible to use the signing oracle to decrypt messages for an attacker. It achieves the cryptographic principle of key separation while reducing computational complexity at key generation and reduces bandwidth in sharing the keys as well. The technique may thereby be useful for improving single sign-on systems using one key and may have many other applications as well. Insofar as the public exponents are concerned: RSA systems only require these exponents to be odd numbers smaller than N (and coprime to φ(N), but this is tested at key generation). In practice, there is no actual limitation. Systems often use numbers like 3, 5, 17, 257, 65537 for performance reasons but others may be used instead. Note also that, although described with respect to RSA examples, at least some of the techniques described herein are applicable to other cryptographic techniques, such as multi-prime RSA or other RSA-like key pairs. By RSA-like, it is meant that, for instance, moduli are used that are the products of more than two primes (so the modulus N would be N=p1*p2* . . . *pr where the pi for i=1, 2, . . . , r are all primes, and e1,e2 should be coprime to each of the pi−1 for i=1, 2, . . . , r and φ(N)=(p1−1)*(p2−1)* . . . *(pr−1).) Accordingly, aspects of this disclosure are applicable to multi-prime (R>2) moduli. In such cases, key generation would check whether e1,e2 are coprime to each of the pi−1 for i=1, 2, . . . , r instead of just coprime to (p−1) and (q−1).
Moreover, although many of the illustrative examples described herein employ two keypairs that share a common modulus, the techniques are applicable to the generation and use of three or more keypairs that share a common modulus. For example, four keypairs can be generated, two for encryption/decryption (e1,d1; e3,d3) and two for signing/verifying (e2,d2; e4,d4), where each of the four public keys (e1, e2, e3, e4) satisfy the general condition that each is not divisible by the others (over the integers.) In general any number of keypairs may be generated for encryption/decryption and any number of keypairs may be generated for signing/verifying, with at least one key pair per type (where all satisfy the condition that the public exponents of the keypairs cannot divide each other (over the integers.)) Furthermore, although the examples herein primarily involve RSA or RSA-like keypairs, at least some aspects of the disclosure are applicable to other cryptography schemes or protocols, such as those that use higher algebraic structures or multivariate systems (i.e. systems using asymmetric cryptographic primitives based on multivariate polynomials over finite fields.) In general, however, the techniques described herein are not expected to be applicable to elliptic curve cryptography (ECC) or to any cryptographic system based on non-commutative mathematical structures.
Exemplary Hardware Environment
The common modulus embedded key provisioning systems/methods described herein can be exploited in a wide range of devices and for a wide range of applications.
In general, the common modulus systems/methods described herein are broadly useful in any circumstance where a device needs to be capable of generating public-key/private-key pairs and also needs to sign messages (wherein the modulus can be kept confidential.) To provide a concrete example, an exemplary hardware environment will now be described where an embedded key provisioning component is provided on a SoC processing circuit for use in a smartphone mobile communication device or other access terminal. Other exemplary hardware environments in which the embedded key provisioning systems/methods may be implemented include other communication devices and components or peripheral devices for use therewith, etc., as well as traditional desktop computers and transaction servers connected to the Internet.
The application processing circuit 210 typically controls the operation of all components of the mobile communication device. In one aspect, the application processing circuit 210 is coupled to a host storage controller 250 for controlling storage of data, including storage of public and private keys in a key storage element 233 of an internal shared storage 232 that forms part of internal shared hardware (HW) resources 230. The application processing circuit 210 may also include a boot ROM or RAM 218 that stores boot sequence instructions for the various components of the SoC processing circuit 200. The SoC processing circuit 200 further includes one or more peripheral subsystems 220 controlled by application processing circuit 210. The peripheral subsystems 220 may include but are not limited to a storage subsystem (e.g., read-only memory (ROM), random access memory (RAM)), a video/graphics subsystem (e.g., digital signal processing circuit (DSP), graphics processing circuit unit (GPU)), an audio subsystem (e.g., DSP, analog-to-digital converter (ADC), digital-to-analog converter (DAC)), a power management subsystem, security subsystem (e.g., other encryption components and digital rights management (DRM) components), an input/output (I/O) subsystem (e.g., keyboard, touchscreen) and wired and wireless connectivity subsystems (e.g., universal serial bus (USB), Global Positioning System (GPS), Wi-Fi, Global System Mobile (GSM), Code Division Multiple Access (CDMA), 2G Long Term Evolution (LTE) modems). The exemplary peripheral subsystem 220, which is a modem subsystem, includes a DSP 222, various other hardware (HW) and software (SW) components 224, and various radio-frequency (RF) components 226. In one aspect, each peripheral subsystem 220 also includes a boot ROM or RAM 228 that stores a primary boot image (not shown) of the associated peripheral subsystems 220.
As noted, the SoC processing circuit 200 further includes various internal shared HW resources 230, such as an internal shared storage 232 (e.g. static RAM (SRAM), flash memory, etc.), which is shared by the application processing circuit 210 and the various peripheral subsystems 220 to store various runtime data or other parameters and to provide host memory. In the example of
In one aspect, the components 210, 218, 220, 228 and 230 of the SoC processing circuit 200 are integrated on a single-chip substrate. The SoC processing circuit 200 further includes various external shared HW resources 240, which may be located on a different chip substrate and may communicate with the SoC processing circuit 200 via one or more buses. External shared HW resources 240 may include, for example, an external shared storage 242 (e.g. double-data rate (DDR) dynamic RAM) and/or permanent or semi-permanent data storage 244 (e.g., a secure digital (SD) card, hard disk drive (HDD), an embedded multimedia card, a universal flash device (UFS), etc.), which may be shared by the application processing circuit 210 and the various peripheral subsystems 220 to store various types of data, such as an operating system (OS) information, system files, programs, applications, user data, audio/video files, etc. When the mobile communication device incorporating the SoC processing circuit 200 is activated, the SoC processing circuit begins a system boot up process in which the application processing circuit 210 may access boot ROM or RAM 218 to retrieve boot instructions for the SoC processing circuit 200, including boot sequence instructions for the various peripheral subsystems 220. The peripheral subsystems 220 may also have additional peripheral boot ROM or RAM 228.
Exemplary Common Modulus Key Generation/Processing Procedures
As noted, the message 412 can contain a challenge (i.e. a random number). This message may or may not be signed by the server using a server-own key that is itself chained to a public certificate that is stored in the device. By this method, the device knows it obtains an authentic message from the server. Then the device replies. If the message 412 contains a challenge, then the signed reply message 418 can contain the response to this challenge. It is not necessary that this message be encrypted with a server key, but such is possible. It is important to note, however, that the message contains the original challenge or a response and the message is signed (whereby the signature can play the role of a proper response, since it can be done only by the device and the server can verify it.) At this point, the acknowledgement of 424 may also contain data that may contain the actual key that is provisioned to the device by the server. This key is application specific, and any further communication between server and the target TA in the device uses this new information.
In an illustrative example, the client payload library 606 may include software components 608 equipped to handle the hello function using a certificate and a challenge. This may be performed, for example, by chaining the certificate to an embedded root, generating an encrypted device public key (DPK_EK), generating an encrypted chip ID, generating a challenge response and performing an RSA encryption of the encrypted device public key (DPK_EK), the chip ID and the challenge response. The client payload library 606 may also include software components equipped to set the wrapped key (SetKey) with the certificate by chaining the certificate to the embedded root, verify a challenge and response, generate the device public key (DPK) and unwrap the key and any metadata provided therewith.
In the illustrative example, the server payload library 602 may include software components 604 equipped to generate a challenge using a cryptographic quality random number generator (RNG) or PRNG. The server payload library 602 may also include software components equipped to wrap a service key based on the response message (ResponseMsg), a private key, a service key and some metadata. For example, the software may employ RSA to decrypt the response message received from the client payload library 606 using the private key and then extract an encrypted chip ID, an encrypted device public key (DPK_EK) and the response. The software then verifies the challenge response and performs a database lookup using the encrypted chip ID. The software decrypts the database record using device public key (DPK_EK), verifies a hash of the database record, extracts the device public key (DPK), a key wrap service key and the metadata. Again, these are just illustrative examples of software functions that might be performed while exploiting common modulus keypairs.
In an illustrative example, the server payload library 702 may include software components 704 equipped to generate the aforementioned challenge using a cryptographic quality RNG or PRNG. The software also includes components operative to authenticate the device using the chip ID, a database seed, a set of approved TA hashes, a signed response and a device public key. For example, the software may generate the hash for authentication using the device public key, the chip ID, and the database seed, then verify device public key (based on a database lookup using the hash. The software may also use RSA to verify the response using a public key for the SoC (such as SoC processing circuit 200 of
In the illustrative example, the client payload library 706 may include software components 708 equipped to respond to an authentication challenge. If the RSA device keypair is not present, the software generates a key pair using a bare public key (BPK) derivative and stores the key pair. The software then generates a response to the challenge by signing the challenge, the response, the TA hash (of a calling TA) and the opaque data. The software may also unwrap a service key and a certificate by chaining the certificate to an embedded device root, then verifying the signature over the wrapped key. The software can use the SoC private key to decrypt the wrapping key, then unwrap the service key and any metadata provided therewith. A calling TA can be verified using TA hashes and, if verified, the service key and metadata are returned to the caller. Again, these are just illustrative examples of software functions.
Exemplary Systems and Methods
In the example of
The processing circuit 804 is responsible for managing the bus 802 and for general processing, including the execution of software stored on the machine-readable medium 806. The software, when executed by processing circuit 804, causes processing system 814 to perform the various functions described herein for any particular apparatus. Machine-readable medium 806 may also be used for storing data that is manipulated by processing circuit 804 when executing software.
In at least some examples, the processing circuit 804 is configured to obtain first and second public-key/private-key pairs, wherein the first and second public-key/private-key pairs share a common modulus; decrypt a message using a private key of the first public-key/private-key pair; obtain a digital signature for the message by signing the message using a private key of the second public-key/private-key pair; and the transmitter device of the transceiver 810 is configured to send the digital signature from the cryptographic device.
Moreover, in at least some examples, the processing circuit 804 (or other means for processing) provides a means for obtaining first and second public-key/private-key pairs, wherein the first and second public-key/private-key pairs share a common modulus; means for decrypting a message using a private key of the first public-key/private-key pair; means for obtaining a digital signature for the message by signing the message using a private key of the second public-key/private-key pair; and the transmitter device (or other means for transmitting) of the transceiver 810 provides means for sending the digital signature from the cryptographic device. In some examples, the processing circuit is further configured to provide means for obtaining the first and second public-keys (e1, e2) so that the first public key (e1) is not a multiple of the second public key (e2) and/or the second public key (e2) is not a multiple of the first public key (e1). In some examples, the processing circuit is further configured to provide means for obtaining the prime numbers p and q while verifying that p−1 and q−1 are coprime to both the first public key (e1) and the second public key (e2).
Still further, in at least some examples, the receiver device of the transceiver 810 is configured to receive first and second public keys of first and second public-key/private-key pairs from a separate device, wherein the first and second public-key/private-key pairs share a common modulus; and the processing circuit 804 is configured to encrypt a message using the first public key of the first and second public-key/private-key pairs that share the common modulus; send the encrypted message to the separate device using the transmitter device of the transceiver 810; receive a signed reply to the message from the separate device using the receiver device of the transceiver 810, wherein the message has been signed with a signature obtained using a private key of the second public-key/private-key pair; and verify the signature of the signed reply using the second public key of the first and second public-key/private-key pairs that share the common modulus.
Moreover, in at least some examples, the receiver device (or other means for receiving) of the transceiver 810 provides means for receiving first and second public keys of first and second public-key/private-key pairs from a separate device, wherein the first and second public-key/private-key pairs share a common modulus; and the processing circuit 804 (or other means for processing) provides means for encrypting a message using the first public key of the first and second public-key/private-key pairs that share the common modulus; means for sending the encrypted message to the separate device using the transmitter device of the transceiver 810; means for receiving a signed reply to the message from the separate device using the receiver device (or other means for receiving) of the transceiver 810, wherein the message has been signed with a signature obtained using a private key of the second public-key/private-key pair; and means for verifying the signature of the signed reply using the second public key of the first and second public-key/private-key pairs that share the common modulus. In some examples, the first and second public-key/private-key pairs are distinct from one another. In some examples, the first and second public-keys (e1, e2) are such that the first public key (e1) is not a multiple of the second public key (e2) and/or the second public key (e2) is not a multiple of the first public key (e1). In some examples, the common modulus (N) is N=pq where p and q are prime numbers.
One or more processing circuits 804 in the processing system may execute software or software components. Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. A processing circuit may perform the tasks. A code segment may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory or storage contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.
The software may reside on machine-readable medium 806. The machine-readable medium 806 may be a non-transitory machine-readable medium. A non-transitory processing circuit-readable, machine-readable or computer-readable medium includes, by way of example, a magnetic storage device (e.g., hard disk, floppy disk, magnetic strip), an optical disk (e.g., a compact disc (CD) or a digital versatile disc (DVD)), a smart card, a flash memory device (e.g., a card, a stick, or a key drive), RAM, ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), a register, a removable disk, a hard disk, a CD-ROM and any other suitable medium for storing software and/or instructions that may be accessed and read by a machine or computer. The terms “machine-readable medium”, “computer-readable medium”, “processing circuit-readable medium” and/or “processor-readable medium” may include, but are not limited to, non-transitory media such as portable or fixed storage devices, optical storage devices, and various other media capable of storing, containing or carrying instruction(s) and/or data. Thus, the various methods described herein may be fully or partially implemented by instructions and/or data that may be stored in a “machine-readable medium,” “computer-readable medium,” “processing circuit-readable medium” and/or “processor-readable medium” and executed by one or more processing circuits, machines and/or devices. The machine-readable medium may also include, by way of example, a carrier wave, a transmission line, and any other suitable medium for transmitting software and/or instructions that may be accessed and read by a computer.
The machine-readable medium 806 may reside in the processing system 814, external to the processing system 814, or distributed across multiple entities including the processing system 814. The machine-readable medium 806 may be embodied in a computer program product. By way of example, a computer program product may include a machine-readable medium in packaging materials. Those skilled in the art will recognize how best to implement the described functionality presented throughout this disclosure depending on the particular application and the overall design constraints imposed on the overall system. For example, the machine-readable storage medium 806 may have one or more instructions which when executed by the processing circuit 804 causes the processing circuit to: obtain first and second public-key/private-key pairs, wherein the first and second public-key/private-key pairs share a common modulus; decrypting a message using a private key of the first public-key/private-key pair; obtain a digital signature by signing the message using a private key of the second public-key/private-key pair; and send the digital signature from the cryptographic device.
One or more of the components, steps, features, and/or functions illustrated in the figures may be rearranged and/or combined into a single component, block, feature or function or embodied in several components, steps, or functions. Additional elements, components, steps, and/or functions may also be added without departing from the disclosure. The apparatus, devices, and/or components illustrated in the Figures may be configured to perform one or more of the methods, features, or steps described in the Figures. The algorithms described herein may also be efficiently implemented in software and/or embedded in hardware.
The various illustrative logical blocks, modules, circuits, elements, and/or components described in connection with the examples disclosed herein may be implemented or performed with a general purpose processing circuit, a digital signal processing circuit (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic component, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processing circuit may be a microprocessing circuit, but in the alternative, the processing circuit may be any conventional processing circuit, controller, microcontroller, or state machine. A processing circuit may also be implemented as a combination of computing components, e.g., a combination of a DSP and a microprocessing circuit, a number of microprocessing circuits, one or more microprocessing circuits in conjunction with a DSP core, or any other such configuration.
Hence, in one aspect of the disclosure, processor 213 illustrated in
The embedded key provisioning processor 902 also has an encryption module/circuit 922 operative to encrypt messages using the first public-key/private-key pair and a decryption module/circuit 923 operative to decrypt messages using the first public-key/private-key pair. Still further, the embedded key provisioning processor 902 also has a common modulus digital signature processor module/circuit 906 operative to provide, obtain or otherwise generate digital signatures by signing the message using a private key of the second public-key/private-key pair. The digital signature processor module/circuit 906 includes a signing module/circuit 924 operative to sign messages using a private key of the second public-key/private-key pair and a verification module/circuit 926 operative to verify the signatures of messages using a public key of the second public-key/private-key pair. A signature message transmission/reception module/circuit 928 is operative to receive and/or transmit encrypted messages and signed messages and messages that are both encrypted and signed.
The embedded key provisioning instructions 1002 also include encryption instructions 1022 operative to encrypt messages using the first public-key/private-key pair and decryption instructions 1023 operative to decrypt messages using the first public-key/private-key pair. Still further, the embedded key provisioning instructions 1002 also include common modulus digital signature processor instructions 1006 operative to provide, obtain or otherwise generate digital signatures by signing the message using a private key of the second public-key/private-key pair. The digital signature processor instructions 1006 include signing instructions 1024 operative to sign messages using a private key of the second public-key/private-key pair and verification instructions 1026 operative to verify the signatures of messages using a public key of the second public-key/private-key pair. Signature message transmission/reception instructions 1028 are operative to receive and/or transmit encrypted messages and signed messages and messages that are both encrypted and signed.
Thus,
Still further, a common modulus digital signature processor module/circuit 1412 is operative to control signature verification procedures and the like using common modulus keypairs. More specifically, a verification module/circuit 1414 is operative to verify the signatures of messages received by the remote system wherein verification uses a public key of a common modulus keypair. For example, verification module/circuit 1414 may verify the signature of a signed reply received from the device of
Still further, common modulus digital signature processor instructions 1512 are operative to control signature verification procedures and the like using common modulus keypairs. More specifically, verification instructions 1514 are operative to verify the signatures of messages received by the remote system wherein verification uses a public key of a common modulus keypair. For example, verification instructions 1514 may verify the signature of a signed reply received from the device of
Note that aspects of the present disclosure may be described herein as a process that is depicted as a flowchart, a flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination corresponds to a return of the function to the calling function or the main function.
Those of skill in the art would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the aspects disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.
The methods or algorithms described in connection with the examples disclosed herein may be embodied directly in hardware, in a software module executable by a processor, or in a combination of both, in the form of processing unit, programming instructions, or other directions, and may be contained in a single device or distributed across multiple devices. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. A storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor.
The various features of the invention described herein can be implemented in different systems without departing from the invention. It should be noted that the foregoing embodiments are merely examples and are not to be construed as limiting the invention. The description of the embodiments is intended to be illustrative, and not to limit the scope of the claims. As such, the present teachings can be readily applied to other types of apparatuses and many alternatives, modifications, and variations will be apparent to those skilled in the art.