Final Exam

Comments and Answers

Question

With a magnetic card and his dog Buddy's name as a password, President Clinton e-signed a bill Friday that will make electronic signatures as real as those on paper.
FoxNews, 30 June 2000

In June, President Cliton signed the Electronic Signatures in Global and National Commerce Act into law. The Act adopted the general rule that an electronic signature has the same legal status in transactions involving interstate commerce as a traditional signature. The Act, however, did not specify any technology requirements on what is required to create and validate an electronic signature.

You have been hired to design a national infrastructure for securely creating and validating electronic signatures.

General Comments:

This was (obviously) an unreasonably large question --- people have been working on key infrastructures and secure signing for years, without anyone yet producing a completely satisfactory solution. Nevertheless, I believe the question provided you with a good opportunity to demonstrate what you learned (or didn't learn) in the class. Good answers revealed both a clear understanding of concrete concepts like public-key cryptography and hashing, as well as awareness and appreciation of the large system security issues. I'm pleased that about half the answers did this adequately (although, none were such that I would run out to my congressman and plead with him to adopt your solution right away!)

Simplicity is Good

In general, simple answers are better than complex ones. Complicated solutions tended to either have fatal flaws or be so incomprehensible I couldn't figure out what they had in mind. The way to present a complex answer is to present a simple one first, and then explain why the complexity was added.

Trusting PCs is Bad

The point of the separate signing device is to keep secret information and security sensitive tasks off a PC that is used to read email, browse the web, run untrustworthy application, etc. It is dangerous to assume any information kept on the PC is secure or to trust any computations done on the PC. The less your answer depended on trusting the PC, the better.

Language Peaves

Most of you seem to think "he/she" and "his/her" are English words. They are not. While I commend your attempts to avoid sexist language, slashisms are not the answer (and they are still sexist since the "he" or "his" is invariably first). A better alternative is to reword the sentence so no pronoun is necessary (e.g., "the signer"), or to give the roles names ("Alice is the signer. Bob is the recipient."). (For Douglas Hofstadter's satire on why you shouldn't just use "he", see A Person Paper on Purity in Language.)

1. Signing a Document (35)

Describe clearly and precisely your design for signing a document.

Signers should be able to sign a document using a moderately inexpensive device that attaches to a standard PC. That device may include a small display (but not large enough to show an entire document) and one or more input devices. You should not assume that any single device manufacturer can be completely trusted, but can assume the likelihood of more than one independent company conspiring is low.

Your description should explain where the keys are stored and how they are generated, what algorithms you use, and how information is transferred between the PC and the signing device.

The signer of a document should be able to have some degree of confidence that she knows what she is signing (or at least, if she is tricked into signing something different that she can prove she was tricked).

The owner of a signing device should have some degree of confidence that someone who sneaks into his home and has access to the signing device will not be able to easily forge signed documents.

Comments:

One approach would use these steps:

1. PC displays document and its hash to signer.
2. PC sends document to signing device.
3. Signing device calculated hash and displays it on screen. Signer verifies that hash matches hash displayed by PC.
4. Signer enters passphrase into signing device. Device uses passphrase to decrypt private key (KR_A), which is stored in signing device encrypted with passphrase.
5. Device calculates E_KRA [H(M)], and erases KR from its memory.
6. Device sends E_KRA [H(M)] to PC (which can include it with M in an email message).

A good choice for the hash algorith is SHA (MD5 is a reasonable choice, but viewed as less secure). A good choice for the public-key encryption algorithm used in step 5 would be RSA with at least 768-bit keys (but more than 1024 would be excessive, and probably too expensive to compute).

Since the PC could be compromised, the signer should be suspicious that the document it displays and the document it sends to the signing device are different. Note that the hash displayed by the PC doesn't help much here, since the compromised PC software could still display the wrong document, along with the hash for the document the malcode author wants you do sign.

One partial solution would be to have the client software print the document on paper along with its hash value as a watermark on every page. The signer could read the printout to confirm it is something she wants to sign, and confirm that the hash value matches the one displayed on the signing device. If SHA-1 is used, the hash value is 160 bits, which can be displayed as 27 alphabet characters. It is probably not unreasonable to expect a signer to inspect these by hand to make sure they match.

Other important issues such as how the keys are loaded into the signing device, and how a public key is associated with a principal as discussed in parts 2 and 3.

2. Validating a Signature (15)

Describe clearly and precisely your design for validating a signature. After validating a signature, the recipient should have good confidence that the signer signed the document. An independent judge should be able to validate the signature and content of the document if there are any disputes.

Comments:

Bob has received M || X from Alice, and wants to verify that X is really Alice's signature for M.

If X is a valid signature, it matches E_KRA [H(M)]. Bob's PC software contacts key authorities (see part 3 for details) to obtain Alice's public key, KU_A. Then, it uses the public key to decrypt and get H(M).

If Bob has a signing device, he can send M to the device and see H(M) on the display. If this matches the encrypted value from Alice, he accepts it as a valid signed document.

Note that the decryption part of this protocol places a perhaps unwise amount of faith in Bob's PC software. For some applications this may be unacceptable. This is discussed further in part 4.

3. Other Issues (25)

Discuss any other issues that you think are important for the success and security of your national signatures infrastructure.

Comments:

This part of the question required more mind-reading than it should have. I hoped it would be used to discuss things like revocation, time stamping, associating principals with keys, economics and market acceptance, etc., but was generally lenient in grading any reasonable discussing of relevant issues.

One of the toughest problems with public-key cryptosystems is associating a public key with a principal in a secure way. When Bob verifies Alice's signature, he needs to obtain her public key. He can do this by contacting a trusted key authority. He would need to have the public key for the key authority in order to communicate with it securely (this could be preloaded onto his machine or in the signing verification software --- but beware it could be tampered with!) The key authority needs to obtain Alice's public key in such a way that it knows it is really Alice's (that is, only the real Alice has the corresponding private key encrypted on her signing device).

Commercial attempts to build public-key infrastructures have mostly failed, since they base their revenuses on selling keys (or certificates). This motivates them to make it as easy as possible for someone to obtain a key --- all you need to do is say you are Alice and pay them. Hence, there is little confidence when the key authority says it's Alice's publicy that it really is.

For a national signing infrastructure, it should be hard enough to obtain a key that there is some confidence it is associated with the right principal (but easy enough so that people are still willing to do it). Here's one approach:

1. Alice buys a signing device that supports the national signing infrastructure protocols from a company of her choice. The new signing device comes with unloaded write-once memory with space for her keys.
2. Alice visits her local post office and shows a photo ID to their passport's officer. The passport's officer confirms Alice's identity, and takes her to a secure, shielded room containing a special-purpose computer.
3. She connects her signing device to a special-purpose computer kept in a secure room. The compuer generates a new public-private key pair.
4. It sends the private key to Alice's device. Alice enters a pass phrase into her device. The private key is encrypted with her pass phrase and stored in the write-once memory.
5. The special-purpose computer sends Alice's identity and the public key to the key authority over a secure channel.

If Alice doesn't trust the government to know her private key, she can purchase the special two-key signing device. She follows the first five steps as above, and then:

6. Visits her local Starbucks and shows her photo ID to the barista. The barista confirms Alice's identity, gives her a White Chocolate Mocha, and takes her to a secure, shielded room containing a special-purpose computer.
7. Same as 3, 4 and 5 above.

Now when she signs a document, she will encrypt the hash value with both keys. Note that RSA keys cannot be combined like symmetric keys to obtain a single new key. Instead, her device would need to compose the encryption steps, and calculate: E_KRASBUX [E_KRAUSPS [H(M)]]

Unless there is a conspiracy between the post office and Starbucks (not an altogether unlikely prospect!), neither one can forge her signature with just one of the private keys.

To verify her signature, Bob would need to obtain both public keys and decrypt with each to get the hash value.

Okay, so Alice can obtain two private keys that have public keys that are securely associated with her identity. But, how does Bob obtain those keys in a trustworhy way?

Assuming they are stored by a trustworthy key authority (and there should be serveral different key authorities to choose from), Bob needs a way to communicate securely with that key authority and know he is not communicating with an imposter. SSH helps, but only if Bob has a secure way to obtain and store the key authority server's public key (that is, not on his PC). He could also try asking the authority for his own key and check it gets the right answer. Of course, a really motivated imposter would just forward that request to a real key authority and then back to Bob. This is a hard problem and I don't know of any solution to it.

4. Vulnerability Analysis (25)

Describe the vulnerabilities of your system. What are the most frightening attacks? What countermeasures (don't necessarily limit yourself to only technical countermeasures) should be adopted to limit the risks?

Comments:

All of the submitted answers were vulnerable (to varying degrees) to this fairly easy attack: Colleen wants to get Alice to sign a bogus document. She knows Alice and Bob are alwyas communicating, and forges an email message from Bob that contains the body, "Hi Alice, Here's the contract we talked about. Please sign and return. -B" and has a Word document attached. This document looks like a normal contract that Alice would sign, but it also contains a macro that replaces Alice's signing client software with Colleen's rogue software.

Alice opens the Word document, and confirms it is a good contract for her. Then she runs the client signing software (which is now Colleen's rogue software unbeknownst to Alice). Colleen's rogue software behaves like the original software, except when it is used to sign a particular document matching the one Colleen sent in her forged email. Then, it displays that contract, but sends Colleen's bogus contract to the signing device. Alice is tricked into signing it, because she thinks it is the other document. Colleen intercepts the message to Bob with the signature.

A few years later, Colleen takes the signature and her bogus document to a judge and asks Alice to pay up.

My protocol in pat 1 is still vulnerable to this attack, except now Alice would have the printout that reveals the hash value and contract. Colleen's rogue software could print the wrong hash value (that is, one matching the bogus document), but now Alice would be able to show her prinout to the Judge. They could then calculate the actual hash value of the printed document, and Alice could prove that she was tricked into signing the wrong document.

Of course, Alice could try this for a legitimate signature. If she decided after that fact that she shouldn't have signed something, she could produce a fake printout with a different contract and the old hash value. We could employ trusted notaries or use a time stamped one-way safe to store the printouts to make this harder.

I think the next most troubling vulnerability is the difficulty in obtaining a public key associated with a principal (as discussed in part 3).

Some answers incorporated biometric devices, and wrote about the vulnerability of someone cutting off the signer's finger or "stealing" her eyeball. Although these are nice and gory, they are a bit harder to pull off without getting caught than the software vulnerabilities. A more realistic fear for the biometric inputs is that someone would lift your fingerprint off a glass, or be able to intercept the communications between the reader and device.

University of Virginia Department of Computer Science CS 551: Security, Privacy, and the Zen of Information Hiding

David Evans evans@cs.virginia.edu