Financial Cryptography

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?

Why is is this blog secure? Because there is only one mode, and it is secure!

Anon asks:

> ian: I never understood why you insist on using HTTPS for the blog... maybe you can shed light ?

Fair question, and often I ask myself whether it is worth the extra effort. As succinctly as I can put it, it is because of the fundamental principle:

There is only one mode, and it is secure.

This principle is not so well understood in today's Internet security business, so I'll explain. Whenever a system has two modes, there is always weakness as it switches from one mode to another. In security systems, we get security weakness as we switch from unsecured mode to secured mode.

A very basic problem with security is that attackers are intelligent and active and users are distracted and passive. Not exactly dumb, but just paying attention to other things. So attackers will search out weaknesses, and users will not notice weaknesses, and therefore attacks at the weaknesses.

Then, attackers will attack at the switch in mode, and users won't really notice. Easy to say, but how does this work in practice? Consider browsing. You go to the website of your bank by typing the name into the google bar on the top right of google (ok, *you* might not, but you have a friend who will...) and clicking on the top result [1]. Or you could do it any number of other ways. Whichever, you end up at a website. Then you click around looking for the place to type your password and username.

The session started out "insecure", and ended up "secure". Hopefully. Normal users will pay attention at the beginning, but their attention wanes with each click. So in general, they won't notice when they switched into secure model. Which also means they won't notice who they switched too, which in turn leads to an easy attack: around the time the user is not paying attention, switch somewhere else that looks like what they expect.

Hence, phishing, in all its variations.

The fundamental flaw here is that we browse insecurely and then switch to secure mode for something important. We can eliminate a whole class of attacks here by being secure always. Never having to switch. Hence the principle; in that *if* you are doing anything that requires security, you are a million times better off if you *always* do everything secure [2].

Financial Cryptography is using HTTPS to remind people doing serious security work of that principle: you should design your systems to be always secure. Every time you click on the FC website and see that it is in HTTPS, I want you to remember that the application known as secure browsing is fundamentally broken, because it breaches the 3rd hypothesis: There is only one mode, and it is secure [3].

You, and your friend, are at risk because of that. To paraphrase an old saying, you enter a state of sin when you design a system with a security switch in it. It follows that, if we want to do anything that involves security on the web, then, everything should be in HTTPS, not just this blog. All blogs, all wikis, all websites, all the REST, everything.

[1] I was looking for an example, so I googled Bank of America. The first link took me straight to a https site (via a redirect). Outstanding!

Clicking around from the second link on google, I found that it switched me (via North Carolina) across to a login box in HTTPS with this site: https://businessconnect.ebanking-services.com/nubi/signin.aspx . Firefox says (oddly) "This web site does not supply identity information." .... but the certificate says it is Metavante Corporation ... ok, so this is a bad example, even I am totally confused by what is happening here...

[2] What "secure" means and how you do that are other questions that can only be answered with reference to the specific circumstances. E.g., for browsing, secure means that you are talking to the right site, and nobody else.

[3] How we got to this state of affairs, where practically everyone on the planet believes that insecure browsing is normal, should be considered as a research question.

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.

Historical copy of PGP 5.0i for sale -- reminder of the war we lost

Back in the 1990s, a group called the cypherpunks waged the crypto wars with the US government. They wanted easy access to crypto, the US government didn't want them to have it. RAH points to Sameer's blog:

The solution for my company, C2Net Software, Inc., was to develop an offshore development team and have them develop the software there. Other companies developed different strategies. Most opted to sell broken products to their overseas customers. One other company cared about the security of their customers. That company was PGP.

PGP chose a different strategy however. They published their source code as a book. The book was then exported, the contents of that book were then scanned in, and then a completely legal international version of PGP was born.

Sameer is selling his copy of PGP 5.0i, the book that was printed in the USA and exported in boxes to the international scanning project.

PGP 5.0i, on the other hand, was compiled from source code that was printed in a book (well, actually 12 books - over 6000 pages!). The books were exported from the USA in accordance with the US Export Regulations, and the pages were then scanned and OCRed to make the source available in electronic form.

This was not an easy task. More than 70 people from all over Europe worked for over 1000 hours to make the PGP 5.0i release possible. But it was worth it. PGP 5.0i was the first PGP version that is 100% legal to use outside the USA, because no source code was exported in electronic form.

The last 1% was done at HIP 1997, or hacking-in-progress, a Dutch open-air festival conducted once every 4 years. (You can see an early attempt at blogging here and here and a 2004 post.)

