June 30, 2008

Cross-border Notarisations and Digital Signatures

My notes of a presentation by Dr Ugo Bechini at the Int. Conf. on Digital Evidence, London. As it touches on many chords, I've typed it up for the blog:

The European or Civil Law Notary is a powerful agent in commerce in the civil law countries, providing a trusted control of a high value transaction. Often, this check is in the form of an Apostille which is (loosely) a stamp by the Notary on an official document that asserts that the document is indeed official. Although it sounds simple, and similar to common law Notaries Public, behind the simple signature is a weighty process that may be used for real estate, wills, etc.

It works, and as Eliana Morandi puts it, writing in the 2007 edition of the Digital Evidence and Electronic Signature Law Review:

Clear evidence of these risks can be seen in the very rapid escalation, in common law countries, of criminal phenomena that are almost unheard of in civil law countries, at least in the sectors where notaries are involved. The phenomena related to mortgage fraud is particularly important, which the Mortgage Bankers Association estimates to have caused the American system losses of 2.5 trillion dollars in 2005.

OK, so that latter number came from Choicepoint's "research" (referenced somewhere here) but we can probably agree that the grains of truth sum to many billions.

Back to the Notaries. The task that they see ahead of them is to digitise the Apostille, which to some simplification is seen as a small text with a (dig)sig, which they have tried and tested. One lament common in all European tech adventures is that the Notaries, split along national lines, use many different systems: 7 formats indicating at at least 7 softwares, frequent upgrades, and of course, ultimately, incompatibility across the Eurozone.

To make notary documents interchangeable, there are (posits Dr Bechini) two solutions:

  1. a single homogenous solution for digsigs; he calls this the "GSM" solution, whereas I thought of it as a potential new "directive failure".
  2. a translation platform; one-stop shop for all formats

A commercial alternative was notably absent. Either way, IVTF (or CNUE) has adopted and built the second solution: a website where documents can be uploaded and checked for digsigs; the system checks the signature, the certificate and the authority and translates the results into 4 metrics:

  • Signed - whether the digsig is mathematically sound
  • Unrevoked - whether the certificate has been reported compromised
  • Unexpired - whether the certificate is out of date
  • Is a notary - the signer is part of a recognised network of TTPs

In the IVTF circle, a notary can take full responsibility for a document from another notary when there are 4 green boxes above, meaning that all 4 things check out.

This seems to be working: Notaries are now big users of digsigs, 3 million this year. This is balanced by some downsides: although they cover 4 countries (Deustchland, España, France, Italy), every additional country creates additional complexity.

Question is (and I asked), what happens when the expired or revoked certificate causes a yellow or red warning?

The answer was surprising: the certificates are replaced 6 months before expiry, and the messages themselves are sent on the basis of a few hours. So, instead of the document being archived with digsig and then shared, a relying Notary goes back to the originating Notary to request a new copy. The originating Notary goes to his national repository, picks up his *original* which was registered when the document was created, adds a fresh new digsig, and forwards it. The relying notary checks the fresh signature and moves on to her other tasks.

You can probably see where we are going here. This isn't digital signing of documents, as it was envisaged by the champions of same, it is more like real-time authentication. On the other hand, it does speak to that hypothesis of secure protocol design that suggests you have to get into the soul of your application: Notaries already have a secure way to archive the documents, what they need is a secure way to transmit that confidence on request, to another Notary. There is no problem with short term throw-away signatures, and once we get used to the idea, we can see that it works.

One closing thought I had was the sensitivity of the national registry. I started this post by commenting on the powerful position that notaries hold in European commerce, the presenter closed by saying "and we want to maintain that position." It doesn't require a PhD to spot the disintermediation problem here, so it will be interesting to see how far this goes.

A second closing thought is that Morandi cites

... the work of economist Hernando de Soto, who has pointed out that a major obstacle to growth in many developing countries is the absence of efficient financial markets that allow people to transform property, first and foremost real estate, into financial capital. The problem, according to de Soto, lies not in the inadequacy of resources (which de Soto estimates at approximately 9.34 trillion dollars) but rather in the absence of a formal, public system for registering property rights that are guaranteed by the state in some way, and which allows owners to use property as collateral to obtain access to the financial captal associated with ownership.

But, Latin America, where de Soto did much of his work, follows the Civil Notary system! There is an unanswered question here. It didn't work for them, so either the European Notaries are wrong about their assertation that this is the reason for no fraud in this area, or de Soto is wrong about his assertation as above. Or?

Posted by iang at 08:02 AM | Comments (1) | TrackBack

June 17, 2008

Digital Evidence -- 26-27 June, London

Cryptographers, software and hardware architects and others in the tech world have developed a strong belief that everything can be solved with more bits and bites. Often to our benefit, but sometimes to our cost. Just so with matters of law and disputes, where inventions like digital signatures have laid a trail of havoc and confusion through security practices and tools. As we know in financial cryptography, public-key reverse encryptions -- confusingly labelled as digital signatures -- are more usefully examined within the context of the law of evidence than within that of signatures.

Now here cometh those who have to take these legal theories from the back of the technologists' napkins and make them really work: the lawyers. Stephen Mason leads an impressive line-up from many countries in a conference on Digital Evidence:

Digital evidence is ubiquitous, and to such an extent, that it is used in courts every day in criminal, family, maritime, banking, contract, planning and a range of other legal matters. It will not be long before the only evidence before most courts across the globe will all be in the form of digital evidence: photographs taken from mobile telephones, e-mails from Blackberries and laptops, and videos showing criminal behaviour on You Tube are just some of the examples. Now is the time for judges, lawyers and in-house counsel to understand (i) that they need to know some of the issues and (ii) they cannot ignore digital evidence, because the courts deal with it every day, and the amount will increase as time goes by. The aim of the conference will be to alert judges, lawyers (in-house lawyers as well as lawyers in practice), digital forensic specialists, police officers and IT directors responsible for conducting investigations to the issues that surround digital evidence.

Not digital signatures, but evidence! This is a genuinely welcome development, and well worth the visit. Here's more of the blurb:

Conference Programme International Conference on Digital Evidence

26th- 27th June 2008, The Vintner's Hall, London – UNITED KINGDOM
Conference: 26th & 27th June 2008, Vintners' Hall, London
Cocktail & Dinner: 26th June 2008, The Honourable Society of Gray's Inn

THE FIRST CONFERENCE TO TREAT DIGITAL EVIDENCE FULLY ON AN INTERNATIONAL PLATFORM...

12 CPD HOURS - ACCREDITED BY THE LAW SOCIETY & THE BAR STANDARDS BOARD
This event has also been accredited on an ad hoc basis under the Faculty's CPD Scheme and will qualify for 12 hours

Understanding the Technology: Best Practice & Principles for Judges, Lawyers, Litigants, the Accused & Information Security & Digital Evidence Specialists

MIS is hosting & developing this event in partnership with & under the guidance of Stephen Mason, Barrister & Visiting Research Fellow, Digital Evidence Research, British Institute of International and Comparative Law.
Mr. Mason is in charge of the programme's content and is the author of Electronic Signatures in Law (Tottel, 2nd edn, 2007) [This text covers 98 jurisdictions including case law from Argentina, Australia, Brazil, Canada, China, Colombia, Czech Republic, Denmark, Dominican Republic, England & Wales, Estonia, Finland, France, Germany, Greece, Hungary, Israel, Italy, Lithuania, Netherlands, Papua New Guinea, Poland, Portugal, Singapore, South Africa, Spain, Switzerland and the United States of America]. He is also an author and general editor of Electronic Evidence: Disclosure, Discovery & Admissibility (LexisNexis Butterworths, 2007) [This text covers the following jurisdictions: Australia, Canada, England & Wales, Hong Kong, India, Ireland, New Zealand, Scotland, Singapore, South Africa and the United States of America]. Register Now!

Stephen is also International Electronic Evidence, general editor, (British Institute of International and Comparative Law, 2008), ISBN 978-1-905221-29-5, covering the following jurisdictions: Argentina, Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Egypt, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Italy, Japan, Latvia, Lithuania, Luxembourg, Malta, Mexico, Netherlands, Norway, Poland, Romania, Russia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Thailand and Turkey.

Posted by iang at 09:46 AM | Comments (2) | TrackBack

June 03, 2008

Technologists on signatures: looking in the wrong place

Bruce Schneier writes about the classical technology / security view and how it applies to such oddities as the fax signature. As he shows, we have trouble making them work according to classical security & tools thinking.

In a 2003 paper, "Economics, Psychology, and Sociology of Security," Professor Andrew Odlyzko looks at fax signatures and concludes:
Although fax signatures have become widespread, their usage is restricted. They are not used for final contracts of substantial value, such as home purchases. That means that the insecurity of fax communications is not easy to exploit for large gain. Additional protection against abuse of fax insecurity is provided by the context in which faxes are used. There are records of phone calls that carry the faxes, paper trails inside enterprises and so on. Furthermore, unexpected large financial transfers trigger scrutiny. As a result, successful frauds are not easy to carry out by purely technical means.

