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 2009 School of Computer Science Volker Sorge 8 December, 2009 Handout 11 Summary of this handout: Certiﬁcates — VeriSign — PGP — Commitment Schemes — Mental Coin Flipping — Mental Poker — Zero Knowledge Proofs

IV.7 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 reliably 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. 73. 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. 74. 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. 75. 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:

82 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. 76. 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 CertCA1 CertCA2

CA1 CA2

CertAlice CertBob Alice Bob

Cross-Certiﬁcation Several CAs are linked by exchanging certiﬁcates directly with each other.

CertCA2

CA1 CA2

CertAlice CertCA1 CertBob 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. 77. 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.7.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.

83 IV.7.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. 78. Socio-ethical motivations for PGP Zimmermann’s development of PGP was mainly motivated by polit- ical considerations and his concerns of a working democratic society in the age of digital communication. He was particularly worried about how to retain privacy of personal communication in the face of an in- creasingly controlling government. Previously, when intending to spy on its citizens, governments had to expend a considerable effort to intercept communication while running a relatively high risk that the interference was detected. In the age of electronic communication however, interception, copying, and scanning of email etc. can not only be done very easily but also in arbitrary large numbers. Moreover, it can be carried out without leaving obvious traces. Zimmermann viewed this as the biggest thread to the freedom of speech and therefore democracy as a whole. And he argued that only by making powerful encryption available to every citizen one could prevent the vision of an Orwellian state.

IV.8 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. 79. 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.

84 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 public key and only publish the private key once the information needs to be veriﬁed by Bob.

80. 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.8.1 Mental Coin Flipping The most basic of commitment scheme’s in Cryptography is bit commitment, where Alice and Bob want to reach a binary decision via a single bit. This comparable with Alice and Bob trying to flip a coin, without actually physically meeting and flipping a coin. First they decide which one of the two will make the call. We assume this is Bob who calls — instead of heads or tails — either 0 or 1. Next they somehow have to flip the coin. Since we assume that neither Alice nor Bob trust the other, we cannot leave the coin toss to either one alone. They could involve Trent to simulate the coin toss, but we also assume that neither Alice nor Bob would trust him. Thus we have to come up with a way to flip the coin that is acceptable to both. In fact, we can simulate flipping the coin by using xor. Both Alice and Bob choose a bit 0 or 1, announce their choices, and the xor of the two 1 bits gives the result of the coin flip. The probability for both 0 or 1 is 2 each, i.e., exactly the probability distribution of a regular coin flip. However, we still have to prevent either party from cheating. Since Bob has already announced his call, if one of the players learns about the other’s choice of bit before they announce theirs, they can adjust their choice to win. E.g., if Bob has called 0 and learns that Alice has chosen 1, he would choose 1 himself and win. One way to prevent cheating is that both players announce their chosen bits simultaneously. However, in reality this is nearly impossible to achieve. We therefore use a commitment scheme to make the play work: One player, say Alice, commits secretly to a value. That is, she chooses either 0 or 1 before the game and cannot change the value anymore. Bob then calls the coin toss, i.e., announces publicly 0 or 1. Bob then also announces publicly his choice of bit to be xor-ed with Alice’s choice. (Observe that Bob’s choice is independent from his previous call.) Finally, Alice’s bit is revealed and xor-ed to Bob’s resulting in the final coin flip. While this approach is certainly concealing, Bob has no real guarantee that it is actually binding. So how can we ensure that Alice does not change the value she has committed to without involving a trusted third party? In order to ensure that Alice cannot change the value of her commitment anymore, she has to publish it while still keeping it secret. While this sounds contradictory it can be quite easily achieved using an arbitrary cipher:

1. Alice commits to b = 0 or b = 1, encrypts the value using a secret key K and publishes EK(b).

2. Bob calls the coin toss, i.e., announces publicly 0 or 1.

3. Bob then also announces publicly his choice of bit c = 0 or c = 1.

4. Alice publishes the key K.

5. Both Alice and Bob can now compute DK (EK(b))⊕c to see who has won.

Obviously it is not strictly necessary for Bob to contribute to the actual coin ﬂipping anymore. Thus here is an even simpler version of mental coin ﬂipping that uses a cryptographic hash function:

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 0 or 1). 3. Alice then publishes the outcome of the original ﬂip, which Bob can verify using the hash function.

85 In practice one generally does not use the bits directly, as this would be too easy for Bob to break, in particular if the hash function has been previously agreed on. Instead Alice uses a nonce to which she adds the bit she commits to before hashing and then publishes both nonce and bit for Bob to verify.

IV.8.2 Mental Poker Now suppose Alice and Bob want to play poker without physically playing cards. We play a simpliﬁed game that consists of

1. shufﬂing the cards, 2. distributing ﬁve 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 A and uses this to encrypt each card of the deck. 3. Alice shuffles the cards. 4. Alice passes the encrypted and shuffled deck to Bob. With the encryption in place, Bob cannot know which card is which. 5. Bob picks an encryption key B 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 A. 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 (A1, A2, etc.) and encrypts them individually. 10. Alice passes the deck to Bob. 11. Bob decrypts each card using his key B. 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 (B1, B2, 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 1 to 5. This information is published. 2. Bob gets cards 6 to 10. This information is published.

3. Alice requests keys B1 to B5 from Bob in order to see her cards.

4. Bob requests keys A6 to A10 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:

86 1. Alice gives keys A1 to A5 to Bob. Bob can now decrypt Alice’s cards.

2. Bob gives keys B6 to B10 to Alice. Alice can now decrypt Bob’s cards. 3. The player with the better cards wins.

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.9 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. Source: Wikipedia

87 06-20008 Cryptography The University of Birmingham Autumn Semester 2009 School of Computer Science Volker Sorge 8 December, 2009

Exercise Sheet 11

This exercise sheet is unassessed!

32. Extend the mental poker protocol presented in the handout by one round in which each player can exchange 0 to 3 cards.

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

88 Cryptography Glossary 11

Bit Commitment A basic commitment scheme to establish the value of a single bit. 85

CA Short for Certification Authority. 82 Certificate Also called Digital Certificate. 82 Certification Authority A trusted third party that issues and validates digital certificates 82 Commitment Scheme A method of sending secret information such that it cannot be altered at 84 a later stage; neither by the sender nor the receiver. Cross-Certification Several CAs are linked by exchanging certificates directly with each 83 other.

Hierarchical CAs Several CAs are certiﬁed by a single root CA. 83

Mental Coin Flipping Acommitmentschemeformakingabinarydecision. 85 Mental Poker A commitment scheme to play poker without physically exchanging 86 cards.

Peggy Theproverinazeroknowledgeproofprotocol. 87 PGP Short for Pretty Good Privacy. 83 PKI Short for Public Key Infrastructure. 82 Pretty Good Privacy A program suite that provides cryptographic tools for cryptographic pri- 83 vacy and authentication. Prover Thesecretholdingpartyinazeroknowledgeprotocol. 87 Public-key Infrastructure An infrastructure for trusted public key encryption, using digital certiﬁ- 82 cates, signatures, and a certiﬁcation authority.

Revoking Certificates Publishing certified lists of certificates that have become invalid. 83

Verifier The party in a zero knowledge protocol that needs to be convinced that 87 the prover possesses the secret. VeriSign A commercial certification authority. 83 Victor Theverifierinazeroknowledgeproofprotocol. 87

Web of Trust A decentralised public key infrastructure, in which certiﬁcation is 83 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 87 in possession of a secret without revealing the secret itself.