Lucky Green turned up with a box and ... left it lying around, at which point the blogging stopped and the work started. A team of non-Americans then spent around 2 days working through the last, unscanned and broken pages. There were about 20 at the peak, working in teams of 2 and 3 across all of HIP, swapping their completed files back at the cypherpunks tent. Somewhere around is a photo of the last file being worked through, with three well-known hackers on one keyboard.

It was uploaded around 3 in the morning, Sunday if I recall, as the party was winding down; some brave souls waited around for the confirmed download, but by 5am, only Sameer was still up and willing to download and compile a first international PGP 5.0.

The story has a sad ending. In the last months of 1999, the US government released the controls on exporting free and open cryptography. Hailed by all as a defeat, it was really a tactical withdrawal from ground that wasn't sustainable. The cypherpunks lost more: with the departure of their clear enemy, they dispersed over time, and emerging security and financial cryptography entrepreneurs lost our coolness factor and ready supply of cryptoplumbers. Lots of crypto projects migrated back to the US, where control was found by other means. The industry drifted back to insecure-practice-by-fiat. Buyers stopped being aware of security, and they were setup for the next failure and the next and the next...

Strategic victory went to the US government, which still maintains a policy of keeping the Internet insecure by suppressing crypto where and when it can. Something to remember if you ever get offered a nice public relations job in the DHS, or if you ever get phished.

Hypothesis #4 -- The First Requirement of Security is Usability

Duane points to a recent debate, something about DNSSEC and its added value, which resulted in this comment by one Thierry Moreau: DNNSEC is almost worthless! The reasons appear to be based on an analysis of three usage models, and each usage model heads for the rocks for one reason or other. Thierry points out that user #1 is not interested, user #2 is small, and user #3 will be not be allowed. The analysis is worth a read, as it is nicely laid out (regardless of whether you agree or not).

What is going wrong with DNSSEC? From the outside, the results are clear: it was never used. In my terms it breaches parts of my 4th hypothesis, which is, in short, "Usability is Number One." To start off with:

#4.1 Zero Users means Zero Security

The most common failure mode of any security protocol is not being used by users, at all.

There have been thousands of attempts at secure protocols in recent Internet times. Many did not get completed, many were completed but were rejected as too hard to use, and many great protocols missed the boat and were swamped by bad protocols. These are therefore all failures; their delivered security is zero. Zip, zilch, nada.

Perfect security, multiplied by zero users, always equals Zero security. Try it with any variation of zero you like, and any grade of security. Count up as many security projects as you like, and look at the very strong correlation: Security perfectly reaches zero with all known forms of mathematics, if it is has zero users.

Only a delivered protocol that protects and ships packets for actual, warm, live, talkative users can deliver security. A good protocol with some gaping holes will always outperform a perfect protocol that remains undelivered, in security terms. A good protocol in widespread use will generally outperform a better protocol that is poorly used.

Again simple mathematics tells us why: a protocol that is perfect that protects one person perfectly, is still limited to that one person. The mathematics of security says that is a one. If you can reduce your protocol's theoretical security from 100% to 99%, and get ten users, that then means you can reach 9.9, in delivered security to those ten users. Approximately. If you can reduce to 98%, but gain 100 users then your security reaches 98.

Security is as delivered to users, and is summed across them. Therefore, it goes up almost perfectly with the number of users. By far the biggest determinant of security is then the number of users that you can gain. Consider that first and foremost.

This result certainly applies to DNSSEC, and the hypothesis title of Usability may hint at why. Or not.

The Dutch show us how to make money: Peace and Cash Foundation

Sometime around 3 years back, banks started to respond to phishing efforts by putting in checks and controls to stop people sending money. This led to the emergence of a new business model that promised great returns on investment by arbitraging the controls, and has led to the enrichment of many! Now, my friends in NL have alerted me to the NVB's efforts to sell the Dutch on the possibilities.

Welcome to the Peace and Cash Foundation!

A fun few minutes, and even though it is in Dutch, the symbology should be understood. Does anyone have an English translation?

(Okay, you might not see the Peace and Cash Foundation by the time you click on the site, but another generation will be there to help you to well-deserved riches...)

BarCampBankLondon: alternative finance workshop

Thomas Barker sends this press release:

Innovators Gather in the City to Set Shape for Future of Finance

Contact: Thomas Barker
Email: tbarker(at)barcampbank[..]org

LONDON, UK, Monday June 2nd, 2008 - On Saturday July 5th, 2008, one of the most unusual conferences in the financial services industry, BarCampBankLondon (BCBL), will get underway at 9:30 AM near the heart of the City. BCB London follows the success of previous BarCampBanks in Paris, Seattle, San Francisco, New Hampshire and New York City. Ranging from interested students, to banking executives, to VCs, startup founders and internet technologists. BCBL is a forum where participants from diverse backgrounds can get together to discuss topics impacting the industry. It will attract thought leaders and innovators from as far away as America for an intense day of discussions on the future of financial services.

