25.Digital Cash Protocol

Lobbyist Alice can transfer digital cash to Congresscritter Bob so that newspaper reporter Eve does not know Alice’s identity. Bob can then deposit that electronic money into his bank account, even though the bank has no idea who Alice is. But if Alice tries to buy cocaine with the same piece of digital cash she used to bribe Bob, she will be detected by the bank. And if Bob tries to deposit the same piece of digital cash into two different accounts, he will be detected—but Alice will remain anonymous. Sometimes this is called anonymous digital cash to differentiate it from digital money with an audit trail, such as credit cards.

Protocol #1

The first few protocols are physical analogies of cryptographic protocols. This first protocol is a

simplified physical protocol for anonymous money orders:

(1) Alice prepares 100 anonymous money orders for $1000 each.

(2) Alice puts one each, and a piece of carbon paper, into 100 different envelopes. She gives

them all to the bank.

(3) The bank opens 99 envelopes and confirms that each is a money order for $1000.

(4) The bank signs the one remaining unopened envelope. The signature goes through the

carbon paper to the money order. The bank hands the unopened envelope back to Alice, and

deducts $1000 from her account.

(5) Alice opens the envelope and spends the money order with a merchant.

(6) The merchant checks for the bank’s signature to make sure the money order is legitimate.

(7) The merchant takes the money order to the bank.

(8) The bank verifies its signature and credits $1000 to the merchant’s account.

This protocol works. The bank never sees the money order it signed, so when the merchant brings it to the bank, the bank has no idea that it was Alice’s. The bank is convinced that it is valid, though, because of the signature.

26 Key management. Certification problem. Certificate

Public-key cryptography makes key management easier, but it has its own unique problems. Each person has only one public key, regardless of the number of people on the network. If Alice wants to send a message to Bob, she has to get Bob’s public key. She can go about this several ways:

— She can get it from Bob.

— She can get it from a centralized database.

— She can get it from her own private database.

Alice wants to send a message to Bob. She goes to the public-key database and gets Bob’s public key. But Mallory, who is sneaky, has substituted his own key for Bob’s. (If Alice asks Bob directly, Mallory has to intercept Bob’s transmission and substitute his key for Bob’s.) Alice encrypts her message in Mallory’s key and

sends it to Bob. Mallory intercepts the message, decrypts it, and reads it. He re-encrypts it with Bob’s real key and sends it on to Bob. Neither Alice nor Bob is the wiser.

Public-key Certificates

A public-key certificate is someone’s public key, signed by a trustworthy person. Certificates are used to thwart attempts to substitute one key for another . Bob’s certificate, in the public-key database, contains a lot more than his public key. It contains information about Bob—his name,address, and so on—and it is signed by someone Alice trusts: Trent (usually known as a certification authority, or CA). By signing both the key and the information about Bob, Trent checks Trent’s signature and then uses the public key, secure in the knowledge that it is Bob’s and no one else’s. Certificates play an important role in a number of public-key protocols such as PEM.Anyone may sign anyone else’s certificate, but there needs to be some way to filter out questionable certificates: for example, certificates for employees of one company signed by the CA of another company.Normally, a certification chain transfers trust: A single trusted entity certifies trusted agents, trusted

agents certify company CAs, and company CAs certify their employees.

Ideally, Bob would follow some kind of authentication procedure before the CA signs his certificate.Additionally, some kind of timestamp or an indication of the certificate’s validity period is importantto guard against compromised keys .Timestamping is not enough. Keys may be invalidated before they have expired, either through compromise or for administrative reasons. Hence, it is important the CA keep a list of invalidcertificates, and for users to regularly check that list. This key revocation problem is still a difficult one to solve.And one public-key/private-key pair is not enough