Handout 11 Summary of This Handout: Certiﬁcates — Verisign — PGP — Commitment Schemes — Mental Coin Flipping — Mental Poker — Zero Knowledge Proofs

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: Certiﬁcates — 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 participating 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 certiﬁed by a single root CA.

Root-CA ¢¤£¦¥

Cert Cert ¢¤£¨§

CA CA ¡

¤ Cert £ © Cert Alice Bob

Cross-Certiﬁcation Several CAs are linked by exchanging certiﬁcates 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 authentication 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 veriﬁcation and checking of identity 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 authentication. 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 certification 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, implements 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. Alice can also not (at least not realistically) alter her commitment without altering the hash value. Public Key Cipher Assume again Alice wants to commit to some information. She can then generate a public/private key pair, encrypt the information with the private key and only publish the public key once the information needs to be veriﬁed by Bob.

70. Building Commitment Schemes Commitment schemes are a core building block for larger cryptographic protocols. I will not look at the full technical details but rather give an intuition by explaining two “mental games”.

IV.7.1 Mental Coin Flipping We have already seen how we can simulate coin ﬂipping without actually using a coin. Here is an even simpler version using a commitment scheme:

68 1. Alice ﬂips a coin and commits to the value using, for example, a hash function and publishes the

hash value.

2. Bob then makes his call (i.e., either or ¡ ). 3. Alice then publishes the outcome of the original ﬂip, which Bob can verify using the hash function.

IV.7.2 Mental Poker Now suppose Alice and Bob want to play poker without physically playing cards. We play a simplified game that consists of 1. shuffling the cards, 2. distributing five cards each, 3. calling the cards to see who has won. [Parts of the following was taken directly from Wikipedia.org.] In the following we use a cipher for encryption and decryption. It is not important which particular cipher we use, but it is important that encryption and decryption commute. Shuffling: 1. Alice and Bob agree on a deck of cards (e.g., a set of numbers representing cards).

2. Alice picks an encryption key ¢ and uses this to encrypt each card of the deck. 3. Alice shufﬂes the cards. 4. Alice passes the encrypted and shufﬂed deck to Bob. With the encryption in place, Bob cannot know which card is which.

5. Bob picks an encryption key £ and uses it to encrypt each card of the encrypted and shuffled deck. 6. Bob shuffles the deck. 7. Bob passes the double encrypted and shuffled deck back to Alice.

8. Alice decrypts each card using her key ¢ . This still leaves Bob’s encryption in place and she

cannot know which card is which. ¢§¦ 9. Alice picks one encryption key for each card ( ¢¥¤ , , etc.) and encrypts them individually. 10. Alice passes the deck to Bob.

11. Bob decrypts each card using his key £ . This still leaves Alice’s individual encryption in place

though so he cannot know which card is which.

¤ ¦ £ 12. Bob picks one encryption key for each card ( £ , , etc) and encrypts them individually. 13. Bob passes the deck back to Alice. 14. Alice publishes the deck for everyone playing. The deck is now shufﬂed and the order is ﬁxed such that it cannot be changed by either player without letting the other player know. Next we distribute cards.

Dealing: ¨

1. Alice gets cards ¡ to . This information is published.

2. Bob gets cards © to . This information is published. £

3. Alice requests keys £ ¤ to from Bob in order to see her cards. ¢¤ 4. Bob requests keys ¢ to from Alice in order to see his cards. The information on who drew which cards needs to be published in order for the players to be able check that an opponent is requesting keys for the correct cards, and does not cheat by requesting a key for a card s/he does not own. Now Bob can see his cards, but still not Alice’s and vice versa. Next we could have a round of betting and then see who has won.

Calling:

¤ ¢

1. Alice gives keys ¢ to to Bob. Bob can now decrypt Alice’s cards.

£ ¤ 2. Bob gives keys £ to to Alice. Alice can now decrypt Bob’s cards. 3. The player with the better cards win.

We can expand the play to an arbitrary number of players by extending the single steps of the protocol, i.e., shufﬂing, dealing, and calling. We can also extend the game to several rounds of betting by including a protocol for exchanging cards.