He's right. Thinking back, there really aren't ways in which a criminal could use a forged document sent by fax to defraud me.

The problem that shakes the above comments is that signatures are not tools to make things secure, nor to stop fraud. Instead, they are signals of legal intent. The law has developed them over centuries or millenia not as tools to make contracts binding, as per the simplistic common myth, or to somehow make it hard for fraudsters, the above security myth, but signals to record the intent of the person.

These subtleties matter. When you send a fax with your signature on it, it doesn't matter that the signature can be copied; it is the act of you creating and sending the fax with signature that establishes intent. Indeed, the intent can be shown without the signature, and the source of the fax is then as important as anything else. For this reason, we generally confirm what you intended somehow. Or we should, as Bruce Schneier writes:

On October 30, 2004, Tristian Wilson was released from a Memphis jail on the authority of a forged fax message. It wasn't even a particularly good forgery. It wasn't on the standard letterhead of the West Memphis Police Department. The name of the policeman who signed the fax was misspelled. And the time stamp on the top of the fax clearly showed that it was sent from a local McDonald's.

The success of this hack has nothing to do with the fact that it was sent over by fax. It worked because the jail had lousy verification procedures. They didn't notice any discrepancies in the fax. They didn't notice the phone number from which the fax was sent. They didn't call and verify that it was official. The jail was accustomed to getting release orders via fax, and just acted on this one without thinking. Would it have been any different had the forged release form been sent by mail or courier?

It's all backwards, according to the law. There should have been an intent, but there wasn't one. It wasn't that the policeman's signature established an intent, it was that the signature should have been a final step in confirming an intent that already existed. The point of phoning the policeman wasn't to check the signature, but to establish the intent. Which the signature would have nicely confirmed, but the check on intent isn't substitutable with the check on signature. As Jeff commented on the post:

Most people don't understand that signatures don't generally perform a security function, they perform a solemnization function. At least that was the case before the mathematicians got involved and tried to convince folks of the value of digitial signatures . . .. :-)

Before they got it totally backwards, that is. Your copied signature does not show intent by you, instead, it suggests an intent by you, that should be confirmed regardless. For you, this is good, as the principle of redundancy applies: you need something much more than one signature to lock you into a contract, or get you out of prison. And this process of showing intent bounces back to the signature in a particularly powerful protocol that is used in the legal world. This is a closely held secret, but I shall now reveal it and risk censure and expulsion for breaking the code:

Ask!

That's it, just ask the question. This can happen anywhere, but is best seen in a court setting: The judge says "Did you sign this?" If you did, then you say yes. (Else you're up for perjury, which is a serious risk.) If you didn't, you deny it, and then the court has a claim that it is not yours. The court now looks further to establish who's intent was behind this act.

It is for these reasons that digital signatures failed to make any mark on the real world, when cast as some sort of analogue to the human signature. Indeed, the cryptography community got it backwards, upside down and inside out. They thought that the goal was to remove the uncertainty and simplify the procedure, when in fact the goal was to preserve and exploit the uncertainty, and to augment the procedure. They were thinking non-repudiation, yet the signature is there to entice repudiation. They thought the signature was sufficient, yet it is no more than a signal of something much more important. They thought simplicity, when redundancy is the principle.

Digital signatures were presented as a new beginning and ending for electronci contracts, and users intuitively recognised they were neither a beginning nor an ending. Digital signatures were nothing, without a custom, and within a custom were shown to be more trouble than they were worth. Case in point: this is the reason why the digital signature on Ricardian Contracts is just cryptographic sugar: the intent is better shown by the server mounting the contract, by the issuer saying "I'm selling this contract", and by the system memorialising all these events in other signed records.

You might ask, why they are there, but I'll side-step that question for now :) Instead, let us ask, how then do we move forward and use digital signatures?

We should be able to see now that it is the wrong question. The right question is firstly, how do we establish intent, and the follow-up is, intent of what? Attest to a statement, conclude a negotiation, sell a house, contract for a road to be dug up, marriage with or without a shotgun? Once we have established that, we can construct a custom (techies would say a protocol) that captures the intent _and_ the agreement, suitable for the value at hand.

We might find a way to slip in some digsigs or we might not. That's because the role is to capture intent, not the signature. Intent is obligatory, signature is not.

(Indeed, this is why we say, in financial cryptography, the cryptography is optional, which causes no end of head-scratching. What then does a poor vendor of cryptographic digsigs do with them? Simple: define the digsig as meaning nothing, legally, outside an additional custom. Nothing, nix, nada, zip! And use them purely for their cryptographic properties, only. Which happen to be useful enough, if properly designed.)

Posted by iang at 12:02 PM | Comments (4) | TrackBack

February 12, 2008

on Revocation of Signing Certs and Public Key Signing itself

Philipp pointed me to another issue that turns the good ship Digital Signature into yet another Nautilus, rapidly going down the whirlpool.

Consider compromise of my signing key. If my key is compromised, then it can be used to sign any document on behalf of the erstwhile owner (was, me). Now, a curiosity of this is that the signature can be backdated, so if I lose my signing key to you, then you can sign away my house, back date it to a few years back to when it was a valid key, and take my house for a buck.

Hence, when my key is compromised, I have to revoke the key, and also potentially revoke all the signatures. The revocation of a signing cert can result in signatures of all dates becoming invalid, or questionable, even back in time. (Apparently, some proportion of client software works this way, because once a cert is revoked, all signatures are deemed "unacceptable" and thus effectively revoked. Nautilus, meet whirlpool.)

This could even be used by myself, in a nefarious mood, to cast doubt over the my own validly-made signatures. If I was homesick, I could conceivably use this to deny a valid contract to sell my house. Hey presto, Grandma gets her house back! (For other woes in the use of public keys for signing purposes, see Signed Confusion)


So how do we solve this problem? Skip down to **** if you are fully informed on that invention known as the Ricardian Contract, which does solve this issue.

In the Ricardian Contract I solved it by taking the hash of the signed contract, making that the identifier for the contract, and then embedding that hash into every transaction that happens thereafter. So, in effect, all new transactions accept and affirm the contract; and therefore form part of the evidence over the signature; if we question the original digsig, we also question all the transactions in the issuance, which is not reasonable beyond the first few dozen transactions.

What happens in more conventional PKI-land, where wisdom is writ, and standards are dusty? As is frequently pointed out, any human-meaningful use of digital signatures would then need to be confirmed with a secure timestamp, perhaps so that any later key revocation can avoid revoking that signature. Makes some sense, and indeed, every single Ricardo transaction sums to achieve that timestamp, as it builds up a tree of timestamped, signed transactions, pyramided on the original contract and its certificate.

We could then propose a rule in the use of public key digsigs for digital signing:

digital signatures cannot be relied upon over time without secure timestamping

The problem with this is that it undermines the very architecture of PKI; if we are assuming online, authoritive entities such as timestamping or digital cash issuers, then we don't actually need PKI, as it is written. Click on lynn://frequent.rant/ at this point... or for my version, in Ricardo as described above, the strength was the fact that strong evidence of the contract was kept over time, not the digsig. In this case, the evidentiary hash over the total document is what is kept, and the digsig added no more than the sweetness of headline confirmation of intent to the picture.

Because PKI (and in this case, OpenPGP cleartext signing) established a convention of signalling an intent with a digsig, it was handy to use that signal.

But we never relied on that, and a specific requirement was that someone could steal the signing key and create a bogus contract. The real strength that captured the signing over the contract was this: we took the hash of the document, and used that hash as the identifier for the contract. We are talking about Ivan, a person who is an issuer of value, and is purporting to the world that his contract is good. Them we arrange matters so that in every statement he makes to the world, he uses a strong identifier. By including the hash of the contract in every transaction, we establish Ivan's intent, understanding, liability on the basis of strong acts by the signer himself. The subtext is that the dominating evidence of intent on the document was the hash over the document, and the transactions that embedded that hash preserved and published that evidence [1].


**** The conclusion is that the hash is a better "signature" than a public-private-key digsig, if we are talking about evidence of time, leading to intent, etc; both need to be accompanied by an infrastructure that isolates the realtime of effect of the original event, and an environment where that intent is preserved. In which case, we can take the above, spin it and say that simple hashes are as good as public key digsigs at the application known as digital signing, and better because they are cheaper. Or, if the infrastructure is present, then public key digsigs makes a good carrier of hashes, as long as their use doesn't damage the application in other ways (which unfortunately it does, c.f. revocation).


What does a timestamped hash lack? It has no indicator of who the signer is. Hence, the hash does not quite defeat the digsig on the basis of Occam's razor.

But we need that in other ways anyway, as the pure cryptographic notion of a public key signature is no better than "this set of bits saw that set of bits" and we know from practical cryptography that there is no easy way to measure and control the distance from a human (intent) to a set of bits. PKI fails to achieve this because it outsources identity to a thing called Certificate Authorities, which so far have not shown themselves to be useful harbingers of your signatory, if in part because they are more expensive than the old pen&ink method.

