Trust is a fundamental resource which needs to be explicitly defined in any new cryp- tographic system. It is particularity important to understand the trust relationships between entities and their TAs in public key systems. Girault [78] presented a simple formalisation of trust in public key systems making use of a TA by defining three levels of trust, which are:
• Trust Level 1: The TA knows (or can easily compute) entities’ private keys. The TA can impersonate any entity at any time without being detected.
• Trust Level 2: The TA does not know (or cannot easily compute) entities’ private keys. However, the TA can still impersonate an entity by generating false guarantees using false authentication.
• Trust Level 3: The TA does not know (or cannot easily compute) entities’ private keys. The TA can still impersonate any entity, however, the fraud of the TA can be detected.
A CA in traditional certificate-based PKI is often assumed not to issue new certific- ates binding arbitrary public keys and entity combinations of its choice. This is so the CA does not bind public keys where it knows the corresponding private key. In a traditional PKI, if the CA forges certificates, then the CA can be identified as hav- ing misbehaved through the existence of two valid certificates for the same identity. Hence, traditional PKIs achieve Trust Level 3. By contrast, ID-PKC only achieves Trust Level 1 because the PKG knows every entity’s private key. It is instructive to examine the Trust Level that is achieved by CL-PKC. When compared to ID-PKC the trust assumptions made of the TA (that is, KGC) in CL-PKC are much reduced: in ID-PKC users must trust the PKG not to abuse its knowledge of private keys in performing passive attacks, while in CL-PKC users need only trust the KGC not to actively propagate false public keys. In our CL-PKC(A) schemes a new public key could have been created by the legitimate user or by the KGC, and it cannot
be easily decided which is the case. This means that our CL-PKC(A) schemes only achieve Trust Level 2. Notice that using a self certificate (recall Section 4.3.2) does not improve the fundamental trust relationship (that is, Trust Level) between each entity and the TA in CL-PKC(A). This is because the KGC can still impersonate any entity by generating false self certificates. Furthermore, self certificates generated by the entities are indistinguishable from the self certificates generated by the KGC.
As we have seen in Section 4.5.2, we can further strengthen security against a ma- licious KGC in our schemes by allowing entities to choose identifiers, which bind together their public keys and identities. Now the existence of two different working public keys for the same identity will identify the KGC as having misbehaved. By a ‘working’ public key we mean that the private key operation matching the public key has been executed. The existence of two working public keys for an identity can only result from the existence of two partial private keys binding that identity to two different public keys; only the KGC can create these two partial private keys. With this binding in place, CL-PKC(B) reaches a higher trust level than CL-PKC(A). The Trust Level attained by CL-PKC(B) is between Trust Level 2 and Trust Level 3. We explain below why CL-PKC(B) does not fully attain Trust Level 3, but first we take a closer look at encryption schemes in a traditional PKI.
A dishonest CA in standard PKC can be detected trying to impersonate A if it issues a new certificate binding its public key to A’s identifier string. This new certificate contains the CA’s chosen public key, Kpub,CAA, and will have the form:
CertCAA = (IDAkKpub,CAAkΣ(IDAkKpub,CAA), Kpriv,CA).
Entity B encrypts for entity A using the (false) public key Kpub,CAA from CertCAA;
the CA can decrypt the ciphtertext with Kpriv,CAA and then re-encrypt using A’s
original public key, Kpriv,A, from CertA. Note here that the private key of the CA,
Kpriv,CA, which is used for signing certificates is not the same as the private key
used in the impersonation, that is, Kpriv,CAA. Entities A and B can only see that
an attack has taken place if they later compare the certificate that B verified before encrypting to A with the certificate A owns. The attack is detectable only if A and
B suspect it has taken place. The evidence is the CA’s signature on the false public key. Since certificates are intended to be public and readily available, this evidence is easily gathered by A or B.
Now let us examine the same set of issues for CL-PKC(B). A misbehaving KGC in CL-PKC(B) can be detected trying to impersonate A if it issues for itself a new partial private key, binding its chosen public key PCAA to A’s identifier string. This
new partial private key will be produced by a key generation function with input IDAkPCAA, instead of input IDAkPA. Entity B encrypts for A using the public key
PCAA; the CA can decrypt and then re-encrypt using A’s original public key, PA.
Entities A and B can only see that an attack has taken place if they later compare the public key that B used in encrypting to A with the public key A has. The attack is detectable only if A and B suspect it has taken place. If the partial private key is public, the evidence implicating the KGC is the false partial private key. However, unlike the situation with a traditional PKI, we cannot assume that the partial private key is always accessible. It may well be available in a CL-PKC(B) scheme, but there is no guarantee of this for A or B.
When the partial private key is not public, then evidence implicating the KGC is a single message encrypted with two different working public keys. One cannot simply implicate the KGC when the same message is found to be encrypted with two different public keys, by claiming that entity A has one working public key, and the KGC has the other. This is because the evidence can be disputed by the KGC, as it cannot be always assumed that entity B is an honest participant. A dishonest participant B could encrypt the same message once with PA and send it to A and then encrypt
the message with PA0. If we assume that B is honest, then when A and B meet, B can claim that it only encrypted the message using PA0. The KGC is then implicated because it is the only entity that could have translated the ciphertext which B encrypted using PA0 to one which uses the correct public key, PA, by decrypting and
re-encrypting. Hence, the binding does not make the Trust Level of the CL-PKC(B) encryption scheme identical to that of certificate-based PKC: rather, it rests slightly below Trust Level 3, and the exact level depends on the availability of partial private
keys and the honesty of participants. This motivates us to redefine Trust Level 3 as follows: “The TA does not know (or cannot easily compute) entities’ private keys. The TA can still impersonate any entity, however, the fraud of the TA can always be detected.” Thus, on their own, CL-PKC(B) encryption schemes do not achieve Level 3, while certificate-based PKC schemes do.
Now we consider the Trust Level for primitives other than encryption. Any commu- nication which offers a proof of possession (PoP) of the private key corresponding to the public key, such as a signature or communication using keys agreed in an authenticated key agreement protocol, will provide evidence of a working public key which can be used to implicate the KGC. Consequently, any CL-PKC(B) scheme in which the cryptographic primitive is accompanied by a PoP of the private key will automatically achieve Trust Level 3, since the entities are always able to implicate the KGC.
The levels of trust defined in this section are related to non-repudiation (see p.37 for a definition). CL-PKC(B) schemes which achieve Trust Level 3, such as a signature scheme, automatically provide non-repudiation. This is because non-repudiation, which in essence is the inability of an entity to deny having used the private key (known only to himself), can only be attained with Trust Level 3 schemes.
Another important link between Trust Level 3 and non-repudiation arises because an entity will have to convince a court (or a legal system) of the TA’s wrong doing and the court’s decision will be based upon the evidence. This legal process is expensive, and so it is only practical for som cases. Furthermore, in cases where secrets are lost (often associated with encryption and key agreement), the legal process is insufficient, since compensation is usually irrelevant. If the legal process will not be used (or does not exist), the main advantage of deploying a Trust Level 3 encryption scheme instead of Trust Level 2 encryption scheme diminishes.