CDR: Schneier: Why Digital Signatures are not Signatures (was Re: CRYPTO-GRAM, November 15, 2000)
At 5:58 PM -0600 on 11/15/00, Bruce Schneier wrote:
Why Digital Signatures Are Not Signatures
When first invented in the 1970s, digital signatures made an amazing promise: better than a handwritten signature -- unforgeable and uncopyable -- on a document. Today, they are a fundamental component of business in cyberspace. And numerous laws, state and now federal, have codified digital signatures into law.
These laws are a mistake. Digital signatures are not signatures, and they can't fulfill their promise. Understanding why requires understanding how they work.
The math is complex, but the mechanics are simple. Alice knows a secret, called a private key. When she wants to "sign" a document (or a message, or any bucket of bits), she performs a mathematical calculation using the document and her private key; then she appends the results of that calculation -- called the "signature" -- to the document. Anyone can "verify" the signature by performing a different calculation with the message and Alice's public key, which is publicly available. If the verification calculation checks out then Alice must have signed the document, because only she knows her own private key.
Mathematically, it works beautifully. Semantically, it fails miserably. There's nothing in the description above that constitutes signing. In fact, calling whatever Alice creates a "digital signature" was probably the most unfortunate nomenclature mistake in the history of cryptography.
In law, a signature serves to indicate agreement to, or at least acknowledgment of, the document signed. When a judge sees a paper document signed by Alice, he knows that Alice held the document in her hands, and has reason to believe that Alice read and agreed to the words on the document. The signature provides evidence of Alice's intentions. (This is a simplification. With a few exceptions, you can't take a signed document into court and argue that Alice signed it. You have to get Alice to testify that she signed it, or bring handwriting experts in and then it's your word against hers. That's why notarized signatures are used in many circumstances.)
When the same judge sees a digital signature, he doesn't know anything about Alice's intentions. He doesn't know if Alice agreed to the document, or even if she ever saw it.
The problem is that while a digital signature authenticates the document up to the point of the signing computer, it doesn't authenticate the link between that computer and Alice. This is a subtle point. For years, I would explain the mathematics of digital signatures with sentences like: "The signer computes a digital signature of message m by computing m^e mod n." This is complete nonsense. I have digitally signed thousands of electronic documents, and I have never computed m^e mod n in my entire life. My computer makes that calculation. I am not signing anything; my computer is.
PGP is a good example. This e-mail security program lets me digitally sign my messages. The user interface is simple: when I want to sign a message I select the appropriate menu item, enter my passphrase into a dialog box, and click "OK." The program decrypts the private key with the passphrase, and then calculates the digital signature and appends it to my e-mail. Whether I like it or not, it is a complete article of faith on my part that PGP calculates a valid digital signature. It is an article of faith that PGP signs the message I intend it to. It is an article of faith that PGP doesn't ship a copy of my private key to someone else, who can then sign whatever he wants in my name.
I don't mean to malign PGP. It's a good program, and if it is working properly it will indeed sign what I intended to sign. But someone could easily write a rogue version of the program that displays one message on the screen and signs another. Someone could write a Back Orifice plug-in that captures my private key and signs documents without my consent or knowledge. We've already seen one computer virus that attempts to steal PGP private keys; nastier variants are certainly possible.
The mathematics of cryptography, no matter how strong, cannot bridge the gap between me and my computer. Because the computer is not trusted, I cannot rely on it to show me what it is doing or do what I tell it to. Checking the calculation afterwards doesn't help; the untrusted computer can't be relied upon to check the calculations properly. It wouldn't help to verify the code, because the untrusted computer is running the code (and probably doing the verification). It wouldn't even help to store the digital signature key in a secure module: the module still has to rely on the untrusted computer for input and output.
None of this bodes well for digital signatures. Imagine Alice in court, answering questions about a document she signed. "I never saw it," she says. "Yes, the mathematics does prove that my private key signed the document, but I never saw it." And then an expert witness like myself is called to the stand, who explains to the judge that it is possible that Alice never saw the document, that programs can be written to sign documents without Alice's knowledge, and that Alice's digital signature doesn't really mean anything about Alice's intentions.
Solving this problem requires a trusted signing computer. If Alice had a small hand-held computer, with its own screen and keyboard, she could view documents on that screen and sign them with that keyboard. As long as the signing computer is trusted, her signatures are trusted. (But problems remain. Viewing a Microsoft Word document, for example, generally involves the very software most responsible for welcoming a virus into the computer.) In this case we're no longer relying on the mathematics for security, but instead the hardware and software security of that trusted computer.
This is not to say that digital signatures are useless. There are many instances where the insecurities discussed here are not relevant, or where the dollar value of the signatures is small enough not to warrant worrying about them. There are also instances where authenticating to the signing computer is good enough, and where no further authentication is required. And there are instances where real-world relationships can obviate the legal requirements that digital signatures have been asked to satisfy.
Digital signatures prove, mathematically, that a secret value known as the private key was present in a computer at the time Alice's signature was calculated. It is a small step from that to assume that Alice entered that key into the computer at the time of signing. But it is a much larger step to assume that Alice intended a particular document to be signed. And without a tamperproof computer trusted by Alice, you can expect "digital signature experts" to show up in court contesting a lot of digital signatures.
Comments on the new federal digital signature law: <http://www4.zdnet.com:80/intweek/stories/news/0,4164,2635346,00.html> (multipage, don't miss the others) <http://www4.zdnet.com:80/intweek/stories/news/0,4164,2634368,00.html> <http://www.infoworld.com:80/articles/hn/xml/00/10/02/001002hnesign.xml> <http://www.pioneerplanet.com/tech/tcv_docs/028992.htm>
A survey of laws in various states and countries: <http://rechten.kub.nl/simone/DS-LAWSU.HTM>
-- ----------------- R. A. Hettinga <mailto: rah@ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
On Wed, 15 Nov 2000, R. A. Hettinga forwarded from a 3rd party:
When the same judge sees a digital signature, he doesn't know anything about Alice's intentions. He doesn't know if Alice agreed to the document, or even if she ever saw it.
It's nice to see somebody else recognize the fundamental flaw with PKC is the god-damned key management. ____________________________________________________________________ He is able who thinks he is able. Buddha The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage@ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------
I think we knew that, but the particular problem posited here is that Alice's sig can be associated with a record she never saw, an acute symptom, not a chronic one, I'd hope. But I have asked for education in that regard, and hope it's forthcoming. MacN On Wed, 15 Nov 2000, Jim Choate wrote:
On Wed, 15 Nov 2000, R. A. Hettinga forwarded from a 3rd party:
When the same judge sees a digital signature, he doesn't know anything about Alice's intentions. He doesn't know if Alice agreed to the document, or even if she ever saw it.
It's nice to see somebody else recognize the fundamental flaw with PKC is the god-damned key management.
____________________________________________________________________
He is able who thinks he is able.
Buddha
The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage@ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------
On Wed, 15 Nov 2000, Mac Norton wrote:
I think we knew that, but the particular problem posited here is that Alice's sig can be associated with a record she never saw, an acute symptom, not a chronic one, I'd hope. But I have asked for education in that regard, and hope it's forthcoming.
If 'you' knew that, nobody could tell from the comments. The general cypherpunks view seems to be the PGP web-of-trust is sufficient (and they are woefully wrong). This is actualy one of the two key problems with PKC management, authentication/verification. The other being scaling. The authentication/verification problem itself has two branches. The first being submitter/user authentication and the other being protocol/implimentation verification. As to scaling, I've been touting 'small network' approaches for years. It's interesting that Napster and it's ilk are just that. Couple this with a universal namespace (ala Plan 9) and some service like LDAP and you might have a usable system. Couple this with a cryptographicaly secure network layer (this is another key management problem also) and 'indepenent' or open source nameservers (for IP resolution, not to be confused with the 'working' namespace I mention above). The only thing I've seen that looks remotely workable is completely distributed and open sourced. The problem is setting up the not-for-profit namespace and key registries (assuming the problems above are resolved). How should they be funded? There is no real answer to any of them at the current time though. ____________________________________________________________________ He is able who thinks he is able. Buddha The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage@ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------
Jim Choate wrote:
On Wed, 15 Nov 2000, R. A. Hettinga forwarded from a 3rd party:
When the same judge sees a digital signature, he doesn't know anything about Alice's intentions. He doesn't know if Alice agreed to the document, or even if she ever saw it.
It's nice to see somebody else recognize the fundamental flaw with PKC is the god-damned key management.
You didn't even read the posting did you? That isn't what he said at all. He said that the problem with ALL use of computers (which for this purpose include mobile phones, car locks, smart-cards, ATMs etc. etc.) for authentication is the binding between the person & the system that does the authentication. It doesn't matter a dam whether you use PKC, DES or the Great Seal of the Holy Roman Empire. If the equipment isn't tamper-proof, or if the signer doesn't understand how the process works or if the software isn't provably valid, there can be a problem. Ken
INteresting, but seems to assume that Alice entered her key without seeing the relevant record, or that same was substituted after key entry. Plausible? yes. Practical? help. Easy? help, please. MacN
On Wed, 15 Nov 2000, Mac Norton wrote:
INteresting, but seems to assume that Alice entered her key without seeing the relevant record, or that same was substituted after key entry. Plausible? yes. Practical? help. Easy? help, please.
Actualy there is a whole host of issues with key management in regards PKC and scaling to really usable system sizes. As Bruce points out, a major one is the identity authentication. And you can't use a levels of indirection (i.e. a key to certify a key add infinitum). Another is scaling, the problem with PGP is it's too hard to manage large (i.e. 100's of Millions of keys) at the individual level. Yet any usable systems must do just that. What organization resolves protocols and who decides whom the primary implimentor will be? Consider the code base validation issue? Compare closed and open source approaches, they each have some interesting problems. My personal opinion is the only workable system is a 3-party with the 3rd party acting as arbiter/notary. It is also just as clear that that group can't be either a government agency or a profit making business. I also believe that an OS along the Plan 9 lines is the ideal Internet framework. The Austin Cypherpunks ran an anonymous remailer for about a year and we discussed some of the issues we found on the cypherpunks list. You might look back at the archives from about 2-3 years ago. The machine was called kourier.ssz.com (it's long dead). There were also some legal liability issues that our meager legal skills simply didn't resolve, and we didn't have the money to do it professionaly. ____________________________________________________________________ He is able who thinks he is able. Buddha The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage@ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------
Bruce's article is well-written, but it covers ground already well-trodden by others. Moreover, most, if not all, of his points apply to data-scrambling encryption applications on the same computer. Still, maybe it'll raise the visibility of this problem. -Declan On Wed, Nov 15, 2000 at 10:51:06PM -0500, R. A. Hettinga wrote:
At 5:58 PM -0600 on 11/15/00, Bruce Schneier wrote:
Why Digital Signatures Are Not Signatures
When first invented in the 1970s, digital signatures made an amazing promise: better than a handwritten signature -- unforgeable and uncopyable -- on a document. Today, they are a fundamental component of business in cyberspace. And numerous laws, state and now federal, have codified digital signatures into law.
These laws are a mistake. Digital signatures are not signatures, and they can't fulfill their promise. Understanding why requires understanding how they work.
The math is complex, but the mechanics are simple. Alice knows a secret, called a private key. When she wants to "sign" a document (or a message, or any bucket of bits), she performs a mathematical calculation using the document and her private key; then she appends the results of that calculation -- called the "signature" -- to the document. Anyone can "verify" the signature by performing a different calculation with the message and Alice's public key, which is publicly available. If the verification calculation checks out then Alice must have signed the document, because only she knows her own private key.
Mathematically, it works beautifully. Semantically, it fails miserably. There's nothing in the description above that constitutes signing. In fact, calling whatever Alice creates a "digital signature" was probably the most unfortunate nomenclature mistake in the history of cryptography.
In law, a signature serves to indicate agreement to, or at least acknowledgment of, the document signed. When a judge sees a paper document signed by Alice, he knows that Alice held the document in her hands, and has reason to believe that Alice read and agreed to the words on the document. The signature provides evidence of Alice's intentions. (This is a simplification. With a few exceptions, you can't take a signed document into court and argue that Alice signed it. You have to get Alice to testify that she signed it, or bring handwriting experts in and then it's your word against hers. That's why notarized signatures are used in many circumstances.)
When the same judge sees a digital signature, he doesn't know anything about Alice's intentions. He doesn't know if Alice agreed to the document, or even if she ever saw it.
The problem is that while a digital signature authenticates the document up to the point of the signing computer, it doesn't authenticate the link between that computer and Alice. This is a subtle point. For years, I would explain the mathematics of digital signatures with sentences like: "The signer computes a digital signature of message m by computing m^e mod n." This is complete nonsense. I have digitally signed thousands of electronic documents, and I have never computed m^e mod n in my entire life. My computer makes that calculation. I am not signing anything; my computer is.
PGP is a good example. This e-mail security program lets me digitally sign my messages. The user interface is simple: when I want to sign a message I select the appropriate menu item, enter my passphrase into a dialog box, and click "OK." The program decrypts the private key with the passphrase, and then calculates the digital signature and appends it to my e-mail. Whether I like it or not, it is a complete article of faith on my part that PGP calculates a valid digital signature. It is an article of faith that PGP signs the message I intend it to. It is an article of faith that PGP doesn't ship a copy of my private key to someone else, who can then sign whatever he wants in my name.
I don't mean to malign PGP. It's a good program, and if it is working properly it will indeed sign what I intended to sign. But someone could easily write a rogue version of the program that displays one message on the screen and signs another. Someone could write a Back Orifice plug-in that captures my private key and signs documents without my consent or knowledge. We've already seen one computer virus that attempts to steal PGP private keys; nastier variants are certainly possible.
The mathematics of cryptography, no matter how strong, cannot bridge the gap between me and my computer. Because the computer is not trusted, I cannot rely on it to show me what it is doing or do what I tell it to. Checking the calculation afterwards doesn't help; the untrusted computer can't be relied upon to check the calculations properly. It wouldn't help to verify the code, because the untrusted computer is running the code (and probably doing the verification). It wouldn't even help to store the digital signature key in a secure module: the module still has to rely on the untrusted computer for input and output.
None of this bodes well for digital signatures. Imagine Alice in court, answering questions about a document she signed. "I never saw it," she says. "Yes, the mathematics does prove that my private key signed the document, but I never saw it." And then an expert witness like myself is called to the stand, who explains to the judge that it is possible that Alice never saw the document, that programs can be written to sign documents without Alice's knowledge, and that Alice's digital signature doesn't really mean anything about Alice's intentions.
Solving this problem requires a trusted signing computer. If Alice had a small hand-held computer, with its own screen and keyboard, she could view documents on that screen and sign them with that keyboard. As long as the signing computer is trusted, her signatures are trusted. (But problems remain. Viewing a Microsoft Word document, for example, generally involves the very software most responsible for welcoming a virus into the computer.) In this case we're no longer relying on the mathematics for security, but instead the hardware and software security of that trusted computer.
This is not to say that digital signatures are useless. There are many instances where the insecurities discussed here are not relevant, or where the dollar value of the signatures is small enough not to warrant worrying about them. There are also instances where authenticating to the signing computer is good enough, and where no further authentication is required. And there are instances where real-world relationships can obviate the legal requirements that digital signatures have been asked to satisfy.
Digital signatures prove, mathematically, that a secret value known as the private key was present in a computer at the time Alice's signature was calculated. It is a small step from that to assume that Alice entered that key into the computer at the time of signing. But it is a much larger step to assume that Alice intended a particular document to be signed. And without a tamperproof computer trusted by Alice, you can expect "digital signature experts" to show up in court contesting a lot of digital signatures.
Comments on the new federal digital signature law: <http://www4.zdnet.com:80/intweek/stories/news/0,4164,2635346,00.html> (multipage, don't miss the others) <http://www4.zdnet.com:80/intweek/stories/news/0,4164,2634368,00.html> <http://www.infoworld.com:80/articles/hn/xml/00/10/02/001002hnesign.xml> <http://www.pioneerplanet.com/tech/tcv_docs/028992.htm>
A survey of laws in various states and countries: <http://rechten.kub.nl/simone/DS-LAWSU.HTM>
-- ----------------- R. A. Hettinga <mailto: rah@ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
At 1:12 AM -0500 on 11/16/00, Declan McCullagh wrote:
Bruce's article is well-written, but it covers ground already well-trodden by others.
Certainly. Carl Ellison, Perry Metzger, and even law professors like Jane Kauffman Wynn, have been saying this stuff for years.
Moreover, most, if not all, of his points apply to data-scrambling encryption applications on the same computer.
Yup. But, frankly, you don't want to do commerce, especially finance, on a platform you don't have absolute control over, anyway. As Chaum and others point out, you want your own box, with its own I/O, and so on. Fortunately, falling hardware prices and miniaturization continue to accelerate apace.
Still, maybe it'll raise the visibility of this problem.
And that's why I'm passing this around. Bruce succeeds where others fail, by the way, because takes complicated crypto stuff like this and reduces it to plain English better than just about anybody out there at the moment. Cheers, RAH -- ----------------- R. A. Hettinga <mailto: rah@ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
What is not clear in Schneier's several critiques of crypto weaknesses is what will be made of them to advance the burgeoning interests of law enforcement and the compsec industry in cybercrime control measures. While it may not be Bruce's intent to provide support for "the legitimate interests of law enforcement and industry" to combat "cybercriminality," what does appear to be evolving from the interests of the compsec industry is a close working relationship with the prime consumers of their services and products -- especially with the privitazation and melding of natsec and domsec. No doubt this is a carryover from the traditional close relationship between compsec and comsec researchers, developers and producers with government. Still, is there no alternative to giving government and corporations first, if not exclusive, choice on the best products and services, or contrarity, criminalizing activities and programs which do not succumb to government and corporate lobbying/purchasing persuasion (covert arm-twisting; sweetheart contracts; favorable standards, regulations, exceptions, etc.)? Count on one hand those who have resisted the lure and pressure to serve the nation as they serve their own interests. Count them stigmatized, broke, "renegades," outlaws, pitiful once-weres who lost touch with reality. Count those who are realistic as manifold, patriots, speakers at the best conclaves, propounders of sound advice to the wayward, reminders of what they've learned on the way is no longer true, award winners, celebrities with swelling bank accounts -- so long as the archy line is toed. Now, none of this applies to Bruce's evolving computer security body of work, which is most impressive. It's just not clear what will evolve as Counterpane takes more of his time and effort. What is clear is that cryptoanarchy, or or broader cyberanarchy, is not in his interests, any more than it is in government's, except as a bugaboo. Cybercrime begins with criminalizing digital information, that is, to regulate who gets access to private secrets, who runs the protection rackets: "don't trust your computer" is the next step after "don't trust the Internet." Confidence in both requires the assurance services of who? Ah yes, I see.
On Thu, 16 Nov 2000, John Young wrote:
Still, is there no alternative to giving government and corporations first, if not exclusive, choice on the best products and services,
Not if you plan to make a legal profit, there isn't. After all, government and corporations are the people with the money.
Now, none of this applies to Bruce's evolving computer security body of work, which is most impressive. It's just not clear what will evolve as Counterpane takes more of his time and effort.
Which mostly consists of pointing out flaws and problems with things other than the encryption/decryption algorithms in use: Bits of it are definitely worth a read between auditing routines in your code. (oh yeah, I have 64 bits of key in this local variable, and I'm exiting the routine: better remember to write over them so whatever grabs the memory next can't read them.... and while I'm at it, I better declare that 'volatile' so the system can't swap it to disk...) This stuff is why you can't just plug libraries together and have a good crypto product; A 'math library' made for crypto has to do fundamental things to prevent other applications getting their hands on 'numbers' that a math library for general application does not have to do. Ditto a windowing or GUI system made for crypto, etc. All these slap-together GUI programs made with MFC etc that we're seeing, are a completely wrong approach for cryptographic software; you can't make that stuff secure, you have to write your own. And this is what Schneier has been pointing out. And thank goodness somebody's been pointing it out.
Cybercrime begins with criminalizing digital information, that is, to regulate who gets access to private secrets, who runs the protection rackets: "don't trust your computer" is the next step after "don't trust the Internet." Confidence in both requires the assurance services of who? Ah yes, I see.
But for Homer Husband and Harriet Housewife, this is a valid point. We can download source, audit it, compile it, and then audit the crucial bits of binary to make sure nothing funny is going on with our compilers. We, as technogeeks and cryptogeeks, can set up our own trusted machines. But Homer and Harriet can't count to eleven without someone lending them a hand, and without training and dedication, there is no way in hell that they can hold enough stuff in their heads to set up a trusted machine on their own - thus "trust" will always be a leap of faith. However, even with a "machine trust" issue in the way, I don't see that digital signatures are *less* secure than the types of signatures now accepted in court. After all, signature forgery on paper documents is not unknown or impossible either, and the "Digital signature act" earlier this year allows unencrypted (!) HTTP requests received via the internet to be held as signatures in court. There is a fundamental schism here between the "identity is meat" school of thought in which our legal system is based and the "identity is bits" school of thought manifested in digital signature protocols. But that's a more fundamental idea, and I want to address it in a different post. Bear
Herr Bear's two paragraphs below are among of the most clear, concrete explanations of 'why security is hard/ crypto is insufficient' that I've read. Clear to a programmer, anyway. But still, I think that the vast majority of users will end up trusting something, and the vast majority will be well secured. Most do not, for example, worry about black-bag jobs. How many hardcore cpunks have reverse engineered the source to the security apps they actually use? PGPDisk *and* PGPfone *and* PGP version whatever? With time left over for SSL? And you do regular RF sweeps too? Do you work on your own brakes, too? Maybe some need to, and they recognize this. Most don't, and recognize this. The ones who need it but don't see it get culled. The ones who don't need it but see it are paranoid, or cautious, depending. Finally, things will get deployed (and paid for) only when there's some utility to the deployees. Either AMEX is going to pay for all these cards & readers because its worth it to AMEX, or Homer & vendors are going to pay because its worth it to them. With the current $50 credit card fraud limit on the customers' side, and the generally reliable POTS dial up to the credit card folks on the vendors', there is little motivation to change... no matter how efficient (cheap) or convenient the future might be if we were to start now. [I am reminded of the following: California mandates (suppressing the "needs killing" remarks for now) electric car sales, but drivers won't buy them. Rational drivers will buy (initially) more expensive but efficient hybrids if and only if (when) the price of petrol goes up enough to make it worthwhile. Ergo, If people were responsible for much more fraud-debt, they might accept / pay for / require more secure tech. Economics is physics. These are testable hypotheses; look to expensive-petrol places (Euro) to buy into high-milage hybrids faster, and 12-cylinder Caddys to be cruising the oil-rich nations until they're dry] You can get people to carry metal things around *all the time*, and you can sell them things to stick the metal things into, if they see a benefit ---like someone not stealing their padlocked objects. $50 of fraud, inertia/protectionism, and a general lack of use/concern for anonymity means Hettinga's Stored Value Smartcard-Requiring Utopia (tm) is a few years off. ..... I wonder if Gutenberg had to put up with: "But why print so many books? Almost everyone can't read" ...... At 01:49 PM 11/16/00 -0500, Ray Dillinger wrote:
Which mostly consists of pointing out flaws and problems with things other than the encryption/decryption algorithms in use: Bits of it are definitely worth a read between auditing routines in your code. (oh yeah, I have 64 bits of key in this local variable, and I'm exiting the routine: better remember to write over them so whatever grabs the memory next can't read them.... and while I'm at it, I better declare that 'volatile' so the system can't swap it to disk...)
This stuff is why you can't just plug libraries together and have a good crypto product; A 'math library' made for crypto has to do fundamental things to prevent other applications getting their hands on 'numbers' that a math library for general application does not have to do. Ditto a windowing or GUI system made for crypto, etc. All these slap-together GUI programs made with MFC etc that we're seeing, are a completely wrong approach for cryptographic software; you can't make that stuff secure, you have to write your own. And this is what Schneier has been pointing out. And thank goodness somebody's been pointing it out.
On Thu, Nov 16, 2000 at 08:56:12PM -0500, David Honig wrote:
Herr Bear's two paragraphs below are among of the most clear, concrete explanations of 'why security is hard/ crypto is insufficient' that I've read. Clear to a programmer, anyway.
But still, I think that the vast majority of users will end up trusting something, and the vast majority will be well secured. Most do not, for example, worry about black-bag jobs.
How many hardcore cpunks have reverse engineered the source to the security apps they actually use? PGPDisk *and* PGPfone *and* PGP version whatever? With time left over for SSL? And you do regular RF sweeps too? Do you work on your own brakes, too?
No, I don't do those things. I hire an accountant for my taxes, a lawyer for such affairs, a mechanic for my car, and so on. Modern society is build on trust relationships in a free market, combined with a division of labor. Crypto is subtle, true, but so is tax law, litigation, and modern automotive control systems. It is not in principle different from those areas, where money, property, and life is at stake, and we trust others to help us. -Declan
At 11:50 PM 11/16/00 -0500, Declan McCullagh wrote:
On Thu, Nov 16, 2000 at 08:56:12PM -0500, David Honig wrote:
Herr Bear's two paragraphs below are among of the most clear, concrete explanations of 'why security is hard/ crypto is insufficient' that I've read. Clear to a programmer, anyway.
But still, I think that the vast majority of users will end up trusting something, and the vast majority will be well secured. Most do not, for example, worry about black-bag jobs.
How many hardcore cpunks have reverse engineered the source to the security apps they actually use? PGPDisk *and* PGPfone *and* PGP version whatever? With time left over for SSL? And you do regular RF sweeps too? Do you work on your own brakes, too?
No, I don't do those things. I hire an accountant for my taxes, a lawyer for such affairs, a mechanic for my car, and so on. Modern society is build on trust relationships in a free market, combined with a division of labor.
Crypto is subtle, true, but so is tax law, litigation, and modern automotive control systems. It is not in principle different from those areas, where money, property, and life is at stake, and we trust others to help us.
-Declan
So it seems we agree, that most folks will end up trusting a gizmo and/or code they haven't personally inspected. The engineers' goal then becomes to design [a range of] architectures that are as trustworthy and foolproof [1] as they can be. (The lawyers' goal should be to get a fair and reasonable legal infrastructure to support them, where appropriate, e.g., crypto sigs. The marketeers' goal is to figure out how to pay for the implementation and profit off its use.) [1] You can be foolproof and not trustworthy, but you must be foolproof to be trustworthy.
According to current law in all nations (as far as I know), identity is meat. One person has one identity, and the identity is persistent and lifelong. All law is based on this assumption. Emerging in this forum and elsewhere is a different assumption, which is that identity is bits. If an entity has Alice's key, then that entity is Alice. Alice's person may be a different person this time, but only if Alice's last person was stupid or careless. And in this case Alice is probably better off with a different person anyway. Your dealings with Alice are still bound by the same guarantees of trust that you've always had with Alice: the laws of mathematics and the steps of the protocols. Alice's reputation and interests are likely to have changed with the change in person, but that's okay. Under the former assumption (Identity as meat) Alice transferring fortune and property to her son meant a change in the identity of the owner, and it was significant. Under the latter assumption (identity as bits) if she wants her son to now be the owner of all her stuff, she just hands her son the Alice keys and as far as anyone else is concerned nothing has changed. Alice is still the owner of the property, it's just that Alice now has a different person. Digital personas can be shared among several people, or handed off from one person to the other, without losing their integrity. This is one of their desirable properties. They can also be stolen, but so can most things of value. If your digital persona is the owner of several tons of gold in the form of digital bearer notes, and somebody else steals your digital persona, guess what? The ownership of those digital bearer notes has not changed. They are still owned by the same entity. You're just not that entity's physical person anymore. So if it is important to you that your identity remains "yours", guard your keys and audit your software, because on the net, identity is bits. If you want to impose an "identity is meat" assumption, you will have to pursue it in the meat world, where that assumption is valid -- thereby abandoning any hope of retaining the benefits of the net environment, such as anonymity or privacy. Bear
...which brings us to http://www.acs.ohio-state.edu/units/law/swire1/pscrypto.htm Which is, mostly, based on Professor Peter Swire's opinion on the cypherpunk "identity is bits" paradigm delivered at FC97, though apparently edited some since then. Not that I agree with him, at all, actually, but there are *lots* of twisty bits in there to wrestle with. Cheers, RAH At 11:14 AM -0800 on 11/16/00, Ray Dillinger wrote:
According to current law in all nations (as far as I know), identity is meat. One person has one identity, and the identity is persistent and lifelong. All law is based on this assumption.
Emerging in this forum and elsewhere is a different assumption, which is that identity is bits. If an entity has Alice's key, then that entity is Alice. Alice's person may be a different person this time, but only if Alice's last person was stupid or careless. And in this case Alice is probably better off with a different person anyway. Your dealings with Alice are still bound by the same guarantees of trust that you've always had with Alice: the laws of mathematics and the steps of the protocols. Alice's reputation and interests are likely to have changed with the change in person, but that's okay.
-- ----------------- R. A. Hettinga <mailto: rah@ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
At 11:14 AM -0800 11/16/00, Ray Dillinger wrote:
According to current law in all nations (as far as I know), identity is meat. One person has one identity, and the identity is persistent and lifelong. All law is based on this assumption.
Not so fast. Corporations sign legally-binding contracts every day. Institutions enter into leases, contracts, agreements, and other legally-binding arrangements. And the issue of their "identity" is not a matter of _meat_. We don't absolve Boeing of contracts because the guy who signed a contract, or even the N guys, are dead. Q.E.D., signatures are more than just meat. And Boeing's _identity_, vis-a-vis things it signs, is more than just meat. Usually we say that Boeing's signing officers/authorities, those who enter the signatures on relevant documents, are authorized to do so by Boeing. There is much case law about all of this, I'm sure. (I've read anecdotal reports about how corporate mergers involve large teams of lawyers and officers of all parties signing a blizzard of documents, and in carefully controlled order so as to minimized chances for deadlock or fraud. A complicated protocol, one which crypto may _someday_ be part of.) A guy somewhere in Boeing who uses his PGP signature on some document is neither assumed automatically to be committing Boeing to some contract ("...it depends") nor would his death (the meat is gone) mean that Boeing is free to ignore some contract ("...it depends"). I'm obviously not a lawyer. Some here are. But this is still a specialty area. Moreover, this is very little relevant case law. Schneier's warnings are useful, but, as others have said, is obvious to nearly anyone. We on this list began talking about this issue in 1992. There will be much case law, much role for the crypto equivalient of "handwriting experts," as the years go by. And we can expect a spectrum of signing technologies and strengths. For example, the mundane auto-signing which someone may use for their e-mail is substantially less persuasive ("probative," I think the lawyers would say) than an ultra-high-security, backed-with-a-bond key which Boeing's Legal Department uses to digitally sign sensitive papers. I believe Greg Broiles is still working for Signet Assurance, www.sac.net, which is one company tackling parts of this problem. Whether they will be a dominant player is of course unknown to me. Anyway, lots of issues. But "meat" is one of the least important issues. --Tim May -- (This .sig file has not been significantly changed since 1992. As the election debacle unfolds, it is time to prepare a new one. Stay tuned.)
On Thu, Nov 16, 2000 at 01:00:48PM -0800, Tim May wrote:
And we can expect a spectrum of signing technologies and strengths. For example, the mundane auto-signing which someone may use for their e-mail is substantially less persuasive ("probative," I think the lawyers would say) than an ultra-high-security, backed-with-a-bond key which Boeing's Legal Department uses to digitally sign sensitive papers.
I believe Greg Broiles is still working for Signet Assurance, www.sac.net, which is one company tackling parts of this problem. Whether they will be a dominant player is of course unknown to me.
Actually, yesterday was my last day on Signet's payroll; there has been some writing (both English and Java) regarding risk transfer, signatures, evidence, etc., at Signet, but the legal and technical people who were gathered at Signet have pretty much dispersed to other, more fruitful projects. I don't know what direction(s) the company will move in the future. I seem to be eternally a few hours away from finishing a paper on the legal aspects of digital signatures - but the really short version is that context and intent are crucial. Software applications and business applications which don't take those aspects of a signature into account are likely to be useless at best and dangerous at worst. -- Greg Broiles gbroiles@netbox.com PO Box 897 Oakland CA 94604
On Thu, 16 Nov 2000, Ray Dillinger wrote:
Emerging in this forum and elsewhere is a different assumption, which is that identity is bits.
No, it is a secure proxy protocol through bits that doesn't require physical (and usualy proximate) authentication. ____________________________________________________________________ He is able who thinks he is able. Buddha The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage@ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------
At 03:11 PM 11/16/00 -0500, Ray Dillinger wrote: Alice's person may be a different
person this time, but only if Alice's last person was stupid or careless.
This is the core: if you leave your housekeys with your address in a public place, expect to get burgled. Joesixpack humans will and can (mostly) secure physical objects where the motivations are right, ie, they lose if out of their control.
On Thu, Nov 16, 2000 at 09:40:01AM -0500, R. A. Hettinga wrote:
At 1:12 AM -0500 on 11/16/00, Declan McCullagh wrote:
Bruce's article is well-written, but it covers ground already well-trodden by others.
Certainly.
Carl Ellison, Perry Metzger, and even law professors like Jane Kauffman Wynn, have been saying this stuff for years.
Moreover, most, if not all, of his points apply to data-scrambling encryption applications on the same computer.
Yup.
But, frankly, you don't want to do commerce, especially finance, on a platform you don't have absolute control over, anyway. As Chaum and others point out, you want your own box, with its own I/O, and so on. Fortunately, falling hardware prices and miniaturization continue to accelerate apace.
What's interesting about this is that while everyone wants the added security from a device like this, no one wants to pay for it. I did a lot of the design for a secure smartcard keyboard that was produced a few years ago by a company called N*Able (bought last year by Wave Systems). It solved the problem of trusting the PC that you shove your smartcard into not to steal the PIN or sign something else or lie about what you're signing. Rather than having to trust MS (or linux) to protect your signing keys and what you're signing, you only had to trust our keyboard, which was designed from the beginning to be secure (while that's not perfect but it's a heck of a lot better than trusting MS, and good enough for commercial applications). However, in meeting with the US banking industry, we were told in so many words "this solves our security problems, we'd love to use it, but we want someone else to pay for deployment". The financial industry sees security problems not as something to be fixed, but as a cost to be borne. If the cost of the security breaks is less than the cost of the technology to fix it, or if the cost of security breaches can be passed on to someone else, there is no reason to put a security measure into place to fix the problem. I beleive that most financial systems in the US, operate on the second model (credit cards do by law- loss over $50 is eaten by the merchant or sometimes the issuing bank, to be passed back to consumers in higher prices). I think that the force that would distribute secure signing hardware in the US is profit- the hardware and the systems to support it would need to cost enough less than the fraud rate that there's a profit to be made off the difference. Unfortunately with this type of hardware, most of the cost is not in the hardware itself, but in the distribution, software and support. AMex seems to have discovered that with "blue"- there's no support for actual on-line payments. In fact the company that did the software, GlobeSET, recently folded. So now it's a regular credit card with a pretty gold-colored symbol on one side. The cost might have been worth paying for long-term customer acquisition, but it was a bust as far as fraud reduction and security is concerned. -- Eric Murray Consulting Security Architect SecureDesign LLC http://www.securedesignllc.com PGP keyid:E03F65E5
On Thu, 16 Nov 2000, R. A. Hettinga wrote:
At 1:12 AM -0500 on 11/16/00, Declan McCullagh wrote:
Bruce's article is well-written, but it covers ground already well-trodden by others.
Certainly.
Carl Ellison, Perry Metzger, and even law professors like Jane Kauffman Wynn, have been saying this stuff for years.
Bullshit. They've all dancing around the issue for years. Not one of them has proposed a solution or even a decent description of the various parameters and facets. I challenge you to provide a URL that provide real world key management issues and/or solutions. ____________________________________________________________________ He is able who thinks he is able. Buddha The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage@ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------
The Word example actually has other worrying problems not mentioned. A Word document contains a lot of hidden information, including other versions. It would be quite easy to sign a Word document that, when you viewed it, looks significantly different then it could be displayed without violating the signature. This is due to numerous problems, the most basic of which is that we often don't sign what we view but instead some binary that we _believe_ represents what we viewed but often does not. This is not just theoretical nor esoteric, but quite easy as the Word example shows. In effect we have absolutely no idea what we are signing most of the time even without comprimise of keys, programs and all that good stuff.
-----Original Message----- From: owner-cryptography@c2.net [mailto:owner-cryptography@c2.net]On Behalf Of R. A. Hettinga Sent: Wednesday, November 15, 2000 10:51 PM To: dcsb@ai.mit.edu; Digital Bearer Settlement List; cryptography@c2.net; cypherpunks@cyberpass.net Subject: Schneier: Why Digital Signatures are not Signatures (was Re:CRYPTO-GRAM, November 15, 2000)
At 5:58 PM -0600 on 11/15/00, Bruce Schneier wrote:
Why Digital Signatures Are Not Signatures
Paul Kierstead wrote:
The Word example actually has other worrying problems not mentioned. A Word document contains a lot of hidden information, including other versions. It would be quite easy to sign a Word document that, when you viewed it, looks significantly different then it could be displayed without violating the signature. This is due to numerous problems, the most basic of which is that we often don't sign what we view but instead some binary that we _believe_ represents what we viewed but often does not. This is not just theoretical nor esoteric, but quite easy as the Word example shows.
the answer to THAT is quite obvious, isn't it? I never sign anything that's not plain text. if you put your signature on a multi-page document without opening it, that's your fault. I know the word example is more complicated, and most people have 0.0 clue about those possibilities, but again: that's their problem. don't sign something that you don't understand.
Schneier's piece does a good job of listing some of the problems with digital signatures, but he really throws the baby out with the bathwater when he concludes that "Digital signatures aren't signatures." This has been his habit lately. The book _Secrets and Lies_ is filled with plenty of handwringing about how no computer security system is ever going to be good enough. The standards he applies to digital signatures are much too severe. I think that even pen-and-ink signatures wouldn't pass, a conclusion that would lead to the strange sentence, "Signatures aren't signatures and they can't fulfill their promise." The law is very vague about the definition of signatures. It's simply a mark that is made with the intent of binding yourself to a contract. That means the old 'X' scratched on a piece of paper can still bind the illiterate. Mathematicians and computer security folks will probably recoil in horror about the circularity of the whole scheme, but that's the best the law could develop during the pen-and-ink years. It is certainly possible to concentrate upon the ways that digital signatures can fail. Anyone who finds out the secret key can forge signatures with impunity. Anyone who hacks into a system can sneak things past a signer. But these techniques can also work with pen-and-ink signatures. Kids frequently learn to forge their parents' signatures on notes, tests, and permission slips. Skilled forgers can be quite adept. Most managers develop a stupid quick scrawl that is simple to copy. Pen-and-ink signatures are also easy to abuse. You can trace another signature. You can use a projector to place an image of the signature on a paper for tracing. You can cut and paste the signature using scissors and glue before you photocopy the paper. The opportunities are easy to exploit. To put it as Bruce does, a pen-and-ink signature does not authenticate the link between Alice and the paper. To make matters worse, pen-and-ink signatures do not preclude someone from changing the inside of a contract. That's why each side of the deal keeps a copy. If one copy disappears, though, all bets are off. Anyone can insert pages, replace pages, and generally create mayhem. At least digital signatures are not this easy to subvert. There is a well established network of signature experts who testify in court. While I guess it's sad that digital signatures will lead to a similar cadre of professional expert cryptographers, I'm not willing to simply state that digital signatures shouldn't be considered signatures. Unfortunately, this can be all that we have sometimes. -- -------------------------- Tune to http://www.wayner.org/books/ffa/ for information on my book on Free Software.
On Fri, 17 Nov 2000, Peter Wayner wrote:
The law is very vague about the definition of signatures. It's simply a mark that is made with the intent of binding yourself to a contract. That means the old 'X' scratched on a piece of paper can still bind the illiterate. Mathematicians and computer security folks will probably recoil in horror about the circularity of the whole scheme, but that's the best the law could develop during the pen-and-ink years.
This is the reason for witnesses and notaries. One person can easily lie about a signature. It's harder to arrange several (independent) agents to lie about it. The 'x' mark usualy has to be witnessed to be legitimate. ____________________________________________________________________ He is able who thinks he is able. Buddha The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage@ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------
On Mon, Nov 20, 2000 at 10:45:38AM -0600, Jim Choate wrote:
On Fri, 17 Nov 2000, Peter Wayner wrote:
The law is very vague about the definition of signatures. It's simply a mark that is made with the intent of binding yourself to a contract. That means the old 'X' scratched on a piece of paper can still bind the illiterate. Mathematicians and computer security folks will probably recoil in horror about the circularity of the whole scheme, but that's the best the law could develop during the pen-and-ink years.
This is the reason for witnesses and notaries.
One person can easily lie about a signature. It's harder to arrange several (independent) agents to lie about it.
The 'x' mark usualy has to be witnessed to be legitimate.
Do you have a cite for that? Peter Wayner's summary is a lot closer to the case law I've seen. -- Greg Broiles gbroiles@netbox.com PO Box 897 Oakland CA 94604
participants (16)
-
David Honig -
Declan McCullagh -
Eric Murray -
Greg Broiles -
Jim Choate -
Jim Choate
-
Jim Choate -
John Young -
Ken Brown -
Mac Norton -
Paul Kierstead -
Peter Wayner -
R. A. Hettinga -
Ray Dillinger -
Tim May -
Tom Vogt