Let's step back then, and place this in terms of requirements. We need these things to create any system of digital signing:

  • a contract
  • who is the person(s) that is "intending" the contract
  • the time of original intent
  • the preservation of all the above

Public key signatures add very little if anything over hashes and timestamps, as the former needs independent timestamping and revocation, which means that their PKI claims of offline-checking are unravelled. Neither public key digsigs or simple hashes establishes who, easily (consider the cost of PKI infrastructures versus the low statements of reliance), and neither establishes intent.

Indeed, the requirements are so badly met that we can invent a system in 30 seconds that beats the incumbent "approved digital signing systems", hands down:

Iang is who Iang says he is.
Sha1:9dea25a24190bd2cb129cc0b8718b6cf046fe154

This is strong, because, it was me that said it, me that posted it, and this blog, google, the time machine and all the other net tricks will preserve it [2]. Oh, and the hash adds some precision.

Are public key signatures dead? In technical and legal terms, yes. Public key signatures are at least brain-dead, and should be terminated for lack of sentience. While they retain some residual value in marketing senses and in infrastructure senses, they cannot be relied upon as signatures. We'll continue to put in the cryptocandy of the OpenPGP signatures on contracts, but the strength is elsewhere.

Which also means that we do not need to worry about revocation in digsig signing applications: the PKI digsigs as signing applications already revoked themselves, and we shouldn't spend any time over the issue except to say that they are not reliable enough for reliance applications. Instead, if you want a reliable digital signing application, read the Ricardian Contract paper carefully, and construct a protocol that carries the cryptocandy of the existing infrastructure alongside a proper chain that evidences the perfection of the contract: reading/understanding/intent/delivery.


Notes [1]: To follow a digital issuance through in technical, accounting terms: in a digital currency, we start out with one transaction to create value. This is of necessity a double entry transaction that puts large positive value into a manager's account, against large negative value into a float account. Then, the freshly minted positive value is distributed to the users, resulting in more transactions. The value is probably split in the second transaction and further split and recombined in each succeeding transaction, resulting in something like a tree structure.

Each of these transactions evidence an intent to honour the contract, as they all point back by means of the same hash over the same document. Hence, the OpenPGP signature is crypto-icing over the real cake within the Ricardian contract; in this particular case at least, the OpenPGP signature adds little to what the evidentiary chain of transactions provides.

Note [2]: If you want to wrap some cleartext signing sugar onto it, try this:

----- BEGIN OpenPGP Hash-Signed Document -----
I am who I say I am.
----- BEGIN HashSIG -----
d51cb67e97ae815c662042950189c59784a1560d
----- END HashSIG -----

Note [3]: how did we do that hash? Like this:

$ openssl sha1
Hash-signing my contract is as easy as typing text and adding newline then control-D at the end
1100ff22b4e28f439c03a9557b8a88eb8a749235
$

Cut and paste the text line into a Unix terminal application, and follow the instructions. Don't forget to hit return, then hit ctrl-D. Don't include the spaces at the beginning.

Posted by iang at 10:48 AM | Comments (3) | TrackBack

June 28, 2007

"Trusted-Hardcopy" -- more experiments with digitising paper and signatures

RAH points to WSJ on security and paper from HP:

H-P Designs 'Digital Signature' Against Forgeries

BANGALORE, India -- As anyone who does business in India knows, you can't get very far without the right piece of paper. That makes forgery a big problem and one of the most common types of fraud. ... In a research and development laboratory here in Bangalore, India's tech hub, Hewlett-Packard Co. is researching a way of marking new paper documents with a bar code that helps prevent forgeries....

With Trusted Hardcopy, which is just one of the tailored efforts, rather than requiring holograms or watermarked paper, the system uses equipment no more complicated than some software, a scanner and a computer. The bar code is designed to act like a digital signature, "thus bringing network level security to the world of paper," says H-P in a company document. H-P envisages government entities, public offices and companies as potential users, such as for the registration of land ownership.

... Yet India also is famously bureaucratic and forms-ridden. So the company has focused some of its efforts on trying to bridge the gap between tech and paper.... "We sort of assume that paper's not going to go away," said Mr. Kuchibhotla. "And we say that if paper's not going to go away, what technology do you need to bridge what's happening in the paper world with what's happening in the IT world?"

H-P's goal was to make a product that allowed paper to be read by a machine and secure against forgery. An early version of Trusted Hardcopy puts a bar code on paper that is similar to the bar codes on groceries. It contains the data that are also printed on the document and can be read by a scanner. It also encodes the data in the bar code to prevent tampering.

Because the bar code contains the authentic data, any changes to the document should be identifiable. The bar codes can't be easily copied. The bar code is printed at the bottom of a page of regular size copier paper....

Posted by iang at 01:23 PM | Comments (6) | TrackBack

January 05, 2007

Non-repudiation, Evidence and TLS: another fine mess I've got you into :-(

Back in the good old days when security people would sprout nonsense and nobody blinked, we talked about non-repudiation as a feature of public keys. Finally, we blabbered to anyone who would listen, we can prove that the bad guy is bad, through adroit application of PAIN and other suitable acronyms.

I was put straight on this issue by a post on the cryptography list several years back (many thanks to Carl Ellison). Basically, non-repudiation is a contradiction, as there is no way to stop a person repudiating something. She simply says

"I did not!"

And now it is over to the two sides to prove it or otherwise. Which is to say that repudiation is a basic human act, and it is a foundational stone of our modern juridical system; one side makes a claim, the other side disputes it. In court, before an impartial judge.

The term "non-repudiation" is nonsense. Even worse, the technology didn't even come close to that sense, because of the whole security mess known as the PC. Ellison & Schneier said simply that "it is your machine signing for another machine," which I long-windedly refer to as a failure to anthromorphise the PC: we have no good theory to relate a human to a key.

And, in more formal legal terms, it's a straightforward case of agent-principal failure, in that there is no clear agent-principal relationship between a natural person and a PC; given the predominant security record of Microsoft and competitors, there is no real hope for ever pushing the fantasy in court that the PC is acting for the user.

So .... as a security field, a lot of us have been beating the drum that non-repudiation does not exist in practicality, it's a hype feature only. And digital signatures aren't human signatures. And... (read my collected PKI grumble list for more).

One small contribution I might have been responsible for was the perspective that we should be talking about evidence, not signatures. Protocols reveal evidence. As anyone who's been through the mill of the legal process will tell you, anything can be evidence, and it is up to the court to decide what is good evidence and what is bad.

Hence, our role as architects is to think in terms of the quality of evidence. How can we improve the conclusions drawn from the events and logs? Well, one way is to use PK digital signatures, with the caveats of compromised keys and so forth. Another way is to use hash chains and entanglement, with the caveats of compromised PCs and so forth. Then there are timestamps, and written statements, and ... the list goes on.

By way of personal example, the Ricardian Contract gets it right, because it thrusts a human readable document out there in front of ... humans! It isn't the digsig that helps, it is the fact that the human who signed cannot be unaware of the document, normal circumstances pertaining. So as time goes on, the chances of the contract issuer "repudiating" his own contract diminish dramatically. Cunning tricks like that are the meat and drink of financial cryptography -- getting into the core of the real finance application and understanding how they tick; and then designing systems to help them tick better.

Which long preamble brings us to an Internet Draft entitled "Transport Layer Security (TLS) Evidence Extensions." This document purports to add an "evidence" extension to the venerable but ever popular TLS protocol (a.k.a. SSL, secure browsing and all that). From the introduction:

Evidence created using this extension may also be used to audit various aspects of the TLS handshake, including the cipher suite negotiation and the use of other TLS extensions. In many cases, the evidence does not need to be validated by third parties; however, in other cases, the evidence might be validated by third parties. To accommodate all of these situations, the evidence is generated using a digital signature.

Now ordinarily I would applaud this "single-minded approach" as a very useful employment of my hypothesis of "there is only one mode, and it is secure." But, from the Overview:

Generating evidence is not compatible with Diffie-Hellman Ephemeral (DHE) key exchanges. DHE does not permit the same keying material to be generated for validation of the evidence after the TLS session is over. Persistent evidence requires the use of a digital signature so that it can be validated well after the TLS session is over.

I beg to differ! As I mooted above, evidence is what you present to the court; A DHE session will do nicely thank you very much as it can log information that can be utilised for evidentiary purposes: time logs, successful password usages, etc.

So why the need to eliminate classes of evidence? More from the body:

Persisten[t] evidence of the TLS session content is produced by the TLS Evidence Protocol.
[Ed: my slight correction of word persistence used in the ID.]

What we have is a new chance at the old non-repudiation trick. That trick goes like this: First, we redefine the term "Evidence" to be what we want. Then we deliver what we want, calling it all the time Evidence. Then we force people to adopt Evidence because evidence is needed.

