GB2421407A - Generating a shared symmetric key using identifier based cryptography - Google Patents

Generating a shared symmetric key using identifier based cryptography Download PDF

Info

Publication number
GB2421407A
GB2421407A GB0427795A GB0427795A GB2421407A GB 2421407 A GB2421407 A GB 2421407A GB 0427795 A GB0427795 A GB 0427795A GB 0427795 A GB0427795 A GB 0427795A GB 2421407 A GB2421407 A GB 2421407A
Authority
GB
United Kingdom
Prior art keywords
party
key
trusted entity
signature
identifier string
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.)
Withdrawn
Application number
GB0427795A
Other versions
GB0427795D0 (en
Inventor
Keith Alexander Harrison
Liqun Chen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Development Co LP
Original Assignee
Hewlett Packard Development Co LP
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Development Co LP filed Critical Hewlett Packard Development Co LP
Priority to GB0427795A priority Critical patent/GB2421407A/en
Publication of GB0427795D0 publication Critical patent/GB0427795D0/en
Priority claimed from US11/305,869 external-priority patent/US20060215837A1/en
Publication of GB2421407A publication Critical patent/GB2421407A/en
Application status is Withdrawn legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communication including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communication including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3252Cryptographic mechanisms or cryptographic arrangements for secret or secure communication including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using DSA or related signature schemes, e.g. elliptic based signatures, ElGamal or Schnorr schemes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0847Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving identity based encryption [IBE] schemes

Abstract

A first party (A) wishing to share an inter-party cryptographic key (k) with a second party (B), outputs an identifier string (IDB) comprising a condition. This identifier string is provided to a trusted entity (TA2) which checks whether the second party (B) meets the condition and generates the inter-party key (k). The trusted entity (TA2) generates the inter-party key (k) by forming a deterministic combination of at least the identifier string (IDB) and a base key <EMI ID=2.1 HE=6 WI=9 LX=613 LY=1141 TI=UI> <PC>available also to the first party (A), and applying a one-way hash function (H1) to this combination. The trusted entity (TA2) then provides the inter-party key (k) to the second party (B) meeting the condition. Preferably, the base key <EMI ID=2.2 HE=7 WI=9 LX=1703 LY=1297 TI=UI> <PC>is generated by a Diffie-Hellman key exchange between the first party (A) and the trusted entity (TA2). Authentication of the first party (A) can also be implemented with the aid of a second trusted entity (TA1).

Description

Field of the Invention Cryptographic Key Distribution The present invention relates to cryptographic key distribution; in particular, but not exclusively, the present invention relates to identifier-based authenticated cryptographic key distribution for use, for example, in email systems.

Background of the Invention The distribution of keys for symmetric-key cryptography presents a number of challenges including security of the distribution and authentication of the recipient parties. This is true whether the keys are distributed by physical or by electronic means. Electronic distribution is generally much preferable due to the very high cost and inconvenience of physical distribution. A well known technique for electronic key distribution is the Diffie-Hellman (DH) key exchange algorithm. For this algorithm, public system parameters p, q and g are defined; when parties A and B with respective secrets XA and xB wish to share a symmetric key, each sends the other the public parameter g raised to the power of its respective secret. Thus, A sends B gxA mod p, and B sends A gxB mod p. The receiving party then raises the received value to the power of its own secret so that each ends up with the value gxAxB mod p which can be used as a symmetric key. A key formed in this way is referred to herein as a Diffie-Hellman or DH key. Of course, this mechanism for 'distributing' a key does not provide any guarantee to either party regarding the identity of the other party. One way of overcoming this drawback is to store the values gxA mod p and gxB mod p in a trusted server against the authenticated identities of the parties concerned. In this case, if party A wishes to exchange a key with a specific party B, party A obtains from the trusted server the value gxB mod p stored there in respect of the party B as identified by party A; party B when contacted by party A can then similarly retrieve the stored value gxA mod p corresponding to the identity presented to B by A.However, this arrangement whilst being suitable for small organizations, is not easily scalable; furthermore, it also suffers from the disadvantages of requiring the trusted server to authenticate participants in advance and of needing to store the values, of generic form gx mod p, for each authenticated participant. An alternative, highly scalable, approach to providing party authentication is to use a public key infrastructure where each party has an associated public/private key-pair. More particularly, assuming that a party A has an associated public/private key-pair for which party A holds the private key, another party B can use A's public key both to send a message in confidence to A, and to verify a digital signature applied by A to a message using her private key. Such a system relies on party B trusting the association between the public key and A and this is achieved by the use of a digital certificate issued and signed by a certification authority using its own public key.Of course, for B to trust the certificate, B 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. Where a PKI exists and the parties A and B are participants, it is relatively easy for each to verify the identity of the other by a simple challenge / response mechanism. Once the parties A and B have authenticated each other, they can readily share a secret key to carry out symmetric-key cryptography; for example, the parties can use a DH key exchange mechanism to generate a shared key or one party can generate the key and send it to the other party encrypted under the public key of that party. As is well known, because symmetric key encryption/decryption algorithms are less processor intensive than public key encryption/decryption algorithms for the same level of security, the parties A and B would conduct the transfer of any significant amounts of data using a shared symmetric key. Of course, a major disadvantage of the foregoing approaches to party authentication is the requirement for an infrastructure with which the parties are already registered and which must hold data about each registered party. A different approach to enabling at least recipient authentication is identifier-based cryptography. 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 and 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. Because the authentication of the receiving party and the generation of the private key corresponding to the sender-chosen string, can be effected by the trusted party as and when needed, the trusted party does not need a large storage capacity and a hierarchical infrastructure is not required. It may be noted that in certain applications of identifier-based cryptography, the public cryptographically-unconstrained 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 string" herein in relation to cryptographic methods and systems is to be understood simply as implying an 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. A number of identifier-based cryptographic methods are known, including: - methods based on "Quadratic Residuosity" as described in the paper: "An identity based encryption scheme based on quadratic residues", C. Cocks, Proceedings of the 8th IMA International Conference on Cryptography and Coding, LNCS 2260, pp 360363, Springer-Verlag, 2001; - methods using Weil or Tate pairings - see, for example: D. Boneh, M. Franklin "Identity-based Encryption from the Weil Pairing" in Advances in Cryptology CRYPTO 2001, LNCS 2139, pp. 213-229, Springer-Verlag, 2001; - methods based on mediated RSA as described in the paper "Identity based encryption using mediated RSA", D. Boneh, X. Ding and G. Tsudik, 3rd Workshop on Information Security Application, Jeju Island, Korea, Aug, 2002. Generally, in identifier-based encryption/decryption methods, a trusted party carries out one or more actions (such as identity checking) in accordance with information in the sender-chosen string, before enabling a recipient to recover a message encrypted by a message sender. Usually, the trusted party will generate an identifier-based decryption key and provide it to the recipient for the latter to use in decrypting the encrypted message. However, it is also possible to provide identifier-based encryption/decryption methods in which the trusted party carries out the decryption. Using identifier-based cryptography a party A that wants to communicate securely with party B using a shared symmetric key, can simply send a symmetric key in encrypted form to party B along with the identifier string used to encrypt the symmetric key and an indicator of the trusted authority whose public data was used in the encryption process (where the identity of this trusted authority is not apparent). Party B then contacts the trusted authority, sending it the identifier string and asking for the corresponding decryption key. The trusted authority, after checking that party B meets all the conditions set out in the identifier string, generates the decryption key from the string and sends this key to party B. Finally, party B uses the decryption key to decrypt the encrypted symmetric key sent by party A. In many applications, it is not just the identity of the recipient that is required to be authenticated but also that of the message sender. One way of achieving sender authentication without the use of a public key infrastructure and in a manner compatible with identifier-based cryptography is described in our co-pending UK patent application GB 0414062.0 filed 23 June 2004. It is an object of the present invention to provide an improved key distribution method and apparatus.

Summary of the Invention According to a first aspect of the present invention, there is provided a cryptographic key distribution method, comprising a trusted entity: receiving an identifier string output by a first party, the identifier string comprising at least one condition; checking that a second party meets said at least one condition; generating an inter-party symmetric key by effecting a deterministic combination of at least the identifier string and a base key available also to the first party, and applying a one-way hash function to said combination; and providing said inter-party symmetric key to a second party for use in secure data exchange between the first and second parties; at least the provision of the inter-party symmetric key to the second party only being effected if that party meets said at least one condition. The present invention also encompasses apparatus and computer program products for implementing the foregoing method. Brief Description of the Drawings Embodiments of the invention will now be described, by way of non-limiting example, with reference to the accompanying diagrammatic drawings, in which: . Figure 1 is a diagram illustrating the operation of a first embodiment in which a trusted authority is used to authenticate an intended key recipient; . Figure 2 is a diagram illustrating the operation of a second embodiment in which a first trusted authority is used to authenticate a key sender and a second trusted authority is used to authenticate an intended key recipient, both trusted authorities having the same public system parameters; and . Figure 3 is a diagram illustrating the operation of a third embodiment, this embodiment being similar to that of Figure 2 but with the two trusted authorities having different public system parameters. Best Mode of Carrying Out the Invention The cryptographic methods and apparatus described below with respect to Figures 1 to 3 involve three or four parties, namely a message sender A acting through computing entity 30, a message receiver B acting through computing entity 40, a first trusted authority TA1 acting through computing entity 50 (not present in the first embodiment), and a second trusted authority TA2 acting through computing entity 60. The computing entities 30, 40, 50 and 60 are typically based around program-controlled processors though some or all of the cryptographic functions may be implemented in dedicated hardware. The entities 30, 40, 50 and 60 inter-communicate, for example, via the internet or other computer network though it is also possible that two, three or all four entities actually reside on the same computing platform.It would alternatively be possible for some or all of the communication between the entities 30, 40, 50 and 60 to effected by the physical transport of data storage media. For convenience, the following description is given in terms of the parties A, B, TA1 and TA2, it being understood that these parties act through their respective computing entities. In all the embodiments described below, when the party A wishes to communicate securely with party B, it generates an inter-party symmetric key k using elements including an identifier string IDB for party B and a key element associated with the trusted authority TA2; in the illustrated embodiments, this key element is a public key of TA2 but it could alternatively be a secret shared by TA2 and party A. The trusted authority TA2 also generates the inter-party symmetric key k and provides it to party B after satisfying itself that party B is compliant with the identifier string IDB. The generation of the inter-party key k by TA2 requires the use of a secret key known to TA2 (but possibly shared with party A), thereby providing assurance to party A that only a party satisfying TA2 as to its compliance with IDB can obtain the key k.The overall process is thus an identifier-base( key distribution process. In the embodiments described with respect to Figures 2 and 3, the identity of the party A i: authenticated by a trusted authority TA1 and proof of this authentication is provided t( TA2; this enables party B to know or control with whom it communicates. Both these embodiments use Schnorr-type signatures which are known per se and are described, fo example, in the paper: "Efficient signature generation by smart cards" C. Schnorr. Journal of Cryptology, 4(3):161-174, 1991. Figure 1 Embodiment In this embodiment there is no sender authentication so TA1 is not needed and the trustee authority TA2 is only required to check that party B is compliant with the identifier string IDB before generating the inter-party key k and providing it to party B. The operations carried out in this embodiment by A, B, and TA2 are described below witl reference to Figure 1, these operations being numbered 1 to 14. Initial Set Up Phase 1. System public parameters p, q, g established by TA2 or another entity; typically: q is a random prime (for example of 160 bits) p is a random prime (for example of 1024) such that q p-1 g is a random integer such that gq = 1 mod p 2. TA2 chooses a random secret X2 (private key) such that 1 < X2 < q 3. TA2 computes y2 = gX2 mod p (public key) 4. TA2 publishes y2 and keeps X2 secret Key Generation and Distribution Phase When A wants to share an inter-party symmetric key k with B 5. A chooses IDB as B's identifier string 6. A chooses secret r at random in the range: 0 < r < q 7. A computes: <img class="EMIRef" id="022922596-00010000" />

8. A computes: <img class="EMIRef" id="022922596-00020000" />

where H1 is a one-way hash function and stores k as the inter-party symmetric key 9. A sends (z, IDB) to B 10. B forwards (z, IDB) to TA2 11. TA2 checks B is compliant with IDB - if this check fails, processing terminates. 12. TA2 computes: <img class="EMIRef" id="022922596-00030000" />

13. TA2 sends k, as the inter-party symmetric key, to B in secret 14. A & B use the inter-party symmetric key k for the secure transfer of data (in one or both directions) In effect, in the foregoing process A and TA2 perform a Diffie-Hellman (DH) key exchange with A's secret being r and TA2's secret being X2; the result of this exchange is <img class="EMIRef" id="022922596-00040000" />

p, and by TA2 as: zx2 mod p). Both A and TA2 then form the inter-party symmetric key k as a hashed concatenation of this DH key and the identifier string IDB. Placing the DH key grx2 mod p inside the hash guarantees to A that TA2 must be involved in its generation for B; placing IDB inside the hash ensures that it is impossible for B to adapt the key to a different identity IDB''. Figure 2 Embodiment In this embodiment, TA1 authenticates the association between party A and the identity IDA and proof of this is then provided by A to TA2. The trusted authority TA2 is therefore not only required to check that party B is compliant with the identifier string IDB before generating the inter-party key k and providing it to party B, but is further required to check that the party identified by IDA has been authenticated by TA 1. The overall process is such that the only party (apart from TA2) that can compute the inter-party symmetric key k is the party identified by IDA. For this embodiment, both trusted authorities TA1 and TA2 use the same system parameters p, q and g. The operations carried out in this embodiment by A, B, TA1 and TA2 are described below with reference to Figure 2, these operations being numbered 1 to 20. Initial Set Up Phase 1. System public parameters p, q, g established by TA1 or TA2 or another entity; typically: q is a random prime (for example of 160 bits) p is a random prime (for example of 1024) such that qp-1 g is a random integer such that gq = 1 mod p 2. TA1 chooses random secret x1 (private key) such that 1 < x1 < q 3. TA1 computes y1 = gx1 mod p (public key) 4. TA1 publishes y1 and keeps x1 secret 2'. TA2 chooses random secret X2 (private key) such that 1 < X2 < q 3'. TA2 computes y2 = gX2 mod p (public key) 4'. TA2 publishes y2 and keeps X2 secret Key Generation and Distribution Phase 5. A chooses identifier IDA and sends it to TA1 6. TA1 checks A is compliant with IDA 7. TA1 computes Schnorr-type signature over IDA by: choosing secret u at random in the range 0 < u < q computing: <img class="EMIRef" id="022922596-00050000" />

where H2 is a one-way hash function computing: <img class="EMIRef" id="022922596-00060000" />

8. TA1 sends signature (h, s) to A in secret 9. A keeps s as her ID private key and computes: <img class="EMIRef" id="022922596-00070000" />

to complete her ID public key (IDA, h, yA) When A wants to share an inter-party symmetric key k with B 10. A chooses IDB as B's identifier string 11. A chooses secret r at random in range 0 < r < q 12. A computes: <img class="EMIRef" id="022922596-00080000" />

13. A computes: <img class="EMIRef" id="022922596-00090000" />

where H1 is a one-way hash function and stores k as the inter-party symmetric key 14. A sends (z, IDB) and (IDA, h, yA) to B 15. B forwards (z, IDB) and (IDA, h, yA) to TA2 16. TA2 checks B is compliant with IDB - if this check fails, processing terminates. 17. TA2 checks: <img class="EMIRef" id="022922596-00100000" />

As explained more fully below, if this check is passed, TA2 knows that only a party verified by TA1 as entitled to be associated with IDA (as received by TA2) will be able to generate a correct value for the inter-party key k, this being a value which is the same as that which TA2 will compute in operation 18 below. If the check fails, processing terminates. 18. TA2 computes: <img class="EMIRef" id="022922596-00110000" />

19. TA2 sends k, as the inter-party symmetric key, to B in secret 20. A & B use the inter-party symmetric key k for the secure transfer of data It will be appreciated that H1 and H2 can be the same one-way hash function. In the foregoing process the signing of IDA by TA1 using a Schnorr signature and the retention of the signature component s by A whilst passing on the derivative element gs mod p, enables TA2 to assume that the party associated with the identity IDA holds the component element s. Because the inter-party key k is of such a form that only TA2 or the party possessing the secret s can construct the key correctly, TA2 knows that the key k it forms will only be useful for communicating with a party verified by TA1 as identified by IDA. It should be noted that (h, s) is a valid Schnorr signature on IDA, but (h, yA) is not because anyone can falsify it without knowing x1 by randomly choosing u, and computing: <img class="EMIRef" id="022922596-00120000" />

However, (h, yA) becomes a valid Schnorr signature on IDA for the case where the discrete logarithm s of yA based on g modulo p is known to the party identified by IDA since it is an acceptable assumption that solving the discrete logarithm problem in a finite field is computationally infeasible. For the present embodiment, the computation of gsx2 mod p required for computing the key k needs knowledge of either s or x2 (for the same reason that solving the discrete logarithm problem in a finite field is computationally infeasible). Because X2 is known only to TA2, TA2 believes that gsx2 mod p can only be computed by itself or someone knowing s.Therefore if the check operation 17 is passed, TA2 knows that either (h, yA) is a valid Schnorr signature and the party A identified by IDA will be able to generate the same value of the key k as TA2, or that the signature is invalid and the identified party will be unable to generate a value of the key matching that generated by TA2. to establish to the satisfaction of the first-mentioned trusted entity that only a party verified by the further trusted entity as entitled to be associated with the first-party identifier string received by the first-mentioned trusted entity, will be able to generate a correct value for the inter-party key Regarding the construction of the key k, in the foregoing process A and TA2 effectively perform two Diffie-Hellman (DH) key exchanges. In the first of these exchanges, A's secret is r and TA2's secret is X2; the result of this exchange is that A and TA2 share a DH <img class="EMIRef" id="022922596-00130000" />

p). In the second DH key exchange, A's secret is s and TA2's secret is X2; the result of this exchange is that A and TA2 share a DH key gsx2 mod p (this key having been formed by A as: y2s mod p, and by TA2 as: yAx2 mod p).Both A and TA2 then form the inter-party symmetric key k as a hashed concatenation of the two DH keys and the identifier string IDB. Placing the DH key gsx2 mod p inside the hash both guarantees to A that TA2 must be involved in generating the key for B, and as already discussed, guarantees for TA2 that only the party identified by IDA can generate the key (apart from TA2); placing IDB inside the hash ensures that it is impossible for B to adapt the key to a different identity IDB'. Placing the DH key grx2 mod p in the hash, as well as being a repeat guarantee to A of the involvement of TA2, also serves to ensure freshness (assuming that r is newly generated at random each time A wants to communicate with B). The DH key grx2 mod p can be omitted from the hashed concatenation of terms used to derive k but in this case freshness of the key for each use with party B will (if required) need to be provided for in some other manner such as by the inclusion of a nonce in IDB. Omitting the term grx2 mod p also means that TA1 can construct the key k (assuming it knows IDB). Figure 3 Embodiment This embodiment is similar to the Figure 2 embodiment in that TA1 authenticates the association between the party A and its identity IDA, and proof of this is provided by A to TA2. However, in this embodiment, the two trusted authorities TA1 and TA2 use different <img class="EMIRef" id="022922596-00140000" />

The operations carried out in this embodiment by A, B, TA1 and TA2 are described below with reference to Figure 3, these operations being numbered 1 to 22. Initial Set Up Phase 1. System public parameters p1, q1, g1 established by TA1 or another entity; typically: q, is a random prime (for example of 160 bits) <img class="EMIRef" id="022922596-00150000" />

g1 is a random integer such that g1q1 = 1 mod p1 2. TA1 chooses random secret xi (TA1's private key) such that 1 < x1 < q, 3. TA1 computes: y, = g1x1 mod p1 (TA1 's public key) 4. TA1 publishes y1 and keeps x1 secret 1'. System public parameters p2, q2, g2 established by TA2 or another entity; typically: q2 is a random prime (for example of 160 bits) P2 is a random prime (for example of 1024) such that q2p2-1 gi is a random integer such that g2q2 = 1 mod P2 2'. TA2 chooses random secret X2 (TA2's private key) such that 1 < X2 < q2 3'. TA2 computes: y2 = g2x2 mod P2 (TA2's public key) 4'. TA2 publishes y2 and keeps X2 secret Key Generation and Distribution Phase 5. A chooses identifier IDA and sends it to TA1 6. TA1 checks A is compliant with IDA 7. TA1 computes Schnorr-type signature over IDA by: choosing secret u at random in the range 0 < u < q computing: <img class="EMIRef" id="022922596-00160000" />

where H2 is a one-way hash function computing: <img class="EMIRef" id="022922596-00170000" />

8. TA1 sends signature (h, s) to A in secret 9. A keeps s as her ID private key and computes: <img class="EMIRef" id="022922596-00180000" />

to complete her ID public key (IDA, h, y1A) When A wants to share an inter-party symmetric key k with B 10. A chooses IDB as B's identifier string 11. A chooses secret r at random in the range: 0 < r < min (q1, q2) 12. A computes: <img class="EMIRef" id="022922596-00190000" />

13. A computes: <img class="EMIRef" id="022922596-00200000" />

where H1 is a one-way hash function and stores k as the inter-party symmetric key 14. A computes: <img class="EMIRef" id="022922596-00210000" />

where H3 is a one-way hash function t = r - s * j mod max(q 1, q2) or without mod 15. A sends (j, t, y2A, IDB) and (IDA, h, y1A) to B <img class="EMIRef" id="022922596-00220000" />

17. TA2 checks B is compliant with IDB - if this check fails, processing terminates. 18. TA2 checks: <img class="EMIRef" id="022922596-00230000" />

If this check is passed, TA2 knows, subject to the check of operation 20, that only a party verified by TA1 as entitled to be associated with IDA (as received by TA2) can compute a correct value for the inter-party key k, this being a value which is the same as that which TA2 will compute in operation 19 below. If the check fails, processing terminates. 19. TA2 computes: <img class="EMIRef" id="022922596-00240000" />

20. TA2 checks: <img class="EMIRef" id="022922596-00250000" />

21. TA2 sends k, the inter-party symmetric key, to B in secret 22. A and B use the inter-party symmetric key k for secure transfer of data It will be appreciated that H1, H2 and H3 can be the same one-way hash function. As for the Figure 2 embodiment, the check operation 18 tells TA2 that (h, y1A) is a valid signature on IDA in the case where the party identified by IDA knows the discrete logarithm s of y1A on the base g1 modulo p1. However, because computation of k by TA2 necessarily involves y2A (based on g2) rather than the y1A value (based on g1) used in the signature verification process, TA2 can no longer assume that the resultant value of k will only be useful where the signature values have not been falsified. For avoiding this ambiguity, A demonstrates to TA2 that the discrete logarithm of y1A on the base g1 modulo p, is equal to the discrete logarithm of y2A on the base g2 modulo p2. To do this, A makes use of a double Schnorr signature (j, t) on the value k under "public key" y1A and y2A, which is computed as follows: <img class="EMIRef" id="022922596-00260000" />

<img class="EMIRef" id="022922596-00270000" />

holds. After this check succeeds, TA2 is convinced that (h, y1A) is a valid Schnorr signature on IDA signed by TA1. Note that this property does not hold in the Figure 2 embodiment. Again as for the Figure 2 embodiment, creation of the inter-party symmetric key k requires computation of g2sx2 mod p2, which calls for knowledge of either s or x2 since solving the discrete logarithm problem in a finite field is computationally infeasible. Because X2 is known only to TA2, TA2 believes that g2sx2 mod p2 can only be computed by itself or someone knowing s, and that the value s is also the discrete logarithm of y1A on the base g1 modulo p1. TA2 is therefore convinced that it shares the value k with the right entity A. Regarding the construction of the key k, in the foregoing process A and TA2 effectively perform a DH key exchange involving A's secret s and TA2's secret x2; the result of this exchange is that A and TA2 share a DH key g2sx2 mod p2 (this key having been formed by <img class="EMIRef" id="022922596-00280000" />

party symmetric key k as a hashed concatenation of the DH key and the identifier string IDB. Placing the DH key g2sx2 mod p2 inside the hash both guarantees to A that TA2 must be involved in generating the key for B, and as already discussed, guarantees for TA2 that only the party identified by IDA can generate the key (apart from TA2); placing IDB inside the hash ensures that it is impossible for B to adapt the key to a different identity IDB'. If freshness of the key k is required for each use with the party B then this can be achieved by the inclusion of a nonce in IDB. Alternatively, an approach similar to that used in the Figure 2 embodiment can be used, namely the DH key g2rx2 mod p2 can be included in the hashed concatenation when forming k, this key being formed by A as: y2r mod p2, and by TA2 as: z2x2 mod p2; thus, A would form k as: <img class="EMIRef" id="022922596-00290000" />

Special cases of the Figure 3 embodiment are when: <img class="EMIRef" id="022922596-00300000" />

In the latter case, it is preferable to use the Figure 2 arrangement. With regard to the computational load on party A in the Figure 3 embodiment, whilst at first sight this might appear significant, this will generally not be the case because the results of most of the computations can be re-used multiple times. Thus: - whilst y1 and IDA remain unchanged, the ID public key (IDA, h, y1A) need only be sent once to TA2; - whilst y1, g2 and IDA remain unchanged, the value y2A need not be recomputed; - whilst y1, y2 and IDA remain unchanged, (y2s mod p) need not be recomputed; - whilst IDA, IDB, y1 and y2 remain unchanged, k need not be recomputed; - z1 and z2 need only be computed once. There will therefore be many occasions when computation for party A will be very light and not involve any exponentiation. With regard to the computational load for TA2, this will depend on whether it has already accepted y1A and y2A or not. Furthermore, in practical implementations it is not necessary to make q1 and q2 publicly available though in this case, x, r and u are preferably one bit smaller than q1 and q2. Generic Variants It will be appreciated that many variants are possible to the above described embodiments of the invention. Thus, for example, in forming the inter-party key k, rather than the constituent elements simply being concatenated for hashing, these elements can be combined together using any deterministic combination function before being subject to the hash function H1. Similarly, the elements within the hashes H2 and H3 can be combined using any deterministic combination function. Of course, the combination functions used must be known to the parties concerned. Additional elements can be included in each combination. It will be appreciated that TA2 can generate the inter-party key k before, or in parallel with, carrying out its checks regarding compliance by B with the identifier string. Similarly, with respect to the embodiments of Figures 2 and 3, TA2 can generate the inter-party key k before, or in parallel with, its check regarding the identity of party A. Further with regard to the embodiments of Figures 2 and 3, it will be appreciated that TA2 can be arranged to pass the key k to party B even if the checks regarding party A are failed (party B preferably being informed of this failure). The parties A and B can use inter-party key k directly for encryption/decryption key or they can combine the key with other elements known to both parties before employing the key. All transmissions are preferably integrity protected in any suitable manner. If party A and the trusted authority TA2 already share a secret key, then it would be possible for the inter-party key to be formed by hashing a deterministic combination of this shared secret key with the identifier string IDB. In this case, it would not be necessary to perform a DH key exchange to form a shared secret key; furthermore, the identity IDA of party A whilst needing to be supplied to TA2, would not need to be authenticated since the inter-party key k generated by TA2 would only be suitable for use in communicating with a party that TA2 associated with the identity IDA. One useful application of the above-described identifier-based key distribution embodiments is in secure email applications. It may be noted that the method used in the embodiments of Figures 2 and 3 for authenticating the party A in respect use of the key k, can be used in other contexts. Thus, where both TA1 and TA2 use the same system parameters (as in the Figure 2 embodiment), the authentication method comprises: (a) TA 1 forming a Schnorr type signature on IDA and passing the signature components (s, h) to party A; (b) party A keeping s and substituting gs in the Schnorr signature before passing it to TA2 along with IDA; (c) TA2 verifying the Schnorr signature; (d) party A and TA2 effecting a DH key exchange, with TA2 using gs for the key material from party A; and (e) using the DH key for a particular operation involving A, this key only being operative if party A truly corresponds to identity IDA. In this case, the authentication is indirect in the sense that the 'particular operation' being undertaken will only work if party A truly corresponds to identity IDA; in fact, the carrying out of the 'particular operation' can be viewed as a second authentication check, which if successful, confirms that party A corresponds to identity IDA. In the Figure 3 embodiment the authentication explicitly involves a second check (operation 20) which if passed, confirms to TA2 that party A corresponds to identity IDA.In all cases, for the second check the party A is required to form an element that calls for it to know the value of s used in the term gs substituted for s in the Schnorr type signature (thus, in the Figure 2 embodiment, party A must know the correct value of s to form an operative DH key whilst in the Figure 3 embodiment, party A must know the correct value of s to form the correct Schnorr signature value t to work with the public key element y1A used in the first check operation 18). The Identifier Strings As regards the contents of the identifier string IDB chosen by the sender A for party B, as already indicated this string may be any string though in many cases restrictions will be placed on the string - for example, the string IDB may be required to comply with a particular XML schema. The string IDB will frequently comprise a condition identifying a specific person or entity for party B; in this case, the trusted authority TA2 carries out an authentication process with the party B to check that B meets the identity condition. Rather than identifying party B as a particular individual or entity, the identifier string IDB may comprise one or more conditions specifying one or more attributes that a party must possess to receive the key k; for example, a condition may specify that a party must have a certain credit rating. Again, it is the responsibility of the trusted authority TA2 to check out this condition(s) before providing the key k to the party requesting it. The so-called identifier string IDB may additionally or alternatively comprise one or more conditions unrelated to an attribute of the intended key recipient; for example, a condition may be included that the key k is not to be provided by TA2 before a particular date or time. Indeed, the string IDB can be used to convey to the trusted authority TA2 information concerning any actions to be taken by the trusted authority when it receives the key request. The information in the string IDB may thus relate to actions to be taken by the trusted authority that do not directly affect key provision - for example, the trusted authority TA2 may be required to send a message to party A at the time the TA2 provides the key to party B.However, as already indicated, the information in the string IDB will generally specify one or more conditions to be checked by the trusted authority as being satisfied before the trusted authority provides the key to the requesting party. Whatever the conditions relate to, the string IDB may directly set out the or each condition or may comprises one or more condition identifiers specifying corresponding predetermined condition known to the trusted authority TA2 (in the latter case, the trusted authority uses the or each condition identifier to look up the corresponding condition to be checked). With regard to the identifier string IDA, this will generally comprise specific identity information regarding the party A and / or an indication of one or more attributes possessed by party A. The string IDA can also include one or more indicators of actions to be carried out by TA2. Preferably both IDA and IDB contain nonces to ensure freshness.

Claims (17)

1. A cryptographic key distribution method, comprising a trusted entity: receiving a second-party identifier string output by a first party, the second-party identifier string comprising at least one condition; checking that a second party meets said at least one condition; generating an inter-party symmetric key by effecting a deterministic combination of at least the second-party identifier string and a base key available also to the first party, and applying a one-way hash function to said combination; and providing said inter-party symmetric key to a second party for use in secure data exchange between the first and second parties; at least the provision of the inter-party symmetric key to the second party only being effected if that party meets said at least one condition.
2. A method according to claim 1, wherein the trusted entity derives said base symmetric key by a Diffie-Hellman key exchange operation with the first party.
3. A method according to claim 1, further comprising the first party: choosing and subsequently outputting said identifier string; and generating said inter-party symmetric key by effecting said deterministic combination of at least the identifier string and said base symmetric key, and applying said one-way hash function to the result.
4. A method according to claim 3, wherein the first party and the trusted entity derive said base symmetric key by a Diffie-Hellman key exchange operation in which key material is exchanged between the first party and the trusted entity.
5. A method according to claim 3, further comprising a further trusted entity verifying the entitlement of the first party to be associated with a first-party identifier string and providing signature evidence of this; said signature evidence being used by the first party and the first-mentioned trusted entity to establish to the satisfaction of the first-mentioned trusted entity that only a party verified by the further trusted entity as entitled to be associated with the first-party identifier string received by the first-mentioned trusted entity, will be able to generate a correct value for the inter-party key.
6. A method according to claim 5, wherein said further trusted entity uses a first set of public system parameters in forming said signature evidence, and wherein the first party and the first-mentioned trusted entity derive said base symmetric key by a Diffie-Hellman key exchange operation using a second set of public system parameters.
7. A method according to claim 3, further comprising: a further trusted entity verifying the entitlement of the first party to be associated with a first-party identifier string, forming a Schnorr-type signature over the first-party identifier string, and outputting first and second signature components in secret to the first party; the first party raising a first public system parameter to the power of the first signature component to produce a third signature component, retaining the first signature component as a first-party ID private key, and outputting as a first-party ID public key, the first-party identifier string together with the second and third signature components; and the first-mentioned trusted entity receiving the first-party ID public key and effecting a Schnorr-type signature verification process as at least a partial check that only a party verified by the further trusted entity as entitled to be associated with the first-party identifier string received by the first-mentioned trusted entity, will be able to generate a correct value for the inter-party key.
8. A method according to claim 4, further comprising: a further trusted entity verifying the entitlement of the first party to be associated with a first-party identifier string, forming a Schnorr-type signature over the first-party identifier string, and outputting first and second signature components in secret to the first party; the first party raising a first public system parameter to the power of the first signature component to produce a third signature component, retaining the first signature component as a first-party ID private key, and outputting as a first-party ID public key, the first-party identifier string together with the second and third signature components; the first-mentioned trusted entity receiving the first-party ID public key and effecting a Schnorr-type signature verification process to confirm that only a party verified by the further trusted entity as entitled to be associated with the first-party identifier string received by the first-mentioned trusted entity, will be able to generate a correct value for the inter-party key; and the first-mentioned trusted entity using the second signature component as the key material received from the first party in the course of said Diffie-Hellman key exchange; the public system parameters used by the said further trusted entity in respect of said Schnorr-type signature being the same as those used by the first party and the firstmentioned trusted entity in respect of said Diffie-Hellman key exchange.
9. A method according to claim 8, wherein the first party and the first-mentioned trusted party effect a further Diffie-Hellman key exchange in which the key material provided by the first party is based on a random secret generated by the first party, the further DiffieHellman key exchange resulting in the generation of a further base key which is used, both by the first party and the first mentioned trusted entity, in the generation of the inter-party symmetric key by being combined with the first-mentioned base key and said second-party identifier string by said deterministic combination.
10. A method according to claim 4, further comprising: a further trusted entity verifying the entitlement of the first party to be associated with a first-party identifier string, forming a first Schnorr-type signature over the first-party identifier string, and outputting first and second signature components to the first party, the first Schnorr-type signature being effected using a first set of public system parameters; the first party raising a first parameter of said first set of public system parameters to the power of the first signature component to produce a third signature component, retaining the first signature component as a first-party ID private key, and outputting as a first-party ID public key, the first-party identifier string together with the second and third signature components; the first party forming a second Schnorr-type signature using said first signature component as a private signature key whereby to form fourth and fifth signature components, the second Schnorr-type signature being effected using at least said first set of public system parameters, and the first party outputting the fourth and fifth signature components; the first party raising a first parameter of a second set of public system parameters to the power of said first signature component to produce a first key element which it outputs, the first-mentioned trusted entity receiving the output of the first party and effecting a signature verification process on each of the first and second Schnorr-type signatures with the third signature component being used in both verification processes whereby verification of both signatures serves to confirm that only a party verified by the further trusted entity as entitled to be associated with the first-party identifier string received by the first-mentioned trusted entity, will be able to generate a correct value for the inter-party key; and the first-mentioned trusted entity using the first key element as the key material received from the first party in the course of said Diffie-Hellman key exchange, this exchange being effected using said second set of public system parameters.
11. A method according to claim 10, wherein the first party and the first-mentioned trusted party effect a further Diffie-Hellman key exchange, using said second set of public system parameters, in which the key material provided by the first party is based on a random secret generated by the first party; the further Diffie-Hellman key exchange resulting in the generation of a further base key which is used, both by the first party and the first mentioned trusted entity, in the generation of the inter-party symmetric key by being combined with the first-mentioned base key and said second-party identifier string by said deterministic combination.
12. A method according to any one of the preceding claims, wherein said at least one condition comprises a condition relating to the identity of an intended recipient of said message.
13. A method according to any one of the preceding claims, wherein said at least one condition comprises a condition concerning a non-identity attribute that an intended recipient of said message must possess.
14. A method according to any one of the preceding claims, wherein the generation of the inter-party key is only effected if the second party meets said at least one condition.
15. A method according to any one of claims 1 to 13, wherein the generation of the interparty key is effected before or in parallel with checking that the second party meets said at least one condition.
16. Apparatus for carrying the cryptographic method of any one of the preceding claims.
17. A computer program product for conditioning programmable computing apparatus for carrying out the method of any one of claims 1 to 15.
GB0427795A 2004-12-18 2004-12-18 Generating a shared symmetric key using identifier based cryptography Withdrawn GB2421407A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
GB0427795A GB2421407A (en) 2004-12-18 2004-12-18 Generating a shared symmetric key using identifier based cryptography

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
GB0427795A GB2421407A (en) 2004-12-18 2004-12-18 Generating a shared symmetric key using identifier based cryptography
GB0517700A GB2421408A (en) 2004-12-18 2005-09-01 Generating an Identifier-Based Public / Private Key Pair from a Multi-Component Signature
GB0525074A GB2421410A (en) 2004-12-18 2005-12-09 Generating and Identifier-Based Public / Private key Pair from a Multi-Component Signature
US11/305,869 US20060215837A1 (en) 2004-12-18 2005-12-16 Method and apparatus for generating an identifier-based public/private key pair

Publications (2)

Publication Number Publication Date
GB0427795D0 GB0427795D0 (en) 2005-01-19
GB2421407A true GB2421407A (en) 2006-06-21

Family

ID=34090324

Family Applications (3)

Application Number Title Priority Date Filing Date
GB0427795A Withdrawn GB2421407A (en) 2004-12-18 2004-12-18 Generating a shared symmetric key using identifier based cryptography
GB0517700A Withdrawn GB2421408A (en) 2004-12-18 2005-09-01 Generating an Identifier-Based Public / Private Key Pair from a Multi-Component Signature
GB0525074A Withdrawn GB2421410A (en) 2004-12-18 2005-12-09 Generating and Identifier-Based Public / Private key Pair from a Multi-Component Signature

Family Applications After (2)

Application Number Title Priority Date Filing Date
GB0517700A Withdrawn GB2421408A (en) 2004-12-18 2005-09-01 Generating an Identifier-Based Public / Private Key Pair from a Multi-Component Signature
GB0525074A Withdrawn GB2421410A (en) 2004-12-18 2005-12-09 Generating and Identifier-Based Public / Private key Pair from a Multi-Component Signature

Country Status (1)

Country Link
GB (3) GB2421407A (en)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010111439A3 (en) * 2009-03-25 2010-11-18 Pacid Technologies, Llc Method and system for securing communication
US20110078449A1 (en) * 2009-09-29 2011-03-31 Silverbrook Research Pty Ltd Encrypted Communication System with Limited Number of Stored Encryption Key Retrievals
WO2011081589A1 (en) * 2010-01-04 2011-07-07 Dts Steering Group Ab Secure digital communications
US8479021B2 (en) 2011-09-29 2013-07-02 Pacid Technologies, Llc Secure island computing system and method
US8726032B2 (en) 2009-03-25 2014-05-13 Pacid Technologies, Llc System and method for protecting secrets file
US8782408B2 (en) 2009-03-25 2014-07-15 Pacid Technologies, Llc Method and system for securing communication
US8934625B2 (en) 2009-03-25 2015-01-13 Pacid Technologies, Llc Method and system for securing communication
US8959350B2 (en) 2009-03-25 2015-02-17 Pacid Technologies, Llc Token for securing communication

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4876716A (en) * 1986-08-22 1989-10-24 Nec Corporation Key distribution method
EP0482233A1 (en) * 1990-10-24 1992-04-29 Omnisec Ag Cryptographic system allowing encrypted communication between users with a secure mutual cipher key determined without user interaction
GB2384406A (en) * 2002-01-21 2003-07-23 Hyun Ku Yeun Three party cryptosystem having pairs of private keys

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6567793B1 (en) * 1997-12-22 2003-05-20 Christian Bielefeldt Hicks Remote authorization for unlocking electronic data system and method
CA2235359C (en) * 1998-03-23 2012-04-10 Certicom Corp. Implicit certificate scheme with ca chaining
AU6719801A (en) * 2000-06-09 2001-12-17 Certicom Corp A method for the application of implicit signature schemes
JP4741503B2 (en) * 2003-10-28 2011-08-03 サーティコム コーポレーション To verify possible to generate a public key and a device

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4876716A (en) * 1986-08-22 1989-10-24 Nec Corporation Key distribution method
EP0482233A1 (en) * 1990-10-24 1992-04-29 Omnisec Ag Cryptographic system allowing encrypted communication between users with a secure mutual cipher key determined without user interaction
GB2384406A (en) * 2002-01-21 2003-07-23 Hyun Ku Yeun Three party cryptosystem having pairs of private keys

Cited By (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010111439A3 (en) * 2009-03-25 2010-11-18 Pacid Technologies, Llc Method and system for securing communication
US10044689B2 (en) 2009-03-25 2018-08-07 Pacid Technologies, Llc System and method for authenticating users
US9882883B2 (en) 2009-03-25 2018-01-30 Pacid Technologies, Llc Method and system for securing communication
US9876771B2 (en) 2009-03-25 2018-01-23 Pacid Technologies, Llc System and method for authenticating users
US9407610B2 (en) 2009-03-25 2016-08-02 Pacid Technologies, Llc Method and system for securing communication
US9172533B2 (en) 2009-03-25 2015-10-27 Pacid Technologies, Llc Method and system for securing communication
US9165153B2 (en) 2009-03-25 2015-10-20 Pacid Technologies, Llc System and method for protecting secrets file
US9009484B2 (en) 2009-03-25 2015-04-14 Pacid Technologies, Llc Method and system for securing communication
US8959350B2 (en) 2009-03-25 2015-02-17 Pacid Technologies, Llc Token for securing communication
US8934625B2 (en) 2009-03-25 2015-01-13 Pacid Technologies, Llc Method and system for securing communication
US8782408B2 (en) 2009-03-25 2014-07-15 Pacid Technologies, Llc Method and system for securing communication
US8539241B2 (en) 2009-03-25 2013-09-17 Pacid Technologies, Llc Method and system for securing communication
US8726032B2 (en) 2009-03-25 2014-05-13 Pacid Technologies, Llc System and method for protecting secrets file
US10171433B2 (en) 2009-03-25 2019-01-01 Pacid Technologies, Llc System and method for authenticating users
US8615085B2 (en) * 2009-09-29 2013-12-24 Zamtec Ltd Encrypted communication system with limited number of stored encryption key retrievals
US8533451B2 (en) * 2009-09-29 2013-09-10 Zamtec Ltd Method of encrypted communication with limited number of stored encryption key retrievals
US8504848B2 (en) * 2009-09-29 2013-08-06 Zamtec Ltd Encrypted communication device with limited number of encryption key retrievals from memory
US20110078449A1 (en) * 2009-09-29 2011-03-31 Silverbrook Research Pty Ltd Encrypted Communication System with Limited Number of Stored Encryption Key Retrievals
US20110078456A1 (en) * 2009-09-29 2011-03-31 Silverbrook Research Pty Ltd Encrypted Communication Device with Limited Number of Encryption Key Retrievals from Memory
US20110078457A1 (en) * 2009-09-29 2011-03-31 Silverbrook Research Pty Ltd Method of Encrypted Communication with Restricted Rate of Stored Encryption Key Retrievals
US20110078451A1 (en) * 2009-09-29 2011-03-31 Silverbrook Research Pty Ltd Encrypted Communication System with Restricted Rate of Stored Encryption Key Retrievals
US20110078450A1 (en) * 2009-09-29 2011-03-31 Silverbrook Research Pty Ltd Method of Encrypted Communication with Limited Number of Stored Encryption Key Retrievals
US20110078454A1 (en) * 2009-09-29 2011-03-31 Silverbrook Research Pty Ltd Encrypted communication device with restricted rate of encryption key retrievals from memory
US8635455B2 (en) * 2009-09-29 2014-01-21 Zamtec Ltd Encrypted communication device with restricted rate of encryption key retrievals from memory
WO2011081589A1 (en) * 2010-01-04 2011-07-07 Dts Steering Group Ab Secure digital communications
US9443110B2 (en) 2011-09-29 2016-09-13 Pacid Technologies, Llc Secure island computing system and method
US8479021B2 (en) 2011-09-29 2013-07-02 Pacid Technologies, Llc Secure island computing system and method

Also Published As

Publication number Publication date
GB0517700D0 (en) 2005-10-05
GB0427795D0 (en) 2005-01-19
GB0525074D0 (en) 2006-01-18
GB2421408A (en) 2006-06-21
GB2421410A (en) 2006-06-21

Similar Documents

Publication Publication Date Title
Dutta et al. Pairing-Based Cryptographic Protocols: A Survey.
Okamoto et al. Key distribution system based on identification information
US5481613A (en) Computer network cryptographic key distribution system
Li et al. Certificate-based signature: security model and efficient construction
US7036015B2 (en) Verification protocol
EP1782213B1 (en) Secure messaging system with derived keys
CN1717895B (en) System and method for establishing trust without revealing identity
US20100082986A1 (en) Certificate-based encryption and public key infrastructure
Yang et al. Password authentication schemes with smart cards
CA2235359C (en) Implicit certificate scheme with ca chaining
Shiuh-Jeng et al. Smart card based secure password authentication scheme
Blake-Wilson et al. Unknown key-share attacks on the station-to-station (STS) protocol
US6915434B1 (en) Electronic data storage apparatus with key management function and electronic data storage method
US6154841A (en) Digital signature method and communication system
US6389136B1 (en) Auto-Recoverable and Auto-certifiable cryptosystems with RSA or factoring based keys
US20020038420A1 (en) Method for efficient public key based certification for mobile and desktop environments
US20060206433A1 (en) Secure and authenticated delivery of data from an automated meter reading system
Mandt et al. Certificateless authenticated two-party key agreement protocols
US8499149B2 (en) Revocation for direct anonymous attestation
EP1582024B1 (en) System, apparatus and method for replacing a cryptographic key
US7480384B2 (en) Method for distributing and authenticating public keys using random numbers and Diffie-Hellman public keys
US9065637B2 (en) System and method for securing private keys issued from distributed private key generator (D-PKG) nodes
US5796833A (en) Public key sterilization
Shao Proxy signature schemes based on factoring
US7246379B2 (en) Method and system for validating software code

Legal Events

Date Code Title Description
WAP Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1)