The present invention relates to a method and apparatus for providing short-term private keys in public-key cryptographic systems.
Public-key cryptographic systems are well known and involve the use of a public/private key-pair associated with a particular party. More particularly, assuming that the public/private key-pair is associated with a first party, Alice, and that Alice holds the private key and keeps it secret, a second party, Bob, can use the public key both to send a message in confidence to Alice, and to verify a digital signature applied by Alice to a message using her private key. Such a system relies on Bob trusting the association between the public key and Alice and this is often achieved by the use of a digital certificate issued and signed by a certification authority using their own public key. Of course, for Bob to trust the certificate, Bob must trust the association of the public key used to sign the certificate with the certification authority; this association may therefore itself be subject of a further certificate issued by a higher certification authority and so on up a hierarchy of certification authorities until a root authority is reached. The infrastructure established by the hierarchy of certification authorities is referred to as a public key infrastructure, often abbreviated to “PKI”. In fact, a PKI will generally also take care of key management issues such as generating and distributing new keys, and revoking out-of-date keys. Due to the overhead involved in issuing and revoking keys, it is generally impractical with a large-scale PKI for keys to be updated frequently. According, private keys must be stored securely to ensure that they can have a long operational lifetime.
Whilst appropriate key-storage security measures can be implemented by large organisations, individual users will generally only have available equipment, such as a standard personal computer, that provides only weak protection for stored data unless special measures are taken. For example, a private key stored in a personal computer without special protection measures will only be protected by the conventional file access protection mechanisms.
By way of a compromise, the storage of a cryptographic private key in a weakly protected environment may be considered acceptably secure if the key has a short operational lifetime (for example, one day or one hour). However, as indicated above, a short lifetime for the private key of a public/private key-pair is incompatible with the practicalities of public key infrastructures.
It is an object of the present invention to alleviate the foregoing difficulties.
As will become apparent hereinafter, embodiments of the present invention make use of cryptographic techniques using bilinear mappings. Accordingly, a brief description will now be given of certain such prior art techniques.
In the present specification, G 1 and G 2 denote two algebraic groups of large prime order ι in which the discrete logarithm problem is believed to be hard and for which there exists a non-degenerate computable bilinear map p, for example, a Tate pairing or Weil pairing. Note that G 1 is a [ι]-torsion subgroup of a larger algebraic group G 0 and satisfies [ι]P=0 for all PεG 1 where O is the identity element, ι is a large prime, and ι*cofactor=number of elements in G 0 . The group G 2 is a subgroup of a multiplicative group of a finite field.
For the Weil pairing: the bilinear map p is expressed as
p: G 1 ×G 1 →G 2 .
The Tate pairing can be similarly expressed though it is possible for it to be of asymmetric form:
p: G 1 ×G 0 →G 2
Generally, the elements of the groups G 0 and G 1 are points on an elliptic curve (typically, though not necessarily, a supersingular elliptic curve); however, this is not necessarily the case.
As is well known to persons skilled in the art, for cryptographic purposes, modified forms of the Weil and Tate pairings are used that ensure p(P,P)≠1 where PεG 1 ; however, for convenience, the pairings are referred to below simply by their usual names without labeling them as modified. Further background regarding Weil and Tate pairings and their cryptographic uses can be found in the following references:
For convenience, the examples given below assume the use of a symmetric bilinear map (p: G 1 ×G 1 →G 2 ) with the elements of G 1 being points on an elliptic curve of general form y 2 =x 3 +ax+b where x and y are variables and a and b are constants; however, these particularities, are not to be taken as limitations on the scope of the present invention.
As the mapping between G 1 and G 2 is bilinear, then for P, Q, RεG 1 , both:
p ( P+Q,R )= p ( P,R )* p ( Q,R )
p ( P,Q+R )= p ( P,Q )* p ( P,R )
Furthermore, exponents/multipliers can be moved around. Thus, where aP represents the scalar multiplication of P by an integer a (that is, P added to itself a times), then for integers a, b, cεZ ι :
Additionally, the following cryptographic hash functions are defined:
H 1 : {0,1)*G 1
H 2 : {0,1)*Z* ι
H 3 : G 2 →{0,1)*
The function H 1 ( ) is often referred to as the map-to-point function as it serves to convert a string input to a point on the elliptic curve being used.
A normal public/private key-pair can be defined for a trusted authority:
Additionally, an identifier based public key/private key-pair can be defined for a party with the cooperation of the trusted authority. As is well known to persons skilled in the art, in “identifier-based” cryptographic methods a public, cryptographically unconstrained, string is used in conjunction with public data of a trusted authority to carry out tasks such as data encryption or signing. The complementary tasks, such as decryption and signature verification, require the involvement of the trusted authority to carry out computation based on the public string and its own private data In message-signing applications and frequently also in message encryption applications, the string serves to “identify” a party (the sender in signing applications, the intended recipient in encryption applications); this has given rise to the use of the label “identifier-based” or “identity-based” generally for these cryptographic methods. However, at least in certain encryption applications, the string may serve a different purpose to that of identifying the intended recipient and, indeed, may be an arbitrary string having no other purpose than to form the basis of the cryptographic processes. Accordingly, the use of the term “identifier-based” herein in relation to cryptographic methods and systems is to be understood simply as implying that the methods and systems are based on the use of a cryptographically unconstrained string whether or not the string serves to identify the intended recipient. Furthermore, as used herein the term “string” is simply intended to imply an ordered series of bits whether derived from a character string, a serialized image bit map, a digitized sound signal, or any other data source.
In the present case, the identifier-based public/private key-pair defined for the party has a public key Q ID and private key S ID where Q ID , S ID εG 1 . The trusted authority's normal public/private key-pair (P,R/s) is linked with the identifier-based public/private key by
S ID =sQ ID and Q ID =H 1 ( ID )
where ID is the identifier string for the party.
Some typical uses for the above described key-pairs will now be given with reference to FIG. 1 of the accompanying drawings that depicts a trusted authority 1 with a public key (P, sP) and a private key s. A party A serves as a general third party whilst for the identifier-based cryptographic tasks (IBC) described, a party B has an IBC public key Q ID and an IBC private key S ID , this latter key being generated by private-key generation functionality of the trusted authority 1 from the identifier ID of party B. The trusted authority will generally only provide the party B with its private key after having checked that party B is entitled to the identifier ID (for example, by having verified that party B meets certain conditions specified in the identifier, such as an identity condition).
Short Signatures (see dashed box 2 ): The holder of the private key s (that is, the trusted authority 1 or anyone to whom the latter has disclosed s) can use s to sign a bit string; more particularly, where m denotes a message to be signed, the holder of s computes a signature element Sig as follows:
Sig=sH 1 ( m ).
Verification by party A involves this party checking that the following equation is satisfied:
p ( P,Sig ) =p ( R,H 1 ( m ))
This is based upon the mapping between G 1 and G 2 being bilinear exponents/multipliers, as described above. That is to say,
Further description of short signatures of this form can be found in “Short signatures from the Weil pairing”, Boneh, D., B. Lynn, and H. Shacham, in Advances in Cryptology—ASIACRYPT ' 01, LNCS 2248, pages 514-532, Springer-Verlag, 2001.
Identifier-Based Encryption (see dashed box 3 ):—Identifier based encryption allows the holder of the private key S ID of an identifier based key-pair (in this case, party B) to decrypt a message sent to them encrypted (by party A) using B's public key Q ID .
More particularly, party A, in order to encrypt a message m, first computes:
U=rP
where r is a random element of Z* ι . Next, party A computes:
V=m⊕H 3 ( p ( R,rQ ID ))
Party A now has the ciphertext elements U and V which it sends to party B.
Decryption of the message by party B is performed by computing:
The foregoing example encryption scheme is the “Basicldent” scheme described in the above-referenced paper by D. Boneh and M. Franklin. As noted in that paper, this basic scheme is not secure against a chosen ciphertext attack (the scheme only being described to facilitate an understanding of the principles involved—a fully secure scheme is described later on in the paper and the reader should refer to the paper for details).
Identifier-Based Signatures (see dashed box 4 ):—Identifier based signatures using pairings can be implemented. For example:
Party B first computes:
g=p ( P,S ID ) r
where r is a random element of Z* ι .
Party B then applies the hash function H 2 to m∥g (concatenation of m and g, with g having been first converted to string form) to obtain:
h=H 2 ( m∥g )
Thereafter party B computes
W =( r−h ) S ID
thus generating the output Wand h as the signature on the message m.
Verification of the signature by party A can be established by computing:
g′=P ( P,W )* p ( R,Q ID ) h
where the signature can only be accepted if h=H 2 (m∥g).
According to one aspect of the present invention, there is provided a method of providing a short-term private key for use by a computing entity in effecting cryptographic operations during an operational period, said entity having an associated static public/private key-pair formed by a static private key comprising a secret stored in higher-security storage and a static public key comprising both a first element and that element combined with said secret; the method comprising:
It will be appreciated that the association of the static public/private key-pair with the computing entity may be indirect, the key-pair being principally associated (for example, by a digital certificate issued by a certification authority) with a particular party that has elected to use the computing entity.
Preferably, the higher-security storage is provided by a memory card or a smartcard, the lower-security storage being, for example, part of a standard file system of the computing entity. Because the short-term private key is only used and stored in lower-security storage for a limited period, the overall security risk is bounded and is balanced against the greater availability of the operational private key.
A second computing entity wishing to carry out a cryptographic transaction with the first-mentioned computing entity during the aforesaid operational period in which the first-mentioned computing entity is arranged to use the short-term private key for cryptographic operations, can do so by using the aforesaid second element and at least the component of the static public key formed by combining the first element and said secret. The continued involvement of this combined component ensures the continued validity of any assurance provided (for example, through a public key certificate) to the second computing entity about the association of the static public key with the first-mentioned computing entity or with a party using that entity. With regard to the second element, this latter can either be independently generated by the second computing entity or fetched from the first-mentioned computing entity.
According to another aspect of the present invention, there is provided a method of providing a short-term private key for use by computing apparatus during an operational period, said apparatus having an associated static public/private key-pair formed by a static private key comprising a secret stored in higher-security storage and a static public key comprising both a first element of a first algebraic group and the product of this element with said secret; the method comprising:
According to a further aspect of the present invention, there is provided a cryptographic method wherein a second party generates a short-term public key element and uses it during an operational period in effecting cryptographic operations pertaining to a first party that has an associated static public/private key-pair formed by a static private key comprising a secret, and a static public key comprising both a first element and that element combined with said secret; the method comprising the second party:
According to a still further aspect of the present invention, there is provided a cryptographic system comprising:
Each of the first and second entities can be a person or organisational entity acting through a computing agent, or a computing entity itself.
According to a yet further aspect of the present invention, there is provided a certificate authority of a public key infrastructure, the certificate authority being arranged to provide certificates each certifying an association between an identified entity and the public key of a static public/private key-pair the private key of which is held by the identified entity, at least one certificate also including a formula by which the corresponding public key is to be migrated to form short-term public keys each for use during a corresponding limited operational period in carrying out cryptographic operations pertaining to the identified entity concerned.
Embodiments of the invention will now be described, by way of non-limiting example, with reference to the accompanying diagrammatic drawings, in which:
FIG. 1 is a diagram showing prior art cryptographic processes based on elliptic curve cryptography; and
FIG. 2 is a diagram illustrating an embodiment of the invention.
FIG. 2 illustrates an arrangement in which a first party A (‘Alice’) with smartcard 20 has use of a first computing entity 11 , and a second party B (‘Bob’) has use of a second computing entity 12 ; by way of example, both computing entities are desktop computers or portable computers. The computing entity 11 comprises a conventional file system 15 for managing data and programs held on a mass storage device, a processing unit 16 , a network interface 41 , and a smartcard interface 17 with which the smartcard 20 can be detachably engaged for the exchange of data with the computing entity 11 . The computing entity 12 comprises a conventional file system 18 , a processing unit 19 , and a network interface 42 . The computing entities 11 and 12 inter-communicate, for example, via the internet or other computer network 40 though it is also possible that the entities actually reside on the same computing platform or that communication between entities is effected by the physical transfer of a data storage medium.
A long-term or “static” public/private key-pair is associated with Alice. The static private key s A of this key-pair is stored in Alice's smartcard 20 (a relatively high-security environment) whilst the static public key of the key-pair is stored in the file system 15 of Alice's computer 11 (that is, the static public key is stored on the mass storage device of the computer, a relatively low-security environment from where it is accessible under the same limited access control restrictions as the normal files of the computer).
Alice's static public key comprises a first component P constituted by a first point on a predetermined elliptic curve, and a second component R constituted by the scalar product of the point P with the secret s A , this second component R(=s A P) also being a point on the predetermined elliptic curve. As is well known in the field of elliptic curve cryptography, because the discrete logarithm problem is hard, a third party given P and s A P cannot discover s A from s A P.
Alice's static public key (P, R) is, for example, initially generated using the smartcard 20 with its installed secret s A . Alternatively, both Alice's static private key s A and static public key (P, R) can be created by a trusted third party and then installed respectively in the smartcard 20 and computing entity 11 . However Alice's static public/private key-pair is created, a certification authority 14 of a public key infrastructure 13 is arranged to issue a certificate CertA (for example, an X.500 certificate) that vouches for the association of the static public key (P,R) with Alice after having checked this association. Conveniently, the certification authority 14 itself generates Alice's static key-pair and issues the key-pair in a secure way to Alice along with a copy of the certificate CertA.
Alice's computer 11 also holds in its file system 15 the current version of a short-term private key S t and, optionally, a corresponding short-term public key element P t . These short-key public and private key elements are used by the computer 11 to carry out cryptographic operations during a short operational period, for example, one calendar day or one hour, before being superseded; holding the current versions of the short-term public and private key elements in the file system 15 has the advantage that they are readily accessible to the processing unit 16 . Key management functionality of the computer 11 ensures that each version of the short-term private key is only held in the relatively insecure file system 15 of the computer 11 for a limited period that encompasses the operational period to which it applies; thereafter, that version of the short-term private key is either destroyed or removed to a more secure storage. By only using any one version of the short-term public and private key elements for a limited operational period, and by only keeping that version of the short-term private key in the low security file system for a limited period, the overall security risk of holding an operational private key in the low security file system is minimised. How the short-term keys are created and used will be described hereinafter.
Bob's computer 12 also stores Alice's static public key (P,R) in its file system 18 along with the certificate CertA, these data having been obtained either from Alice's computer 11 or from another source such as the certification authority 14 . In standard manner, Bob can choose to rely on the certificate CertA as verifying the association of the static public key (P,R) with Alice but should only do so after verifying that the certificate CertA has indeed been signed by the certification authority 14 (which may require reference to other, higher-level, certification authorities of the PKI 13 ).
The file system 18 of Bob's computer may also hold Alice's current short-term public key element P t , Bob's computer 11 having either fetched this key element from Alice's computer 11 or independently created it. Although Bob's computer 12 can be arranged to fetch or create Alice's current short-term public key element as and when required without referring to the file system 18 , it will generally be more efficient to hold the short-term public key element P t , once obtained, in the file system 18 since even though the operational period of the key element P t is only short term, multiple usages of the key element P t during the period are still likely following a first usage.
Before describing the creation and usage of the short-term key elements P t and S t , a description will be given of Alice's smartcard 20 . As used herein, the term “smartcard” is intended to include any small-sized device (such as a credit-card sized object) incorporating memory and processing functionality, usually on a single chip, that is externally accessible by any suitable interface whether using physical contacts or non-contact means. Preferably, at least the memory will be tamper resistant/tamper proof.
The smartcard 20 comprises an input/output interface functional block 21 and a cryptographic functional block 24 (shown in dashed outline).
The interface block 21 comprises a data input channel 30 , a data output channel 31 , and an access security entity 22 . The interface block 21 is adapted to permit the smartcard to be coupled with the smartcard interface 17 provided on the computer 11 . The access security entity 22 is, for example, implemented to require the input of a PIN code before allowing use of the smartcard, this code being input by a user (in this case, Alice) via apparatus with which the smartcard is operatively coupled.
The input channel 30 is arranged to receive a cryptographically unconstrained input string (generically, string str) whilst the output channel 31 is arranged to output an element P″. The form in which the element P″ is output can be set by entity 29 of interface block 11 to be, for example, of string form.
The cryptographic block 24 of smartcard 20 comprises the following functional entities:
Preferably, the elements P″ and P″ are points on the same elliptic curve of general form y 2 =x 3 +ax+b where x and y are variables and a and b are constants. The various hash functions already described above with reference to the FIG. 1 examples will be used for the examples given below; in particular, the map-to-point function implemented by entity 27 is the hash function H 1 ( ).
Various usages of a smartcard of the above-described form are set out in our co-pending published US patent application No. 2005/0102523 (published may 12 , 2005 ).
By its very nature, the smartcard 20 provides a more secure storage environment for Alice's static private key s A than the file system 15 of the computer 11 . Features that contribute to this greater security include:
Any one or more of these features results in the smartcard 20 being more secure for storage of the secret s A than the file system 15 of the computer 11 . It will also be noted that because the smartcard 20 includes the required functionality for effecting point multiplication, the secret s A does not need to be copied into the computer 11 at any stage.
Consideration will now be given as to how Alice's short-term key elements are generated and used.
In order to generate a short-term private key S t for an operational period such as the current day, Alice inserts her smartcard 20 into the interface 17 of the computer 11 and activates a key generation program 50 for execution by the processing unit 16 . Key generation then proceeds as follows:
The program 50 is also arranged to set the operational period over which the current short-term key elements are to be used by the computer 11 for cryptographic operations. Thus, the program 50 provides a user interface for enabling the Alice to specify the operational period (or defaults to a suitably short period); the program 50 is also responsible for automatically removing at least the short-term private key S t from the file system 15 at the end of the associated operational period (the program 50 thus provides the above-mentioned key management functionality).
It will be appreciated that generally (though not necessarily) there will be multiple successive operational periods during which the computer 11 is to carry out cryptographic operations using short-term keys based on the same static public/private key-pair. It will be further appreciated that the short-term keys for different operational periods should differ from each other; in this respect, it may be noted that where there is only one operational period per calendar day, then the foregoing formula for the string (str) t ensures that the string, and thus the short-term private key S t , will be unique for each operational period. Bob's computer 12 is arranged to run a program 55 to generate Alice's short-term public key element P t for the current operational period of Alice's computer 11 either for storage in the file system 18 and subsequent use as and when required, or simply as and when required. This, of course, requires Bob's computer 12 to know the formulaic basis and data upon which Alice's computer creates the string (str) t and this information is preferably obtained in advance or is predictable (for example, in the present case the formula for generating (str) t could be included in the certificate certA or obtained from the computer 11 , whilst the component P x will already be available as part of Alice's static public key and the date component will be known). Bob's computer 12 preferably also knows the extent of the operational period for which the short-term public key element is valid, this information being obtained in the same way as that required for constructing the string (str) t .
As will become apparent hereinafter, in order for Bob's computer to carry out cryptographic operations during an operational period that complement operations executed or to be executed by Alice's computer using the short-term private key S t for the period concerned, Bob's computer must utilise Alice's static public key (P, R) as well as the short-term public key element P t determined for the period concerned. It is therefore convenient to consider the short-term public key for an operational period to be made up not only of the element P t but also of the elements P and R from Alice's static public key; in other words, the short-term public key comprises (P, R, P t ).
Two example cryptographic processes will now be described that make use of Alice's current short-term private key S t and short-term public key (P,R, P t ). Each process comprises a cryptographic operation carried out by one of Alice's and Bob's computers 11 , 12 and a subsequent complimentary cryptographic operation carried out by the other of Alice's and Bob's computers 11 , 12 . These cryptographic operations are typically carried out by corresponding programs running on the processors of the computers 11 , 12 but can alternatively be implemented by dedicated hardware of the computers 11 , 12 ; in either case, the computers 11 , 12 are effectively provided with cryptographic units for carrying out cryptographic operations.
Encryption/Decryption
This encryption/decryption process is similar to that described above with reference to dashed box 3 of FIG. 1. Suppose that Bob wishes to send confidential subject data (message m) to Alice. To do this, Bob initiates the running of an encryption program 56 by the processing unit 19 of computer 12 , this program being supplied with the message m as input and having access to and Alice's short-term public key (P, R, P t ) in a manner already described above. Under the control of program 56 , Bob's computer 12 :
Bob can trust that only Alice (that is, only a computing entity associated with Alice, such as computer 11 ) can decrypt the encrypted message V because the message has been encrypted using the element R (=s A P) of Alice's public key and requires a knowledge of the secret s A to decrypt it.
To decrypt the encrypted message V, Alice's computer 11 initiates the running of a decryption program 51 by the processing unit 16 of computer 11 , this program being supplied with the encrypted message V and the element U as input and having access to Alice's current short-term private key S t in file system 15 . Under the control of program 56 , Alices' computer 11 :
Since the decryption process does not involve Alice's static private key s A by itself but only as combined with P t in the short-term private key S t , decryption does not require the presence of the smartcard in the interface 17 ; thus, decryption can be carried out without Alice being present (which would not be the case if direct use of the secret s A was required as Alice will generally take the smartcard 20 with her when leaving the computer 11 ).
Signature/Verification
This signature/verification process is similar to that described above with reference to dashed box 4 of FIG. 1. Alice can sign subject data (again, taken to be a message m) such that Bob can verify that the signed message originated from Alice. To do this, Alice initiates the running of a signature program 52 by the processing unit 16 of computer 11 , this program being supplied with the message m as input and having access to Alice's current short-term private key S t and Alice's static public key (P,R) in file system 15 . Under the control of program 52 , Alice's computer 11 :
Again, since the signature process does not involve Alice's static private key s A by itself but only as combined with P t in the short-term private key S t , signing does not require the presence of the smartcard in the interface 17 ; thus, signing can be carried out without Alice being present.
To verify that the received form m′ of the message is an uncorrupted message sent by Alice, Bob initiates the running of a verification program 57 by the processing unit 19 of computer 12 , this program being supplied with the received message m′ and the received signature components W′ and h′ as input and having access to Alice's short-term public key (P, R, P t ) in a manner already described above. Under the control of program 57 , Bob's computer 12 :
Bob can trust that the verification check will only be passed if Alice signed the message because only Alice (that is, only a computing entity associated with Alice, such as computer 11 ) has access to the secret s A and use of this secret during the signing process is necessary for the verification check to be passed as this check involves the element R (=s A P).
Variants
Many variants are possible to the above-described embodiment of the invention and some of these variants will now be described.
With respect to how the string (str) t is formed for the or each operational period, there are three main considerations:
Thus, whilst the previously given formula for (str) t involving the x coordinate of the point P and the current date, is a preferred formulation for the string, neither of these components is in itself essential. As with the given formula for the string (str) t , the string can be composed of multiple components, though it is also possible to use a single component.
With regard to the duration of the or each operational period, this can be set by specific times or by a specific duration; alternatively, the beginning and/or end of an operation period can be triggered by a non-time-related event.
It is to be noted that the short-term private key associated with a given operational period can be held in the low-security storage represented by the file system 15 of computer 11 for a limited period that is greater than the operational period itself; this is because, the degree of security required may allow for such longer retention. Thus, it may be convenient to allow for a short-term private key to be created and stored in the file system 15 in advance of the operational period to which it applies so that where Alice knows in advance that she will not be present (and thus her smartcard will not be available) at the time of the next operational period, Alice can cause the short-term private key for that period to be generated in advance and stored ready for the commencement of the operational period.
It will be appreciated that whilst in the described embodiment Alice's static private key s A has been stored in a smartcard, other relatively secure storage environments can be used to store the static private key. Other suitable secure storage environments include a memory stick (such as a USB memory stick) or other removable memory device, and encrypted storage in the computer 11 with decrypted access requiring the presence of Alice (as tested, for example, biometrically or in some other manner).
The short-term private key S t need not be stored in the file system of a computer and can be held in any suitable storage providing an acceptable degree to security. It will be appreciated that the required level of security of the storage used for the short-term private key S t is less than that required for the storage used for the static private key s A .
It should also be noted that other reasons may exist for using migrating short-term keys besides that of wishing to use the more-accessible but less secure file system of Alice's computer for private-key storage. For example, Alice may wish to delegate her work to subordinates by giving each a short-term private key for a respective period for which they are responsible; each subordinate may store the short-term private key in storage of equal security to that used by Alice for her static private key. In such a situation, key migration still provides advantages even though the short-term private keys may not be any more accessible, or any more insecure, than the static private key.