Nobody notices there are two disparate definitions until it is too late and they have adopted it, but that's ok because the mission is adoption, not evidence.

This would be OK if Evidence delivered anything useful. But, as we described above:

When digital certificates are to be employed in evidence creations, the client must obtain the public key certificate (PKC) for the server, and the server must obtain the PKC for the client. This is most easily accomplished by using the PKCs provided in the Handshake Protocol Certificate messages. Further, both parties SHOULD have an opportunity to validate the PKC that will be used by the other party before evidence creation. Again, this is naturally accomplished using the Handshake Protocol, where the TLS session can be rejected if the PKC cannot be validated.

Spot the problem? The client they are talking about is software, but the party they are talking about is the poor dumb victim behind the PC. Call it agency-principal failure or anthromorphism failure, it's still failure, and the security threats inherent within are unrecognised in the document despite a long history (and a very clear heading entitled 6. Security Considerations).

So what is it that they want? It looks to me -- my personal opinion -- like the same old same old: "we" need a way to push various groups into mandating PKI key infrastructure, a la the many and various agency dreams from a decade ago. Sarbanes-Oxley and others create a need for compliance, and evidence feeds into compliance.

The two come together: create a web of technical blah blah that leads to a claim that TLS delivers the Evidence, the whole Evidence, and nothing but the Evidence. Then convince everyone to accept this future RFC via the unimpeachable IETF standards process, those stalwart protectors of the Internet. Then take the RFC and push it before the regulators eyes -- if they have our Evidence, then they have your Compliance with Sarbanes-Oxley.

The hope is that another bunch of suckers will be duped into pushing PKI into inappropriate places. This simply won't work. Indeed, the way it treats evidence is so callous that it probably (my LLB U.Gresham coming into play here) makes matters worse. The evidence it produces will likely not be useful nor reliable in court, and it may even be dangerous because of the false sense of security generated. E.g., there will be enough expert witnesses around to testify that it is useless, and the added complexity will cause all sorts of problems.

And it will certainly slow down the usage of TLS or similar security processes, which is the last thing anyone wants. A security protocol used is far more secure than one not used because the barriers to adoption are too high.

Posted by iang at 10:16 AM | Comments (4) | TrackBack

April 14, 2006

Court rules email addresses are not signatures, and signs death warrant for Digital Signatures.

Daniel points to the Register:

The High Court in Manchester has ruled that an email cannot be recognised as a legal written offer if it does not contain a signature or name within the body of the mail. The inclusion of a user name in the message header is not enough.

Judge Pelling ruled that the automatic inclusion of an email address is not enough to count as a signature.

Yes, that makes sense. The email address is like a letterhead. It itself it doesn't make for more than a mild indication as to where it was supposed to have come from.

In this particular case, it seems that one party sent the other an email offering a personal guaruntee. But as Judge Pelling wrote in his ruling:

9. Section 4 of the Statute of Frauds provides that "no action shall be brought ... whereby to charge the defendant upon any special promise to answer for the debt default or miscarriage of another person ... unless the agreement upon which such action shall be brought or some memorandum or note thereof shall be in writing and signed by the party to be charged therewith or some other person thereunto by him lawfully authorised ". It follows that:
9.1. The agreement in question must be in writing or, if the agreement is made orally, there must be a memorandum or note evidencing the oral agreement; and

9.2. The agreement or memorandum must be signed by either

9.2.1. The guarantor, or

9.2.2. Someone authorised by the guarantor to sign the agreement or memorandum on his behalf.

The effect of a non compliance with Section 4 is that the contract is unenforceable.

[FC Editorial note. I shall break with normal tradition and only use indenting to highlight the quoted words.] Right. So the question at hand is whether the email was signed. If not, the statute does not apply (although Judge Pelling was careful to write that other issues probably did apply quite happily). And here we get to the crux:

19. As well know to anyone who uses email on a regular basis, What is relied upon is not inserted by the sender of the email in any active sense. It is inserted automatically. My knowledge of the technicalities of email is not sufficiently detailed to enable me to know whether it is inserted by the ISP with whom the sender or the recipient has his email account. ...

Which is pretty well spot on, including the apropos injection of user confusion. The email address is inserted automatically by an agent of uncertain pedigree. Citing an 1892 precedent:

25. It was this argument that succeeded. Cave J, said:
"I am of opinion that the principle to be derived from the decisions is this. In the first place, there must be a memorandum of a contract, not merely a memorandum of a proposal; and secondly, there must be in the memorandum, somewhere or other, the name of the party to be charged, signed by him or by his authorized agent. Whether the name occurs in the body of the memorandum, or at the beginning, or at the end, if it is intended for a signature there is a memorandum of the agreement within the meaning of the statute. " [Emphasis supplied]

As was emphasised by Cave J, the appearance of the name of the party to be bound must be "intended for a signature ". It is noteworthy that that this case was cited to the House of Lords in Elpis Maritime but was not disapproved by Lord Brandon. I do not think it can be said (and, in any event, there is no evidence) that either Mr Mehta's employee or the ISP either sending or receiving the e mail intended Mr Mehta's e mail address to be a signature in the sense identified above.

A name is only a signature if it is intended to be a signature, which goes right to the core of contract law. The signature exists as evidence of intent, and it is not the signature itself that is key, but the intent.

What then could make for a good signature, conceivably for this new invention of the typed email? Presumably in order to bolster his logic, Judge Pelling then proceeds to speculate on this question. He cites Lord Chelmsford C:

... It must be inserted in the writing in such a manner as to have the effect of "authenticating the instrument" or "so as to govern the whole instrument" ... The name of the party, and its application to the whole of the instrument, can alone satisfy the requisites of a signature. ...

and Lord Westbury:

" ... be so placed as to show that it was intended to relate and refer to, and that in fact it does relate and refer to, every part of the instrument. ... It must govern every part of the instrument. It must shew that every part of the instrument emanates from the individual so signing, and that the signature was intended to have that effect. It follows that if a signature be found in an instrument incidentally only, or having relation and reference only to a portion of the instrument, the signature cannot have legal effect and force which it must have in order to comply with the statute, and to give authenticity to the whole of the memorandum, [Emphasis supplied]

Again, notice that it must cover the entire instrument, and it must intend to govern. It is that latter part that blows away most every so-called digital signature effort - the technology cannot and will not show intent. Digital signatures are not and never can be signatures, alone.

Judge Pelling then closes:

26. In the light of the dicta cited above, it seems to me that a party can sign a document for the purposes of Section 4 by using his full name or his last name prefixed by some or all of his initials or using his initials, and possibly by using a pseudonym or a combination of letters and numbers (as can happen for example with a Lloyds slip scratch), providing always that whatever was used was inserted into the document in order to give, and with the intention of giving, authenticity to it. Its inclusion must have been intended as a signature for these purposes. ...

A typed name at the bottom of an email may constitute a good signature, if I intend for it to be so. And as a logical consequence, a "digital signature" is not and cannot be a signature, by itself. It can only be a digital signature if the user intends it to be so, but then so can a typed name.

That might be bad news for all those suppliers of cryptographic signing blah blah out there as all of their theories were expressly intended to override any user intention in order to give recipient more reliability. Not so, says the court in Metha v. JPF. User intention cannot ever be overridden by mere theories, user intent must be shown according to the law and precedents of signatures.

Bad news for digital signature suppliers, but good news for the rest of the world - as we can now get back to using digital signatures for their cryptographic and evidentiary properties without having to trip over the bogus human signature argument.


Addendums.

.
Posted by iang at 06:46 AM | Comments (18) | TrackBack

April 10, 2006

Notary Publics to Cryptographers - keep yur grubby mits off!

I've often written about how certain words are stolen and misrepresented in the field of FC. One is non-repudiation, which continues to bedevil some architectures and policies where they haven't been informed of the impossibility. Another is trust, which is more often used as a marketing plus than an admission of fundamental weakness. Yet another -- we're on a roll here -- is digital signature, which Lynn euphemistically refers to as sometimes being foolishly confused with signatures made by humans (one example v. another).

Philipp pointed me to a 2001 American Notarization Association position paper complaining about the abuse of the term 'notary' by the tech industry.

A Position on Misleading Usage of Notary Terms in the Electronic Age

Notarization, Notary, and related terms are being co-opted by certain private companies and state legislatures and applied to processes that have nothing to do with valid, legally recognized notarization. These new processes either do not involve state-commissioned Notaries at all or they violate key principles involving trusted third parties, principles that form the bedrock of commerce and law.

The repercussions of this verbal misappropriation can be devastating to consumers because, believing they are receiving certain protections from a process misrepresented as notarization, they may instead find themselves victimized by loss of valuable personal and real property without the legal assurances offered by valid notarization.

Where I've complained about the term notary is in the OpenPGP forum where there are efforts (every 12 months or so) to bolster up the capability of that protocol to do notary stuff. My comments were quite simple - the meaning and application of the word is completely different between civil law and common law, so when you apply the term into an international, cross-jurisdictional cryptoprotocol such as OpenPGP, which were you referring to?

