CA2330749C - Private key validity and validation - Google Patents
Private key validity and validation Download PDFInfo
- Publication number
- CA2330749C CA2330749C CA002330749A CA2330749A CA2330749C CA 2330749 C CA2330749 C CA 2330749C CA 002330749 A CA002330749 A CA 002330749A CA 2330749 A CA2330749 A CA 2330749A CA 2330749 C CA2330749 C CA 2330749C
- Authority
- CA
- Canada
- Prior art keywords
- private key
- criteria
- key
- seed
- tests
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
- H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/26—Testing cryptographic entity, e.g. testing integrity of encryption key or encryption algorithm
Abstract
A method of generating a private key for use in a public key data communication system implemented between a pair of correspondents is disclosed. The method comprises the steps of generating a random number for use as a private key and testing the number against a predetermined set of criteria. The criteria are chosen to determine the statistical randomness of the number. The random number is utilized as a key upon satisfying the criteria.
Description
PRIVATE KEY VALIDITY AND VALIDATION
The present inveiition relates to secure digital data communication systeins and, in particular, to a method for ensuring a particular ratidom cryptographic private key value has adequate randomness properties (considered by itself) and a method for validating cryptographic private keys in such systems.
BACKGROUND OF THE INVENTION
Secure data comniunication systems are used to transfer infonnation between a pair of correspondents. At least part of the information that is exchanged is encoded (enciphered) by a predetermined mathematical operation by the sender. The recipient may then perfonn a complimentary mathenlatical operation to unencode (decipher) the information. The enciphering and decipliering of information is normally perforined utilizing a cryptographic key detennined by the particular cryptographic sclieme iinplemented between the correspondents. Consequehtly, there are certain parameters that must be known beforehand between the correspondents. For exaniple, in public key or syinmetric key systems, various schemes aiid protocols have been devised to validate the sender's public key, the identity of the sender and such like.
In all of these schemes, it is assumed that the cryptographic keys, be it the private key, the public key or the symmetric key, is derived and valid as specified in the protocol sclieme. Problerns, however, will arise if these parameters are either bogus or defective in soine way.
Digital signature metliods have been derived to prove to a third party that a message was signed by the actual originator. Practical public key sigiiature schemes are based on the difficulty of solving certain matllematical problems to make alteration or forgery by unauthorized parties difficult. Most of the proposed schemes have been based either on the problein of factoring large integers or in the difficulty of cominIting discrete logaritlinls over f ilite fields (or over finite grotips, in general).
For example, the RSA system depends on the difficulty of factoring large integers.
A digital signature of a niessage is a number which is dependent on some secret known only to the signor, and additionally, on the content of the message being signed. Signatures inust be verifiable. If a dispute arises as to whether a party signed (caused by either a signor tl-ying to repudiate a signature it did create or a fraudulent claimant), an unbiased tliird party should be able to resolve the matter equitably without requiring access to the signor's secret information, i.e., private key.
The ElGamal signature scheme is a randomized signatures niechanism. In order to generate keys for the ElGamal signature scheme, eacll entity creates a public key and corresponding private key. Thus, each entity generates a large random prime p and a generator cx of the multiplicative group ZiP. Next, the etitities select a random ititeger a such that 1_< a_< p - 2 and computes the value y= ocamodp. Thus, for example, entity A's public key is (y) along with the system parameters p and ot , while A's private key is a.
The security of the above system is generally based on the difficulty of the discrete log problem. The RSA cryptosystem uses a modulus of the form n=pq where p and q are distinct odd primes. The primes p and q must be of sufficient size that factorization of the product is beyond computational reach. Moreover, there should be random primes in the sense that they are chosen as a function of a random input through a process defining a pool of candidates of sufficient cardinality that an exhaustive attack is itlfeasible. In practice, the resulting primes niust also be of a predetermined bit length to meet systems specifications. Without these constraints on the selection of the primes p and-q, the RSA systeni is vulnerable to a so-called "first person attack".
In elliptic curve cryptosystems, the elliptic curve private key is a statistically uiiique and unpredictable value selected between I and n-1 where n is the prime order of G, the generating point of the large subgroup specified by the associated EC domain parameters.
In a possible "first person attack", entity A the attacker, creates a private key that is weak and uses it to obtain services and sucll like. Later, the dislionest entity repudiates or disavows its private key as being weak atld then claims that it did not request these services. That is, party A
alleges it inadvertently used a weak private key resulting in a public key that was easily attacked, allowing a third party to derive its private key and thus, was able to impersonate the original entity A. For example, where the key is generated using a seeded hash to produce a 161 bit private EC
key by generating 264, party A may select the one (expected) key with a high order 64 bits of Os. The first party goes to a judge with a repudiation request and points out that an adversary could attack remaining 97 bits in feasible time. He therefore repudiates his key as it has already been shown that 97 bit keys can be broken. Clearly, in high security applications, it is desirable to avoid the first persoii attack.
One way to address this possible concern about first party repudiatioil is simply to deny all first party repudiation requests. However, this may result in a problenl if a key is generated that actually is weak.
What is needed is the ability of the owner to be assured that his particular private key is not weak. In some applications it may not be sufficient to claim that generation of weak key pairs is statistically improbable. The z owner wants to be assured that his specific key has no properties that might make it weak, as no matter what value it inight be, he is not able to later-repudiate it.
The cryptographic strength of the key depends to a large extent on the random distribution of bits in the binary representation used as the key.
Thus, although the key may be generated by a pseudorandom number generator and is tlierefore random, it may be weak if the digits are distributed in a recognizable pattern or grouped to provide a shorter key.
Thus, it is desirable to implement an_ECC ElGamal type scheme in wliicli the probability of private key repudiation is Inininiized.
SUMMARY OF THE INVENTION
In general terms, the present invention provides a method of generating a private key for use in a public key data comniunication system implemented between a pair of correspondents, said nietliod comprising the steps of generating a random number for use as a private key, testing said number against a predetennined set of criteria to determine the statistical randomness of said numbers and utilizing said random number upon satisfying said criteria.
BRIEF DESCRIPTION OF THE DRAWINGS
These and other features of the preferred embodiments of the invention will become more apparent in the following detailed description in wliich reference is made to the appended drawings wherein:
Figure 1 is a schematic diagram of a digital coinmunication system;
Figure 2 is a schenlatic diagram of an encryption unit of figure 1;
and Figure 3 shows a flow diagram of a canonical private key generation scheme.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
Referring to figure 1, a digital data communication system 10 includes a pair of correspondents designated as a sender 12 and recipient 14 who are connected by a communication cllannel 16. Each of the correspondents 12 and 14 includes an encryption unit 18, 20, respectively that may process digital information and prepare it for transmission through the channel 16 as will be described below.
In the following description, embodiments of the invention will be exemplified with reference to an elliptic curve ElGamal type scheme understood that the other cryptosystems or Diffie Hellman key exchanges may equally be utilized.
An elliptic curve private key is a statistically unique and unpredictable value selected between I and n-1, where n is the prime order of G, the generating point of the large subgroup specified by ihe associated elliptic curve (EC) domain parameters. In high sectlrity applicatiotis, one iriay wish to be able to be assured and subsequently demonstrate that strict key generation criteria was met. To facilitate this, a key test processor 28 is included in the key generation and to validate the keys subsequently an EC private key validate processor 30 is incorporated into the encryption units 18, 20:
As shown in figure 2, a private key k is generated in a canonical private key generation function 32 as shown in figure 2. The random iiumbers presented as possible private keys from function 32 are selected to be of a size which is approximately the same size as n, the prime order of the generating point G. The numbers can be generated by either a true noise ~
liardware randomizer or via a seeded pseudorandom function as shown in figure 3.
Either a (true) random number generator (RNG) 36 or a pseudo random number generator (PRNG) 38 produces a SEED 34. To utilize the PRNG 38 a random seed is input into the PRNG to generate the SEED 34 at the output whereas the RNG generates the SEED 34 directly. The SEED 34 is hashed in a one way function at 40 and the output from the hash is shaped so that it is the correct size for a private key. The resulting value is a bit string that may be used as the private key, denoted as k.
The llash function used is SHA-1. A counter value X'O 1', X'02', etc.
is concatenated to the SEED to produce different 160 bit values, which are concatenated on the right until the resulting value is larger than n. The shape function used is niodulo n.
Key test processor 28 receives the value generated by the key generation function 32 and applies to it a predetermined, selectable set of tests that confirm that the key k meets the set of criteria considered acceptable to the user. Typically, the processor may apply standard statistical tests to ensure that the bit distribution in the key appears random and unpredictable. Among the tests that can be used to check for apparent randomness are:
1. Frequency test (monobit test) 2. Poker test 3. Runs test 4. Long run test The output from the generator function 32 is subjected to each of the following tests and if any of the tests fail, then the candidate private key k is rejected. By way of example, The Monobit Test require the counting of the number of ones in the 20,000 bit stream. Denote this quantity by X.
The test is passed if 65 < X < 135 for an error probability of 1 in 1,000,000, i.e., a very high confidence level.
Similarly, the Poker Test divides the 200 bit stream into 66 contiguous 3 bit segments. Count and store the number of occurrences of each of the 8possible 3 bit values is counted and stored. Denote f(i) as the number of each 3 bit value I where 0 < = i < = 8.
Evaluate the following:
X = (8/66) * SUM from i= 0 to 8 [(f(i))**2] - 66 The test is considered passed if the value A of x falls within the predetermined range determined by the required confidence level.
The Runs Test utilizes a run defmed as a maximal sequence of consecutive bits of either all ones or all zeros, which is part of the 200 bit sample stream. The incidences of runs (for both consecutive zeros and consecutive ones) of all lengths (> = 1) in the sample stream are counted and stored. The distribution of the lengths is monitored by the frequency of the run length in each range compared with an acceptable criteria determined by the required confidence level.
In addition, a long run test may be included the Long Run Test defmed to be a run of length 16 or more (of either zeros or ones). On the sample of 200 bits, the test is passed if there are NO long runs.
By including a long run test to the above, one can be assured that any specific private key appears random and is therefore difficult to attack.
21784297.1 By selecting an appropriate value for each statistical test that is related to the confidence level desired by the user for a particular clailned randoni sequence to be used for a private key, the only keys selected will be those that are acceptable to the criteria set by the user. Thereafter, repudiation is not possible, provided the criteria are met. If the confidence level is zero, then no statistical tests are run. If the confidence level is 80%
or 90%, then the appropriate acceptable range of values is determined for eacll test and the tests run to see if the actual value is in the acceptable range. Note that as the statistic approaches 100%, more candidate private key values will be discarded and therefore key pair generation would be expected to take longer.
Naturally, additional tests may be substituted or included as considered appropriate.
Referring again to figure 2, after the key k has been accepted, it is associated within encryption unit 18 with a set of EC domain parameters 24. The dolnain parameters include a EC public key kG derived from the key k. The parameters also include plaintext (opened) EC private key data structure that is claimed to be associated with the above set of EC domain parameters and EC public key. The plaintext EC private key data structure contains (at least) the following information:
1. An indication of the EC domain parameters associated with this private key.
2. The SEED that produced the value of the private key k.
3. The value of the private key k.
4. An indication of the level of confidence that the value of the private key k "appears" random. This is a value between 0 and 99 applied during the statistical tests and represents a percentage.
The output of this process is either pass or fail. Pass indicates the EC
Private Key passed all validation tests. Fail indicates the EC Private Key k did not pass all validatioii tests. The private and public keys nlay then be used to sign a message or authenticate a key using established protocols between the correspondents 12, 14.
The EC private key data structure is maintained secure in the domain and opened by implementation-dependent means so that the plaintext of the private key is recovered and its integrity verified as part of the process of opening the key.
If a signature is repudiated, the validity of the key may be verified using the private key data structure 24. The parameters are forwarded to a processor 30, which tests the validity of the private key against a predetermined set of criteria.
The process performed in the processor 30 is described as follows:
1. Coinpare the (claimed) EC domain parameters with the iridicatioil in the private key data structure of the associated EC domain parameters to ensure that all respective components are identical in value.
2. Validate the length of the SEED to ensure it is larger than n, the prime order of the generating point G.
3. Validate the SEED by passing it as inptit to the canonical seeded hash function to ensure that the private key k is the result.
4. Validate the private key k by comparing kG with the value of the (claimed) associated public key to ensure they are identical in value.
The present inveiition relates to secure digital data communication systeins and, in particular, to a method for ensuring a particular ratidom cryptographic private key value has adequate randomness properties (considered by itself) and a method for validating cryptographic private keys in such systems.
BACKGROUND OF THE INVENTION
Secure data comniunication systems are used to transfer infonnation between a pair of correspondents. At least part of the information that is exchanged is encoded (enciphered) by a predetermined mathematical operation by the sender. The recipient may then perfonn a complimentary mathenlatical operation to unencode (decipher) the information. The enciphering and decipliering of information is normally perforined utilizing a cryptographic key detennined by the particular cryptographic sclieme iinplemented between the correspondents. Consequehtly, there are certain parameters that must be known beforehand between the correspondents. For exaniple, in public key or syinmetric key systems, various schemes aiid protocols have been devised to validate the sender's public key, the identity of the sender and such like.
In all of these schemes, it is assumed that the cryptographic keys, be it the private key, the public key or the symmetric key, is derived and valid as specified in the protocol sclieme. Problerns, however, will arise if these parameters are either bogus or defective in soine way.
Digital signature metliods have been derived to prove to a third party that a message was signed by the actual originator. Practical public key sigiiature schemes are based on the difficulty of solving certain matllematical problems to make alteration or forgery by unauthorized parties difficult. Most of the proposed schemes have been based either on the problein of factoring large integers or in the difficulty of cominIting discrete logaritlinls over f ilite fields (or over finite grotips, in general).
For example, the RSA system depends on the difficulty of factoring large integers.
A digital signature of a niessage is a number which is dependent on some secret known only to the signor, and additionally, on the content of the message being signed. Signatures inust be verifiable. If a dispute arises as to whether a party signed (caused by either a signor tl-ying to repudiate a signature it did create or a fraudulent claimant), an unbiased tliird party should be able to resolve the matter equitably without requiring access to the signor's secret information, i.e., private key.
The ElGamal signature scheme is a randomized signatures niechanism. In order to generate keys for the ElGamal signature scheme, eacll entity creates a public key and corresponding private key. Thus, each entity generates a large random prime p and a generator cx of the multiplicative group ZiP. Next, the etitities select a random ititeger a such that 1_< a_< p - 2 and computes the value y= ocamodp. Thus, for example, entity A's public key is (y) along with the system parameters p and ot , while A's private key is a.
The security of the above system is generally based on the difficulty of the discrete log problem. The RSA cryptosystem uses a modulus of the form n=pq where p and q are distinct odd primes. The primes p and q must be of sufficient size that factorization of the product is beyond computational reach. Moreover, there should be random primes in the sense that they are chosen as a function of a random input through a process defining a pool of candidates of sufficient cardinality that an exhaustive attack is itlfeasible. In practice, the resulting primes niust also be of a predetermined bit length to meet systems specifications. Without these constraints on the selection of the primes p and-q, the RSA systeni is vulnerable to a so-called "first person attack".
In elliptic curve cryptosystems, the elliptic curve private key is a statistically uiiique and unpredictable value selected between I and n-1 where n is the prime order of G, the generating point of the large subgroup specified by the associated EC domain parameters.
In a possible "first person attack", entity A the attacker, creates a private key that is weak and uses it to obtain services and sucll like. Later, the dislionest entity repudiates or disavows its private key as being weak atld then claims that it did not request these services. That is, party A
alleges it inadvertently used a weak private key resulting in a public key that was easily attacked, allowing a third party to derive its private key and thus, was able to impersonate the original entity A. For example, where the key is generated using a seeded hash to produce a 161 bit private EC
key by generating 264, party A may select the one (expected) key with a high order 64 bits of Os. The first party goes to a judge with a repudiation request and points out that an adversary could attack remaining 97 bits in feasible time. He therefore repudiates his key as it has already been shown that 97 bit keys can be broken. Clearly, in high security applications, it is desirable to avoid the first persoii attack.
One way to address this possible concern about first party repudiatioil is simply to deny all first party repudiation requests. However, this may result in a problenl if a key is generated that actually is weak.
What is needed is the ability of the owner to be assured that his particular private key is not weak. In some applications it may not be sufficient to claim that generation of weak key pairs is statistically improbable. The z owner wants to be assured that his specific key has no properties that might make it weak, as no matter what value it inight be, he is not able to later-repudiate it.
The cryptographic strength of the key depends to a large extent on the random distribution of bits in the binary representation used as the key.
Thus, although the key may be generated by a pseudorandom number generator and is tlierefore random, it may be weak if the digits are distributed in a recognizable pattern or grouped to provide a shorter key.
Thus, it is desirable to implement an_ECC ElGamal type scheme in wliicli the probability of private key repudiation is Inininiized.
SUMMARY OF THE INVENTION
In general terms, the present invention provides a method of generating a private key for use in a public key data comniunication system implemented between a pair of correspondents, said nietliod comprising the steps of generating a random number for use as a private key, testing said number against a predetennined set of criteria to determine the statistical randomness of said numbers and utilizing said random number upon satisfying said criteria.
BRIEF DESCRIPTION OF THE DRAWINGS
These and other features of the preferred embodiments of the invention will become more apparent in the following detailed description in wliich reference is made to the appended drawings wherein:
Figure 1 is a schematic diagram of a digital coinmunication system;
Figure 2 is a schenlatic diagram of an encryption unit of figure 1;
and Figure 3 shows a flow diagram of a canonical private key generation scheme.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
Referring to figure 1, a digital data communication system 10 includes a pair of correspondents designated as a sender 12 and recipient 14 who are connected by a communication cllannel 16. Each of the correspondents 12 and 14 includes an encryption unit 18, 20, respectively that may process digital information and prepare it for transmission through the channel 16 as will be described below.
In the following description, embodiments of the invention will be exemplified with reference to an elliptic curve ElGamal type scheme understood that the other cryptosystems or Diffie Hellman key exchanges may equally be utilized.
An elliptic curve private key is a statistically unique and unpredictable value selected between I and n-1, where n is the prime order of G, the generating point of the large subgroup specified by ihe associated elliptic curve (EC) domain parameters. In high sectlrity applicatiotis, one iriay wish to be able to be assured and subsequently demonstrate that strict key generation criteria was met. To facilitate this, a key test processor 28 is included in the key generation and to validate the keys subsequently an EC private key validate processor 30 is incorporated into the encryption units 18, 20:
As shown in figure 2, a private key k is generated in a canonical private key generation function 32 as shown in figure 2. The random iiumbers presented as possible private keys from function 32 are selected to be of a size which is approximately the same size as n, the prime order of the generating point G. The numbers can be generated by either a true noise ~
liardware randomizer or via a seeded pseudorandom function as shown in figure 3.
Either a (true) random number generator (RNG) 36 or a pseudo random number generator (PRNG) 38 produces a SEED 34. To utilize the PRNG 38 a random seed is input into the PRNG to generate the SEED 34 at the output whereas the RNG generates the SEED 34 directly. The SEED 34 is hashed in a one way function at 40 and the output from the hash is shaped so that it is the correct size for a private key. The resulting value is a bit string that may be used as the private key, denoted as k.
The llash function used is SHA-1. A counter value X'O 1', X'02', etc.
is concatenated to the SEED to produce different 160 bit values, which are concatenated on the right until the resulting value is larger than n. The shape function used is niodulo n.
Key test processor 28 receives the value generated by the key generation function 32 and applies to it a predetermined, selectable set of tests that confirm that the key k meets the set of criteria considered acceptable to the user. Typically, the processor may apply standard statistical tests to ensure that the bit distribution in the key appears random and unpredictable. Among the tests that can be used to check for apparent randomness are:
1. Frequency test (monobit test) 2. Poker test 3. Runs test 4. Long run test The output from the generator function 32 is subjected to each of the following tests and if any of the tests fail, then the candidate private key k is rejected. By way of example, The Monobit Test require the counting of the number of ones in the 20,000 bit stream. Denote this quantity by X.
The test is passed if 65 < X < 135 for an error probability of 1 in 1,000,000, i.e., a very high confidence level.
Similarly, the Poker Test divides the 200 bit stream into 66 contiguous 3 bit segments. Count and store the number of occurrences of each of the 8possible 3 bit values is counted and stored. Denote f(i) as the number of each 3 bit value I where 0 < = i < = 8.
Evaluate the following:
X = (8/66) * SUM from i= 0 to 8 [(f(i))**2] - 66 The test is considered passed if the value A of x falls within the predetermined range determined by the required confidence level.
The Runs Test utilizes a run defmed as a maximal sequence of consecutive bits of either all ones or all zeros, which is part of the 200 bit sample stream. The incidences of runs (for both consecutive zeros and consecutive ones) of all lengths (> = 1) in the sample stream are counted and stored. The distribution of the lengths is monitored by the frequency of the run length in each range compared with an acceptable criteria determined by the required confidence level.
In addition, a long run test may be included the Long Run Test defmed to be a run of length 16 or more (of either zeros or ones). On the sample of 200 bits, the test is passed if there are NO long runs.
By including a long run test to the above, one can be assured that any specific private key appears random and is therefore difficult to attack.
21784297.1 By selecting an appropriate value for each statistical test that is related to the confidence level desired by the user for a particular clailned randoni sequence to be used for a private key, the only keys selected will be those that are acceptable to the criteria set by the user. Thereafter, repudiation is not possible, provided the criteria are met. If the confidence level is zero, then no statistical tests are run. If the confidence level is 80%
or 90%, then the appropriate acceptable range of values is determined for eacll test and the tests run to see if the actual value is in the acceptable range. Note that as the statistic approaches 100%, more candidate private key values will be discarded and therefore key pair generation would be expected to take longer.
Naturally, additional tests may be substituted or included as considered appropriate.
Referring again to figure 2, after the key k has been accepted, it is associated within encryption unit 18 with a set of EC domain parameters 24. The dolnain parameters include a EC public key kG derived from the key k. The parameters also include plaintext (opened) EC private key data structure that is claimed to be associated with the above set of EC domain parameters and EC public key. The plaintext EC private key data structure contains (at least) the following information:
1. An indication of the EC domain parameters associated with this private key.
2. The SEED that produced the value of the private key k.
3. The value of the private key k.
4. An indication of the level of confidence that the value of the private key k "appears" random. This is a value between 0 and 99 applied during the statistical tests and represents a percentage.
The output of this process is either pass or fail. Pass indicates the EC
Private Key passed all validation tests. Fail indicates the EC Private Key k did not pass all validatioii tests. The private and public keys nlay then be used to sign a message or authenticate a key using established protocols between the correspondents 12, 14.
The EC private key data structure is maintained secure in the domain and opened by implementation-dependent means so that the plaintext of the private key is recovered and its integrity verified as part of the process of opening the key.
If a signature is repudiated, the validity of the key may be verified using the private key data structure 24. The parameters are forwarded to a processor 30, which tests the validity of the private key against a predetermined set of criteria.
The process performed in the processor 30 is described as follows:
1. Coinpare the (claimed) EC domain parameters with the iridicatioil in the private key data structure of the associated EC domain parameters to ensure that all respective components are identical in value.
2. Validate the length of the SEED to ensure it is larger than n, the prime order of the generating point G.
3. Validate the SEED by passing it as inptit to the canonical seeded hash function to ensure that the private key k is the result.
4. Validate the private key k by comparing kG with the value of the (claimed) associated public key to ensure they are identical in value.
5. Validate the value of the private key k to ensure it meets the level of confidetice specified in the statistical tests run by the test function 28.
6. If all tests succeed, then output "pass"; otherwise output "fail". A pass iildicates that the private key inet all criteria specified by the correspondent 12 and therefore, cannot be repudiated.
Applications witll very high security requirements may also wish to validate that the per-message secret k value was generated by use of an approved pseudorandoln number generator from a KSEED value. When this option is desired, a particular KSEED value is associated with a particular private key and the KSEED value shall not be used for any other purpose. The KSEED value shall be stored securely with the other components of the private key along with an indication regarding whicll pseudorandom number generator is used. The range of possible values for k is the same as the range of possible values for a private key associated witli a particular set of domain parameters. The only difference is that multiple k values are generated from KSEED, while one private key is generated froin SEED. Kiiowing this information, the validatiotl routine outputs a caller-specified ilumber of k values and the associated r values (wllich would nonnally be a part of the digital signature). The caller then conlpares the output r values with a stored list of r values from previous signatures, to ensure that they are consistent.
While the invention has been described in connection with the specific embodiment thereof, and in a specific use, various niodifications tliereof will occur to those skilled in the art without departing from the spirit of the invention as set forth in the appended claims.
The terms and expressions which have been employed in this specification are used as terms of description and not of limitations, there is no int.ention in the use of such terms and expressions to exclude any eyuivalence of the features shown and described or portions thereof, but it is recogiiized that various modifications are possible within the scope of the claims to the invention.
Applications witll very high security requirements may also wish to validate that the per-message secret k value was generated by use of an approved pseudorandoln number generator from a KSEED value. When this option is desired, a particular KSEED value is associated with a particular private key and the KSEED value shall not be used for any other purpose. The KSEED value shall be stored securely with the other components of the private key along with an indication regarding whicll pseudorandom number generator is used. The range of possible values for k is the same as the range of possible values for a private key associated witli a particular set of domain parameters. The only difference is that multiple k values are generated from KSEED, while one private key is generated froin SEED. Kiiowing this information, the validatiotl routine outputs a caller-specified ilumber of k values and the associated r values (wllich would nonnally be a part of the digital signature). The caller then conlpares the output r values with a stored list of r values from previous signatures, to ensure that they are consistent.
While the invention has been described in connection with the specific embodiment thereof, and in a specific use, various niodifications tliereof will occur to those skilled in the art without departing from the spirit of the invention as set forth in the appended claims.
The terms and expressions which have been employed in this specification are used as terms of description and not of limitations, there is no int.ention in the use of such terms and expressions to exclude any eyuivalence of the features shown and described or portions thereof, but it is recogiiized that various modifications are possible within the scope of the claims to the invention.
Claims (14)
PRIVILEGE IS CLAIMED ARE DEFINED AS FOLLOWS:
1. A method of generating a private key and corresponding public key for use by a correspondent as a key pair in a public key data communication system implemented between a pair of correspondents, said method comprising the steps of generating a number to be used as a private key, establishing a predetermined set of criteria to be satisfied by said private key, testing said number against each of said set of criteria to determine the suitability of said number as said private key, rejecting said number upon failure to meet said criteria, accepting said number as said private key upon meeting said criteria, retaining said private key and said set of criteria against which said private key has been tested for subsequent validation, and generating from said private key a corresponding public key, whereby, upon utilization of said key pair in said data communication system, repudiation of said private key is inhibited by determining the validity thereof against said set of criteria.
2. A method according to claim 1 wherein said set of criteria include results of statistical tests to determine the randomness of said number.
3. A method according to claim 2 wherein said criteria includes a determination of a confidence level of said statistical tests.
4. A method according to claim 1 where in said set of criteria is a selectable set being retained by said one correspondent.
5. A method according to claim 1 wherein said number is produced from a seed value according to a defined mathematical operation and said seed value, said number and said set of criteria are retained in a secure domain.
6. A computer readable medium comprising computer executable instructions that when executed cause a cryptographic processor to perform the method according to any one of claims 1 to 5.
7. A cryptographic unit comprising a cryptographic unit configured to obtain and process a set of computer readable instructions for performing the method according to any one of claims 1 to 5.
8. A method of validating a private key used to produce a digital signature in a public key data communication system comprising the steps of one correspondent selecting a number as a private key, testing said number against a set of criteria to determine its suitability as a private key, accepting said number upon satisfying said tests, generating a corresponding public key from said private key, retaining said private key and said criteria in a secure domain, signing a message with said private key to produce a digital signature, verifying the validity of said signature by retrieving said private key from said secure domain, testing said retrieved private key against said set of criteria and validating said signature upon said retrieved private key satisfying said tests, whereby repudiation of said signature is inhibited.
9. A method according to claim 8 wherein said set of criteria include results of statistical tests.
10. A method according to claim 9 wherein said set of criteria is selectable by said one correspondent.
11. A method according to claim 9 in which said retrieved private key is used to generate a corresponding public key and said public keys are compared.
12. A method according to claim 11 wherein said number is obtained by performing a mathematical operation on a seed, said method including retaining said seed, performing said mathematical operation on said seed and comparing the result with said retrieved private key.
13. A computer readable medium comprising computer executable instructions that when executed cause a cryptographic processor to perform the method according to any one of claims 8 to 12.
14. A cryptographic unit comprising a cryptographic unit configured to obtain and process a set of computer readable instructions for performing the method according to any one of claims 8 to 12.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/074,540 US6195433B1 (en) | 1998-05-08 | 1998-05-08 | Private key validity and validation |
| US09/074,540 | 1998-05-08 | ||
| PCT/CA1999/000381 WO1999059286A1 (en) | 1998-05-08 | 1999-05-10 | Private key validity and validation |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2330749A1 CA2330749A1 (en) | 1999-11-18 |
| CA2330749C true CA2330749C (en) | 2009-11-10 |
Family
ID=22120103
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002330749A Expired - Lifetime CA2330749C (en) | 1998-05-08 | 1999-05-10 | Private key validity and validation |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US6195433B1 (en) |
| EP (1) | EP1076952B1 (en) |
| JP (1) | JP4731686B2 (en) |
| AU (1) | AU3695299A (en) |
| CA (1) | CA2330749C (en) |
| DE (1) | DE69942390D1 (en) |
| WO (1) | WO1999059286A1 (en) |
Families Citing this family (45)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6643374B1 (en) | 1999-03-31 | 2003-11-04 | Intel Corporation | Duty cycle corrector for a random number generator |
| US6795837B1 (en) | 1999-03-31 | 2004-09-21 | Intel Corporation | Programmable random bit source |
| EP1182777B1 (en) * | 1999-05-18 | 2003-10-01 | Angel José Ferre Herrero | Self-corrective randomizer-encryptor system and method |
| US6687721B1 (en) | 2000-03-31 | 2004-02-03 | Intel Corporation | Random number generator with entropy accumulation |
| US6792438B1 (en) | 2000-03-31 | 2004-09-14 | Intel Corporation | Secure hardware random number generator |
| CA2329590C (en) * | 2000-12-27 | 2012-06-26 | Certicom Corp. | Method of public key generation |
| US7350083B2 (en) * | 2000-12-29 | 2008-03-25 | Intel Corporation | Integrated circuit chip having firmware and hardware security primitive device(s) |
| FR2834155B1 (en) * | 2001-12-21 | 2005-02-18 | Gemplus Card Int | METHOD FOR GENERATING CRYPTOGRAPHIC ELECTRONIC KEYS AND CORRESPONDING COMPONENT |
| US7031469B2 (en) * | 2001-12-27 | 2006-04-18 | Slam Dunk Networks, Inc. | Optimized enveloping via key reuse |
| JP2003309544A (en) * | 2002-04-15 | 2003-10-31 | Nec Corp | Cipher key delivery apparatus |
| CA2427870C (en) * | 2002-05-03 | 2014-07-08 | Certicom Corp. | Method and apparatus for performing elliptic curve arithmetic |
| US7788479B2 (en) * | 2002-07-25 | 2010-08-31 | International Business Machines Corporation | Apparatus, system and method of ensuring that only randomly-generated numbers that have passed a test are used for cryptographic purposes |
| EP1435558A1 (en) * | 2003-01-02 | 2004-07-07 | Texas Instruments Incorporated | On-device random number generator |
| US7424115B2 (en) * | 2003-01-30 | 2008-09-09 | Nokia Corporation | Generating asymmetric keys in a telecommunications system |
| US8131649B2 (en) * | 2003-02-07 | 2012-03-06 | Igware, Inc. | Static-or-dynamic and limited-or-unlimited content rights |
| US20100017627A1 (en) | 2003-02-07 | 2010-01-21 | Broadon Communications Corp. | Ensuring authenticity in a closed content distribution system |
| US7779482B1 (en) | 2003-02-07 | 2010-08-17 | iGware Inc | Delivery of license information using a short messaging system protocol in a closed content distribution system |
| US7177888B2 (en) * | 2003-08-01 | 2007-02-13 | Intel Corporation | Programmable random bit source |
| GB0329039D0 (en) * | 2003-12-15 | 2004-01-14 | Ncipher Corp Ltd | Cryptographic security module method and apparatus |
| US20050149732A1 (en) * | 2004-01-07 | 2005-07-07 | Microsoft Corporation | Use of static Diffie-Hellman key with IPSec for authentication |
| US7657612B2 (en) * | 2004-01-07 | 2010-02-02 | Microsoft Corporation | XML schema for network device configuration |
| US20050198221A1 (en) * | 2004-01-07 | 2005-09-08 | Microsoft Corporation | Configuring an ad hoc wireless network using a portable media device |
| US20050198233A1 (en) * | 2004-01-07 | 2005-09-08 | Microsoft Corporation | Configuring network settings of thin client devices using portable storage media |
| US7769995B2 (en) * | 2004-01-07 | 2010-08-03 | Microsoft Corporation | System and method for providing secure network access |
| US7974405B2 (en) * | 2004-01-26 | 2011-07-05 | Nec Corporation | Method and device for calculating a function from a large number of inputs |
| US7710587B2 (en) * | 2004-10-18 | 2010-05-04 | Microsoft Corporation | Method and system for configuring an electronic device |
| US20060156013A1 (en) * | 2005-01-07 | 2006-07-13 | Beeson Curtis L | Digital signature software using ephemeral private key and system |
| US20060153370A1 (en) * | 2005-01-07 | 2006-07-13 | Beeson Curtis L | Generating public-private key pair based on user input data |
| US7826833B2 (en) * | 2005-02-17 | 2010-11-02 | Madhavan P G | Channel assay for thin client device wireless provisioning |
| US7616588B2 (en) * | 2005-03-31 | 2009-11-10 | Microsoft Corporation | Simplified creation and termination of an ad hoc wireless network with internet connection sharing |
| US7797545B2 (en) | 2005-09-29 | 2010-09-14 | Research In Motion Limited | System and method for registering entities for code signing services |
| US8340289B2 (en) | 2005-09-29 | 2012-12-25 | Research In Motion Limited | System and method for providing an indication of randomness quality of random number data generated by a random data service |
| DE602005018215D1 (en) * | 2005-09-29 | 2010-01-21 | Research In Motion Ltd | System and method for registering data units for code signing services |
| EP1770588B1 (en) * | 2005-09-29 | 2008-12-17 | Research In Motion Limited | System and method for providing code signing services |
| ATE418112T1 (en) * | 2005-09-29 | 2009-01-15 | Research In Motion Ltd | ACCOUNT MANAGEMENT IN A SYSTEM AND METHOD FOR PROVIDING CODE SIGNING SERVICES |
| EP1770587A1 (en) * | 2005-09-29 | 2007-04-04 | Research In Motion Limited | Remote hash generation in a system and method for providing code signing services |
| EP2033350A2 (en) | 2006-05-02 | 2009-03-11 | Broadon Communications Corp. | Content management system and method |
| US7624276B2 (en) * | 2006-10-16 | 2009-11-24 | Broadon Communications Corp. | Secure device authentication system and method |
| US7613915B2 (en) * | 2006-11-09 | 2009-11-03 | BroadOn Communications Corp | Method for programming on-chip non-volatile memory in a secure processor, and a device so programmed |
| US8923519B2 (en) * | 2009-05-29 | 2014-12-30 | Alcatel Lucent | Method of efficient secure function evaluation using resettable tamper-resistant hardware tokens |
| US8627097B2 (en) | 2012-03-27 | 2014-01-07 | Igt | System and method enabling parallel processing of hash functions using authentication checkpoint hashes |
| JP5759932B2 (en) * | 2012-05-24 | 2015-08-05 | 株式会社エヌ・ティ・ティ・データ | KEY DATA GENERATION DEVICE, KEY DATA GENERATION METHOD, AND PROGRAM |
| US9906505B2 (en) * | 2015-05-08 | 2018-02-27 | Nxp B.V. | RSA decryption using multiplicative secret sharing |
| CA2944646C (en) * | 2016-10-05 | 2022-10-25 | The Toronto-Dominion Bank | Certificate authority master key tracking on distributed ledger |
| WO2022008553A1 (en) * | 2020-07-09 | 2022-01-13 | Telefonaktiebolaget Lm Ericsson (Publ) | Processing a series of bits |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5005200A (en) * | 1988-02-12 | 1991-04-02 | Fischer Addison M | Public key/signature cryptosystem with enhanced digital signature certification |
| JPH0237383A (en) * | 1988-07-27 | 1990-02-07 | Hitachi Ltd | Prime number generating system |
| US5016274A (en) | 1988-11-08 | 1991-05-14 | Silvio Micali | On-line/off-line digital signing |
| JP2956709B2 (en) * | 1990-11-26 | 1999-10-04 | 松下電器産業 株式会社 | Public key generation method and apparatus |
| JPH04191788A (en) * | 1990-11-26 | 1992-07-10 | Matsushita Electric Ind Co Ltd | Disclosure key producing method and disclosure key generating device |
| DE69113988D1 (en) * | 1991-04-29 | 1995-11-23 | Omnisec Ag Regensdorf | Encryption system based on the difference between two information. |
| US5201000A (en) * | 1991-09-27 | 1993-04-06 | International Business Machines Corporation | Method for generating public and private key pairs without using a passphrase |
| JPH05158662A (en) * | 1991-12-03 | 1993-06-25 | Hitachi Ltd | Uniform random number generating method |
| US5299262A (en) | 1992-08-13 | 1994-03-29 | The United States Of America As Represented By The United States Department Of Energy | Method for exponentiating in cryptographic systems |
| US5442707A (en) | 1992-09-28 | 1995-08-15 | Matsushita Electric Industrial Co., Ltd. | Method for generating and verifying electronic signatures and privacy communication using elliptic curves |
| JP3240723B2 (en) * | 1993-01-26 | 2001-12-25 | 松下電器産業株式会社 | Communication method, secret communication method and signature communication method |
| US5475763A (en) | 1993-07-01 | 1995-12-12 | Digital Equipment Corp., Patent Law Group | Method of deriving a per-message signature for a DSS or El Gamal encryption system |
| US5347581A (en) | 1993-09-15 | 1994-09-13 | Gemplus Developpement | Verification process for a communication system |
| FR2713419B1 (en) | 1993-12-02 | 1996-07-05 | Gemplus Card Int | Method for generating DSA signatures with low cost portable devices. |
| JP3625353B2 (en) * | 1997-04-18 | 2005-03-02 | 株式会社東芝 | External storage device, encryption unit device, decryption unit device, encryption system, decryption system, encryption method, and decryption method |
-
1998
- 1998-05-08 US US09/074,540 patent/US6195433B1/en not_active Expired - Lifetime
-
1999
- 1999-05-10 EP EP99918996A patent/EP1076952B1/en not_active Expired - Lifetime
- 1999-05-10 AU AU36952/99A patent/AU3695299A/en not_active Abandoned
- 1999-05-10 DE DE69942390T patent/DE69942390D1/en not_active Expired - Lifetime
- 1999-05-10 CA CA002330749A patent/CA2330749C/en not_active Expired - Lifetime
- 1999-05-10 JP JP2000548991A patent/JP4731686B2/en not_active Expired - Lifetime
- 1999-05-10 WO PCT/CA1999/000381 patent/WO1999059286A1/en active Application Filing
Also Published As
| Publication number | Publication date |
|---|---|
| CA2330749A1 (en) | 1999-11-18 |
| US6195433B1 (en) | 2001-02-27 |
| AU3695299A (en) | 1999-11-29 |
| EP1076952A1 (en) | 2001-02-21 |
| DE69942390D1 (en) | 2010-07-01 |
| EP1076952B1 (en) | 2010-05-19 |
| JP2002515613A (en) | 2002-05-28 |
| WO1999059286A1 (en) | 1999-11-18 |
| JP4731686B2 (en) | 2011-07-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2330749C (en) | Private key validity and validation | |
| Kohnfelder | Towards a practical public-key cryptosystem. | |
| US5933504A (en) | Strengthened public key protocol | |
| Anderson et al. | Robustness principles for public key protocols | |
| Kaliski Jr | An unknown key-share attack on the MQV key agreement protocol | |
| US7139917B2 (en) | Systems, methods and software for remote password authentication using multiple servers | |
| Mitomo et al. | Attack for flash mix | |
| Li et al. | Remark on the threshold RSA signature scheme | |
| US6345098B1 (en) | Method, system and apparatus for improved reliability in generating secret cryptographic variables | |
| Angluin et al. | Provable security of cryptosysterns: A survey | |
| Peng et al. | Batch zero-knowledge proof and verification and its applications | |
| Huang et al. | Convertible nominative signatures | |
| Krawczyk et al. | Chameleon hashing and signatures | |
| Klíma et al. | Further results and considerations on side channel attacks on RSA | |
| Peng | A general and efficient countermeasure to relation attacks in mix-based e-voting | |
| Golle | Reputable mix networks | |
| CA2290952A1 (en) | Auto-recoverable auto-certifiable cryptosystems | |
| US7519178B1 (en) | Method, system and apparatus for ensuring a uniform distribution in key generation | |
| Eaton et al. | Security analysis of signature schemes with key blinding | |
| Kalamsyah et al. | Digital contract using block chaining and elliptic curve based digital signature | |
| Błaśkiewicz et al. | Two-Head Dragon Protocol: Preventing Cloning of Signature Keys: Work in Progress | |
| Longo | Formal Proofs of Security for Privacy-Preserving Blockchains and other Cryptographic Protocols | |
| KR100349418B1 (en) | Method for preventing abuse in blind signatures | |
| Kiktenko et al. | Proof-of-forgery for hash-based signatures | |
| Yeun | Design, analysis and applications of cryptographic techniques |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKEX | Expiry |
Effective date: 20190510 |