Financial Cryptography

Security Expertise from Cryptographers: the Signals of Hubris

Over on the crypto forum, an old debate restarted where some poor schmuck made the mistake of asking why CBC mode should not have an IV of all zeros?

For the humans out there, a "mode" is way of using a block cipher ("encrypts only a block") to encrypt a stream. CBC mode chains each block to each next block by feeding the results from the last to the next ("cipher-block-chaining"). But, we need an initial value (IV) to start the process. In the past, zeros were suggested as good enough.

The problem surfaces that if you use the same starting key, and the user sends the same packet, then the encrypted results will be the same (a block cipher being deterministic, generally). So we use a different IV for every different use of the secret key, in order to cause different results, and hide the same packet being sent. (There are also some other difficulties, but these are not only much more subtle, they are beyond my ability to write about, so I'll skip past them blithely.)

Back to the debate. Predictably, there was little controversy over the answer ("you can't do that!"), some controversy over the fuller answer (what to do), but also more controversy over the attitude. In short, the crypto community displayed what might be considered a severe case of hubris:

"If you don't know, then you had better employ a security expert who does!"

There are many problems with this. Here's some of them:

1. At a guess, designing secure protocols is 50% business, 40% software, 10% crypto. So when you say "employ a security expert" we immediately have the problem that security is many disciplines. A security expert might know a lot about cryptography, or he might know very little. What we can't reasonably expect is that a security expert knows a lot about everything.

We have to be cut some out, and as security -- the entire field -- only rarely and briefly depends on cryptography, it seems reasonable that your average security expert only knows the basics of cryptography.

Adi Shamir said in his misconceptions in cryptography:

By implementers: Cryptography solves everything, but:

• only basic ideas are successfully deployed
• only simple attacks are avoided
• bad crypto can provide a false sense of security

What then are the basics? Block ciphers are pretty basic. Understanding all the ins and outs of modes and IVs however is not. Where we draw the line is in knowing our own limitations, so therefore the original question ("what's wrong with IV of all zeros?") indicates quite good judgement.

2. But what about software? We can see it in the cryptographers' view:

"Just use a unique IV."

Although this sounds simple, it is a lot harder to implement than to say, and the person who gets to be responsible for the reality is the programmer. In glorious, painful detail.

Consider this: say you choose to put random numbers in the IV, and then you specify that the protocol must have a good RNG ("random number generator"). Then, how do you show that this is what actually happens? How can you show that the user's implementation has a good RNG? Big problem: you can't. And this has been an ignored problem for basically the entire history of Internet cryptography.

Dilbert on Randomness

This would suggest that if you are doing secure protocols, what you want is someone who knows more about software than cryptography, because you want to know the costs of those choices more than you want to know the snippety little details.

3. Unfortunately, cryptography has captured the attention as a critical element of security. Software on the other hands is less interesting; just ask any journalist.

Because of this, crypto has become a sort of rarified unchallengeable beast in technological society, an institution more displaying of religious beliefs than cold science. Mere software engineers can rarely debate the cryptographers as peers, even the most excellent ones (like Zooko, Hal Finney and Dani Nagy) who can seriously write the maths.

So while I suggest that software is more important to the end result than cryptography, the programmers still lose in the face of assumed superiority. "Employ someone better than you" smacks of false professionalism, guildmaking. It's simple enough economics; if we as a group can create an ethos like the medical industry, where we could become unchallenged authorities, then we can lock out competitors (who haven't passed the guild exam), and raise prices.

Unfortunately, this raises the chance to near certainty that we also lock out people who can point out when we are off the rails.

4. And, we can forget about the business aspects completely. That is, a focus on requirements is just not plausible for people who've buried themselves in mathematics for a decade, as they don't understand where the requirements come from. Talking about risk is a vague hand-wavy subject, better left alone because of its lack of absolute provability.

By way of example, one of the questions in the recent debate was

"you haven't heard of anyone breaking SD cards have you?"

From a business perspective this makes complete sense, it is a completely standard risk perspective with theory to back it up (albeit a simplification); from a cryptographer's perspective it is laughable.

Who's right? Actually, both perspectives have merit, and choosing the right approach is again the subject of judgement.

5. Hence, a strong knee-jerk tendency to fall-back to the old saws like the CIA of confidentiality, integrity and authentication. But, it is generally easy to show that CIA and similar things are nice for crypto school but a bad start in real life.