IV.8 Zero Knowledge Proofs In commitment schemes one commits to a value and reveals it at a later stage of the protocol for others to verify it. In zero knowledge proofs the object is now to never reveal a secret and only to convince others that one actually knows the secret. Zero knowledge proofs are a two party protocol, where one party is the prover and the other is the verifier, often called Peggy and Victor. In general one uses hard, computationally infeasible, mathematical problems as secret and demonstrate the knowledge of the solution to the verifier. Since one never re- leases the actual secret, Victor can never be 100% certain that Peggy actually knows it. However, the idea is to gain a certain level of confidence such that it is very unlikely that Peggy can answer correctly without knowing the actual secret. I will not go into any mathematical detail on zero knowledge proofs but instead give their intuition with the well-known cave story. In this story, Peggy has uncovered the secret word used to open a magic door in a cave. The cave is shaped like a circle, with the entrance in one side and the magic door blocking the opposite side. Victor says he’ll pay her for the secret, but not until he’s sure that she really knows it. Peggy says she’ll tell him the secret, but not until she receives the money. They devise a scheme by which Peggy can prove that she knows the word without telling it to Victor. First, Victor waits outside the cave as Peggy goes in. We label the left and right paths from the entrance A and B. She randomly takes either path A or B. Then, Victor enters the cave and shouts the name of the path he wants her to use to return, either A or B, chosen at random. Providing she really does know the magic word, this is easy: she opens the door, if necessary, and returns along the desired path. Note that Victor does not know which path she has gone down. However, suppose she does not know the word. Then, she can only return by the named path if Victor gives the name of the same path that she entered by. Since Victor chooses A or B at random, she has at most a 50% chance of guessing correctly. If they repeat this trick many times, say 20 times in a row, her chance of successfully anticipating all of Victor’s requests becomes vanishingly small, and Victor is convinced that she knows the secret. You may ask, why not just make Peggy take a known path that will force her through the door, and make Victor wait at the entrance? Certainly, that will prove that Peggy knows the secret word, but it also allows the possibility of eavesdropping. By randomising the initial path that Peggy takes and preventing Victor from knowing it, it reduces the chances that Victor can follow Peggy and learn not just that she knows the secret word, but what the secret word actually is. This part of the exchange is important for keeping the amount of information revealed to a minimum. This example as well as the illustrations below has been taken directly from the Wikipedia. ikipedia W Source:

70 06-20008 Cryptography The University of Birmingham Autumn Semester 2006 School of Computer Science Volker Sorge 12 December, 2006

Exercise Sheet 11

1. Extend the mental poker protocol presented in the handout by one round in which each player can

exchange to cards. 2. Which parts of the mental poker protocol presented in the handout have to be extended to accom- modate a third player Carol?

Field Trip to Bletchley Park, Wednesday 13th: We will leave at 10 am sharp(!) from the roundabout between University station and building 18. See part C on the campus map. We will be back before 6pm.

71 Cryptography Glossary 11

CA Short for Certi®cation Authority. 66 Certi®cate Also called Digital Certi®cate. 66 Certi®cation Authority A trusted third party that issues and validates digital certi®cates 66 Commitment Scheme A method of sending secret information such that it cannot be altered at 68 a later stage; neither by the sender nor the receiver. Cross-Certi®cation Several CAs are linked by exchanging certi®cates directly with each 67 other.

Hierarchical CAs Several CAs are certi®ed by a single root CA. 67

Mental Coin Flipping A commitment scheme for making a binary decision. 68 Mental Poker A commitment scheme to play poker without physically exchanging 69 cards.

Peggy The prover in a zero knowledge proof protocol. 70 PGP Short for Pretty Good Privacy. 67 PKI Short for Public Key Infrastructure. 66 Pretty Good Privacy A program suite that provides cryptographic tools for cryptographic pri- 67 vacy and authentication. Prover The secret holding party in a zero knowledge protocol. 70 Public-key Infrastructure An infrastructure for trusted public key encryption, using digital certi®- 66 cates, signatures, and a certi®cation authority.

Revoking Certi®cates Publishing certi®ed lists of certi®cates that have become invalid. 67

Veri®er The party in a zero knowledge protocol that needs to be convinced that 70 the prover possesses the secret. VeriSign A commercial certi®cation authority. 67 Victor The veri®er in a zero knowledge proof protocol. 70

Web of Trust A decentralised public key infrastructure, in which certi®cation is 67 achieved by authentication via several already known and trusted others.

Zero Knowledge Proof A two party protocol where one party convinces another party that it is 70 in possession of a secret without revealing the secret itself.