Event co-founder, Frederic Baud said "We wanted to get away from the typical event where a group of senior executives listen to PowerPoint slides and exchange business cards. This is really about getting together people who share a genuine interest in building the future." The event has no set speakers, agenda or sales pitches and getting in the door will only set you back £10. To ensure that the event is relevant to all those attending, the agenda will be discussed online (http://barcamp.org/BarCampBankLondon), then set by the participants on the morning of the event.

It might seem strange that an event like this has taken so long to reach London, a city often considered to be the global financial hub. Another organizer, Thomas Barker said "People might not immediately think of London as a tech cluster. But walking around the City, you can see hundred of software firms nestled in among the banks and lawyers. There's a lot happening here". So far, BCBL intends to discuss the topics of P2P lending, startup financing, mobile banking, personal finance management and micro-finance amongst others.

To attend BCBL, register online at http://bcblondon.eventbrite.com/ .

Sun Microsystems are generously hosting BCBL in their City offices. The event, which is organized by volunteers, welcomes participation from anyone who would like to help with logistics or spreading the word. Interested parties can contact Thomas Barker at tbarker [at]barcampbank,org, or Antony Evans at Antony (At) thestartupexchange D0t com.

About BarCampBank:

The aim of BarCampBank is to foster innovation and the creation of new business models in the world of banking and finance. The next BarCampBank after London will be held in Charleston, USA. For more information, please contact George Pasley at gpasley att gmail d0T com . The following one will be held in Vancouver, Canada. For more information, please contact Tim McAlpine at tmcalpine (a) currencymarketing AT ca .

# # #
If you'd like more information about his event, please contact Thomas Barker (contact information above) or Antony Evans (Antony _Att_ thestartupexchange . com)

Posted by iang at 06:54 AM | Comments (1) | TrackBack

Case Study 2: OpenSSL's patched-out randomness

In the aftermath of the OpenSSL failure due to a vendor patch (which bit the vendor badly...) there has been more analysis. Clearly, early attempts to describe this were flawed, and mine was no exception, as the precise failure was not well described.

I did miss out on one important thing, pointed out by Philipp Güring: when doing high-sec apps, it is necessary to mix in different sources, because we should assume that the lower layers will fail. But, while necessary, it is not sufficient. We still require to show that our mixed randoms are getting into the right place. Then, we need some form of testing strategy that shows this. I suggest:

1. all sources be set to some fixed X like zero, and then run many times, to show that the result is the same each time,
2. each source be singly varied, and then show that the result varies each time,
3. test each result for randomness,
4. read the code. (So, use simple code for this area.)

In addition to other's comments, I found this extremely useful, from David Brodbeck, posted in comments on EC:

In aviation it's common to talk about an "accident chain," the series of small mistakes that lead up to an incident. Breaking any one link in the chain would have stopped the accident from happening. That's kind of what happened here.

I suggest we incorporate the accident chain into the security lingo. We can guess that each mistake by itself was probably innocuous, otherwise we would have fixed it. Instead of the current 'best practices' of fingerpointing, it is then much better to document the chain of mistakes that led to the accident. And think about how you are going to deal with them. Ideally, be able to show that anyone component could fail completely, and disaster would not then follow.

Finally, as I mentioned, it's better to own the problem than to avoid it. I was heartened then to see that Eric Young wrote:

I just re-checked, this code was from SSLeay, so it pre-dates OpenSSL taking over from me (about 10 years ago, after I was assimilated by RSA Security).

So in some ways I'm the one at fault for not being clear enough about why 'purify complains' and why it was not relevant. Purify also incorrectly companied about a construct used in the digest gathering code which functioned correctly, but purify was also correct (a byte in a read word was uninitialised, but it was later overwritten by a shifted byte).

One of the more insidious things about Purify is that once its complaints are investigated, and deemed irrelevant (but left in the library), anyone who subsequently runs purify on an application linking in the library will get the same purify warning. This leads to rather distressed application developers. Especially if their company has a policy of 'no purify warnings'.

One needs to really ship the 'warning ignore' file for purify (does valgrind have one?).

I personally do wonder why, if the original author had purify related comments, which means he was aware of the issues, but had still left the code in place, the reviewer would not consider that the code did some-thing important enough to ignore purify's complaints.

So what we saw was a timebomb that had been ticking for around 10 years. As Ben Laurie mentioned, an awful lot has changed in our knowledge and available tools since then, and as mentioned above, the original code author has long since left the scene. Definately a case for avionics accident investigation. I wonder if they write books on that sort of stuff?