E.g., in the above debate, it turns out that the application in question is DRM -- Digital Rights Management. What do we know about DRM?

If anything has been learnt at massive cost over the last 10 years of failed efforts, it is that DRM security does not have to be strong. Rather it has to create a discrimination between those who will pay and those who won't. This is a pure business decision. And it totally blows away the C, confidentiality, in CIA.

Don't believe me? Buy an iPod. The point here is that if one analyses the market for music (or ringtones, or cell phones, apparently) then the last thing one cares about is being able to crack the crypto. If one analyses the market for anything, CIA turns out to be such a gross simplification that you can pretty much assume it to be wrong from the start.

6. If you've subscribed to the above, even partly, you might then be wondering how we can tell a good security expert from a bad one? Good question!

Even I find it difficult, and I design the stuff (not at the most experienced level, but way more than for the hobby level). It is partly for that reason that I name financial cryptographers on the blog: to develop a theory of just how to do this.

How is a manager who has no experience in this going to do pick from a room full of security experts, who mostly disagree with each other? Basically, you're stuffed, mate!

So where does that leave us? Steve Bellovin says that when we hire a security expert, we are hiring his judgement, not his knowledge of crypto. Which means knowing when to worry, and especially _when not to worry_, and I fully agree with that! So how then do we determine someone's judgement in security matters?

Here's a scratched-down emerging theory of signals of security judgement:

BAD: If someone says "you need to hire a security expert, because you don't know enough, and that could be dangerous" that's a red-flag.

GOOD: If they ask what the requirements are, that's good.

BAD: If they assume CIA before the requirements, that's bad.

GOOD: If they ask what the application is, then a big plus.

BAD: If they say "use a standard protocol" then that's bad.

GOOD: If they say "this standard protocol may be a good starting point" then that's good.

BAD: If they know what goes wrong when an IV is not perfect, that's a danger sign.

GOOD: If they know enough to say "we have to be careful of the IV" then that's good.

BAD: If they don't know what risk is, they cannot reduce your risk.

GOOD: If they know more software than crypto, that's golden.

Strongly oriented to weeding out those who know too much about cryptography, it seems.

Sadly, the dearth of security engineers who don't subscribe to the hubristic myths leaves us with an unfortunate result: the job is left up to you. This has been the prevalent result of so many successful Internet ventures that it is a surprise that it hasn't been more clear. I'm sufficiently convinced that I think it has reached the level of a Hypothesis:

"It's your job. Do it."

Hubris? Perhaps! It's certainly your choice to either do it yourself, or hand it over to a security expert, so let's hear your experiences!

e-gold founders indicted

Bob Hettinga found and forwarded the press release from the Washington DC courts:

A federal grand jury in Washington, D.C. has indicted two companies operating a digital currency business and their owners on charges of money laundering, conspiracy, and operating an unlicensed money transmitting business, Assistant Attorney General Alice S. Fisher of the Criminal Division and U.S. Attorney for the District of Columbia Jeffrey A. Taylor announced today.

The four-count indictment, handed down on April 24, 2007, and unsealed today, charges E-Gold Ltd; Gold & Silver Reserve, Inc.; and their owners Dr. Douglas L. Jackson, of Satellite Beach, Fla.; Reid A. Jackson, of Melbourne, Fla.; and Barry K. Downey, of Woodbine, Md., each with one count of conspiracy to launder monetary instruments, one count of conspiracy to operate an unlicensed money transmitting business, one count of operating an unlicensed money transmitting business under federal law and one count of money transmission without a license under D.C. law.

(Or here.) This is the next chapter in a long running saga. The e-gold investigation started sometime around 2002, with three primary agencies involved: IRS, FBI and USSS. The latter, the US Secret Service, has the original mission of protecting the currency, and hence their interest in money.

The actual charges are curiously not that interesting. Obviously, it is a money operation so there will always be a charge of Money Laundering, which in today's US courts is guilty by naming. Slightly less obviously, the charge of conspiracy just implies something else criminal was done by people acting together: and of course there are several people involved. So that charge simply succeeds if the others do, else it fails by definition.