Such comments were nowhere near as informed as this document, which includes a very concise, clear definition of the process, at least in US terms:

Fundamental Components of Notarization

In order to fully appreciate the harm caused by misleading usage of the term notarization it is necessary to understand the fundamental components of a traditional notarial act. Briefly explained, there are five essential steps in an acknowledgment;2 acknowledgment is the notarial act most often used to authenticate documents of great monetary value:

* Personal Appearance: The document signer must appear in person before, and communicate with, the Notary Public, face to face, in the same room. Physical presence allows the Notary not only to identify the signer, but also to make observations and commonsense judgments that the individual appears willing and aware.

* Identification: The Notary must positively identify the document signer beyond a reasonable doubt, either through personal knowledge of the individual's identity, the sworn vouching of a personally known credible witness, or reliable identification documents.

* Acknowledgment by Signer: Personal appearance and identification are meaningless without a context, and it is the signer's active acknowledgment of a particular signature, document, and transaction that provides the context.

* Lack of Duress: Integral to the acknowledgment is the Notary's observation that the signer was not under duress or direct physical threat at the hands of a third party.

* Awareness: Essential as evidence of the signer's intent is the Notary's observation and judgment that the signer appears to be conscious and aware at the time of signing.

Hot Dang! Try doing that in a remote-parties cryptoprotocol with NIST-approved blah blah. I have to admit, I'm impressed by the quality of writing in this paper. It goes right for the jugular.

Corporate License

Increasingly, American corporations offering Public Key Infrastructure (PKI)3 management services have been using the terms Notary and notarization to describe their services. These processes typically involve the time-date stamping of text, and they amount to notarization only in the metaphorical sense. These services do not provide the assurances associated with official notarial acts by a state-commissioned Notary Public and, for that reason, they lack the legal authority of proper notarization, which is "... to provide prima facie evidence of the truth of the facts recited in the certificate and to establish the genuineness of the signatures attached to an instrument."

It is repeatedly asked in circles where crypto really matters what the form of statement your average CA is making. This paper points out one of the flaws in the process - a CA may well not have any legal authority to make the statements that it is purporting to make! Think the so-called digital signature laws might resolve this? Think again:

Governmental License

Another development is adding to the current state of confusion in the marketplace and it is potentially more harmful to the public than deceptive misuse of sensitive terms by corporate marketers; that is, poorly thought-out redefinition of notarial procedures by hasty lawmakers.

Names are named! Not only are the States various slammed for their laws, many commercial services are given a darn good slapping. Read the whole thing, if only to see how no-nonsense rejections of poorly thought-out marketing programmes can be written. We need more of these!

Posted by iang at 01:29 PM | Comments (3) | TrackBack

March 31, 2006

Random Pennies

A curious remark from a German bank called Postbank about their desire to use digital signatures:

The electronic signature, which the bank attaches to its e-mail, is issued by TC Trust, the German subsidiary of GeoTrust.

Only Postbank customers using e-mail applications with both S/MIME authentication and TC Trust certification will receive a certification symbol, confirming that the text message is from the bank, according to Ebert.

Currently, only Outlook supports the Postbank service, he said.

Confused. I think he means that TC Trust's root isn't in other mail clients. More curioser is this:

Plans are underway to switch the certification service from TC Trust to VeriSign, which already provides certification services for Postbank's Web pages, according to Ebert. "We started with TC Trust but we think it's better to have everything with Verisign, which is more widely used," he said.

While on the subject of phishing (Internet fraud maybe being the #1 topic in netnews over time) here's a list of myths in phishing:

Secure, encrypted web page indicates a valid website - Contrary to a popular advise, never rely solely on "https://" prefix or padlock icon that indicate a "secure" page. It is possible for a phishing website to have a valid SSL certificate.

Yeah, heard that one before :) There are 10 more. Meanwhile, the US DoJ conducts a large survey and finds:

About 3 percent of all households in the U.S., totaling an estimated 3.6 million families, were hit by some sort of ID theft during the first six months of 2004, according to DOJ data set to be released Sunday. ... According to the DOJ's numbers, credit card misuse is the most common consequence of identity theft. It accounted for about half of the cases of identity theft that the survey tracked, Baum said.

Of the other identity theft victims, about 25 percent had banking and other types of accounts used without permission, 15 percent had their personal information misused, and about 12 percent faced a combination of several types of ID theft.

The average loss from these crimes amounted to US$1,290, with two-thirds of respondents saying that the theft cost them money. Based on these numbers, the nationwide estimated loss during the six months of the study amounted to $3.2 billion, for an annualized total of $6.4 billion.

Risks points at a costly burger mistake:

Four burgers at his neighborhood Burger King cost George Beane a whopping $4,334.33.

Beane ordered two Whopper Jr.s and two Rodeo cheeseburgers when he pulled up to the drive-through window last Tuesday. The cashier, however, forgot that she'd entered the $4.33 charge on his debit card and punched in the numbers again without erasing the original ones - thus creating a four-figure bill.
...
Terri Woody, the restaurant manager, said Burger King officials tried to get the charge refunded. But the bank said the funds were on a three-day hold and could not be released, Pat Beane said.

The hold is designed to prevent customers from spending money that no longer is available in their accounts and to let the bank confirm a transaction is legitimate before transferring funds, said Bank of America supervisor Joel Solorio.

Could have been worse ... could have happened on a stock exchange.

Posted by iang at 10:42 AM | Comments (0) | TrackBack

February 22, 2006

High Assurance - summary of the Due Diligence

Someone (who has requested anonymity) has been doing the research on at least some of the goings on in the "High Assurance" programme. It seems that GeoTrust/RSA/Identrus approached the ABA with the view to endorsing the programme for purpose of notarising documents -- GeoTrust's current strategic desires in e-notarisation. To this end, they are proposing signoff by bank and a lawyer (thus we see the Identrus and ABA involvement) as well as a site visit and a supplementary WebTrust audit to bring the accountants on side.

The documents are located on the ABAnet site (over on the lower right, in the Listserv box, there is a javascript popup called Cert Issuance Standards.) The meat of the proposal seems to be enhanced Due Diligence ("DD"). Here's a summary:

(a) Notarization of the signature on the Application for the High Assurance certificate: This establishes a face-to-face contact with a real person acting on behalf of the certificate applicant for the first time in the industry. A notary will also ask for and record a piece of reliable ID (e.g., a driver's license or passport) from the person signing the Application, which will be invaluable in tracking down a fraudster.

(b) Obtaining an attorney opinion letter confirming important Application information: An attorney opinion letter from the Applicant's counsel will verify critical pieces of identity information
that a public CA presently only assumes by inference, such as current corporate existence and actual authority of the person requesting the Certificate. The attorney opinion letter will also be the chief way by which public CAs can verify the legal right of an Applicant to use a trademark or logo, thereby helping to avoid commercial disputes. Verified trademarks and logos will likely be included inside TLS/SSL digital certificates in the near future for use in new applications, creating important new branding opportunities for businesses.

(c) Confirming that the Applicant is actively engaged in business (i.e., is a "real" business) by confirming that the Applicant maintains a bank account: Consumer surveys show the public does not want to do business or share information online with imaginary business entities or shell corporations that have no real-world business existence. The High Assurance vetting process confirms that the Applicant maintains a banking relationship with a financial institution, which not only provides solid evidence of ongoing business activity but also provides an important additional confirmed point of contact in the event of a consumer complaint. Because financial institutions must follow stringent "know your customer" rules under federal regulations, they are likely to have extremely accurate information about the Applicant.

(d) Finally, verifying that a representative of the Applicant can be located at a confirmed physical location: Consumers have also indicated they want to be able to link a web site to a physical location where the site owner can actually be found, but no such testing is done by any CA for current SSL certificates. Public CAs today could even issue an organizational certificate to an Applicant listing a particular address, only to find out later (after online fraud) that the address is a vacant lot or an anonymous mailbox service and the web site owner has vanished. The High Assurance certificate is backed by a real-world site visit to the Applicant's address with recorded information to verify that a
representative of the Applicant can be found there, which establishes the final vital point of contact.

The good thing about DD processes is that if yours isn't working, there's always more you can throw into it. The bad thing is that this won't necessarily improve it.

There are several problems with the above, but probably the biggest issue is again how the big boys are doing the deals in the back rooms on their wish lists, and then expecting the net to swallow this as some sort of open consensus / rough working code. Those who are not represented in this process are the smaller CAs, the notaries, and all of the users; as suspected, my source informs me that there was no open call for wider industry participation, so some of the most obvious problems will go unaddressed until it is too late.

See also the competing proposal by the National Notary Association (in America) as written by the able Daniel Greenwood.

Posted by iang at 10:29 AM | Comments (1) | TrackBack

February 06, 2006

The last (US) telegram, another FV copycat, another signature snafu

Western Union sent its last telegram last week. That's a communications method that then survived 150 years - a salutory reminder as to how long some networks take to die. Perhaps in 100 years or so we'll read about the last IPv4 packet...

Samuel Morse, inventor of the Morse Code, sent the first telegram from Washington to Baltimore on May 26, 1844, to his partner Alfred Vail to usher in the telegram era that displaced the Pony Express.

It read, "What hath God wrought?"

No news on what other countries are doing, typically.

WSJ writes on Paypal's response to Googles "imminent" entry into the payment systems business.

But PayPal must now contend with Google. The Mountain View, Calif., Web-search giant, which has terrified Silicon Valley with its ability to quickly create new consumer products and services, is developing a rival service called GBuy. For the last nine months, Google has recruited online retailers to test GBuy, according to one person briefed on the service. GBuy will feature an icon posted alongside the paid-search ads of merchants, which Google hopes will tempt consumers to click on the ads, says this person. GBuy will also let consumers store their credit-card information on Google.

Google said that it has acknowledged publicly on many occasions that it is working on payment products. The company also said it already processes online payments for ad services, as well as fees from consumers who use features such as Google Store and Google Earth. It declined to comment on any pending products.

Basically, Google is going the conventional copy-Paypal route. Install a credit card with Google, buy your retail products and get Google to aggregate the payments. You'll probably have a balance and be billed monthly. This is the same model that First Virtual pioneered, and muffed. Paypal refined it slightly (removed the two obvious bugs) and won big time. (Peppercoin tried this, not sure how they are doing.)

Why then is it taking so long? One wonders, but I'd speculate that for Google the honeymoon is over, and they have to dot the i's and cross the t's. If they muff it they might not get a second chance. Just speculation, mind.

In non-digital signature news, consider the plight of the Chairman of Qantas caught red-handed with copies of aircraft plans on entering american airspace:

Yet when the TSA rifled through her bag last year at Los Angeles Airport, their discovery of aircraft diagrams got them salivating. "Why have you got all this this?" one asked. "'I'm the chairman of an airline. I'm the chairman of Qantas," replied Margaret. "But you're a woman," replied the TSA goon. ... After a one hour interrogation and with TSA officials unimpressed by Margaret's production of official Quantas letterhead documents, she devised a way out that speaks volumes about the nature of this whole farce.

She simply wrote a note to the TSA official saying that she was CEO of Quantas and signed it.

Notice two interesting issues other than the obvious that the TSA doesn't know what planet it is on. Firstly the checker was trained to pick up on inconsistencies and picked up that a woman was calling herself Chairman. In California, that's inconsistent and politically incorrect. In Australia, that's more like a statement of pride. Oops. So there is an obvious limitation in teaching sophisticated checking of cultural cues to someone who has never left California.

Secondly, a signed statement carries enough weight to have over-ridden the entire process. What does that say about signatures? What does that say about bureaucracies and social engineering? Can you imagine the Chairman whipping out her smart card, inserting it into the TSA's reader and digitally signing a statement?

(Which brings to mind the infamous digital signing story from the 90s when the US President and the Irish PM used smart cards to sign an ecommerce agreement... After signing the treaty, they swapped the smart cards as if they were football jerseys...)

Posted by iang at 09:57 AM | Comments (0) | TrackBack

January 26, 2006

US District Court uses digital signatures

Highlighting an order by Judge Collyer in the previous entry, we find her order duly signed:

ORDER

As agreed by the parties in open court on January 13, 2006, it is hereby ORDERED that Suntrust Account Number 1000..... and Regions Bank Account Number 6709.... shall be unfrozen; however, the United States shall retain control of the funds previously seized from those accounts pursuant to the warrant issued by Magistrate Judge Facciola in Case No. 05-664 M-01 (JMF) on December 14, 2005.

SO ORDERED.

Date: January 13, 2006
/s/

ROSEMARY M. COLLYER
United States District Judge

The digital signature appears on the paper as /s/.

Discuss.

Posted by iang at 03:15 PM | Comments (0) | TrackBack

January 23, 2006

DigSig News - Notaries apply for an old Franchise, Colorado does PK with BRNs, old anecdote

MIT and the National Notary Association released a white paper on how to use notaries and cryptographic digital signatures (a.k.a. digsigs). The press release is a curious throwback to a decade ago where organisations aspirated deeply and warned that unless something was done immediately, fire, flood and pestilance was sure to strike eommerce.

Many paper-based transactions, from real estate conveyances to international adoptions to last wills and testaments, are notarized in order to prevent, detect and prosecute fraud. As government agencies and industry move toward a complete paperless workflow, electronic documents will need to receive the same level of security as their paper counterparts. However, Greenwood warns that laws and regulations to guide Notaries in the performance of electronic notarizations are lacking and must be immediately addressed to ensure the protection of property rights in the 21st century.

"Those who regulate Notaries Public would be derelict in their duty if they failed to effect the rule-making necessary to transition to a reliable system of e-notarization," Greenwood writes. "Failing to exercise oversight and control in this area would be akin to failing to provide and enforce safety rules for hydrogen or hybrid cars because the new technology is different from the old."

Cryptographic digsigs can work fine as indicators of human intent without laws, without notaries, and without fuss, once you get into the core of the application. On the other hand, a law put in place can set us back a decade or more. One of the reasons why we do not see digsigs used more often is because of the early franchise-building Utah models that were popularised in the mid 90s.

To my knowledge, courts and lawyers have this all wrapped up as they know that a signature is an indicator of intent, and the intent rules, not the mark. Efforts to regulate this long-known legal principle are therefore likely no more than franchise building, and should be summarily rejected for what they are.

Luckily the PDF that Daniel Greenwood wrote is far more clear on what a digital signature can be. Here's one fascinating snippet:

The state of Colorado has pioneered a simple but effective solution to enable state regulation of electronic notarization.26 It is called the Document Authentication Number, or DAN, and works like this:

In Colorado, this is an eleven-digit accounting number issued to each notary by the Secretary of State's accounting system. This number can be accessed and referenced by anybody. Like a white pages entry, it is unique but publicly accessible identification. The number will be searchable online to verify a notary's name, commission number, commission expiration date and other important information.

Second, each notary is issued multiple random numbers generated by the Secretary of State, who keeps a copy of each such number. Unlike the first number, these are kept confidential. They should be secured, just as is the notary's seal for paper-and-ink notarizations. One of these random, confidential numbers is used by the notary to ``brand'' every discrete eNotarization. The notary also has, associated with each confidential number, the relevant data that appears on the respective official seal, such as name, title, jurisdiction and commission expiration date. When used together, the Document Authentication Number and a randomly generated number assigned by the Secretary of State constitute the notary's electronic signature for a particular notarization.

In order to execute an eNotarization, the Colorado notary would simply affix to the electronic document both the private and public numbers, along with the pertinent commission information. This could be done by manually ``copying and pasting'' the data from a document or spreadsheet or through easy-to-use software. Thereby, the notary has tied the document to the electronic notary signature. In effect, an electronic notarization has occurred.

Nice! Public / private digital signatures with just a bunch of big random numbers (BRNs). That shows extraordinary flair by Colorado, and one wonders how they managed to slip that one past all the franchise builders, cryptography guildsmen and other worryworts.

I was reminded the other night of an anecdote about digsig laws. Some years ago, I was asked to (informally) advise a small nation on digital signatures. I read the two page draft law, and said, that's fine, but you don't need that, and here's why... (Insert blah blah here as above.)

It was then explained to me that the purpose of the law was not to regulate digital signatures, but to fill the spot, as a certain other friendly but elderly country of masculine sibling nature was pushing to put in place a regime of another sort. This action was recognised as a complete agenda push by the helpful elder sibling, and therefore a defensive action was needed: "we already have a digsig law, thanks, we don't need yours."

At which point I then understood. Fine, put in place your digsig laws, but stick to the tiny model: a digital signature should not be rejected by courts solely on the basis that it is a digital signature. End of story. Meanwhile, let the private sector get on with working out how to do this.

Posted by iang at 10:21 PM | Comments (3) | TrackBack

April 02, 2005

Old tech never dies - fax machines

The fax machine refuses to die. Check the below and notice how many clues there are in the use of signatures and paper records; you can see these clues in the Ricardian contract, where we insist it is printable and we go to extraordinary lengths to entangle it in lieu of a visual signature. The big message: tech needs to meld with old ways, not demand to replace it.

The fax machine refuses to die

By Robert Johnson The New York Times Tuesday, March 29, 2005

Older technology still not obsolete

In an office world that has gone largely digital, hand-held and wireless, the fax machine is ancient technology that just will not go away. No one shows off their fax machine the way they might, say, a BlackBerry. Yet the fax persists as a mockery of the much-predicted paperless society.

Ask Rodney Eddins. If any of his accounting clients want his undivided attention at work first thing in the morning, they should shun e-mail or his telephone answering machine. Instead, they should send him a fax.

"The first thing I look at when I arrive is the incoming tray of my fax machine," said Eddins, a certified public accountant in Orlando, Florida. "If there's paper there, I feel like I have to look at it." Only after he sorts through the faxes of the morning - though most on a recent day were ads - does Eddins log on to his computer and listen to his phone messages.

Still, like many other people, Eddins readily acknowledges a tortured relationship with his fax machine. Finding it essential for transmitting sensitive accounting documents and forms that require signatures, like tax returns, he grudgingly tolerates the noise and mess, not to mention the deluge of junk faxes.

"I actually hate my fax machine," he said. "But I need it."

Jonathan Bees, a former product manager for office machines at Konica, who is now editor in chief of Better Buys for Business magazine, said, "Back in the mid-1990s, when e-mail was really coming into its own, we had high-priced consultants telling us that the fax was going the way of the horse and buggy." Among the products he reviews for consumers these days are fax machines.

"They're better than ever - quieter, faster and with clearer reproduction," he said. "They haven't been passed by, after all."

Some 1.5 million fax machines were sold in the United States last year for use at both businesses and homes, according to the Consumer Electronics Association. Manufacturers estimate that they sold 500,000 more machines that combined a fax function with other functions, like copying and scanning.

Although sales of stand-alone fax machines are well below their peak of 3.6 million in 1997, some manufacturers say that if the multiuse machines are included, demand has been rising of late. "We have been seeing an increase in fax sales for the last four or five years," said Paul Fountain, marketing product manager at Hewlett-Packard in San Diego.

In 1994, Hewlett-Packard left the fax market, believing the predictions of impending obsolescence. "We came back in 1998," Fountain said, "because we realized the fax was not going away."

While fax machines are not as prevalent as computers in the workplace or home offices, Bill Young, a communications coach at Strickland Group in New York City, said, "The fax has important functions that e-mail simply hasn't been able to take over." Those would include reproducing signatures on documents like contracts, business proposals and medical prescriptions.

CVS, a 5,300-store chain, relies on fax machines as the most common means of receiving prescriptions, said a company spokesman, Todd Andrews. "The fax gives the pharmacist a written record of what the doctor ordered," he said. Faxing avoids misunderstandings that can occur when prescriptions are phoned in.

http://www.iht.com/bin/print_ipub.php?file=/articles/2005/03/28/business/fax.html

Posted by iang at 09:31 AM | Comments (2) | TrackBack

March 25, 2005

Digitally-Signed Mail in e-Commerce - FC05 survey

In a paper (sorry, PDF only) last month at FC05, Garfinkel and friends reported on an interesting survey conducted in two communities of merchants, one which received signed email from a supplier, and one which did not. This was an unusual chance to test two groups distinguished by usage of a crypto tool.

The biggest result to my mind is that users simply didn't as a body understand what the signed emails were all about. Even though these merchants were dealing with valuable transactions, the group that was receiving signed email only did a little better than the control group in knowing it (33% as opposed to 20%). This is a confusion that I'd expect, I recently installed a good cert into my Thunderbird and I still cannot send out signed or encrypted email using S/MIME (I forget why).

It's a very valuable survey, and welcome addition to the work of Ping, Friedman, et al, and of course Simson Garfinkel's thesis. I've copied the Conclusion below as anyone involved with email or user security should be aware of how real systems meet real users.

But there is one area where I take exception at. Garfinkel el al believe that commercial entities "should immediately adopt the practice of digitally-signing their mail to customers with S/MIME signatures using a certificate signed by a widely-published CA such as VeriSign."

Strongly Disagree! As there is nothing in the paper that indicates the meaning of a digital signature, this is a bad recommendation. Are they asking merchants to take on unlimited liability? Is this a simply a protection against forged emails? Or a checksum against network corruption? Without some thought as to what it is the merchant is promising, I'd recommend that signing be left off.

(Encryption, on the other hand, is fine. We can never have enough encryption. But this survey didn't cover that.)

Views, Reactions and Impact of Digitally-Signed Mail in e-Commerce

Abstract.We surveyed 470 Amazon.com merchants regarding their experience, knowledge and perceptions of digitally-signed email. Some of these merchants (93) had been receiving digitally-signed VAT invoices from Amazon for more than a year. Respondents attitudes were measured as to the role of signed and/or sealed mail in e-commerce. Among our findings: 25.2% of merchants thought that receipts sent by online merchants should be digitally-signed, 13.2% thought they should be sealed with encryption, and 33.6% thought that they should be both signed and sealed. Statistically-significant differences between merchants who had received the signed mail and those who had not are noted. We conclude that Internet-based merchants should send digitally-signed email as a best practice, even if they think that their customers will not understand the signatures, on the grounds that today s email systems handle such signatures automatically and the passive exposure to signatures appears to increase acceptance and trust.

4 Conclusions and Policy Implications

We surveyed hundreds of people actively involved in the business of e-commerce as to their views on and experience with digitally-signed email. Although they had not received prior notification of the fact, some of these individuals had been receiving digitally-signed email for more than a year. To the best of our knowledge this is the first survey of its kind

It is widely believed that people will not use cryptographic techniques to protect email unless it is extraordinarily easy to use. We showed that even relatively unsophisticated computer users who do not send digitally-signed mail nevertheless believe that it should be used to protect the email that they themselves are sending (and to a lesser extent, receiving as well).

We believe that digitally-signed mail could provide some measure of defense against phishing attacks. Because attackers may try to obtain certificates for typo or copycat names, we suggest that email clients should indicate the difference between a certificate that had been received many times and one that is being received for the first time much in the way that programs implementing the popular SSH protocol [15] alert users when a host key has changed.

We found that the majority (58.5%) of respondents did not know whether or not the program that they used to read their mail handled encryption, even though the vast majority (81.1%) use such mail clients. Given this case, companies that survey their customers as to whether or not the customers have encryption-capable mail readers are likely to yield erroneous results.

We learned that digitally-signed mail tends to increase the recipient s trust in the email infrastructure.We learned that despite more than a decade of confusion over multiple standards for secure email, there are now few if any usability barriers to receiving mail that s digitally-signed with S/MIME signatures using established CAs.

Finally, we found that people with no obvious interest in selling or otherwise promoting cryptographic technology believe that many email messages sent today without protection should be either digitally-signed, sealed with encryption, or both.

The complete survey text with simple tabulations of every question and all respondent comments for which permission was given to quote is at http://www.simson.net/smime-survey.html.

4.1 Recommendations

We believe that financial organizations, retailers, and other entities doing business on the Internet should immediately adopt the practice of digitally-signing their mail to customers with S/MIME signatures using a certificate signed by a widely-published CA such as VeriSign. Software for processing such messages is widely deployed. As one of our respondents who identified himself as a very sophisticated computer user wrote:

I use PGP, but in the several years since I have installed it I have never used it for encrypting email, or sending signed email. I have received and verified signed email from my ISP. I have never received signed email from any other source (including banks, paypal, etc, which are the organisations I would have thought would have gained most from its use).

Given that support for S/MIME signatures is now widely deployed, we also believe that existing mail clients and webmail systems that do not recognize S/MIME-signed mail should be modified to do so. Our research shows that there is significant value for users in being able to verify signatures on signed email, even without the ability to respond to these messages with mail that is signed or sealed.

We also believe that existing systems should be more lenient with mail that is digitally-signed but which fails some sort of security check. For example, Microsoft Outlook and Outlook Express give a warning if a message is signed with a certificate that has expired, or if a certificate is signed by a CA that is not trusted. We believe that such warnings only confuse most users; more useful would be a warning that indicates when there is a change in the distinguished name of a correspondent or even when the sender s signing key changes indicating a possible phishing attack.

Posted by iang at 07:16 PM | Comments (6) | TrackBack

February 10, 2005

First case of a digital signature repudiation?

Dan Kaminsky spotted this apparent repudiation of a "non-repudiable" digital signature. Even more interesting, it was over a Sarbanes-Oxley filing and certification, leading to the question of why the SEC thought it was OK for Penthouse founder Guccione to file a digitally signed document, and then claim his secretary did it? Is this like a get-out-of-trouble card for a Sarbanes-Oxley filing, or are we going to see digsig-fine-inflation until people stop using them?

Here's the article. You'll have to go to the site yourself to get the pictures. I'll put the URL at the end, just to make sure.

Penthouse's Guccione Settles with SEC

A $1 million dollar accounting problem caused big trouble for the former chief of the bare-all magazine.

Stephen Taub, CFO.com January 26, 2005

The Securities and Exchange Commission settled charges against Penthouse magazine's founder, Robert Guccione, who, without admitting or denying guilt, consented to the SEC's findings. The charge was filed against Penthouse, now known as PHSL Worldwide Inc., in the U.S. District Court for the Southern District of New York.

The commission also charged Penthouse International Inc. and two individuals formerly associated with the company with accounting fraud, reporting violations, and violations of the Sarbanes-Oxley Act certification rules.

According to the SEC’s complaint, in the quarter ended March 31, Penthouse improperly included as revenue $1 million received as an up-front payment in connection with a five-year Web site management agreement.

SEC officials asserted that the payment should not have been recognized in that quarter because the agreement was not actually signed until the following quarter. Further under generally accepted accounting principles, the $1 million payment should have been recognized as deferred revenue and amortized into income over the five-year life of the agreement.

By including the $1 million payment, Penthouse boosted its reported revenue by about 9 percent, to $12.72 million, and changed a quarterly net loss of $167,000 to a purported net profit of $828,000.

The SEC also asserts that the company's 10-Q bore an unauthorized electronic signature of Guccione -- who was Penthouse's principal executive officer and principal financial officer at the time. The signature indicated that Guccione had reviewed and signed the filing and the accompanying Sarbanes-Oxley certification. “This representation was false,” the SEC stated in its complaint.

http://www.cfo.com/article.cfm/3597911/c_3597966?f=home_todayinfinance

Posted by iang at 11:27 PM | Comments (0) | TrackBack

March 22, 2004

Reinventing Contract

This article by Professor Burke, of the Riga Graduate School of Law, explains how the common law tradition creates a framework of contracts based on negotiation by equal parties, and tries to squeeze all agreement into its framework. Yet, form contracts do not squeeze so readily, and only the presence of legal fictions - ones fraught with potential for flaky rulings - can make these form contracts work under the regime of the classical negotiated contract.

Standard form contracts are those written by a vendor, for their clients, to create the terms and conditions for some product.

The difference is in the absence of negotiation, consideration of terms, and meeting of the minds. A form contract is presented, and there is no discussion as to terms. Indeed, Burke says, the counterparty, the customer, has no necessary appreciation of the terms, and not even any especial knowledge that there are terms to consider!

Thus, as an inescapable conclusion, there can be no meeting of the minds in a form contract. Yet, form contracts are totally legal, totally acceptable, and people travel to work every day on them: we derive huge economic benefit from them, from bus and airline tickets to dry cleaning stubs, from insurance contracts to software licences...

In fact, Burke proposes that form contracts are 99% of all contracts (albeit with recognition that there is no empirical study to back this up). Whereas 99% of the tradition of contract law is negotiated contracts. This is, to my layman's eye, a huge criticism of the state of the law, but we must drag ourselves back to the here and now.

Ricardian Contracts are Form Contracts. In this sense they are like airline tickets. The user acts according to a purchase of a product. The product is a payment, a transaction, and the product is "purchased" as a whole entity, including the terms and conditions that apply.

What the user does not do is negotiate the contract. The user of a Ricardo transaction doesn't enter into a bargain, nor examine the terms, nor suggest their own terms. They simply buy a product called a payment.

Indeed, in a form contract, as there is no meeting of the minds, there is no symbol to record that event - so, there is no "need" of signatures.

We've known for a long time that the digital signature of the Issuer was ... an act of some pretence, in the sense that it was completely overdone: the hash entanglement, the publication of the document, and original sales create far more of a record of the intent of the Issuer than any mathematical nonsense dressed up as a signature. But we have puzzled over the question of the user's intent.

Surely, goes classical contract logic, we needed the user's signature to record their intent and act of entering into the contract? No, it appears not, if Burke's critique is to be taken at face value. This is a form contract, and the usage of the product is as much as we can expect, and as much as we need.

This discovery doesn't solve every unanswered question about Ricardian Contracts, but it does shift emphasis away from trying to craft a user's signature as a legal symbol (a task of some contortion, if you know your digsig politics). In the general case, the Issuer of a Ricardian Contract needs a signature from the user no more than an auditorium owner needs a signature from members of the audience, as they walk in.

Both are still covered by terms and conditions of the contract for admittance. It may be that a signature is collected for entrance to a shareholders' meeting, as opposed to a concert, but that's a matter of content, not form.

Posted by iang at 11:08 AM | Comments (2) | TrackBack

December 28, 2003

Repudiating non-repudiation

In a debate on the use of "non-repudiation" over on the cryptography list, Carl Ellison raises the point that only people can repudiate.

I have to agree with Carl and stress that the issue is not that the definition for "non-repudiation" is bad or whatever, but the word is simply out of place. Repudiation is an act of a human being. So is the denial of that or any other act, to take a word from one definition.

We can actually learn a lot more from the legal world here, in how they solve this dilemma. Apologies in advance, as what follows is my untrained understanding, derived from a legal case I was involved with in recent years [1]. It is an attempt to show why the use of the word "repudiation" will never help us and will always hinder us.

The (civil) courts resolve disputes. They do *not* make contracts right, or tell wrong-doers to do the right thing, as is commonly thought.

Dispute resolution by definition starts out with a dispute, of course. That dispute, for sake of argument, is generally grounded in a denial, or a repudiation.

One party - a person - repudiates a contract or a bill or a something.

So, one might think that it would be in the courts' interest to reduce the number of repudiations. Quite the reverse - the courts bend over backwards, sideways, and tie themselves in knots to permit and encourage repudiations. In general, the rule is that anyone can file *anything* into a court.

The notion of "non-repudiation" is thus anathema to the courts. From a legal point of view, we, the crypto community, will never make headway if we use this term [2]. What terms we should use, I suggest below, but to see that, we need to get the whole process of the courts in focus.


Courts encourage repudiations so as to encourage all the claims to get placed in front of the forum [3]. The full process that is then used to resolve the dispute is:

1. filing of claims, a.k.a. "pleadings",
2. presentation of evidence,
3. application of law to the evidence,
4. a reasoned ruling on 1 is delivered based on 2,3.

Now, here's where cryptographers have made the mistake that has led us astray. In the mind of a cryptographer, a statement is useless if it cannot be proven beyond a shred of doubt.

The courts don't operate that way - and neither does real life. In this, it is the cryptographers that are the outsiders [4].

What the courts do is to encourage the presentation of all evidence, even the "bad" stuff. (That's what hearings are, the presentation of evidence.)

Then, the law is applied - and this means that each piece of evidence is measured and filtered and rated. It is mulled over, tested, probed, and brought into relationship with all the other pieces of evidence.

Unlike no-risk cryptography, there isn't such a thing as bad evidence. There is, instead, strong evidence and weak evidence. There is stuff that is hard to ignore, and stuff that doesn't add much. But, even the stuff that adds little is not discriminated against, at least in the early phases.

And this is where the cryptography field can help: a digital signature, prima facie, is just another piece of evidence. In the initial presentation of evidence, it is neither weak nor strong.

It is certainly not "non-repudiable." What it is is another input to be processed. The digsig is as good as all the others, first off. Later on, it might become stronger or weaker, depending.

We cryptographers can help by assisting in the process of determining the strength of the evidence. We can do this in three ways, I think:

Firstly, the emphasis should switch from the notion of non-repudiation to the strength of evidence. A digital signature is evidence - our job as crypto guys is to improve the strength of that evidence, with an eye to the economic cost of that strength, of course.

Secondly, any piece of evidence will, we know, be scrutinised by the courts, and assessed for its strength. So, we can help the process of dispute resolution by clearly laying out the assumptions and tests that can be applied. In advance. In as accessible a form as we know how.

For example, a simple test might be that a receipt is signed validly if:

a. the receipt has a valid hash,
b. that hash is signed by a private key,
c. the signature is verified by a public key, paired with that private key.

Now, as cryptographers, we can see problems, which we can present as caveats, beyond the strict statement that the receipt has a valid signature from the signing key:

d. the public key has been presented by the signing party (person) as valid for the purpose of receipts,
e. the signing party has not lost the private key,
f. the signature was made based on best and honest intents...

That's where it gets murky. But, the proper place to deal with these murky issues is in the courts. We can't solve those issues in the code, and we shouldn't try. What we should do is instead surface all the assumptions we make, and list out the areas where further care is needed.

Thirdly, we can create protocols that bear in mind the concept of evidence. That means we use various techniques such as signed receipts, logs, sharing of records and chains of signatures to create pieces of evidence.

We use the careful techniques of protocol design to marshal sufficient evidence of strength to make it easy to resolve any questions; before they become disputes, and ideally, before they leave the protocol!

And, when these questions do become disputes, we try and make it easy (read: cheap) to present strong evidence to those resolving any dispute.

iang

[1] It was highly instructive, and I'd almost recommend all to get in trouble with the courts at least once in your lives, if only it wasn't so darn destructive of ones life!

[2] It's even worse than the signature. At least there is some resemblance between the process and result of a digital signature and a legal signature. With (non)-repudiation, however, cryptographers are saying that the entire meta-concept of the court is wrong.

[3] Courts actually have a rule, that, only claims made up front can be heard - so you had better get your repudiations up there in the beginning!

[4] This is a characteristic of the no-risk school of cryptography, but even economic cryptographers fall into this trap with regularity.

Posted by iang at 02:48 PM | Comments (4) | TrackBack