• Abstract and Figures
• Public Full-text

06-20008 Cryptography The University of Birmingham Autumn Semester 2006 School of Computer Science Volker Sorge 12 December, 2006 Handout 11 Summary of this handout: Certificates — VeriSign — PGP — Commitment Schemes — Mental Coin Flipping — Mental Poker — Zero Knowledge Proofs IV.6 Digital Certificates For the public key ciphers as well as the digital signature algorithms discussed so far, we have only been concerned with the question how public keys can be generated, but not looked at the question how a public key can be published securely. We have simply assumed that Alice’s public key, once published, is available somewhere for Bob to encrypt messages and to check Alice’s signatures. However, Bob can never be absolutely certain that the public key he picks up has really been issued by Alice and not by some imposter. If a public key does not belong to the person that, for instance, claims has signed a message, Bob can be tricked into accepting and verifying signatures that are actually send by Mallory posing as Alice. It is therefore important that public keys can be trustedly associated with a particular party. This goal can be achieved by digital certificates. We note that in a symmetric key system, we do not have to certify which key belongs to which partici- pating party, as we assume that the key distribution is secure and that keys are only in the hands of the parties legitimately participating in the communication. Only if the key distribution mechanism fails or a key is compromised we have to renew and redistribute the common symmetric key to all parties involved, which should lead again to a closed and secure system. In this section we will have a brief look at how digital certificates can be build and how the process of certification can be handled. 64. Certification Authorities Similar to symmetric key distribution, for certification one relies on a trusted third party, a so called certification authority (CA), which is known to every user. The role of the authority is to correctly check the identity of every person that is willing to create a key pair for a public key cryptosystem, and then issue a certificate. 65. Issuing Certificates A certificate consists of a digital signature over the user’s name and additional unique identification information, the issuer’s identification, a serial number, an expiration date, the user’s public key, as well as additional technical information and various optional extensions. The signature is created using the secret signing key of the CA. Ideally, every user knows the corresponding public key of the CA so that the validity of every certificate can be locally tested by everybody. This is generally achieved by pre-distributing the certification authority’s own certificate to all participants. Certificates of important CAs are usually included immediately in web browsers and in other relevant software. The resulting infrastructure is often called a public-key infrastructure (PKI). Note that the CA itself is an off-line entity in the sense that it only takes action when issuing a certificate, but it does not participate in the actual distribution and verification of the certificate in the future. Note further that this constitutes an important advantage over key distribution centres for symmetric keys, as these centres have to be online all the time. 66. Using Certificates In a first step Alice has to obtain or purchase a certificate from a CA. She creates a key pair and presents her public key to the CA together with her proof of identity. The latter is generally done by non-electronic means (e.g., official documents of an organisation, a passport). If the CA can successfully verify Alice’s identity, the CA issues a certificate on her public key and identity, and hands this certificate over to Alice. When Bob wants to send Alice a message that is encrypted with the certified public key he has to go through the following steps: 66 1. Bob requests Alice to send him her certificate. 2. When receiving Alice’s certificate, Bob verifies the validity of the certificate’s signature with re- spect to the public key of the CA (recall that we assumed so far that the public key of the CA is known to everybody) and also checks that the certificate is indeed associated with Alice. 3. If this verification succeeds, Bob retrieves the public key of Alice from the certificate, encrypts the desired message using this key, and sends the ciphertext to Alice. 67. Multiple Certification Authorities So far we have assumed that we have a single CA in a PKI. However, this is not necessarily the case and one has to interact with certificates issued by multiple CAs. There are several ways to combine CAs: Hierarchical CAs Several CAs are certified by a single root CA. Root-CA ¢¤£¦¥ Cert Cert ¢¤£¨§ CA CA ¡ ¤ Cert £ © Cert Alice Bob Cross-Certification Several CAs are linked by exchanging certificates directly with each other. § Cert ¢¤£ CA CA ¡ ¥ ¢¤£ ¤ Cert £ © Cert Cert Alice Bob Web of Trust A decentralised public key infrastructure, in which certification is achieved by authenti- cation via several already known and trusted others. The Pretty Good Privacy programme (see below) implements the web of trust. 68. Revoking Certificates Eventually it may happen that a secret key gets compromised. We then need a mechanism to invalidate the corresponding certificates; one says that these certificates are revoked. Such a revocation can be seen as a statement, signed by the CA, that certain explicitly specified certificates should be considered invalid. The statement needs to be signed, as otherwise an attacker could easily revoke any certificate, resulting in a denial-of-service attack. There are several ways of revoking certificates; from simply publishing lists of invalid certificates to more efficient and complicated protocols. We will not go into details of revocation. Instead with have a quick look at two certification methods used today. IV.6.1 VeriSign VeriSign is a company founded in 1995 by RSA Security. It is a certification authority using RSA public key cipher and DSA signature algorithm to issue certificates. VeriSign currently has more than 3,000,000 certificates in operation. VeriSign is essentially a single central authority, that uses three classes of digital certificates: Class 1 for individuals, intended for email; Class 2 for organisations, for which proof of identity is required; and Class 3 for servers and software signing, for which independent verification and checking of iden- tity and authority is done by the issuing CA. 67 IV.6.2 PGP Pretty Good Privacy (PGP) is a computer program that provides cryptographic privacy and authenti- cation. The first PGP version, was designed and implemented by Phil Zimmermann, and made freely available in 1991. Already with its first implementation PGP has incorporated the Web of Trust cer- tification method. And, although modern implementations of PGP also provide alternative certification methods, the Web of Trust is still central to the PGP idea. Here is a quick sketch how it works in practice: Each user typically trusts several other users, say friends or colleagues. These in turn trust other users, and so on. Now one can hope (and in practice this seems to work pretty well) that if Bob can identify one or even multiple paths between Alice and himself, the public key of Alice can be trusted. Suppose Bob wants to verify Alice’s certificate but does not trust her. However, there exists a third party, say Carol that Bob knows and trusts and Carol in turn knows and trusts Alice. Carol can then certify Alice’s public key for Bob by signing it with her own secret key. Since Bob already trusts Carol he can use her public key to verify the certificate thus obtaining Alice’s public key. To counter the case that one party in such a path is corrupted, one requires to have at least two (or better even multiple) different paths to establish trust in a user’s public key. For example Bob could trust Dave who in turn trusts Eric who in turn trusts Alice. This would lead to another chain of certificates. The web of trust relies on a similar principle as the Internet, i.e. multiple path routing. It therefore, im- plements a very sturdy method of certification that is fairly immune to failure of a certification authority. Its obvious drawback is that one “has to make friends” first before being able to certify the public keys of others. IV.7 Commitment Schemes A commitment scheme is a method of sending secret information such that it cannot be altered at a later stage; neither by the sender nor the receiver. Commitment schemes are particularly important for electronic contract signing, e-voting, and online games. In general, commitment schemes consist of a commit phase and an open phase. The idea is that in the commit phase Alice commits to a value such that it cannot be changed later, while still keeping the value hidden. In the open phase the value is shown to Bob. Commitment schemes should be binding, i.e., Alice cannot change the value after the commit phase, and concealing, i.e., Bob cannot guess the value before the open phase. 69. Guaranteeing Commitment There are various ways of cryptographically guaranteeing commitment. We give two examples, one using hash functions and one employing public key ciphers. Hash Function Assume Alice wants to commit to some information. She can then use a hash function to compute the hash value for the information and send it to Bob. Once the information is released Bob can compute the hash value himself and verify Alice’s commitment.

Load more

  7

Copy Link