Which leaves operating an unlicensed money transmitting business. This is the core charge. As we recall, this law came in in the aftermath of 9/11, when a Hawala was found to have transmitted one of the payments needed to finance the terrorist attack (the vast majority of the funds went through normal bank transfers). This then started a war on Hawalas, and the regulations were put in place * with a clear offer: license yourself as a money transmitter or face the consequences.

e-gold declined the offer. I recall that they argued they were not a money transmitter business because e-gold was not money, and the sales operation of Omnipay just used the banks to transmit the dollars back and forth. (This is from memory, these arguments were made in public in either the press or the mailing lists. ... Addendum: read Dr Jackson's response for more details on the position taken.)

I don't know about you, but that was a ludicrous position to take then, and now. It was pretty clear that the point was, come in from out of the wild wild west, or well go and hunt you down. To argue on a technicality like that was just insane, as courts will ignore such nonsense on the basis of a "reasonable man" test.

Is e-gold more or less in the money transmitting business? A reasonable man will say yes.

This characterises the extraordinary levels of arrogance of the e-gold founders. Because they had built a business that had seemingly escaped from the jaws of defeat and the evils of the banking cartel, they were right, God-blessed and destined to change the world. From their dramatic successes around 2000, there was a persistent belief in the righteousness of their mission, and an equal belief in the willingness of the courts to defend them. Because they were right!

Such hubris has to go down. Whatever we think about David versus Goliath stories, the US Government isn't happy to be taunted that way, and the competitors aren't going to let the USG proudly ignore the taunts. Consider all the banks in the US, and all the (licensed) money transmitters. And if that isn't enough, recall all the other countries in the world that suffered, and still suffer, the indignities of Ronald Reagan's war on drugs: every time there is a criticism about money laundering, all these players are going to keep banging the table about e-gold.

"Sort out your own house, first!" There is only one end to this story. A bad end.

Disclosure: I myself was closely engaged with e-gold in the years 1998 to 2000, and locked in court battles with them from 2001 to 2003. Before those battles, however, I argued that they should take no position that puts them up against (the, any) government. Luckily, e-gold filed my arguments in court, as evidence against me.

* Footnote on Law on Money Transmitters: historically the Hawala episode was just the excuse needed. The draft law had been circulating for some time, and had been inspired directly by the success of Paypal and e-gold in bypassing the normal banking regulations.

US moves to freeze Gold payment reserves

The gold community is a-buzz with the news ... first an announcement from BullionVault (no URL):

There have been growing stresses on our relationship with Brinks Inc, the US-owned vault operator, and it has become clear that they feel uncomfortable about continuing to vault BullionVault gold.

Why this might be so I am genuinely unable to say. Their exact reasoning has not been disclosed to us.

Fortunately, there is an excellent alternative available to us in ViaMat International, the largest Swiss-owned vault operator, and one which has a full quota of internationally located professional bullion vaults.

Swiss ownership suggests an independence from some of the pressures which Brinks may have found themselves operating under recently. Also you - our users - have chosen to vault 26 times as much gold in Switzerland as in the United States, so we believe this change will be both natural and welcome.

This is an echo of the old e-gold story, where different reputable vault companies handed the e-gold reserves around like it was musical chairs. BuillionVault is a new generation gold system, not encouraging payments but instead encouraging holding, buying and selling. It's not yet clear why they would be a threat.

But then, from 1mdc, a payment system:

ATTENTION

Friday Apr 27 2007 - 4AM UTC

It appears that a U.S. Government court order has forced e-gold(R) to close down or confiscate all of 1mdc's accounts. All of 1mdc account's have been closed at e-gold by order of the US Government.

Please note that it appears the accounts of a number of the largest exchangers and largest users of e-gold have also been closed or confiscated overnight: millions of Euros of gold have been held in this event. A couple of large exchanger's accounts have been shutdown.

If the confiscation or court order in the USA is reversed, your e-gold grams remaining in 1mdc will "unbail" normally to your e-gold account.

We suggest not panicking: more will be known on Monday when there will be more activity in the courts.

You CAN spend your 1mdc back and fore to other 1mdc accounts. 1mdc is operating normally within 1mdc. However you should be aware there is the possibility your e-gold will never be released from e-gold due to the court order.

Ultimately e-gold(R) is an entirely USA-based company, owned and operated by US citizens, so, as e-gold users we must respect the decisions of US courts and the US authorities regarding the disposition of e-gold. Even though 1mdc has no connection whstsoever to the USA, and most 1mdc users are non-USA, e-gold(R) is USA based.

You are welcome to email "team@1mdc.com", thank you.

Yowsa! That's heavy. And now, BullionVault's actions make perfect sense. Brinks probably heard rumour of happenings, and BullionVault are probably sweating off those pounds right now crossing the border with rucksacks of kg of yellow ballast.

It's worth while looking at how 1mdc worked, so as to understand what all the above means. 1mdc is simply a pure-play e-gold derivative system, in that 1mdc maintained one (or some) e-gold accounts for the reserve value, and then offered an accounting system in grams for spending back and forth.

1mdc then stands out as not actually managing and reserving in gold. Instead it manages e-gold ... which manages and reserves in gold. Now, contractually, this would be quite messy, excepting that the website has fairly generally made no bones of this: 1mdc is just e-gold, handled better.

So, above, 1mdc is totally uneffected! Except all the users who held e-gold there (in 1mdc) are now totally stuffed! Well, we'll see in time what the real story is, but when this sort of thing happens, there are generally some losers.

What then was the point of 1mdc? e-gold were too stuffy in many ways. One was that they charged a lot, another was the owners of e-gold were pretty aggressive characters, and they scared a lot of their customers away. Other problems existed which resulted in a steady supply of customers over to 1mdc, who famously never charged fees.

We could speculate that 1mdc was destined for sale at some stage. And I stress, I don't actually know what the point was. In contrast to the e-gold story, 1mdc ran a fairly tight ship, printed all of their news in the open, and didn't share the strategy beyond that.

It may appear then that the US has moved to close down competition. Other than pique at not being able to see the account holders, this appeared yesterday to be a little mysterious and self-damaging. Today's news however clarifies, which I'll try and write a bit more about in another entry:

...the Department of Justice also obtained a restraining order on the defendants to prevent the dissipation of assets by the defendants, and 24 seizure warrants on over 58 accounts believed to be property involved in money laundering and operation of an unlicensed money transmitting business.

Breached *and* sued -- is TJX the tipping point to liability alignment?

TJX is to be sued. The huge data breach by the US retailer is news covered elsewhere, as it is just a big one in a series of other like ones.

The suit will argue that TJX failed to protect customer data with adequate security measures, and that the Framingham, Mass.-based retail giant was less than honest about how it handled data.

What is interesting is that this could be the first time that someone big says "boo!" If the banks are now getting together to sue TJX for doing the wrong thing, this sets an interesting precedence: the banks say (presumably) that TJX was negligent and has done damages.

If the courts can show this is worth remedy, then the reverse is possible too. There are other suits possible. If the banks lose the data, then maybe they should be sued? If Microsoft's OS is shown to be insecure and susceptible to lost data, then maybe it should be sued? Or the banks that quite happily permitted it to be used, again? If someone pushes a particular product for commercial purposes (such as a firewall, a secure token, an encryption protocol, or just advice...) and it is shown to be materially involved in a breach, maybe the pusher needs to be sued?

What would this mean? A lot of suits, is one thing, such as is being readied against Paypal. A lot of money wasted, and the lawyers get richer. Some banks, some suppliers, some pushers and some users might modify their behaviour. Others might just get more defensive.

That may be bad ... but what's our alternative?

Suppliers and sellers of bad products have not been punished. Neither have buyers of bad products. Leaving aside the sense of blame and revenge, where is the feedback loop that tells a company that "buying that was wrong, that hurts?" Where is the message that says "you shouldn't use that software for online banking" to the user?

To address this lack of feedback, lack of confirmed danger, many have suggested government action. But, other than the spectacular exception of the SB1386 data breach disclosure law, most government laws and interventions have made matters worse, not better.

Economists like those going to WEIS2007 have suggested many things: Align the incentives, share more breach information amongst victims, make software vendors liable, etc etc. I suspect that one common rejoinder here is that the very economics that explains the problem often gives clues as to why it isn't solved.

Some mad crypto people have even suggested designing security into the system in the first place. Yet other fruitcakes have said that designing the wrong security in was what got us to where we are now...

What doesn't seem clear from an outside, global, society perspective is ... what to do?! None of those approaches are going to "just work," even if they are adopted.

However, the liabilities (growing) and the interests (diverging) are going to be balanced and aligned, one way or another. The Internet security world today is out of balance, unsustainable in its posture.

Here's my prediction: At some point we do reach a tipping point, and at that point the suits start.

However, predicting re-balancing-by-suits has been a little like predicting the collapse of the dollar in the new not-quite-global-currency regime: when it did happen, we were caught by surprise. And then it bounced back again...

So, no dates on that prediction. Let's watch for TJX copies.

The Begining of Governance - the Egyptian Accountants

Governance is about protecting the assets of the owner. Here's an anecdote on an early development in Governance, that reflects the arisal of robust accounting and predicts redundant computing:

IN THE BEGINNING

It’s said that accountants’ predecessors were the scribes of ancient Egypt, who kept the pharaohs’ books. They inventoried grain, gold and other assets. Unfortunately, some fell victim to temptation and stole from their leader, as did other employees of the king. The solution was to have two scribes independently record each transaction (the first internal control). As long as the scribes’ totals agreed exactly, there was no problem. But if the totals were materially different, both scribes would be put to death. That proved to be a great incentive for them to carefully check all the numbers and make sure the help wasn’t stealing. In fact, fraud prevention and detection became the royal accountants’ main duty.

Accounting is both a mundane tool for telling you how much you have, and a critical tool for stopping that "how much" from shrinking through theft. Hence, it is a Governance tool as well; double-entry accounting is also a tool to achieve a governance feature, by the magical trick of clearly identifying errors and separating them from intent.

In the absence of double entry, the Egyptians solved the errors problem using redundant computers. Just like today's designs for redundant computers, errors caused the shutdown of the system, although it seems that Egyptian designs for redundant computers did not advance to voting and quorum systems.

Counting Chickens at eTrade, bankruptcy in Europe, and costs in America

Gunnar Peterson posts:

Identity Chickens Coming Home to 8 Figure Roost

Reason number 2,503,201 why 1995 security architectures based on SSL, network firewalls, and a prayer are not good enough any more. Etrade's 10Q filing (hat tip Dan Geer):

Other expenses increased 97% to $45.7 million and 55% to $101.9 million for the three and nine months ended September 30, 2006, respectively, compared to the same periods in 2005. These increases were primarily due to fraud related losses during the third quarter of 2006 of $18.1 million, of which $10.0 million was identity theft related. The identity theft situations arose from recent computer viruses that attacked the personal computers of our customers, not from a breach of the security of our systems. We reimbursed customers for their losses through our Complete Protection Guarantee. These fraud schemes have impacted our industry as a whole. While we believe our systems remain safe and secure, we have implemented technological and operational changes to deter unauthorized activity in our customer accounts.

Over on EC I suggested that the cost depends on whether you are left or right of the Atlantic. In Europe, the Data Directive mandates fines, I was told it was around 25-50 thousand Euros per record lost . Lose your database, file for bankruptcy.

(OK, so I make this claim. I heard it in a pub... I'd better check on it!)

While we're counting cost, if not coup, here's some US numbers, finally with some serious if unconfirmed attention by Forrester Research:

The average security breach can cost a company between $90 and $305 per lost record, according to a new study from Forrester Research. The research firm surveyed 28 companies that had some type of data breach.

"After calculating the expenses of legal fees, call centers, lost employee productivity, regulatory fines, stock plummets, and customer losses, it can be dizzying, if not impossible, to come up with a true number," wrote senior analyst Khalid Kark in the report. "Although studies may not be able to determine the exact cost of a security breach in your organization, the loss of sensitive data can have a crippling impact on an organization's bottom line, especially if it is ill-equipped, and it's important to be able to make an educated estimate of its cost."

the plan to save Paypal: Skype revealed...

Dani spots:

From within the Skype client, there's a new choice among the forms of communication that a Skype user can initiate with a contact. In addition to being able to chat, make a VoIP call, send files and other contacting information, Skype users can now elect to send another Skype user money via PayPal. Skype and PayPal are both subsidiaries of eBay. So, now, we're beginning to see the bigger picture come together at eBay.

Basically, the mystery of why eBay thought Skype was valuable is now revealed. There was no apparent synergy between chat and auctions, and in fact Skype could be a danger to the centralised auctions model.

The answer was elsewhere, in financial cryptography: Paypal, also owned by eBay, was hurting for fraud. To do real hard payments, we've known for ever that we need a real hard client. As fraud was already hard-baked into Paypal due to early, convenient but bad decisions, improving the Paypal fraud problem required drastic steps.

The first drastic step is to move to a hard client. Skype is the best choice in the world today, as it has a lot of security built in through its crypto, it protects itself from attacks on the local client machine, and it has an already well-grown user base across major platforms. Putting money into Skype is something that any FCer could do; whereas fixing Paypal is a real challenge.

So the plan is to migrate Paypal into Skype. (What took them so long?) This has other ramifications as it means that in time, Skype will become an identity platform. Paypal money is far too identity-driven at this stage to wind back its exposure to the classical regulatory money system, so Skype has to mold to suit.

The good days of Skype privacy might be then over, as identity nexus will be demanded and stored in a US datawarehouse, available at a price. The good news is that now that the model is proven, others can come along and build it. The bad news is that those of us who did build it (Ricardo for example does chat/IM and hard payments in the same infrastructure) will never be able to catch up with the user base.

Our security sucks. Why can't we change? What's wrong with us?

Adam over at EC joined the fight against the disaster known as Internet Security and decided Choicepoint was his wagon. Mine was phishing, before it got boring.

What is interesting is that Adam has now taken on the meta-question of why we didn't do a better job. Readers here will sympathise. Read his essay about how the need for change is painful, both directly and broadly:

At a human level, change involves loss and and the new. When we lose something, we go through a process, which often includes of shock, anger, denial, bargaining and acceptance. The new often involves questions of trying to understand the new, understanding how we fit into it, if our skills and habits will adapt well or poorly, and if we will profit or lose from it.

Adam closes with a plea for help on disclosure :

I'm trying to draw out all of the reasons why people are opposed to change in disclosure habits, so we can overcome them.

I am not exactly opposed but curious, as I see the issues differently. So in a sense, deferring for a moment a brief comment on the essay, here are a few comments on disclosure.

1. Disclosure is something that is very hard to isolate. SB1386 was a big win, but it only covered the easy territory: you, bad company, know the victim's name, so tell them.
2. Disclosure today doesn't cover what we might call secondary disclosure, which is what Adam is looking for. As discussed Schechter and Smith, and in my Market for Silver Bullets:

   Schechter & Smith use an approach of modelling risks and rewards from the attacker's point of view which further supports the utility of sharing information by victims:

   Sharing of information is also key to keeping marginal risk high. If the body of knowledge of each member of the defense grows with the number of targets attacked, so will the marginal risk of attack. If organizations do not share information, the body of knowledge of each one will be constant and will not affect marginal risk. Stuart E. Schechter and Michael D. Smith "How Much Security is Enough to Stop a Thief?", Financial Cryptography 2003 LNCS Springer-Verlag.

   Yet, to share raises costs for the sharer, and the benefits are not accrued to the sharer. This is a prisoner's dilemma for security, in that there may well be a higher payoff if all victims share their experiences, yet those that keep mum will benefit and not lose more from sharing. As all potential sharers are joined in an equilibrium of secrecy, little sharing of security information is seen, and this is rational. We return to this equilibrium later.

3. Disclosure implies the company knows what happens. What if they don't?
4. Disclosure assumes that the company will honestly report the full story. History says they won't.
5. Disclosure of the full story is only ... part of the story. "We lost a laptop." So what? "Don't do that again..." is hardly a satisfactory, holistic or systemic response to the situation.

   (OK, so some explanation. At what point do we forget the nonsense touted in the press and move on to a real solution where the lost data doesn't mean a compromise? IOW, "we were given the task of securing all retail transactions......")

So, while I think that there is a lot to be said about disclosure, I think it is also a limited story. I personally prefer some critical thought -- if I can propose half a dozen solutions to some poor schmuck company's problems, why can't they?

And it is to that issue that Adam's essay really speaks. Why can't we change? What's wrong with us?

Does non-profit mean non-governance? Evidence from the fat, rich and naive business sector

I've previously blogged on how the non-profit sector is happy hunting grounds for scams, fraud, incentives deals and all sorts of horrible deals. This caused outrage by those who believe that non-profits are somehow protected by their basic and honest goodness. Actually, they are fat, happy and ripe for fraud.

The basic conditions are these:

• lots of money
• lots of people from "I want to do good" background
• little of the normal governance is necessary

Examples abound, if you know how to look. Coming from a background of reading the scams and frauds that rip apart the commercial sector, seeing it in the non-profit sector is easy, because of the super-fertile conditions mentioned above.

Here's one. In New York state in the US of A, the schools have been found taking incentives to prefer one lender over another for student loans.

[State Attorney-General] Cuomo has sent letters to and requested documents from more than a hundred schools for information about any financial incentives the schools or their administrators may have derived from doing business with certain lenders, such a gifts, junkets, and awards of stock.

A common practice exposed by Cuomo is a revenue-sharing agreement, whereby a lender pays back a school a fixed percentage of the net value loans steered its way. Lenders particularly benefit when schools place them on a short list of “preferred” lenders, since 3,200 firms nationwide are competing for market share in the $85 billion a year business.

Here's an inside tip that I picked up on my close observance of the mutual funds scandal, also brought by then NY-AG Elliot Spitzer (now Governor, an easy pick as he brought in $1.5bn in fines). If the Attorney-General writes those letters, he already has the evidence. So we can assume, for the working purposes of a learning exercise, that this is in fact what is happening.

There's lots of money ($85Bn). The money comes from somewhere. It can be used in small incentives to steer the major part in certain directions.

To narrow the options, most schools publish lists of preferred lenders for both government and private loans. They typically feature half a dozen lenders, but they might have only one. Students should always ask if the school is getting any type of payment or service from lenders on the list.

To get a loan, schools must certify that you are qualified. By law, schools can't refuse to certify a loan, nor can they cause "unreasonable delays," because you choose a nonpreferred lender. That said, many schools strongly discourage students from choosing a nonpreferred lender.

...

The University of North Carolina at Chapel Hill tells students on a form that if they choose a lender other than the school's sole preferred lender for Stafford loans, "there will be a six-week delay in the processing of your loan application" because it must be processed manually.

How do we address this? If we are a non-profit, then we can do these things:

• pick a very solid mission.
• build an environment that supports that mission, down to the cellular level.
• create an open disclosure policy which allows others to help us pick up drift.
• especially, create a solid framework for all "deals."
• put together a team that knows governance.

It's not so exceptional. Some schools got it:

Thirty-one other schools joined Penn and NYU in adopting a code of conduct that prohibits revenue-sharing with lenders, requires schools to disclose why they chose preferred lenders, and bans financial aid officers and other school officials from receiving more than nominal gifts from lenders.

Clues in bold. How many has your big fat, rich open source non-profit got? I know one that has all of the first list, and has none of the second.

H3 - there is only one mode, and it is secure

Some time ago, I used Thunderbird as a foil for introducing a hypothesis of mine:

There is only one mode, and it is secure.

Thunderbird, although long suffering and unfairly maligned, is a perfect example of how a security application fails to deliver security, because it believes there are "modes" and a user must "enable modes" in order to get security. It is, in the case of Thunderbird, and practically all S/MIME products, a disaster, because it reduces takeup to the numbers that don't permit any valuable market feedback to develop.

Here, then is Hypothesis #3 all written out in simple, direct form.

#3 There is only one Mode, and it is Secure.

Good Protocols bootstrap into secure mode, immediately. On first time starting up, the protocol goes into secure mode. From there on, it only gets better.

There is no insecure mode. No button to turn off, no feature to forget, no way to trick the application.

There should be no necessary setup by the user. If a public key is needed, make it. If the other side needs a secret key, send it. If you need a password, invent it and suggest the user replaces it, don't ask for it and block the action.

It should take an Act of God to start up in anything but the best possible security you can manage. A Presidential Order doesn't cut it. Make your protocol immorally promiscuous and your users will thank you, even if your reputation will take a dive for about 5 years. Don't worry, your users will outlive their users.

In practice, a perfect start-up is impossible, and we do not let a perfect theory be the enemy of a good protocol. Your protocol should leap into life with joy and abandon, and reward your users with instantly secure communication. Let an expert add some extra features if they want to get that warm gooey feeling of no-risk security, but never let him tell you that near enough isn't good enough. Instead, send him paddling over to a committee.

The above says what to do, but it doesn't say why. Let's talk about why.

It's all about take-up: In the building and especially the deployment of a secure protocol, every time we present a choice to the user, we face the binary destruction of our market share. To our poor, overloaded and easily distracted user, if there are two modes, and if everything is equal, she has a 50% chance of turning off the security.

Actually, things aren't equal, and it is much worse than 50%. Some brief examples:

• In crypto mode, we have to talk to someone, and they have to select crypto as well. Divide by 2 for Alice, and 2 for Bob (draw it in a 2 X 2 table, if you like). Keep dividing for everyone else we want to talk to, of course...
• In S/MIME, you can only deliver the keys if you sign the email. How do you sign? Oh, you have to turn that on (divide by 2). Hmmm, and what does that mean, to sign? (Divide by 2.) Well, it's undefined, or it's the same as a human signature, or it's not the same, or .... (divide by 2). And anyway, don't lawyers say "don't sign anything you aren't fully sure of?" (Divide by 2.)

  (Thunderbird now permits encryption *without signing* so it is possible to do a simple "signed nonsense message" to send your key, and avoid the trauma of the above paragraph. This is a big win, as before it was unprofessional and potentially dangerous to recommend S/MIME.)



• But people still have to add certificates .... and they still have to get the certs from somewhere ... else. The number of steps involved is more than the digits on our hands, so divide by 2, until you run out of fingers.


• If they have two email addresses, guess what? The certs won't work as the other side rejects them. (Divide by 2.). It isn't possible to use one cert for two email addresses. Why? I have no idea, but divide by two, as everyone has more than one email address.

I could go on. All these problems have solutions, of course, if you are serious about that sort of thing. Or you could take another tack and sweep all the problems away, by simply employing H3:

There is only one mode, and it is secure.

H3 says "be kind to your users," and don't ask them to turn off your software. H3 suggests "be kind to your shareholders," and don't ask them to apply the maths of binary destruction to the predicted user base in your business plan.

Threatwatch: MITB spotted: MITM over SSL from within the browser

A long awaited browser MITB attack -- in essence an MITM against SSL launched within the browser -- has been spotted (by Lynn) in Netherlands:

...customers opened an email attachment that resulted in a virus being executed on their machines. This virus changed their browsers' behaviour so when they went to open the real ABN Amro online banking site, they were instead re-directed to a spoof site.

The customers then typed in their passwords, which the attacker in turn used to access the bank's real Web site. The customer's own transactions were passed along to the real site, so they didn't notice anything wrong right away, while the attacker simultaneously made their own fraudulent transactions using the bank's urgent payment feature.

ABN Amro has issued its customers with two-factor authentication tokens for several years. But the man-in-the middle attack gets around this security measure by passing the ever-changing part of the password from the token to the bank along with the never-changing part - essentially piggybacking on a legitimate log-in.

Now, if it has been spotted here, it has been going on for some time. The first signs seen of an attack on SSL were late 2004. In essence it was still an uneconomic attack, but the proof of concepts were there. What remains to be seen is whether we are about to see a large scale shift into browser MITM attacks (known as Man-in-the-Browser) or whether we are seeing only tentative experimentation.

Meanwhile, over at Mozilla, "our man in the SSL/UI security team" Johnath is trying to draft up a proposal to work with Firefox. State of play so far:

Creating a simple UI to repair the padlock is no easy matter. EV is a complicating factor in that we need at least 3 states, and that means we need more than 3. This ain't new, but it is easier said than done.

Further, nobody has any hope that EV changes anything. Firstly, it is very confusing, too small, rare, and ultimately spoofable. So people are looking to Mozilla to see whether it will break away and start working on the far stronger user-bank relationship, directly, a.k.a Petnames and Zooko's Triangle and all that.

Maybe. As Gervase does not tire of pointing out, users won't do that. Worse, the above attack slices its way through both of those approaches, because it changes the browser from the inside.

The number of balls in the air is now too many. We've all noticed the migration away from Microsoft to Mac because of security failures. (The press worms bury deeply into the wet soil on this one.) Will there be a wholesale migration away from online banking as all browsers are declared no more solid than swiss cheese in a fondue?

This was what the European banks were worried about when we reported MITB earlier in 2006. One year later there has been no epidemic, and that gave them time to respond. Hopefully they are ready. Chances are, nobody else has or is. To live in interesting times...