Financial Cryptography

Cash seizure is a thing - maybe this picture will convince you

There are many many people who do not believe that the USA police seize cash from people and use it for budget. The system is set up for the benefit of police - budgetary plans are laid, you have no direct recourse to the law because it is the cash that defends itself, the proceeds are carved up.

Maybe this will convince you - if cash seizure by police wasn't a 'thing' we wouldn't need this chart:

Training Day 2: starring Bridges & Force

Readers might have probably been watching the amazing story of the Bridges & Force arrests in USA. It's starting to look much like a film, and the one I have in mind is this: Training Day.

In short: two agents were sent in to bring down the Silk Road website for selling anything (guns, drugs, etc). In the process, the agents stole a lot of the money. And in the process, went on a rampage through the Bitcoin economy robbing, extorting, and manipulating their way to riches.

You can't make this up. Worse, we don't need to. The problem is deep, underlying and demented within our society. We're going to see much more of it, and the reason we know this is that we have decades of experience in other countries outside the OECD purview.

This is our own actions coming back to destroy us. In a nutshell here it is, here is the short story that gets me on the FATF's blacklist and you too if you spread it:

In the 1980s, certain European governments got upset about certain forms of arbitrage across nations by multinationals and rich folk. These people found a ready consensus with others in policing work who said that "follow the money" was how you catch the really bad people, a.k.a. criminals. Between these two groups of public servants they felt they could crack open the bank secrecy that was protecting criminals and rich people alike.

So the Anti Money Laundering or AML project was born, under the aegis of FATF or financial action task force, an office created in Paris under OECD. Their concept was that they put together rules about how to stop bad money moving through the system. In short: know your customer, and make sure their funds were good. Add in risk management and suspicious activity reporting and you're golden.

On passing these laws, every politician faithfully promised it was only for the big stuff, drugs and terrorism, and would never be used against honest or wealthy or innocent people. Honest Injun!

If only so simple. Anyone who knows anything about crime or wealth realises within seconds that this is not going to achieve anything against the criminals or the wealthy. Indeed, it may even make matters worse, because (a) the system is too imperfect to be anything but noise, (b) criminals and wealthy can bypass the system, and (c) criminals can pay for access. Hold onto that thought.

So, if the FATF had stopped there, then AML would have just been a massive cost on society. Westerners would paid basis points for nothing, and it would have just been a tool that shut the poor out of the financial system; something some call the problem of the 'unbanked' but that's a subject for another day (and don't use that term in my presence, thanks!). Criminals would have figured out other methods, etc.

If only. Just. But they went further.

In imposing the FATF 40 recommendations (yes, it got a lot more complicated and detailed, of course) everyone everywhere everytime also stumbled on an ancient truth of bureaucracy without control: we could do more if we had more money! Because of course the society cost of following AML was also hitting the police, implementing this wonderful notion of "follow the money" cost a lot of money.

Until someone had the bright idea: if the money is bad, why can't we seize the bad money and use it to find more bad money?

And so, it came to pass. The centuries-honoured principle of 'consolidated revenue' was destroyed and nobody noticed because "we're stopping bad people." Laws and regs were finagled through to allow money seized from AML operations to be then "shared" across the interested good parties. Typically some goes to the local police, and some to the federal justice. You can imagine the heated discussions about percentage sharing.

What could possibly go wrong?

Now the police were empowered not only to seize vast troves of money, but also keep part of it. In the twinkling of an eye, your local police force was now incentivised to look at the cash pile of everyone in their local society and 'find' a reason to bust. And, as time went on, they built their system to be robust to errors: even if they were wrong, the chances of any comeback were infinitesimal and the take might just be reduced.

AML became a profit center. Why did we let this happen? Several reasons:

1. It's in part because "bad guys have bad money" is such a compelling story that none dare question those who take "bad money from bad guys."

Indeed, money laundering is such a common criminal indictment in USA simply because people assume it's true on the face of it. The crime itself is almost as simple as moving a large pot of money around, which if you understand criminal proceedings, makes no sense at all. How can moving a large pot of money around be proven as ML before you've proven a predicate crime? But so it is.

2. How could we as society be so stupid? It's because the principle of 'consolidated revenue' has been lost in time. The basic principle is simple: *all* monies coming into the state must go to the revenue office. From there they are spent according to the annual budget. This principle is there not only for accountability but to stop the local authorities becoming the bandits The concept goes back all the way to the Magna Carta which was literally and principally about the barons securing the rights to a trial /over arbitrary seizure of their wealth/.

We dropped the ball on AML because we forgot history.

So what's all this to do with Bridges & Force? Well, recall that thought: the serious criminals can buy access. Which of course they've been doing since the beginning, the AML authorities themselves are victims to corruption.

As the various insiders in AML are corrupted, it becomes a corrosive force. Some insiders see people taking bribes and can't prove anything. Of course, these people aren't stupid, these are highly trained agents. Eventually they work out how they can't change anything and the crooks will never be ousted from inside the AML authorities. And they start with a little on the side. A little becomes a lot.

Every agent in these fields is exposed to massive corruption right from the start. It's not as if agents sent into these fields are bad. Quite the reverse, they are good and are made bad. The way AML is constructed it seems impossible that there could be any other result - Quis custodiet ipsos custodes? or Who watches the watchers?

Remember the film Training Day ? Bridges and Force are a remake, a sequel, this time moved a bit further north and with the added sex appeal of a cryptocurrency.

But the important things to realise is that this isn't unusual, it's embedded. AML is fatally corrupted because (a) it can't work anyway, and (b) they breached the principle of consolidated revenue, (c) turned themselves into victims, and then (d) the bad guys.

Until AML itself is unwound, we can't ourselves - society, police, authorities, bitcoiners - get back to the business of fighting the real bad guys. I'd love to talk to anyone about that, but unfortunately the agenda is set. We're screwed as society until we unwind AML.

Google's bebapay to close down, Safaricom shows them how to do it

In news today, BebaPay, the google transit payment system in Nairobi, is shutting down. As predicted in this blog, the payment system was a disaster from the start, primarily because it did not understand the governance (aka corruption) flow of funds in the industry. This resulted in the erstwhile operators of the system conspiring to make sure it would not work.

How do I know this? I was in Nairobi when it first started up, and we were analysing a lot of market sectors for payments technology at the time. It was obvious to anyone who had actually taken a ride on a Matatu (the little buses that move millions of Kenyans to work) that automating their fares was a really tough sell. And, once we figured out how the flow of funds for the Matatu business worked, from inside sources, we knew a digital payments scheme was dead on arrival.

As an aside there is a play that could have been done there, in a nearby sector, which is the tuk-tuks or motorbike operators that are clustered at every corner. But that's a case-study for another day. The real point to take away here is that you have to understand the real flows of money, and when in Africa, understand that what we westerners call corruption means that our models are basically worthless.

Or in shorter terms, take a ride on the bus before you decide to improve it.

Meanwhile, in other news, Safaricom are now making a big push into the retail POS world. This was also in the wings at the time, and when I was there, we got the inside look into this field due to a friend who was running a plucky little mPesa facilitation business for retails. He was doing great stuff, but the elephant in the room was always Safaricom, and it was no polite toilet-trained beast. Its reputation for stealing other company's business ideas was a legend; in the payment systems world, you're better off modelling Safaricom as a bank.

Ah, that makes more sense... You'll note that Safaricom didn't press over-hard to enter the transit world.

The other great takeway here is that westerners should not enter into the business of Africa lightly if at all. Westerners' biggest problem is that they don't understand the conditions there, and consequently they will be trapped in a self-fulfilling cycle of western psuedo-economic drivel. Perhaps even more surprising, they also can't turn to their reliable local NGOs or government partners or consultancies because these people are trained & paid by the westerners to feed back the same academic models.

How to break out of that trap economically is a problem I've yet to figure out. I've now spent a year outside the place, and I can report that I have met maybe 4 or 5 people amongst say 100 who actually understand the difference? Not a one of these is employed by an NGO, aid department, consultant, etc. And, these impressive organisations around the world that specialise in Africa are in this situation -- totally misinformed and often dangerously wrong.

I feel very badly for the poor of the world, they are being given the worst possible help, with the biggest smile and a wad of cash to help it along its way to failure.

Which leads me to a pretty big economic problem - solving this requires teaching what I learnt in a few years over a single coffee - can't be done. I suspect you have to go there, but even that isn't saying what's what.

Luckily however the developing world -- at least the parts I saw in Nairobi -- is now emerging with its own digital skills to address their own issues. Startup labs abound! And, from what I've seen, they are doing a much better job at it than the outsiders.

So, maybe this is a problem that will solve itself? Growth doesn't happen at more than 10% pa, so patience is perhaps the answer, not anger. We can live and hope, and if an NGO does want to take a shot at the title, I'm in for the 101th coffee.

Reset the Net. Don't ask for your privacy. Take it back.

How to make scientifically verifiable randomness to generate EC curves -- the Hamlet variation on CAcert's root ceremony

It occurs to me that we could modify the CAcert process of verifiably creating random seeds to make it also scientifically verifiable, after the event. (See last post if this makes no sense.)

Instead of bringing a non-deterministic scheme, each participant could bring a deterministic scheme which is hitherto secret. E.g., instead of me using my laptop's webcam, I could use a Guttenberg copy of Hamlet, which I first declare in the event itself.

Another participant could use Treasure Island, a third could use Cien años de soledad.

As nobody knew what each other participate was going to declare, and the honest players amongst did a best-efforts guess on a new statically consistent tome, we can be sure that if there is at least one honest non-conspiring party, then the result is random.

And now verifiable post facto because we know the inputs.

Does this work? Does it meet all the requirements? I'm not sure because I haven't had time to think about it. Thoughts?

A very fast history of cryptocurrencies BBTC -- before Bitcoin

Before Bitcoin, there was cryptocurrency. Indeed, it has a long and deep history. If only for the lessons learnt, it is worth studying, and indeed, in my ABC of Bitcoin investing, I consider not knowing anything before the paper as a red flag. Hence, a very fast history of what came before (also see podcasts 1 and 2).

The first known (to me) attempt at cryptocurrencies occurred in the Netherlands, in the late 1980s, which makes it around 25 years ago or 20BBTC. In the middle of the night, the petrol stations in the remoter areas were being raided for cash, and the operators were unhappy putting guards at risk there. But the petrol stations had to stay open overnight so that the trucks could refuel.

Someone had the bright idea of putting money onto the new-fangled smartcards that were then being trialled, and so electronic cash was born. Drivers of trucks were given these cards instead of cash, and the stations were now safer from robbery.

At the same time the dominant retailer, Albert Heijn, was pushing the banks to invent some way to allow shoppers to pay directly from their bank accounts, which became eventually to be known as POS or point-of-sale.

Even before this, David Chaum, an American Cryptographer had been investigating what it would take to create electronic cash. His views on money and privacy led him to believe that in order to do safe commerce, we would need a token money that would emulate physical coins and paper notes. Specifically, the privacy feature of being able to safely pay someone hand-to-hand, and have that transaction complete safely and privately.

As far back as 1983 or 25BBTC, David Chaum invented the blinding formula, which is an extension of the RSA algorithm still used in the web's encryption. This enables a person to pass a number across to another person, and that number to be modified by the receiver. When the receiver deposits her coin, as Chaum called it, into the bank, it bears the original signature of the mint, but it is not the same number as that which the mint signed. Chaum's invention allowed the coin to be modified untraceably without breaking the signature of the mint, hence the mint or bank was 'blind' to the transaction.

All of this interest and also the Netherlands' historically feverish attitude to privacy probably had a lot to do with David Chaum's decision to migrate to the Netherlands. When working in the late 1980s at CWI, a hotbed of cryptography and mathematics research in Amsterdam, he started DigiCash and proceeded to build his Internet money invention, employing amongst many others names that would later become famous: Stefan Brands, Niels Ferguson, Gary Howland, Marcel "BigMac" van der Peijl, Nick Szabo, and Bryce "Zooko" Wilcox-Ahearn.

The invention of blinded cash was extraordinary and it caused an unprecedented wave of press attention. Unfortunately, David Chaum and his company made some missteps, and fell foul of the central bank (De Nederlandsche Bank or DNB). The private compromise that they agreed to was that Digicash's e-cash product would only be sold to banks. This accommodation then led the company on a merry dance attempting to field a viable digital cash through many banks, ending up eventually in bankruptcy in 1998. The amount of attention in the press brought very exciting deals to the table, with Microsoft, Deutsche Bank and others, but David Chaum was unable to use them to get to the next level.

On the coattails of Digicash there were hundreds of startups per year working on this space, including my own efforts. In the mid 1990s, the attention switched from Europe to North America for two factors: the Netscape IPO had released a huge amount of VC interest, and also Europe had brought in the first regulatory clampdown on digital cash: the 1994 EU Report on Prepaid Cards, which morphed into a reaction against DigiCash.

Yet, the first great wave of cryptocurrencies spluttered and died, and was instead overtaken by a second wave of web-based monies. First Virtual was a first brief spurt of excitement, to be almost immediately replaced by Paypal which did more or less the same thing.

The difference? Paypal allowed the money to go from person to person, where as FV had insisted that to accept money you must "be a merchant," which was a popular restriction from banks and regulators, but people hated it. Paypal also leapt forward by proposing its system as being a hand-to-hand cash, literally: the first versions were on the Palm Pilot, which was extraordinarily popular with geeks. But this geek-focus was quickly abandoned as Paypal discovered that what people -- real users -- really wanted was money on the web browser. Also, having found a willing userbase in ebay community, its future was more or less guaranteed as long as it avoided the bank/regulatory minefield laid out for it.

As Paypal proved the web became the protocol of choice, even for money, so Chaum's ideas were more or less forgotten in the wider western marketplace, although the tradition was alive in Russia with WebMoney, and there were isolated pockets of interest in the crypto communities. In contrast, several ventures started up chasing a variant of Paypal's web-hybrid: gold on the web. The company that succeeded initially was called e-gold, an American-based operation that had its corporation in Nevis in the Caribbean.

e-gold was a fairly simple idea: you send in your physical gold or 'junk' silver, and they would credit e-gold to your account. Or you could buy new e-gold, by sending a wire to Florida, and they would buy and hold the physical gold. By tramping the streets and winning customers over, the founder managed to get the company into the black and up and growing by around 1999. As e-gold the currency issuer was offshore, it did not require US onshore approval, and this enabled it for a time to target the huge American market of 'goldbugs' and also a growing worldwide community of Internet traders who needed to do cross-border payments. With its popularity on the increase, the independent exchange market exploded into life in 2000, and its future seemed set.

e-gold however ran into trouble for its libertarian ideal of allowing anyone to have an account. While in theory this is a fine concept, the steady stream of ponzis, HYIPs, 'games' and other scams attracted the attention of the Feds. In 2005, e-gold's Florida offices were raided and that was the end of the currency as an effective force. The Feds also proceeded to mop up any of the competitors and exchange operations they could lay their hands on, ensuring the end of the second great wave of new monies.

In retrospect, 9/11 marked a huge shift in focus. Beforehand, the USA was fairly liberal about alternative monies, seeing them as potential business, innovation for the future. After 9/11 the view switched dramatically, albeit slowly; all cryptocurrencies were assumed to be hotbeds of terrorists and drugs dealers, and therefore valid targets for total control. It's probably fair to speculate that e-gold didn't react so well to the shift. Meanwhile, over in Europe, they were going the other way. It had become abundantly clear that the attempt to shutdown cryptocurrencies was too successful, Internet business preferred to base itself in the USA, and there had never been any evidence of the bad things they were scared of. Successive generations of the eMoney law were enacted to open up the field, but being Europeans they never really understood what a startup was, and the less-high barriers remained deal killers.

Which brings us forward to 2008, and the first public posting of the Bitcoin paper by Satoshi Nakamoto.

What's all this worth? The best way I can make this point is an appeal to authority:

Satoshi Nakamoto wrote, on releasing the code:
> You know, I think there were a lot more people interested in the 90's,
> but after more than a decade of failed Trusted Third Party based systems
> (Digicash, etc), they see it as a lost cause. I hope they can make the
> distinction that this is the first time I know of that we're trying a
> non-trust-based system.

Bitcoin is a result of history; when decisions were made, they rebounded along time and into the design. Nakamoto may have been the mother of Bitcoin, but it is a child of many fathers: David Chaum's blinded coins and the fateful compromise with DNB, e-gold's anonymous accounts and the post-9/11 realpolitik, the cypherpunks and their libertarian ideals, the banks and their industrial control policies, these were the whole cloth out of which Nakamoto cut the invention.

And, finally it must be stressed, most all successes and missteps we see here in the growing Bitcoin sector have been seen before. History is not just humming and rhyming, it's singing loudly.

The evil of cryptographic choice (2) -- how your Ps and Qs were mined by the NSA

One of the excuses touted for the Dual_EC debacle was that the magical P & Q numbers that were chosen by secret process were supposed to be defaults. Anyone was at liberty to change them.

Epic fail! It turns out that this might have been just that, a liberty, a hope, a dream. From last week's paper on attacking Dual_EC:

"We implemented each of the attacks against TLS libraries described above to validate that they work as described. Since we do not know the relationship between the NIST- specified points P and Q, we generated our own point Q′ by first generating a random value e ←R {0,1,...,n−1} where n is the order of P, and set Q′ = eP. This gives our trapdoor value d ≡ e−1 (mod n) such that dQ′ = P. (Our random e and its corresponding d are given in the Appendix.) We then modified each of the libraries to use our point Q′ and captured network traces using the libraries. We ran our attacks against these traces to simulate a passive network attacker.

In the new paper that measures how hard it was to crack open TLS when corrupted by Dual_EC, the authors changed the Qs to match the P delivered, so as to attack the code. Each of the four libraries they had was in binary form, and it appears that each had to be hard-modified in binary in order to mind their own Ps and Qs.

So did (a) the library implementors forget that issue? or (b) NIST/FIPS in its approval process fail to stress the need for users to mind their Ps and Qs? or (c) the NSA knew all along that this would be a fixed quantity in every library, derived from the standard, which was pre-derived from their exhaustive internal search for a special friendly pair? In other words:

"We would like to stress that anybody who knows the back door for the NIST-specified points can run the same attack on the fielded BSAFE and SChannel implementations without reverse engineering.

Defaults, options, choice of any form has always been known as bad for users, great for attackers and a downright nuisance for developers. Here, the libraries did the right thing by eliminating the chance for users to change those numbers. Unfortunately, they, NIST and all points thereafter, took the originals without question. Doh!

The IETF's Security Area post-NSA - what is the systemic problem?

In the light of yesterday's newly revealed attack by the NSA on Internet standards, what are the systemic problems here, if any?

I think we can question the way the IETF is approaching security. It has taken a lot of thinking on my part to identify the flaw(s), and not a few rants, with many and aggressive defences and counterattacks from defenders of the faith. Where I am thinking today is this:

First the good news. The IETF's Working Group concept is far better at developing general standards than anything we've seen so far (by this I mean ISO, national committees, industry cartels and whathaveyou). However, it still suffers from two shortfalls.

1. the Working Group system is more or less easily captured by the players with the largest budget. If one views standards as the property of the largest players, then this is not a problem. If OTOH one views the Internet as a shared resource of billions, designed to serve those billions back for their efforts, the WG method is a recipe for disenfranchisement. Perhaps apropos, spotted on the TLS list by Peter Gutmann:

Documenting use cases is an unnecessary distraction from doing actual work. You'll note that our charter does not say "enumerate applications that want to use TLS".

I think reasonable people can debate and disagree on the question of whether the WG model disenfranchises the users, because even though a a company can out-manouver the open Internet through sheer persistence and money, we can still see it happen. In this, IETF stands in violent sunlight compared to that travesty of mouldy dark closets, CABForum, which shut users out while industry insiders prepared the base documents in secrecy.

I'll take the IETF any day, except when...

2. the Working Group system is less able to defend itself from a byzantine attack. By this I mean the security concept of an attack from someone who doesn't follow the rules, and breaks them in ways meant to break your model and assumptions. We can suspect byzantium disclosures in the fingered ID:

The United States Department of Defense has requested a TLS mode which allows the use of longer public randomness values for use with high security level cipher suites like those specified in Suite B [I-D.rescorla-tls-suiteb]. The rationale for this as stated by DoD is that the public randomness for each side should be at least twice as long as the security level for cryptographic parity, which makes the 224 bits of randomness provided by the current TLS random values insufficient.

Assuming the story as told so far, the US DoD should have added "and our friends at the NSA asked us to do this so they could crack your infected TLS wide open in real time."

Such byzantine behaviour maybe isn't a problem when the industry players are for example subject to open observation, as best behaviour can be forced, and honesty at some level is necessary for long term reputation. But it likely is a problem where the attacker is accustomed to that other world: lies, deception, fraud, extortion or any of a number of other tricks which are the tools of trade of the spies.

Which points directly at the NSA. Spooks being spooks, every spy novel you've ever read will attest to the deception and rule breaking. So where is this a problem? Well, only in the one area where they are interested in: security.

Which is irony itself as security is the field where byzantine behaviour is our meat and drink. Would the Working Group concept past muster in an IETF security WG? Whether it does or no depends on whether you think it can defend against the byzantine attack. Likely it will pass-by-fiat because of the loyalty of those involved, I have been one of those WG stalwarts for a period, so I do see the dilemma. But in the cold hard light of sunlight, who is comfortable supporting a WG that is assisted by NSA employees who will apply all available SIGINT and HUMINT capabilities?

Can we agree or disagree on this? Is there room for reasonable debate amongst peers? I refer you now to these words:

On September 5, 2013, the New York Times [18], the Guardian [2] and ProPublica [12] reported the existence of a secret National Security Agency SIGINT Enabling Project with the mission to “actively [engage] the US and foreign IT industries to covertly influence and/or overtly leverage their commercial products’ designs.” The revealed source documents describe a US $250 million/year program designed to “make [systems] exploitable through SIGINT collection” by inserting vulnerabilities, collecting target network data, and influencing policies, standards and specifications for commercial public key technologies. Named targets include protocols for “TLS/SSL, https (e.g. webmail), SSH, encrypted chat, VPNs and encrypted VOIP.”
The documents also make specific reference to a set of pseudorandom number generator (PRNG) algorithms adopted as part of the National Institute of Standards and Technology (NIST) Special Publication 800-90 [17] in 2006, and also standardized as part of ISO 18031 [11]. These standards include an algorithm called the Dual Elliptic Curve Deterministic Random Bit Generator (Dual EC). As a result of these revelations, NIST reopened the public comment period for SP 800-90.

And as previously written here. The NSA has conducted a long term programme to breach the standards-based crypto of the net.

As evidence of this claim, we now have *two attacks*, being clear attempts to trash the security of TLS and freinds, and we have their own admission of intent to breach. In their own words. There is no shortage of circumstantial evidence that NSA people have pushed, steered, nudged the WGs to make bad decisions.

I therefore suggest we have the evidence to take to a jury. Obviously we won't be allowed to do that, so we have to do the next best thing: use our collective wisdom and make the call in the public court of Internet opinion.

My vote is -- guilty.

One single piece of evidence wasn't enough. Two was enough to believe, but alternate explanations sounded plausible to some. But we now have three solid bodies of evidence. Redundancy. Triangulation. Conclusion. Guilty.

Where it leaves us is in difficulties. We can try and avoid all this stuff by e.g., avoiding American crypto, but it is a bit broader that that. Yes, they attacked and broke some elements of American crypto (and you know what I'm expecting to fall next.). But they also broke the standards process, and that had even more effect on the world.

It has to be said that the IETF security area is now under a cloud. Not only do they need to analyse things back in time to see where it went wrong, but they also need some concept to stop it happening in the future.

The first step however is to actually see the clouds, and admit that rain might be coming soon. May the security AD live in interesting times, borrow my umbrella?

NSA caught again -- deliberate weakening of TLS revealed!?

In a scandal that is now entertaining that legal term of art "slam-dunk" there is news of a new weakness introduced into the TLS suite by the NSA:

We also discovered evidence of the implementation in the RSA BSAFE products of a non-standard TLS extension called "Extended Random." This extension, co-written at the request of the National Security Agency, allows a client to request longer TLS random nonces from the server, a feature that, if it enabled, would speed up the Dual EC attack by a factor of up to 65,000. In addition, the use of this extension allows for for attacks on Dual EC instances configured with P-384 and P-521 elliptic curves, something that is not apparently possible in standard TLS.

This extension to TLS was introduced 3 distinct times through an open IETF Internet Draft process, twice by an NSA employee and a well known TLS specialist, and once by another. The way the extension works is that it increases the quantity of random numbers fed into the cleartext negotiation phase of the protocol. If the attacker has a heads up to those random numbers, that makes his task of divining the state of the PRNG a lot easier. Indeed, the extension definition states more or less that:

4.1. Threats to TLS

When this extension is in use it increases the amount of data that an attacker can inject into the PRF. This potentially would allow an attacker who had partially compromised the PRF greater scope for influencing the output.

The use of Dual_EC, the previously fingered dodgy standard, makes this possible. Which gives us 2 compromises of the standards process that when combined magically work together.

Our analysis strongly suggests that, from an attacker's perspective, backdooring a PRNG should be combined not merely with influencing implementations to use the PRNG but also with influencing other details that secretly improve the exploitability of the PRNG.

Red faces all round.

US State Department rolled, as NSA slides further off-mission. Shoulda used a BlackPhone :D

In what is either belly laugh-level hilarity, or a serious wakeup call for the American taxpayer, Reuters reports on the recent "Fuck the EU" leaks of phone calls. (h/t to zerohedge.) It turns out the recordings may have been (gasp) lifted off the airwaves:

Some U.S. officials blamed Moscow for leaking the call, noting that the recording, posted anonymously, was first highlighted in a tweet from a Russian official.

In Washington, U.S. officials said Nuland and Pyatt apparently used unencrypted cellphones, which are easy to monitor. The officials said smart phones issued to State Department officials had data encryption *but not voice encryption*.

Wtf? Where the hell are you, oh, NSA's security division aka Central Security Service?

The Information Assurance mission confronts the formidable challenge of preventing foreign adversaries from gaining access to sensitive or classified national security information.

How is it that officials of the State Department have zero, zip, nada, nuttin security while blathering on about international negotiations involving an entire strategic country, a major pipeline, and the number one PR circle-jerk for the nation-states?

I had thought that all these things were in the killing zone for the NSA. Ukraine, energy, the Olympic Games, check check check!

But apparently not. The evidence on mission drift is somewhat damning, and becoming deafening.

They have dropped the baby in many ways. They recently downgraded their irrational fear of terrorism, by prioritising the insider threat as a 'national security threat'. Without apparently understanding the bleeding obvious, that insiders such as Snowden and Manning are a threat to them, not to the people who pay their salaries:

“[Snowden and the insider threat] certainly puts us at risk of missing something that we are trying to see, which could lead to [an attack],” said Matthew Olsen, the director of the National Counterterrorism Center.

Spoken without any cynicism or humility!

If they got back to work, and crafted their mission to deliver return on investment to the taxpayer, instead of stealing from other countries' taxpayers, they wouldn't have time to worry about schoolboy plots like terrorism and rogue sysadms.

Message to the American taxpayer: demand your money back. Buy a blackphone instead.

FC++ -- Bitcoin Verification Latency -- The Achilles Heel for Time Sensitive Transactions

New paper for circulation by Ken Griffith and myself:

Bitcoin Verification Latency
The Achilles Heel for Time Sensitive Transactions

Abstract.Bitcoin has a high latency for verifying transactions, by design. Averaging around 8 minutes, such high latency does not resonate with the needs of financial traders for speed, and it opens the door for time-based arbitrage weaknesses such as market timing attacks. Although perhaps tractable in some markets such as peer to peer payments, the Achilles heel of latency makes Bitcoin unsuitable for direct trading of financial assets, and ventures seeking to exploit the market for financial assets will need to overcome this burden.

As with the Gresham's paper, developments moved fast on this question, and there are now more ventures looking at the contracts and trading question. For clarification, I am the secondary author, Ken is lead.

The Ka-Ping challenge -- so you think you can spot a bug?

It being Christmas and we're all looking for a little fun, David Wagner has posted a challenge that was part of a serious study conducted by Ka-Ping Yee and himself:

Are you up to it? Are you a hacker-hero or a manager-mouse? David writes:

I believe I've managed to faithfully reconstruct the version of Ping's code that contains the deliberately inserted bug. If you would like to try your hand at finding the bug, you can look at it yourself:

http://www.cs.berkeley.edu/~daw/tmp/pvote-backdoored.zip

I'm copying Ping, in case he wants to comment or add to this.

Some grounds rules that I'd request, if you want to try this on your own:

1. Please don't post spoilers to the list. If you think you've found a bug, email Ping and David privately (off-list), and I'll be happy to confirm your find, but please don't post it to the list (just in case others want to take a look too).
2. To help yourself avoid inadvertently coming across spoilers, please don't look at anything else on the web. Resist the temptation to Google for Pvote, check out the Pvote web site, or check out the links in the code. You should have everything you need in this email. We've made no attempt to conceal the details of the bug, so if you look at other resources on the web, you may come across other stuff that spoils the exercise.
3. I hope you'll think of this as something for your own own personal entertainment and edification. We can't provide a controlled environment and we can't fully mimic the circumstances of the review over the Internet.

Here's some additional information that may help you.

We told reviewers that there exists at least one bug, in Navigator.py, in a region that contains 100 lines of code. I've marked the region using comments. So, you are free to focus on only that part of the code (I promise you that we did not deliberately insert any bug anywhere else outside that region). Of course, I'm providing all the code, because you may need to understand how it all interacts. The original Pvote code was written to be as secure and verifiable as we could make it; I'm giving you a modified version that was modified to add a bug after the fact. So, this is not some "obfuscated Python" contest where the entire thing was designed to conceal a malicious backdoor: it was designed to be secure, and we added a backdoor only as an afterthought, as a way to better understand the effectiveness of code review.

To help you conduct your code review, it might help to start by understanding the Pvote design. You can read about the theory, design, and principles behind Pvote in our published papers:

• An early version of Pvote, with many of the main ideas: paper: http://pvote.org/docs/evt2006/index.html Ping's slides: http://pvote.org/docs/evt2006/talk.pdf
• Many improvements to the initial idea, and the final Pvote: paper: http://pvote.org/docs/evt2007/index.html slides: http://pvote.org/docs/evt2007/talk.pdf

The Pvote code probably won't make sense without understanding some aspects of its design and how it is intended to be used, so this background material might be helpful to you.

We also gave reviewers an assurance document, which outlines the "assurance case" (a detailed argument describing why we believe Pvote is secure and fit for purpose and free of bugs). Here's most of it:

http://www.cs.berkeley.edu/~daw/tmp/pvad-excerpts.pdf

Why not all of it? Because I'm lazy. The full assurance document contains the actual, unmodified Pvote code. We wrote the assurance document for the unmodified version of Pvote (without the deliberately inserted bug), and the full assurance document includes the code of the unmodified Pvote. If you were to look at that and compare it to the code I gave you above, you could quickly identify the bug by just doing a diff -- but that would completely defeat the purpose of the exercise. If I had copious free time, I'd modify the assurance document to give you a modified document that matches the modified code -- but I don't have time to do that. So, instead, I've just removed the part of the assurance document that contained the region of the code where we inserted our bug (namely, Navigator.py), and I'm giving you the rest of the assurance document.

In the actual review, we provided reviewers with additional resources that won't be available to you. For instance, we outlined for them the overall design principles of Pvote. We also were available to interactively answer questions, which helped them quickly get up to speed on the code. During the part where we had them review the modified Pvote with a bug inserted, we also answered their questions -- here's what Ping wrote about how we handled that part:

Since insider attacks are a major unaddressed threat in existing systems, we specifically wanted to experiment with this scenario. Therefore, we warned the reviewers to treat us as untrusted adversaries, and that we might not always tell the truth. However, since it was in everyone’s interest to use our limited time efficiently, we settled on a time-saving convention. We promised to truthfully answer any question about a factual matter that the reviewers could conceivably verify mechanically or by checking an independent source — for example, questions about the Python language, about static properties of the code, about its runtime behaviour, and so on.

Of course, since this is something you're doing on your own, you won't get the benefit of interacting with us and having us answer questions for you (to save you time). I realize this does make code review harder. My apologies.

You can assume that someone else has done some runtime testing of the code. We deliberately chose a bug that would survive "Logic & Accuracy Testing" (a common technique in elections, where election officials conduct a test in advance where they cast some ballots, typically chosen so that at least one vote has been cast for each candidate, and then check that the system accurately recorded and tallied those votes). Focus on code review.

-- David

Confirmed: the US DoJ will not put the bankers in jail, no matter how deep the fraud

I've often asked the question why no-one went to jail for the frauds of the financial crisis, and now the US government has answered it: they are complicit in the cover-up, which means that the financial rot has infected the Department of Justice as well. Bill Black writes about the recent Bank of America verdict:

The author of the most brilliantly comedic statement ever written about the crisis is Landon Thomas, Jr. He does not bury the lead. Everything worth reading is in the first sentence, and it should trigger belly laughs nationwide.

Bank of America, one of the nation’s largest banks, was found liable on Wednesday of having sold defective mortgages, a jury decision that will be seen as a victory for the government in its aggressive effort to hold banks accountable for their role in the housing crisis."

“The government,” as a statement of fact so indisputable that it requires neither citation nor reasoning, has been engaged in an “aggressive effort to hold banks accountable for their role in the housing crisis.” Yes, we have not seen such an aggressive effort since Captain Renault told Rick in the movie Casablanca that he was “shocked” to discover that there was gambling going on (just before being handed his gambling “winnings” which were really a bribe).

There are four clues in the sentence I quoted that indicate that the author knows he’s putting us on, but they are subtle. First, the case was a civil case. “The government’s” “aggressive effort to hold banks accountable” has produced – zero convictions of the elite Wall Street officers and banks whose frauds drove the crisis. Thomas, of course, knows this and his use of the word “aggressive” mocks the Department of Justice (DOJ) propaganda. The jurors found that BoA (through its officers) committed an orgy of fraud in order to enrich those officers. That is a criminal act. Prosecutors who are far from “aggressive” prosecute elite frauds criminally because they know it is essential to deter fraud and safeguard our financial system. The DOJ refused to prosecute the frauds led by senior BoA officers. The journalist’s riff is so funny because he portrays DOJ’s refusal to prosecute frauds led by elite BoA officers as “aggressive.” Show the NYT article to friends you have who are Brits and who claim that Americans are incapable of irony. The article’s lead sentence refutes that claim for all time.

The twin loan origination fraud epidemics (liar’s loans and appraisal fraud) and the epidemic of fraudulent sales of the fraudulently originated mortgages to the secondary market would each – separately – constitute the most destructive frauds in history. These three epidemics of accounting control fraud by loan originators hyper-inflated the real estate bubble and drove our financial crisis and the Great Recession. By way of contrast, the S&L debacle was less than 1/70 the magnitude of fraud and losses than the current crisis, yet we obtained over 1,000 felony convictions in cases DOJ designated as “major.” If DOJ is “aggressive” in this crisis what word would be necessary to describe our approach?

Read on for the details of how Bill Black forms his conclusion.

Posted by iang at 05:27 AM | Comments (0) | TrackBack

MayDay! MayDay! British Banking Launches new crisis of titanic proportions...

Yes, it's the first of May, also known as May Day, and the communist world's celebration of the victory over capitalism. Quite why MayDay became the international distress message over radio is not known to me, but I'd like to know!

Meanwhile, the British Banking sector is celebrating its own version of MayDay:

The bank went through their customer base and identified which businesses were asset rich and cash poor.

Typically, the SME (small to medium enterprise) would require funding for expansion or to cover short term exposures, and the bank’s relationship manager would work with the business owner on a loan funding cover.

The loan may be for five or ten years, and the relationship manager would often call the client after a short time and say “congratulations, you’ve got the funding”.

The business owner would be delighted and would start committing the funds.

Only then would the relationship manager call them back and say, “ah, we have a concern here about interest rates”.

This would start the process of the disturbance sale of the IRSA.

The rest you can imagine - the bank sold an inappropriate derivative with false information, and without advising the customer of the true costs. This time however the costs were more severe, as it seems that many such businesses went out of business in whole or in part because of the dodgy sale.

In particular, the core issue is that no-one has defined whether the bank will be responsible for contingent liabilities.

The liabilities are for losses made by those businesses that were mis-sold these products and, as a result, have now gone into bankruptcy or been constrained so much that they have been unable to compete or grow their business as they would have if they had not taken these products.

Ouch! I have to applaud Chris Skinner and the Financial Services Club here for coming forth with this information. It is time for society to break ranks here and start dealing with the banks. If this is not done, the banks will bring us all down, and it is not clear at all that the banks aren't going to do just that.

Meanwhile back to the scandal du jour. We are talking about 40k businesses, with average suggested compensation of 2.5 million quid - so we are already up to a potential exposure of 100 billion pounds. Given this, there is no doubt that even the most thickest of the dumbest can predict what will happen next:

Mainly because of the Parliamentary investigation, the Financial Services Authority was kicked into action and, on June 29 2012, announced that it had found "serious failings in the sale of IRSAs to small and medium sized businesses and that this has resulted in a severe impact on a large number of these businesses.”

However, it then left the banks to investigate the cases and work out how to compensate and address them .

The banks response was released on January 31 2013, and it was notable that between the June announcement and bank response in January that the number of cases rose from 28,000 to 40,000. It was also noteworthy that of those 40,000 cases investigated, over 90% were found to have been mis-sold. That’s a pretty damning indictment.

Even then the real issue, according to Jeremy [of Bully Banks], is that the banks are in charge of the process.

Not only is the fox in charge of the chickens, it's also paying off them off for their slaughter. Do we really need to say more? The regulators are in bed with the banks in trying to suppress this scandal.

Obviously, this cunning tactic will save poor banks money and embarrassment. But the emerging problem here is that, as suggested many times in this blog (e.g., 2, 3, 4, ...) and elsewhere, the public is now becoming increasingly convinced that banks are not healthy, honest members of society.

Which is fine, as long as nothing happens.

But I see an issue emerging in the next systemic shock to hit the financial world: if the public's patience is exhausted, as it appeared to be over Cyprus, then the next systemic shock is going to cause the collapse of some major banks. For right or wrong, the public is not going to accept any more talk of bailouts, taxpayer subsidies, etc etc.

The chickens are going to turn on the foxes, and they will not be satisfied with anything less than blood.

One hopes that the old Lady's bank tear-down team is boned up and ready to roll, because they'll be working hard soon.

PKI and SSL - the jaws of trust snap shut

As we all know, it's a right of passage in the security industry to study the SSL business of certificates, and discover that all's not well in the state of Denmark. But the business of CAs and PKI rolled on regardless, seemingly because no threat ever challenged it. Because there was no risk, the system successfully dealt with the threats it had set itself. Which is itself elegant proof that academic critiques and demonstrations and phishing and so forth are not real attacks and can be ignored entirely...

Until 2011.

Last year, we crossed the Rubicon for the SSL business -- and by extension certificates, secure browsing, CAs and the like -- with a series of real attacks against CAs. Examples include the DigiNotar affair, the Iranian affair (attacks on around 5 CAs), and also the lesser known attack a few months back where certificates may have been forged and may have been used in an APT and may have... a lot of things. Nobody's saying.

Either way, the scene is set. The pattern has emerged, the Rubicon is crossed, it gets worse from here on in. A clear and present danger, perhaps? In California, they'd be singing "let's partly like it's 2003," the year that SB1386 slid past our resistance and set the scene for an industry an industry debacle in 2005.

But for us long term observers, no party. There will now be a steady series of these shocks, and journalists will write of our brave new world - security but no security.

With one big difference. Unlike the SB1386 breach party, where we can rely on companies not going away (even as our data does), the security system of SSL and certificates is somewhat optional. Companies can and do expose their data in different ways. We can and do invent new systems to secure or mitigate the damage. So while SB1386 didn't threaten the industry so much as briskly kicked it around, this is different.

At an attacks level, we've crossed a line, but at a wider systems level, we stand on the line.

And that line is a cliff.

Which brings us to this week's news. A CA called Trustwave has just admitted to selling a sub-root for the explicit purpose of MITM'ing. Read about that elsewhere.

Now, we've known that MITMing for fun and profit was going on for a long time. Mozilla's community first learnt of it in the mid 2000s as it was finalising its policy on CAs (a ground-breaking work that I was happy to be involved with). At that time, accusations were circulating against unknown companies listing their roots for the explicit purpose of doing MITMs on unwitting victims. Which raised the hairs, eyebrows and heckles on not a few of us. These accusations have been repeated from time to time, but in each case the "insiders" begged off on the excuse: we cannot break NDA or reputation.

Each time then the industry players were likewise able to fob it off. Hard Evidence? none. Therefore, it doesn't exist, was they industry's response. We knew as individuals, yet as an industry we knew not.

We are all agreed it does exist and it doesn't. We all have jobs to preserve, and will practice cognitive dissonance to the very end.

Of course this situation couldn't last, because a secret of this magnitude never survives. In this case, the company that sold the MITM sub-root, Trustwave, has looked at 2011, and realised the profit from that one CA isn't worth the risk of the DigiNotar experience (bankruptcy). Their decision is to 'fess up now, take it on the chin, because later may be too late.

Which leads to a dilemma, and we the players have divided on each side, one after the other, of that dilemma:

To drop the Trustwave root, or not?

That is the question. First the case for the defence: On the one hand, we applaud the honesty of a CA coming forward and cleaning up house. It's pretty clear that we need our CAs to do this. Otherwise we're not going to get anywhere with this Trust thing. We need to encourage the CAs to work within the system.

Further, if we damage a CA, we damage customers. The cost to lost business is traumatic, and the list of US government agencies that depend on this CA has suddenly become impressive. Just like DigiNotar, it seems, which spread like a wave of mistrust through the government IT departments of the Netherlands. Also, we have to keep an eye on (say) a bigger more public facing CA going down in the aftermath - and the damage to all its customers. And the next, etc.

Is lost business more important than simple faith in those silly certificates? I think lost business is much more important - revenue, jobs, money flowing keeping all of the different parts of the economy going are our most important asset. Ask any politician in USA or Europe or China; this is their number one problem!

Finally, it is pretty clear and accepted that the business purpose to which the sub-Root was put was known and tolerated. Although it is uncomfortable to spy on ones employees, it is just business. Organisations own their data systems, have the responsibility to police them, and have advised their people that this is what they are going to do. SSL included, if necessary.

This view has it that Trustwave has done the right thing. Therefore, pass. And, the more positive proponents suggest an amnesty, after which period there is summary execution for the sins - root removal from the list distributed by the browsers. It's important to not cause disruption.

Now the case for the Prosecution! On the other hand, damn spot: the CA clearly broke their promise. Out!

Three ways, did they breach the trust: It is expressed in the Mozilla policy and presumably of others that certificates are only issued to people who own/control their domains. This is no light or optional thing -- we rely on the policy because CAs and Mozilla and other vendors and auditors and all routinely practice secrecy in this business.

We *must rely on the policy* because they deny us the right to rely on anything else!

Secondly, it is what the public believe in, it is the expectations of any purchaser or user of the product, written or not. It is a simple message, and brooks no complicated exceptions. Either your connection is secure to your online bank, and nobody else can see it *including your employer or IT department*. Or not.

Try explaining this exception to your grandmother, if the words do not work for you.

Finally, the raison d'être: it is the purpose and even the entire goal of the certificate design to do exactly the opposite. The reason we have CAs like TrustWave is to stop the MITM. If they don't stop the MITM, then *we don't need the heavyweight certificate system*, we don't need CAs, and we don't need Mozilla's root list or that of any other vendor.

We can do security much more cost-effectively if we drop the 100% always-on absolutist MITM protection.

Given this breach of trust, what else can we trust in? Can we trust their promises that the purpose was maintained? That the cert never left the building? That secret traffic wasn't vectored in? That HSMs are worth something and audits ensure all is well in Denmark?

This rather being a problem with trust. Lie once, lose it.

There being two views presented, it has to be said that both views are valid. The players are lining up on either side of the line, but they probably aren't so well aware of where this is going.

Only one view is going to win out. Only one side wins this fight.

And in so-doing, in winning, the winner sews the seeds for own destruction.

Because if you religiously take your worldview, and look at the counter-argument to your preferred position, your thesis crumbles for the fallacies.

The jaws of trust just snapped shut on the players who played too long, too hard, too profitably.

Like the financial system. We are no longer worried about the bankruptcy of one or two banks or a few defaults by some fly specks on the map of European. We are now looking at a change that will ripple out and remove what vestiges of purpose and faith were left in PKI. We are now looking at all the other areas of the business that will be effected; ones that brought into the promise even though they knew they shouldn't have.

Like the financial system, a place of uncanny similarity, each new shock makes us wonder and question. Wasn't all this supposed to be solved? Where are the experts? Where is the trust?

We're about to find out the timeless meaning of Caveat Emptor.

Why Threat Modelling fails in practice

I've long realised that threat modelling isn't quite it.

There's some malignancy in the way the Internet IT Security community approached security in the 1990s that became a cancer in our protocols in the 2000s. Eventually I worked out that the problem with the aphorism What's Your Threat Model (WYTM?) was the absence of a necessary first step - the business model - which lack permitted threat modelling to be de-linked from humanity without anyone noticing.

But I still wasn't quite there, it still felt like wise old men telling me "learn these steps, swallow these pills, don't ask for wisdom."

In my recent risk management work, it has suddenly become clearer. Taking from notes and paraphrasing, let me talk about threats versus risks, before getting to modelling.

A threat is something that threatens, something that can cause harm, in the abstract sense. For example, a bomb could be a threat. So could an MITM, an eavesdropper, or a sniper.

But, separating the abstract from the particular, a bomb does not necessarily cause a problem unless there is a connection to us. Literally, it has to be capable of doing us harm, in a direct sense. For this reason, the methodologists say:

Risk = Threat * Harm

Any random bomb can't hurt me, approximately, but a bomb close to me can. With a direct possibility of harm to us, a threat becomes a risk. The methodologists also say:

Risk = Consequences * Likelihood

That connection or context of likely consequences to us suddenly makes it real, as well as hurtful.

A bomb then is a threat, but just any bomb doesn't present a risk to anyone, to a high degree of reliability. A bomb under my car is now a risk! To move from threats to risks, we need to include places, times, agents, intents, chances of success, possible failures ... *victims* ... all the rest needed to turn the abstract scariness into direct painful harm.

We need to make it personal.

To turn the threatening but abstract bomb from a threat to a risk, consider a plane, one which you might have a particular affinity to because you're on it or it is coming your way:

⇒ people dying
⇒ financial damage to plane
⇒ reputational damage to airline
⇒ collateral damage to other assets
⇒ economic damage caused by restrictions
⇒ war, military raids and other state-level responses

Lots of risks! Speaking of bombs as planes: I knew someone booked on a plane that ended up in a tower -- except she was late. She sat on the tarmac for hours in the following plane.... The lovely lady called Dolly who cleaned my house had a sister who should have been cleaning a Pentagon office block, but for some reason ... not that day. Another person I knew was destined to go for coffee at ground zero, but woke up late. Oh, and his cousin was a fireman who didn't come home that day.

Which is perhaps to say, that day, those risks got a lot more personal.

We all have our very close stories to tell, but the point here is that risks are personal, threats are just theories.

Let us now turn that around and consider *threat modelling*. By its nature, threat modelling only deals with threats and not risks and it cannot therefore reach out to its users on a direct, harmful level. Threat modelling is by definition limited to theoretical, abstract concerns. It stops before it gets practical, real, personal.

Maybe this all amounts to no more than a lot of fuss about semantics?

To see if it matters, let's look at some examples: If we look at that old saw, SSL, we see rhyme. The threat modelling done for SSL took the rather abstract notions of CIA -- confidentiality, integrity and authenticity -- and ended up inverse-pyramiding on a rather too-perfect threat of MITM -- Man-in-the-Middle.

We can also see from the lens of threat analysis versus risk analysis that the notion of creating a protocol to protect any connection, an explicit choice of the designers, led to them not being able to do any risk analysis at all; the notion of protecting certain assets such as credit cards as stated in the advertising blurb was therefore conveniently not part of the analysis (which we knew, because any risk analysis of credit cards reveals different results).

Threat modelling therefore reveals itself to be theoretically sound but not necessarily helpful. It is then no surprise that SSL performed perfectly against its chosen threats, but did little to offend the risks that users face. Indeed, arguably, as much as it might have stopped some risks, it helped other risks to proceed in natural evolution. Because SSL dealt perfectly with all its chosen threats, it ended up providing a false sense of false security against harm-incurring risks (remember SSL & Firewalls?).

OK, that's an old story, and maybe completely and boringly familiar to everyone else? What about the rest? What do we do to fix it?

The challenge might then be to take Internet protocol design from the very plastic, perfect but random tendency of threat modelling and move it forward to the more haptic, consequences-directed chaos of risk modelling.

Or, in other words, we've got to stop conflating threats with risks.

Critics can rush forth and grumble, and let me be the first: Moving to risk modelling is going to be hard, as any Internet protocol at least at the RFC level is generally designed to be deployed across an extremely broad base of applications and users.

Remember IPSec? Do you feel the beat? This might be the reason why we say that only end-to-end security cuts the mustard, because end-to-end implies an application, and this draw in the users to permit us to do real risk modelling.

It might then be impossible to do security at the level of an Internet-wide, application-free security protocol, a criticism that isn't new to the IETF. Recall the old ISO layer 5, sometimes called "the security layer" ?

But this doesn't stop the conclusion: threat modelling will always fail in practice, because by definition, threat modelling stops before practice. The place where users are being exposed and harmed can only be investigated by getting personal - including your users in your model. Threat modelling does not go that far, it does not consider the risks against any particular set of users that will be harmed by those risks in full flight. Threat modelling stops at the theoretical, and must by the law of ignorance fail in the practical.

Risks are where harm is done to users. Risk modelling therefore is the only standard of interest to users.

Two-channel breached: a milestone in threat evaluation, and a floor on monetary value

Readers will know we first published the account on "Man in the Browser by Philipp Güring way back when, and followed it up with news that the way forward was dual channel transaction signing. In short, this meant the bank sending an SMS to your handy mobile cell phone with the transaction details, and a check code to enter if you wanted the transaction to go through.

On the face of it, pretty secure. But at the back of our minds, we knew that this was just an increase in difficulty: a crook could seek to control both channels. And so it comes to pass:

In the days leading up to the fraud being committed, [Craig] had received two strange phone calls. One came through to his office two-to-three days earlier, claiming to be a representative of the Australian Tax Office, asking if he worked at the company. Another went through to his home number when he was at work. The caller claimed to be a client seeking his mobile phone number for an urgent job; his daughter gave out the number without hesitation.

The fraudsters used this information to make a call to Craig’s mobile phone provider, Vodafone Australia, asking for his phone number to be “ported” to a new device.

As the port request was processed, the criminals sent an SMS to Craig purporting to be from Vodafone. The message said that Vodafone was experiencing network difficulties and that he would likely experience problems with reception for the next 24 hours. This bought the criminals time to commit the fraud.

The unintended consequence of the phone being used for transaction signing is that the phone is now worth maybe as much as the fraud you can pull off. Assuming the crooks have already cracked the password for the bank account (something probably picked up on a market for pennies), the crooks are now ready to spend substantial amounts of time to crack the phone. In this case:

Within 30 minutes of the port being completed, and with a verification code in hand, the attackers were spending the $45,000 at an electronics retailer.

Thankfully, the abnormally large transaction raised a red flag within the fraud unit of the Commonwealth Bank before any more damage could be done. The team tried – unsuccessfully – to call Craig on his mobile. After several attempts to contact him, Craig’s bank account was frozen. The fraud unit eventually reached him on a landline.

So what happens now that the crooks walked with $45k of juicy electronics (probably convertible to cash at 50-70% off face over ebay) ?

As is standard practice for online banking fraud in Australia, the Commonwealth Bank has absorbed the hit for its customer and put $45,000 back into Craig's account.

A NSW Police detective contacted Craig on September 15 to ensure the bank had followed through with its promise to reinstate the $45,000. With this condition satisfied, the case was suspended on September 29 pending the bank asking the police to proceed with the matter any further.

One local police investigator told SC that in his long career, a bank has only asked for a suspended online fraud case to be investigated once. The vast majority of cases remain suspended. Further, SC Magazine was told that the police would, in any case, have to weigh up whether it has the adequate resources to investigate frauds involving such small amounts of money.

No attempt was made at a local police level to escalate the Craig matter to the NSW Police Fraud and Cybercrime squad, for the same reasons.

In a paper I wrote in 2008, I stated for some value below X, police wouldn't lift a finger. The Prosecutor has too much important work to do! What we have here is a very definate floor beyond which Internet systems which transmit and protect value are unable to rely on external resources such as the law . Reading more:

But the Commonwealth Bank claims it has forwarded evidence to the NSW and Federal Police forces that could have been used to prosecute the offenders.

The bank’s fraud squad – which had identified the suspect transactions within minutes of the fraud being committed - was able to track down where the criminals spent the stolen money.

A spokesman for the bank said it “dealt with both Federal and State (NSW) Police regarding the incident” and that “both authorities were advised on the availability of CCTV footage” of the offenders spending their ill-gotten gains.

“The Bank was advised by one of the authorities that the offender had left the country – reducing the likelihood of further action by that authority,” the spokesperson said.

This number goes up dramatically once we cross a border. In that paper I suggested 25k, here we have a reported number of $45k.

Why is that important? Because, some systems have implicit guarantees that go like "we do blah and blah and blah, and then you go to the police and all your problems are solved!" Sorry, not if it is too small, where small is surprisingly large. Any such system that handwaves you to the police without clearly indicating the floor of interest ... is probably worthless.

So when would you trust a system that backstopped to the police? I'll stick my neck out and say, if it is beyond your borders, and you're risking >> $100k, then you might get some help. Otherwise, don't bet your money on it.

Advanced Persistent Threat (APT) - why did we resist so long?

Bruce Schneier posts on something I've felt as well:

Advanced Persistent Threat (APT)

It's taken me a few years, but I've come around to this buzzword. It highlights an important characteristic of a particular sort of Internet attacker.

A conventional hacker or criminal isn't interested in any particular target. He wants a thousand credit card numbers for fraud, or to break into an account and turn it into a zombie, or whatever. Security against this sort of attacker is relative; as long as you're more secure than almost everyone else, the attackers will go after other people, not you. An APT is different; it's an attacker who -- for whatever reason -- wants to attack you. Against this sort of attacker, the absolute level of your security is what's important. It doesn't matter how secure you are compared to your peers; all that matters is whether you're secure enough to keep him out.

APT attackers are more highly motivated. They're likely to be better skilled, better funded, and more patient. They're likely to try several different avenues of attack. And they're much more likely to succeed.

So, this becomes a really classic case of that old saw: "What's your threat model?"

There are apparently two sterotypical attackers out there (at least in this dichotomy):

1. the random agnostic thief: "A conventional hacker or criminal isn't interested in any particular target. He wants a thousand credit card numbers for fraud, or to break into an account and turn it into a zombie, or whatever." He doesn't share our economic beliefs of society and trade, but he certainly subscribes to the power of our money.
2. the advanced persistent threat: the spy who's after your state-level secrets. He's not economic, in the sense that he isn't constrained by normal commercial levels of investment, instead he's got a very large budget behind, with very large strategic interests directing the target choice.

Very different agents, leading to very different models of security. And all other things, such as how we as society deal with these issues.

Schneier finishes on this:

This is why APT is a useful buzzword.

Sure, no matter how uncomfortable we are with the background, it's the buzzword we've got.

Why then did we disbelieve the APT for so long? I think there are three factors.

• We the people aren't bothered by the APT, we're bothered by the random agnostic thief.
• The credibility of the USA industrial-military machine is at an all time low. Since the low-point of Colin Powell's speech to the UN, the people routinely disbelieve anything said, and now demand evidence.
• They presented no evidence. We had to wait until DigiNotar and the surrounding other events (the other CAs) to understand that this was the real deal.

We still aren't so totally accepting. We still have the problem that our attacker is the random agnostic thief.

Why still resist? My feeling is this: I'm annoyed that the state has managed more success in swinging the major Internet vendors around to dealing with selling to the state's APT -- NIST's pogrom on small numbers, ESG’s U.S. Advanced Persistent Threat Analysis, etc -- than we ever had as an open community in dealing with our random agnostic thieves.

We're still following the NSA's drumbeat.

next-gen Stuxnet targets SCADA companies for intelligence

As an example of good disclosure that we can use to analyse our risks on new attacks come from Symantec:

Key points:

Executables using the Stuxnet source code have been discovered. They appear to have been developed since the last Stuxnet file was recovered.

The executables are designed to capture information such as keystrokes and system information.

Current analysis shows no code related to industrial control systems, exploits, or self-replication.

The executables have been found in a limited number of organizations, including those involved in the manufacturing of industrial control systems.

The exfiltrated data may be used to enable a future Stuxnet-like attack.

Now, Symantec are somewhat 'interested' in this disclosure, in the commercial sense, because they gain reputation and thence sell more defences to more customers. They could just shout FUD out to the world. But in this sense, the market has moved to a sense of competition on solid disclosures, as compared by competitor McAfee also putting its own analysis out there.

And, it turns out that Symantec is doubly interested as the new trojan was signed by one of their (Verisign?) certificates:

*Update [October 18, 2011] - *Symantec has known that some of the malware files associated with the W32.Duqu threat were signed with private keys associated with a code signing certificate issued to a Symantec customer. Symantec revoked the customer certificate in question on October 14, 2011. Our investigation into the key's usage leads us to the conclusion that the private key used for signing Duqu was stolen, and not fraudulently generated for the purpose of this malware. At no time were Symantec's roots and intermediate CAs at risk, nor were there any issues with any CA, intermediate, or other VeriSign or Thawte brands of certificates. Our investigation shows zero evidence of any risk to our systems; we used the correct processes to authenticate and issue the certificate in question to a legitimate customer in Taiwan.

Still, I can't fault the disclosure: they investigated and now claim it was a good cert, stolen from the client. They revoked it the same day of being shown the code/sig.

This information is provided in a way we can RELY on it. From this we can make risk management judgements. See more here.

1st round in Internet Account Fraud World Cup: Customer 0, Bank 1, Attacker 300,000

More grist for the mill -- where are we on the security debate? Here's a data point.

In May 2009, PATCO, a construction company based in Maine, had its account taken over by cyberthieves, after malware hijacked online banking log-in and password credentials for the commercial account PATCO held with Ocean Bank. ....

There are two ways to look at this: the contractual view, and the responsible party view. The first view holds that contracts describe the arrangement, and parties govern themselves. The second holds that the more responsible party is required to be <ahem> more responsible. PATCO decided to ask for the second:

A magistrate has recommended that a U.S. District Court in Maine deny a motion for a jury trial in an ACH fraud case filed by a commercial customer against its former bank. According to the order, which must still be reviewed by the presiding judge, the bank fulfilled its contractual obligations for security and authentication through its requirement for log-in and password credentials. ....

At issue for PATCO is whether banks should be held responsible when commercial accounts, like PATCO's, are drained because of fraudulent ACH and wire transfers approved by the bank. How much security should banks and credit unions reasonably be required to apply to the commercial accounts they manage?

"Obviously, the major issue is the banks are saying this is the depositors' problem," Patterson says, "but the folks that are losing money through ACH fraud don't have enough sophistication to stop this."

And lost.

David Navetta, an attorney who specializes in IT security and privacy, says the magistrate's recommendation, if accepted by the judge, could set an interesting legal precedent about the security banks are expected to provide. And unless PATCO disputes the order, Navetta says it's unlikely the judge will overrule the magistrate's findings. PATCO has between 14 and 21 days to respond.

"Many security law commentators, myself included, have long held that *reasonable security does not mean bullet-proof security*, and that companies need not be at the cutting edge of security to avoid liability," Navetta says. "The court explicitly recognizes this concept, and I think that is a good thing: For once, the law and the security world agree on a key concept."

My emphasis added, and it is an important point that security doesn't mean absolute security, it means reasonable security. Which from the principle of the word, means stopping when the costs outweigh the benefits.

But that is not the point that is really addressed. The question is whether (a) how we determine what is acceptable (not reasonable), and (b) if the Customer loses out when acceptable wasn't reasonable, is there any come-back?

In the disposition, the court notes that Ocean Bank's security could have been better. "It is apparent, in the light of hindsight, that the Bank's security procedures in May 2009 were not optimal," the order states. "The Bank would have more effectively harnessed the power of its risk- profiling system if it had conducted manual reviews in response to red flag information instead of merely causing the system to trigger challenge questions."

But since *PATCO agreed to the bank's security methods when it signed the contract*, the court suggests then that PATCO considered the bank's methods to be reasonable, Navetta says. The law also does not require banks to implement the "best" security measures when it comes to protecting commercial accounts, he adds.

So, we can conclude that "reasonable" to the bank meant putting in place risk-profiling systems. Which it then bungled (allegedly). However, the standard of security was as agreed in the contract, *reasonable or not*.

That is, *reasonable security* doesn't enter into it. More on that, as the observers try and mold this into a "best practices" view:

"Patco in effect demands that Ocean Bank have adopted the best security procedures then available," the order states. "As the Bank observes, that is not the law."

(Where it says "best" read "best practices" which is lowest common denominator, a rather different thing to best. In particular, the case is talking about SecureId tokens and the like.)

Patterson argues that Ocean Bank was not complying with the Federal Financial Institutions Examination Council's requirement for multifactor authentication when it relied solely on log-in and password credentials to verify transactions. Navetta agrees, but the court in this order does not.

"The court took a fairly literal approach to its analysis and bought the bank's argument that the scheme being used was multifactor, as described in the [FFIEC] guidance," Navetta says. "The analysis on what constitutes multifactor and whether some multifactor schemes [out of band; physical token] are better than others was discussed, and, to some degree, the court acknowledged that the bank's security could have been better. Even so, it was technically multifactor, as described in the FFEIC guidance, in the court's opinion, and "the best" was not necessary."

Navetta says the court's view of multifactor does not jibe with common industry understanding. Most industry experts, he says, would not consider Ocean Bank's authentication practices in 2009 to be true multifactor. "Obviously, the 'something you have' factor did not fully work if hackers were able to remotely log into the bank using their own computer," he says. "I think that PATCO's argument was the additional factors were meaningless since the challenge question was always asked anyway, and apparently answering it correctly worked even if one of the factors failed. In other words, it appears that PATCO was arguing that the net result of the other two factors failing was going back to a single factor."

This problem has been known for a long time. When the "best practices" approach is used, as in this FFIEC example, there is a list of things you do. You do them, and you're done. You are encouraged to (a) not do any better, and (b) cheat. The trick employed above, to interpret the term "multi-factor" in a literal fashion, rather than using the security industry's customary (and more expensive) definition, has been known for a long long time.

It's all part of the "best practices" approach, and the court may have been wise to avoid further endorsing it. There is now more competition in security practices, says this court, and you'll find it in your contract.

If data breaches are feared more than hackers, what is the perverse result?

This headline struck my attention:

Data Breaches Feared More than Hackers

The majority of compliance professionals feel that their organizations are well or very well prepared to fend off hacker attacks, however, their confidence wanes significantly when assessing other data breach threats. This according to a survey conducted by the Society of Corporate Compliance and Ethics (SCCE) and the Health Care Compliance Association (HCCA).

This mirrored my results in The Market for Silver Bullets, in that the cost of the loss to intangibles and indirects such as reputation and compliance reviews would far outweigh the direct losses to the individuals. Consequently, this would have perverse effects on the treatment of risks.

I didn't really go into what those perverse effects were. Suffice, I thought at the time, to say, security's really screwed up, there is no way you can expect a rational result from this mess. But one thing struck me on reading that heading.

If the indirect effects of the data breach are feared more than the direct effects of the hacker's impacted damages, then there is an easy solution. Simply share the results, and generate a win-win for both. E.g., if the hacker manages to breach, and steal X data sets, he now has two opportunities. He can either exploit the breach set for some gain X*y where y is the average gain per identity, or he can settle with the lead victim.

Because we know that the indirect costs to the victim will far outweigh the direct gain to the attacker, there is an easy settlement. The victim is easily incentivised to pay for the breach to be settled without additional costs. And the attacker gains too as he has less work to do. Negotiation will find a convenient price between the two bounds.

Thus, this state of affairs predicts that the market for silver bullets leads to a market for extortion. Hack citibank, sell them their data back. I have no firm data, but I am comfortable with predicting that the difference is an order of magitude. That is, the costs to the victim are around 10 times the benefit to the attacker. Plenty of room there for a win-win solution.

(For those who are worried about the impact of an illegal contract, it is easy enough to put a silk dress on the pig and sell the breach techniques, with an NDA attached. This of course is the worry behind those breach markets. How close to extortion does it take us? Where do the morals stop and where does the crime start? A topic for another day...)

As a slight footnote, to confirm my prediction of this particular perverse result, I followed the article. Here's the relevant section found on the survey provider's site, two groups called Society of Corporate Compliance and Ethics and Health Care Compliance Association.

Fears of an accidental breach far outweigh fears of an intentional breach. Respondents were asked how likely they felt that data would be released through hacking attacks, intentional breaches by employees and third party vendors, and accidental breaches by employees and vendors. In general the feeling was that accidental breaches were far more likely. Just 8% felt that it was somewhat or very likely a hacker would gain access to the system, When it came to breaches by employees, 61% thought an accidental breach was somewhat or very likely, but just 30% thought the same of an intentional breach. Likewise 41% thought an accidental breach by a third party vendor was somewhat or very likely but only 13% thought an intentional breach was somewhat or very likely.

Unfortunately, no such luck. Right crowd, different story :) Oh well. So markets in extortion won't happen, right?

"Compound threats" to appear in 2011 ?

One of the things that happened a while back was the arisal of the MITB, which spooked the online banks in Europe. They aggressively pushed forward on their multi-factor approach: using the cell-phone (which Europeans colloquially call the Handy) to confirm the transaction.

It was recognised at the time that his was a good solution due to the divergence of the two platforms. A hacker could hack the browser, but not the phone. But the next development was also expected: an attack that covered both platforms.

Now, there is suggestion that this might be expected to emerge:

McDaid warned, for example, that criminals are increasingly targeting mobile banking and NFC-enabled payments. “I 100 per cent expect these kinds of attacks to increase next year, not just malware attacks but compound threats too,” he explained.

“This is where criminals exploit SMS, email, phone calls and other channels to target victims.”

Next step after that? Well, we go back to dumb phones. But this time, the phones are tasked just to do the online payments, and there are no other apps downloadable. Reasonable? Yes, because the basic phone price in bulk has now dropped to a few bucks. Downside is convincing consumers to use it. Upside is that we can do it if we can get them to think of them as credit cards ...

All in a days work for the strategic marketing department of your bank. If they've got one :)

Threatwatch: taking money & code from "interested parties" (OpenBSD + FBI = backdoors)

Following email is circulating amongst crypto-plumber communities. I have no idea whether it is accurate or not. It was sent to Theo de Raadt, a shaker & mover over at security-leading OpenBSD group. He also doesn't know...

Offered here in the spirit of documenting the potential threats to the ITSec world.

From: Gregory Perry <Gregory.Perry@Go.something.example.tv>
To: "deraadt@openbsd.org" <deraadt@o.o>
Subject: OpenBSD Crypto Framework

Hello Theo,

Long time no talk. If you will recall, a while back I was the CTO at NETSEC and arranged funding and donations for the OpenBSD Crypto Framework. At that same time I also did some consulting for the FBI, for their GSA Technical Support Center, which was a cryptologic reverse engineering project aimed at backdooring and implementing key escrow mechanisms for smart card and other hardware-based computing technologies.

My NDA with the FBI has recently expired, and I wanted to make you aware of the fact that the FBI implemented a number of backdoors and side channel key leaking mechanisms into the OCF, for the express purpose of monitoring the site to site VPN encryption system implemented by EOUSA, the parent organization to the FBI. Jason Wright and several other developers were responsible for those backdoors, and you would be well advised to review any and all code commits by Wright as well as the other developers he worked with originating from NETSEC.

This is also probably the reason why you lost your DARPA funding, they more than likely caught wind of the fact that those backdoors were present and didn't want to create any derivative products based upon the same.

This is also why several inside FBI folks have been recently advocating the use of OpenBSD for VPN and firewalling implementations in virtualized environments, for example Scott Lowe is a well respected author in virtualization circles who also happens top be on the FBI payroll, and who has also recently published several tutorials for the use of OpenBSD VMs in enterprise VMware vSphere deployments.

Merry Christmas...

Gregory Perry
Chief Executive Officer
GoVirtual Education

"VMware Training Products & Services"

540-........ x111 (local)
866-........ x111 (toll free)
540-........ (mobile)
877-........ (fax)

http://www.facebook.com/GregoryVPerry
http://www.facebook.com/GoVirtual

NSA loses the crown jewels, or, Law of Unintended Consequences meets Flights of Brittleness

Lynn points to a long story in The New Yorker that gives a well-written and strong story by Seymour M. Hersh on the origins of the current Cyber War propaganda push by the US Department of Defence. I and many others of the community called this a budgetary war, not a real threat, and it is good to see that there are many in the USA administration that have called "bull" on the Cyber War claim.

Picking up from page 7:

Why not ignore the privacy community and put cyber security on a war footing? Granting the military more access to private Internet communications, and to the Internet itself, may seem prudent to many in these days of international terrorism and growing American tensions with the Muslim world. But there are always unintended consequences of military activity—some that may take years to unravel.

Of particular note for those who subscribe to the "heavy" approach to secure systems, and poo-poo the doctrine of risk management in favour of absolute security, is an example of the Law of Unintended Consequences, and how complicated it is when you push the envelope at so many levels.

Ironically, the story of the EP-3E aircraft that was downed off the coast of China provides an example. The account, as relayed to me by a fully informed retired American diplomat, begins with the contested Presidential election between Vice-President Al Gore and George W. Bush the previous November. That fall, a routine military review concluded that certain reconnaissance flights off the eastern coast of the former Soviet Union—daily Air Force and Navy sorties flying out of bases in the Aleutian Islands—were redundant, and recommended that they be cut back.

“Finally, on the eve of the 2000 election, the flights were released,” the former diplomat related. “But there was nobody around with any authority to make changes, and everyone was looking for a job.” The reality is that no military commander would unilaterally give up any mission. “So the system defaulted to the next target, which was China, and the surveillance flights there went from one every two weeks or so to something like one a day,” the former diplomat continued. By early December, “the Chinese were acting aggressively toward our now increased reconnaissance flights, and we complained to our military about their complaints. But there was no one with political authority in Washington to respond, or explain.” The Chinese would not have been told that the increase in American reconnaissance had little to do with anything other than the fact that inertia was driving day-to-day policy. There was no leadership in the Defense Department, as both Democrats and Republicans waited for the Supreme Court to decide the fate of the Presidency.

The predictable result was an increase in provocative behavior by Chinese fighter pilots who were assigned to monitor and shadow the reconnaissance flights. This evolved into a pattern of harassment in which a Chinese jet would maneuver a few dozen yards in front of the slow, plodding EP-3E, and suddenly blast on its afterburners, soaring away and leaving behind a shock wave that severely rocked the American aircraft. On April 1, 2001, the Chinese pilot miscalculated the distance between his plane and the American aircraft. It was a mistake with consequences for the American debate on cyber security that have yet to be fully reckoned.

For what went wrong after that, read the rest of the story!

Apple's Mac moment of truth arriving? Or just the silver bullet salesman?

Mac's moment of truth is arriving:

"We are approaching a tipping point, where it will soon be financially viable for cybercriminals to target their efforts at Mac users," says Ivan Fermon, senior vice president of product management, Panda Security. "When Apple reaches 15 percent market share worldwide, which Panda expects will happen very soon, we predict that hackers will begin to aggressively target attacks against this platform. The rapid increase in use of Apple-powered devices--iPhones, iPods, iPads--is also making the Mac platform a much more attractive target."

Not just any tipping point, the one where crooks target the platform. It is an interesting phenomena when such a large user base as Macs aren't an appealing target, but what can one say? It's a theory... More numbers:

"We receive an average of 55,000 new threats every day at PandaLabs. .... Panda has identified approximately 5,000 malware variants that specifically target Apple systems, and claims to see an average of 500 new samples each month. The Mac has been getting more security research and attention as well. There were only 34 vulnerabilities identified for the Mac in 2009, but with two months to go that number is already at 175 for 2010.

I'm not sure what to make of 55,000 new threats per day, does that mean PandaLabs has a factory of 1000 people with targets to qualify 55 threats per day? Outstanding productivity! But I know what to make of this:

So, the short answer to the question of whether or not your Mac needs malware protection is "Yes". Or, at least, it will soon need malware protection if the Apple platform continues to grow as a lucrative target. Consider it a badge of honor in recognition of gaining enough market share for cyber criminals to care. That is why Panda Security is launching Panda Antivirus for Macintosh.

Ahhh... So all the rest is in support of a sales call from our friendly silver bullet salesman. Well, of course :)

Cryptographic Numerology - our number is up

Chit-chat around the coffeerooms of crypto-plumbers is disturbed by NIST's campaign to have all the CAs switch up to 2048 bit roots:

On 30/09/10 5:17 PM, Kevin W. Wall wrote:

> Thor Lancelot Simon wrote:
> See below, which includes a handy pointer to the Microsoft and Mozilla policy statements "requiring" CAs to cease signing anything shorter than 2048 bits.

<...snip...>

> These certificates (the end-site ones) have lifetimes of about 3 years maximum. Who here thinks 1280 bit keys will be factored by 2014? *Sigh*.

No one that I know of (unless the NSA folks are hiding their quantum computers from us :). But you can blame this one on NIST, not Microsoft or Mozilla. They are pushing the CAs to make this happen and I think 2014 is one of the important cutoff dates, such as the date that the CAs have to stop issuing certs with 1024-bit keys.

I can dig up the NIST URL once I get back to work, assuming anyone actually cares.

The world of cryptology has always been plagued by numerology.

Not so much in the tearooms of the pure mathematicians, but all other areas: programming, management, provisioning, etc. It is I think a desperation in the un-endowed to understand something, anything of the topic.

E.g., I might have no clue how RSA works but I can understand that 2048 has to be twice as good as 1024, right? When I hear it is even better than twice, I'm overjoyed!

This desperation to be able to talk about it is partly due to having to be part of the business (write some code, buy a cert, make a security decision, sell a product) and partly a sense of helplessness when faced with apparently expert and confident advice. It's not an unfounded fear; experts use their familiarity with the concepts to also peddle other things which are frequently bogus or hopeful or self-serving, so the ignorance leads to bad choices being made.

Those that aren't in the know are powerless, and shown to be powerless.

When something simple comes along and fills that void people grasp onto them and won't let go. Like numbers. As long as they can compare 1024 to 2048, they have a safety blanket that allows them to ignore all the other words. As long as I can do my due diligence as a manager (ensure that all my keys are 2048) I'm golden. I've done my part, prove me wrong! Now do your part!

This is a very interesting problem [1]. Cryptographic numerology diverts attention from the difficult to the trivial. A similar effect happens with absolute security, which we might call "divine cryptography." Managers become obsessed with perfection in one thing, to the extent that they will ignore flaws in another thing. Also, standards, which we might call "beliefs cryptography" for their ability to construct a paper cathedral within which there is room for us all, and our flock, to pray safely inside.

We know divinity doesn't exist, but people demand it. We know that religions war all the time, and those within a religion will discriminate against others, to the loss of us all. We know all this, but we don't; cognitive dissonance makes us so much happier, it should be a drug.

It was into this desperate aching void that the seminal paper by Lenstra and Verheul stepped in to put a framework on the numbers [2]. On the surface, it solved the problem of cross-domain number comparison, e.g., 512 bit RSA compared to 256 bit AES, which had always confused the managers. And to be fair, this observation was a long time coming in the cryptographic world, too, which makes L&V's paper a milestone.

Cryptographic Numerology's star has been on the ascent ever since that paper: As well as solving the cipher-public-key-hash numeric comparison trap, numerology is now graced with academic respectability.

This made it irresistible to large institutions which are required to keep their facade of advice up. NIST like all the other agencies followed, but NIST has a couple of powerful forces on it. Firstly, NIST is slightly special, in ways that other agencies represented in keylength.com only wish to be special. NIST, as pushed by the NSA, is protecting primarily US government resources:

This document has been developed by the National Institute of Standards and Technology (NIST) in furtherance of its statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347. NIST is responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets, but such standards and guidelines shall not apply to national security systems.

That's US not us. It's not even protecting USA industry. NIST is explicitly targetted by law to protect the various multitude of government agencies that make up the beast we know as the Government of the United States of America. That gives it unquestionable credibility.

And, as has been noticed a few times, Mars is on the ascendancy: *Cyberwarfare* is the second special force. Whatever one thinks of the mess called cyberwarfare (equity disaster, stuxnet, cryptographic astrology, etc) we can probably agree, if anyone bad is thinking in terms of cracking 1024 bit keys, then they'll be likely another nation-state interested in taking aim against the USG agencies. c.f., stuxnet, which is emerging as a state v. state adventure. USG, or one of USG's opposing states, are probably the leading place on the planet that would face a serious 1024 bit threat if one were to emerge.

Hence, NIST is plausibly right in imposing 2048-bit RSA keys into its security model. And they are not bad in the work they do, for their client [3]. Numerology and astrology are in alignment today, if your client is from Washington DC.

However, real or fantastical, this is a threat model that simply doesn't apply to the rest of the world. The sad sad fact is that NIST's threat model belongs to them, to US, not to us. We all adopting the NIST security model is like a Taurus following the advice in the Aries section of today's paper. It's not right, however wise it sounds. And if applied without thought, it may reduce our security not improve it:

Writes Thor:
> At 1024 bits, it is not. But you are looking
> at a factor of *9* increase in computational
> cost when you go immediately to 2048 bits. At
> that point, the bottleneck for many applications
> shifts, particularly those ...
> Also,...
> ...and suddenly...
>
> This too will hinder the deployment of "SSL everywhere",...

When US industry follows NIST, and when worldwide industry follows US industry, and when open source Internet follows industry, we have a classic text-book case of adopting someone else's threat, security and business models without knowing it.

Keep in mind, our threat model doesn't include crunching 1024s. At all, any time, nobody's ever bothered to crunch 512 in anger, against the commercial or private world. So we're pretty darn safe at 1024. But our threat model does include

*attacks on poor security user interfaces in online banking*

That's a clear and present danger. And one of the key, silent, killer causes of that is the sheer rarity of HTTPS. If we can move the industry to "HTTPS everywhere" then we can make a significant different. To our security.

On the other hand, we can shift to 2048, kill the move to "HTTPS everywhere", and save the US Government from losing sleep over the cyberwarfare it created for itself (c.f., the equity failure).

And that's what's going to happen. Cryptographic Numerology is on a roll, NIST's dice are loaded, our number is up. We have breached the law of unintended consequences, and we are going to be reducing the security of the Internet because of it. Thanks, NIST! Thanks, Mozilla, thanks, Microsoft.

[2] For detailed work and references on Lenstra & Verheul's paper, see http://www.keylength.com/ which includes calculators of many of the various efforts. It's a good paper. They can't be criticised for it in the terms in this post, it's the law of unintended consequences again.

[3] Also, other work by NIST to standardise the PRNG (psuedo-random-number-generator) has to be applauded. The subtlety of what they have done is only becoming apparent after much argumentation: they've unravelled the unprovable entropy problem by unplugging it from the equation.

But they've gone a step further than the earlier leading work by Ferguson and Schneier and the various quiet cryptoplumbers, by turning the PRNG into a deterministic algorithm. Indeed, we can now see something special: NIST has turned the PRNG into a reverse-cycle message digest. Entropy is now the MD's document, and the psuedo-randomness is the cryptographically-secure hash that spills out of the algorithm.

Hey Presto! The PRNG is now the black box that provides the one-way expansion of the document. It's not the reverse-cycle air conditioning of the message digest that is exciting here, it's the fact that it is now a new class of algorithms. It can be specified, paramaterised, and most importantly for cryptographic algorithms, given test data to prove the coding is correct.

(I use the term reverse-cycle in the sense of air-conditioning. I should also stress that this work took several generations to get to where it is today; including private efforts by many programmers to make sense of PRNGs and entropy by creating various application designs, and a couple of papers by Ferguson and Schneier. But it is the black-boxification by NIST that took the critical step that I'm lauding today.)

Crypto-plumbers versus the Men in Black, round 16.

Skype, RIM, and now CircleTech v. the governments. This battle has been going on for a while. Here's today's battle results:

BIS [Czech counter-intelligence] officers first offered to Satanek that his firm would supply an encryption system with "a defect" to the market which would help the secret service find out the content of encrypted messages. "This is out of question. It is as if we were proclaiming we are selling bullet-proof vests that would actually not be bullet-proof," Satanek told MfD.

This is why BIS offered a deal to the firm's owners. BIS wanted CircleTech to develop a programme to decipher the codes. It would only partially help the secret service since not even CircleTech is capable of developing a universal key to decipher all of its codes. Nevertheless, software companies are offering such partial services, and consequently it would not be a problem for CircleTech to meet the order, MfD notes.

However, BIS officers said the firm need not register the money it would receive from BIS for the order, the paper writes. "You will have on opportunity to get an income that need not be subject to taxation," MfD cites the secret recording of a BIS officer at a meeting with the firm. Satanek rejected the offer and recorded the meetings with BIS.

BIS then gave it up. However, two months ago it contacted Satanek again, MfD writes. "They told me that we are allegedly meeting suspicious persons who pose a security risk to the state. In such a case we may not pass security vetting of the National Security Office (NBU)," Satanek told MfD.

Subversion, bribes, and threats, it's all in there! And, no wonder every hot new code jockey goes all starry-eyed at the thought of working on free, open encryption systems.

threatwatch: 1st signs of attacks on certificates?

An Adobe PDF is being circulated in spam that exploits bugs in Adobe's Reader and/or Windows. The PDF itself is code-signed by a stolen certificate:

The attack, which has been spotted attached to e-mails touting renowned golf coach and author David Leadbetter, also includes a malicious file that's digitally signed with a valid signature from Missouri-based Vantage Credit Union.

VeriSign has revoked the signature, but the already baked malware will still carry what appears to be a valid digital signature, Wisniewski said.

Then, there's a hint of speculation that the expected users of the certificate will be fine. That is, people logging into the Vantage Credit Union will be facing a new certificate as soon as it is in place.

No mention of what happens to the people who aren't doing that, and when they can expect their fix, sometimes known as revocation.

[Wisniewski] compared the Reader zero-day exploit with the Stuxnet worm, which caused concern in July when it was discovered attacking industrial control systems at large manufacturing and utility companies. Symantec traced Stuxnet back to June 2009, with attacks likely beginning the following month, when hackers apparently stole digital certificate keys from a pair of Taiwanese software firms and then used them to sign two versions of the worm.

"This makes two [attacks] that have used valid certificates," Wisniewski said. "I'm starting to wonder if [hackers] aren't using other malware that's specifically targeting certificates and their keys."

One of the things that was very evident in the last decade as phishing rose up to challenge secure browsing, and now similar things like Money/Quicken "embedded" access over SSL, is this: why aren't more attacks simply stealing the certificates or buying them with bad intentions?

We theorised that the ordinary downgrade to HTTP was the best alternative. Crooks being economic, that is. This may be the first public signs of a shift or broadening to attacking the certificate itself. There have been private signs of worry for the last year or so.

Security Planning - who watches the watchers?

I spotted this on a Git doco page:

As the comments on miskan's page intimate, there is a logic there if one is desperate...

profound misunderstandability in your employee's psyche

Speaking of profound misunderstandings, this:

BitDefender created a "test profile" of a nonexistent, 21-year-old woman described as a "fair-haired" and "very, very naïve interlocutor" -- basically a hot rube who was just trying to "figure out how this whole social networking thing worked" by asking a bunch of seemingly innocent, fact-finding questions.

With the avatar created, the fictitious person then sent out 2,000 "friendship requests," relying on the bogus description and made-up interests as the presumptive lure. Of the 2,000 social networks pinged with a "friendship" request, a stunning 1,872 accepted the invitation. And the vast majority (81 percent) of them did it without asking any questions at all. Others asked a question or two, presumably like, "Who are you?" or "How do I know you?" before eventually adding this new "friend."

...

But it gets worse. An astonishing 86 percent of those who accepted the bogus profile's "friendship" request identified themselves as working in the IT industry. Even worse, 31 percent said they worked in some capacity in IT security.

Turning the Honeypot

I'm reading a govt. security manual this weekend, because ... well, doesn't everyone?

To give it some grounding, I'm building up a cross-reference against my work at the CA. I expected it to remain rather dry until the very end, but I've just tripped up on this Risk in the section on detecting incidents:

2.5.7. An agency constructs a honeypot or honeynet to assist in capturing intrusion attempts, resulting in legal action being taken against the agency for breach of privacy.

My-oh-my!

Hacking the Apple, when where how... and whether we care why?

One of the things that has been pretty much standard in infosec is that the risks earnt (costs incurred!) from owning a Mac have been dramatically lower. I do it, and save, and so do a lot of my peers & friends. I don't collect stats, but here's a comment from Dan Geer from 2005:

Amongst the cognoscenti, you can see this: at security conferences of all sorts you’ll find perhaps 30% of the assembled laptops are Mac OS X, and of the remaining Intel boxes, perhaps 50% (or 35% overall) are Linux variants. In other words, while security conferences are bad places to use a password in the clear monoculture on the back of the envelope over a wireless channel, there is approximately zero chance of cascade failure amongst the participants.

I recommend it on the blog front page as the number 1 security tip of all:

Why this is the case is of course a really interesting question. Is it because Macs are inherently more secure, in themselves? The answer seems to be No, not in themselves. We've seen enough evidence to suggest, at an anecdotal level, that when put into a fair fight, the Macs don't do any better than the competition. (Sometimes they do worse, and the competition ensures those results are broadcast widely :)

However it is still the case that the while the security in the Macs aren't great, the result for the user is better -- the costs resulting from breaches, installs, virus slow-downs, etc, remain lower [1]. Which would imply the threats are lower, recalling the old mantra of:

Business model ⇒ threat model ⇒ security model

Now, why is the threat (model) lower? It isn't because the attackers are fans. They generally want money, and money is neutral.

One theory that might explain it is the notion of monoculture.

This idea was captured a while back by Dan Geer and friends in a paper that claimed that the notion of Microsoft's dominance threated the national security of the USA. It certainly threatened someone, as Dan lost his job the day the paper was released [2].

In brief, monoculture argues that when one platform gains an ascendency to dominate the market, then we enter a situation of particular vulnerability to that platform. It becomes efficient for all economically-motivated attackers to concentrate their efforts on that one dominant platform and ignore the rest.

In a sense, this is an application of the Religion v. Darwin argument to computer security. Darwin argued that diversity was good for the species as a whole, because singular threats would wipe out singular species. The monoculture critique can also be seen as analogous to Capitalism v. Communism, where the former advances through creative destruction, and the latter stagnates through despotic ignorance.

A lot of us (including me) looked at the monoculture argument and thought it ... simplistic and hopeful. Yet, the idea hangs on ... so the question shifts for us slower skeptics to how to prove it [3]?

Apple is quietly wrestling with a security conundrum. How the company handles it could dictate the pace at which cybercriminals accelerate attacks on iPhones and iPads.

Apple is hustling to issue a patch for a milestone security flaw that makes it possible to remotely hack - or jailbreak - iOS, the operating system for iPhones, iPads and iPod Touch.

Apple's new problem is perhaps early signs of good evidence that the theory is good. Here we have Apple struggling with hacks on its mobile platform (iPads, iPods, iPhones) and facing a threat which it seemingly hasn't faced on the Macs [4].

The differentiating factor -- other than the tech stuff -- is that Apple is leading in the mobile market.

IPhones, in particular, have become a pop culture icon in the U.S., and now the iPad has grabbed the spotlight. "The more popular these devices become, the more likely they are to get the attention of attackers," says Joshua Talbot, intelligence manager at Symantec Security Response.

Not dominating like Microsoft used to enjoy, but presenting enough of a nose above the pulpit to get a shot taken. Meanwhile, Macs remain stubbornly stuck at a reported 5% of market share in the computer field, regardless of the security advice [5]. And nothing much happens to them.

If market leadership continues to accrue to Apple in the iP* mobile sector, as the market expect it does, and if security woes continue as well, I'd count that as good evidence [6].

[2] Perhaps because Dan lost his job, he gets fuller attention. The full cite would be like: Daniel Geer, Rebecca Bace, Peter Gutmann, Perry Metzger, Charles P. Pfleeger, John S. Quarterman, Bruce Schneier, "CyberInsecurity: The Cost of Monopoly How the Dominance of Microsoft's Products Poses a Risk to Security." Preserved by the inestimable cryptome.org, a forerunner of the now infamous wikileaks.org.

[3] Proof in the sense of scientific method is not possible, because we can't run the experiment. This is economics, not science, we can't run the experiment like real scientists. What we have to do is perhaps psuedo-scientific-method; we predict, we wait, and we observe.

[4] On the other hand, maybe the party is about to end for Macs. News just in:

Security vendor M86 Security says it's discovered that a U.K.-based bank has suffered almost $900,000 (675,000 Euros) in fraudulent bank-funds transfers due to the ZeuS Trojan malware that has been targeting the institution.

Bradley Anstis, vice president of technology strategy at M86 Security, said the security firm uncovered the situation in late July while tracking how one ZeuS botnet had been specifically going after the U.K.-based bank and its customers. The botnet included a few hundred thousand PCs and even about 3,000 Apple Macs, and managed to steal funds from about 3,000 customer accounts through unauthorized transfers equivalent to roughly $892,755.

Ouch!

[4] I don't believe the 5% market share claim ... I harbour a suspicion that this is some very cunning PR trick in under-reporting by Apple, so as to fly below the radar. If so, I think it's well past its sell-by date since Apple reached the same market cap as Microsoft...

[5] What is curious is that I'll bet most of Wall Street, and practically all of government, notwithstanding the "national security" argument, continue to keep clear of Macs. For those of us who know the trick, this is good. It is good for our security nation if the governments do not invest in Macs, and keep the monoculture effect positive. Perverse, but who am I to argue with the wisdom in cyber-security circles?

memes in infosec I - Eve and Mallory are missing, presumed dead

Things I've seen that are encouraging. Bruce Schneier in Q&A:

Q: We've also seen Secure Sockets Layer (SSL) come under attack, and some experts are saying it is useless. Do you agree?

A: I'm not convinced that SSL has a problem. After all, you don't have to use it. If I log-on to Amazon without SSL the company will still take my money. The problem SSL solves is the man-in-the-middle attack with someone eavesdropping on the line. But I'm not convinced that's the most serious problem. If someone wants your financial data they'll hack the server holding it, rather than deal with SSL.

Right. The essence is that SSL solves the "easy" part of the problem, and leaves open the biggest part. Before the proponents of SSL say, "not our problem," remember that AADS did solve it, as did SOX and a whole bunch of other things. It's called end-to-end, and is well known as being the only worthwhile security. Indeed, I'd say it was simply responsible engineering, except for the fact that it isn't widely practiced.

OK, so this is old news, from around March, but it is worth declaring sanity:

Q: But doesn't SSL give consumers confidence to shop online, and thus spur e-commerce?

A: Well up to a point, but if you wanted to give consumers confidence you could just put a big red button on the site saying 'You're safe'. SSL doesn't matter. It's all in the database. We've got the threat the wrong way round. It's not someone eavesdropping on Eve that's the problem, it's someone hacking Eve's endpoint.

Which is to say, if you are going to do anything to fix the problem, you have to look at the end-points. The only time you should look at the protocol, and the certificates, is how well they are protecting the end-points. Meanwhile, the SSL field continues to be one for security researchers to make headlines over. It's BlackHat time again:

"The point is that SSL just doesn't do what people think it does," says Hansen, an security researcher with SecTheory who often goes by the name RSnake. Hansen split his dumptruck of Web-browsing bugs into three categories of severity: About half are low-level threats, 10 or so are medium, and two are critical. One example...

Many observers in the security world have known this for a while, and everyone else has felt increasingly frustrated and despondent about the promise:

There has been speculation that an organization with sufficient power would be able to get a valid certificate from one of the 170+ certificate authorities (CAs) that are installed by default in the typical browser and could then avoid this alert ....

But how many CAs does the average Internet user actually need? Fourteen! Let me explain. For the past two weeks I have been using Firefox on Windows with a reduced set of CAs. I disabled ALL of them in the browser and re-enabled them one by one as necessary during my normal usage....

On the one hand, SSL is the brand of security. On the other hand, it isn't the delivery of security; it simply isn't deployed in secure browsing to provide the user security that was advertised: you are on the site you think you are on. Only as we moved from a benign world to a fraud world, around 2003-2005, this has this been shown to matter. Bruce goes on:

Q: So is encryption the wrong approach to take?

A: This kind of issue isn't an authentication problem, it's a data problem. People are recognising this now, and seeing that encryption may not be the answer. We took a World War II mindset to the internet and it doesn't work that well. We thought encryption would be the answer, but it wasn't. It doesn't solve the problem of someone looking over your shoulder to steal your data.

Indeed. Note that comment about the World War II mindset. It is the case that the entire 1990s generation of security engineers were taught from the military text book. The military assumes its nodes -- its soldiers, its computers -- are safe. And, it so happens, that when armies fight armies, they do real-life active MITMs against each other to gain local advantage. There are cases of this happening, and oddly enough, they'll even do it to civilians if they think they can (ask Greenpeace). And the economics is sane, sensible stuff, if we bothered to think about it: in war, the wire is the threat, the nodes are safe.

However, adopting "the wire" as the weakness and Mallory as the Man-In-The-Middle, and Eve as the Eavesdropper as "the threat" in the Internet was a mistake. Even in the early 1990s, we knew that the node was the problem. Firstly, ever since the PC, nodes in commercial computing are controlled by (dumb) users not professional (soldiers). Who download shit from the net, not operate trusted military assets. Secondly, observation of known threats told us where the problems lay: floppy viruses were very popular, and phone-line attacks were about spoofing and gaining entry to an end-point. Nobody was bothering with "the wire," nobody was talking about snooping and spying and listening [*].

The military model was the precise reverse of the Internet's reality.

To conclude. There is no doubt about this in security circles: the SSL threat model was all wrong, and consequently the product was deployed badly.

Where the doubt lies is how long it will take the software providers to realise that their world is upside down? It can probably only happen when everyone with credibility stands up and says it is so. For this, the posts shown here are very welcome. Let's hear more!

PS: Memes II - War! Infosec is WAR!

Why the browsers must change their old SSL security (?) model

In a paper Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL_, by Christopher Soghoian and Sid Stammby, there is a reasonably good layout of the problem that browsers face in delivering their "one-model-suits-all" security model. It is more or less what we've understood all these years, in that by accepting an entire root list of 100s of CAs, there is no barrier to any one of them going a little rogue.

Of course, it is easy to raise the hypothetical of the rogue CA, and even to show compelling evidence of business models (they cover much the same claims with a CA that also works in the lawful intercept business that was covered here in FC many years ago). Beyond theoretical or probable evidence, it seems the authors have stumbled on some evidence that it is happening:

The company’s CEO, Victor Oppelman confirmed, in a conversation with the author at the company’s booth, the claims made in their marketing materials: That government customers have compelled CAs into issuing certificates for use in surveillance operations. While Mr Oppelman would not reveal which governments have purchased the 5-series device, he did confirm that it has been sold both domestically and to foreign customers.

(my emphasis.) This has been a lurking problem underlying all CAs since the beginning. The flip side of the trusted-third-party concept ("TTP") is the centralised-vulnerability-party or "CVP". That is, you may have been told you "trust" your TTP, but in reality, you are totally vulnerable to it. E.g., from the famous Blackberry "official spyware" case:

Nevertheless, hundreds of millions of people around the world, most of whom have never heard of Etisalat, unknowingly depend upon a company that has intentionally delivered spyware to its own paying customers, to protect their own communications security.

Which becomes worse when the browsers insist, not without good reason, that the root list is hidden from the consumer. The problem that occurs here is that the compelled CA problem multiplies to the square of the number of roots: if a CA in (say) Ecuador is compelled to deliver a rogue cert, then that can be used against a CA in Korea, and indeed all the other CAs. A brief examination of the ways in which CAs work, and browsers interact with CAs, leads one to the unfortunate conclusion that nobody in the CAs, and nobody in the browsers, can do a darn thing about it.

So it then falls to a question of statistics: at what point do we believe that there are so many CAs in there, that the chance of getting away with a little interception is too enticing? Square law says that the chances are say 100 CAs squared, or 10,000 times the chance of any one intercept. As we've reached that number, this indicates that the temptation to resist intercept is good for all except 0.01% of circumstances. OK, pretty scratchy maths, but it does indicate that the temptation is a small but not infinitesimal number. A risk exists, in words, and in numbers.

One CA can hide amongst the crowd, but there is a little bit of a fix to open up that crowd. This fix is to simply show the user the CA brand, to put faces on the crowd. Think of the above, and while it doesn't solve the underlying weakness of the CVP, it does mean that the mathematics of squared vulnerability collapses. Once a user sees their CA has changed, or has a chance of seeing it, hiding amongst the crowd of CAs is no longer as easy.

Why then do browsers resist this fix? There is one good reason, which is that consumers really don't care and don't want to care. In more particular terms, they do not want to be bothered by security models, and the security displays in the past have never worked out. Gerv puts it this way in comments:

Security UI comes at a cost - a cost in complexity of UI and of message, and in potential user confusion. We should only present users with UI which enables them to make meaningful decisions based on information they have.

They love Skype, which gives them everything they need without asking them anything. Which therefore should be reasonable enough motive to follow those lessons, but the context is different. Skype is in the chat & voice market, and the security model it has chosen is well-excessive to needs there. Browsing on the other hand is in the credit-card shopping and Internet online banking market, and the security model imposed by the mid 1990s evolution of uncontrollable forces has now broken before the onslaught of phishing & friends.

In other words, for browsing, the writing is on the wall. Why then don't they move? In a perceptive footnote, the authors also ponder this conundrum:

3. The browser vendors wield considerable theoretical power over each CA. Any CA no longer trusted by the major browsers will have an impossible time attracting or retaining clients, as visitors to those clients’ websites will be greeted by a scary browser warning each time they attempt to establish a secure connection. Nevertheless, the browser vendors appear loathe to actually drop CAs that engage in inappropriate be- havior — a rather lengthy list of bad CA practices that have not resulted in the CAs being dropped by one browser vendor can be seen in [6].

I have observed this for a long time now, predicting phishing until it became the flood of fraud. The answer is, to my mind, a complicated one which I can only paraphrase.

For Mozilla, the reason is simple lack of security capability at the *architectural* and *governance* levels. Indeed, it should be noticed that this lack of capability is their policy, as they deliberately and explicitly outsource big security questions to others (known as the "standards groups" such as IETF's RFC committees). As they have little of the capability, they aren't in a good position to use the power, no matter whether they would want to or not. So, it only needs a mildly argumentative approach on the behalf of the others, and Mozilla is restrained from its apparent power.

What then of Microsoft? Well, they certainly have the capability, but they have other fish to fry. They aren't fussed about the power because it doesn't bring them anything of use to them. As a corporation, they are strictly interested in shareholders' profits (by law and by custom), and as nobody can show them a bottom line improvement from CA & cert business, no interest is generated. And without that interest, it is practically impossible to get the various many groups within Microsoft to move.

Unlike Mozilla, my view of Microsoft is much more "external", based on many observations that have never been confirmed internally. However it seems to fit; all of their security work has been directed to market interests. Hence for example their work in identity & authentication (.net, infocard, etc) was all directed at creating the platform for capturing the future market.

What is odd is that all CAs agree that they want their logo on their browser real estate. Big and small. So one would think that there was a unified approach to this, and it would eventually win the day; the browser wins for advancing security, the CAs win because their brand investments now make sense. The consumer wins for both reasons. Indeed, early recommendations from the CABForum, a closed group of CAs and browsers, had these fixes in there.

But these ideas keep running up against resistance, and none of the resistance makes any sense. And that is probably the best way to think of it: the browsers don't have a logical model for where to go for security, so anything leaps the bar when the level is set to zero.

Which all leads to a new group of people trying to solve the problem. The authors present their model as this:

The Firefox browser already retains history data for all visited websites. We have simply modified the browser to cause it to retain slightly more information. Thus, for each new SSL protected website that the user visits, a Certlock enabled browser also caches the following additional certificate information:

A hash of the certificate. The country of the issuing CA. The name of the CA. The country of the website. The name of the website. The entire chain of trust up to the root CA.

When a user re-visits a SSL protected website, Certlock first calculates the hash of the site’s certificate and compares it to the stored hash from previous visits. If it hasn’t changed, the page is loaded without warning. If the certificate has changed, the CAs that issued the old and new certificates are compared. If the CAs are the same, or from the same country, the page is loaded without any warning. If, on the other hand, the CAs’ countries differ, then the user will see a warning (See Figure 3).

This isn't new. The authors credit recent work, but no further back than a year or two. Which I find sad because the important work done by TrustBar and Petnames is pretty much forgotten.

But it is encouraging that the security models are battling it out, because it gets people thinking, and challenging their assumptions. Only actual produced code, and garnered market share is likely to change the security benefits of the users. So while we can criticise the country approach (it assumes a sort of magical touch of law within the countries concerned that is already assumed not to exist, by dint of us being here in the first place), the country "proxy" is much better than nothing, and it gets us closer to the real information: the CA.

From a market for security pov, it is an interesting period. The first attempts around 2004-2006 in this area failed. This time, the resurgence seems to have a little more steam, and possibly now is a better time. In 2004-2006 the threat was seen as more or less theoretical by the hoi polloi. Now however we've got governments interested, consumers sick of it, and the entire military-industrial complex obsessed with it (both in participating and fighting). So perhaps the newcomers can ride this wave of FUD in, where previous attempts drowned far from the shore.

Phishing numbers

From a couple of sources posted by Lynn:

• A single run only hits 0.0005 percent of users,
• 1% of customers will follow the phishing links.
• 0.5% of customers fall for phishing schemes and compromise their online banking information.
• the monetary losses could range between $2.4 million and $9.4 million annually per one million online banking clients
• in average ... approximately 832 a year ... reached users' inboxes.
• costs estimated at up to $9.4 million per year per million users.
• based on data colleded from "3 million e-banking users who are customers of 10 sizeable U.S. and European banks."

The primary source was a survey run by an anti-phishing software vendor, so caveats apply. Still interesting!

For more meat on the bigger picture, see this article: Ending the PCI Blame Game. Which reads like a compressed version of this blog! Perhaps, finally, the thing that is staring the financial operators in the face has started to hit home, and they are really ready to sound the alarm.

Breaches not as disclosed as much as we had hoped

One of the brief positive spots in the last decade was the California bill to make breaches of data disclosed to effected customers. It took a while, but in 2005 the flood gates opened. Now reports the FBI:

"Of the thousands of cases that we've investigated, the public knows about a handful," said Shawn Henry, assistant director for the Federal Bureau of Investigation's Cyber Division. "There are million-dollar cases that nobody knows about."

That seems to point at a super-iceberg. To some extent this is expected, because companies will search out new methods to bypass the intent of the disclosure laws. And also there is the underlying economics. As has been pointed out by many (or perhaps not many but at least me) the reputation damage probably dwarfs the actual or measurable direct losses to the company and its customers.

Companies that are victims of cybercrime are reluctant to come forward out of fear the publicity will hurt their reputations, scare away customers and hurt profits. Sometimes they don't report the crimes to the FBI at all. In other cases they wait so long that it is tough to track down evidence.

So, avoidance of disclosure is the strategy for all properly managed companies, because they are required to manage the assets of their shareholders to the best interests of the shareholders. If you want a more dedicated treatment leading to this conclusion, have a look at "the market for silver bullets" paper.

Meanwhile, the FBI reports that the big companies have improved their security somewhat, so the attackers direct at smaller companies. And:

They also target corporate executives and other wealthy public figures who it is relatively easy to pursue using public records. The FBI pursues such cases, though they are rarely made public.

Huh. And this outstanding coordinated attack:

A similar approach was used in a scheme that defrauded the Royal Bank of Scotland's (RBS.L: Quote, Profile, Research, Stock Buzz) RBS WorldPay of more than $9 million. A group, which included people from Estonia, Russia and Moldova, has been indicted for compromising the data encryption used by RBS WorldPay, one of the leading payment processing businesses globally.

The ring was accused of hacking data for payroll debit cards, which enable employees to withdraw their salaries from automated teller machines. More than $9 million was withdrawn in less than 12 hours from more than 2,100 ATMs around the world, the Justice Department has said.

2,100 ATMs! worldwide! That leaves that USA gang looking somewhat kindergarten, with only 50 ATMs cities. No doubt about it, we're now talking serious networked crime, and I'm not referring to the Internet but the network of collaborating, economic agents.

Compromising the data encryption, even. Anyone know the specs? These are important numbers. Did I miss this story, or does it prove the FBI's point?

Man-in-the-Browser goes to court

Stephen Mason reports that MITB is in court:

A gang of internet fraudsters used a sophisticated virus to con members of the public into parting with their banking details and stealing £600,000, a court heard today.

Once the 'malicious software' had infected their computers, it waited until users logged on to their accounts, checked there was enough money in them and then insinuated itself into cash transfer procedures.

(also on El Reg.) This breaches the 2-factor authentication system commonly in use because it (a) controls the user's PC, and (b) the authentication scheme that was commonly pushed out over the last decade or so only authenticates the user, not the transaction. So as the trojan now controls the PC, it is the user. And the real user happily authenticates itself, and the trojan, and the trojan's transactions, and even lies about it!

Numbers, more than ordinarily reliable because they have been heard in court:

'In fact as a result of this Trojan virus fraud very many people - 138 customers - were affected in this way with some £600,000 being fraudulently transferred.

'Some of that money, £140,000, was recouped by NatWest after they became aware of this scam.'

This is called Man-in-the-browser, which is a subtle reference to the SSL's vaunted protection against Man-in-the-middle. Unfortunately several things went wrong in this area of security: Adi's 3rd law of security says the attacker always bypasses; one of my unnumbered aphorisms has it that the node is always the threat, never the wire, and finally, the extraordinary success of SSL in the mindspace war blocked any attempts to fix the essential problems. SSL is so secure that nobody dare challenge browser security.

The MITB was first reported in March 2006 and sent a wave of fear through the leading European banks. If customers lost trust in the online banking, this would turn their support / branch employment numbers on their heads. So they rapidly (for banks) developed a counter-attack by moving their confirmation process over to the SMS channel of users' phones. The Man-in-the-browser cannot leap across that air-gap, and the MITB is more or less defeated.

European banks tend to be proactive when it comes to security, and hence their losses are miniscule. Reported recently was something like €400k for a smaller country (7 million?) for an entire year for all banks. This one case in the UK is double that, reflecting that British banks and USA banks are reactive to security. Although they knew about it, they ignored it.

This could be called the "prove-it" school of security, and it has merit. As we saw with SSL, there never really was much of a threat on the wire; and when it came to the node, we were pretty much defenceless (although a lot of that comes down to one factor: Microsoft Windows). So when faced with FUD from the crypto / security industry, it is very very hard to separate real dangers from made up ones. I felt it was serious; others thought I was spreading FUD! Hence Philipp Güring's paper Concepts against Man-in-the-Browser Attacks, and the episode formed fascinating evidence for the market for silver bullets. The concept is now proven right in practice, but it didn't turn out how we predicted.

What is also interesting is that we now have a good cycle timeline: March 2006 is when the threat first crossed our radars. September 2009 it is in the British courts.

Postscript. More numbers from today's MITB:

A next-generation Trojan recently discovered pilfering online bank accounts around the world kicks it up a notch by avoiding any behavior that would trigger a fraud alert and forging the victim's bank statement to cover its tracks.

The so-called URLZone Trojan doesn't just dupe users into giving up their online banking credentials like most banking Trojans do: Instead, it calls back to its command and control server for specific instructions on exactly how much to steal from the victim's bank account without raising any suspicion, and to which money mule account to send it the money. Then it forges the victim's on-screen bank statements so the person and bank don't see the unauthorized transaction.

Researchers from Finjan found the sophisticated attack, in which the cybercriminals stole around 200,000 euro per day during a period of 22 days in August from several online European bank customers, many of whom were based in Germany....

"The Trojan was smart enough to be able to look at the [victim's] bank balance," says Yuval Ben-Itzhak, CTO of Finjan... Finjan found the attackers had lured about 90,000 potential victims to their sites, and successfully infected about 6,400 of them. ...URLZone ensures the transactions are subtle: "The balance must be positive, and they set a minimum and maximum amount" based on the victim's balance, Ben-Itzhak says. That ensures the bank's anti-fraud system doesn't trigger an alert, he says.

And the malware is making the decisions -- and alterations to the bank statement -- in real time, he says. In one case, the attackers stole 8,576 euro, but the Trojan forged a screen that showed the transferred amount as 53.94 euro. The only way the victim would discover the discrepancy is if he logged into his account from an uninfected machine.

OSS on how to run a business

After a rather disastrous meeting a few days ago, I finally found the time to load up:

The Office of Strategic Services was the USA dirty tricks brigade of WWII, which later became the CIA. Their field manual was declassified and published, and, lo and behold, it includes some mighty fine advice. This manual was noticed to the world by the guy who presented the story of the CIA's "open intel" wiki, he thought it relevant I guess.

Sections 11, 12 are most important to us, the rest concentrating on the physical spectrum of blowing up stuff. Onwards:

(11) General Interference with Organizations and Production (a) Organizations and Conferences (1) Insist on doing everything through "channels." Never permit short-cuts to be taken in order to, expedite decisions. (2) Make "speeches." Talk as frequently as possible and at great length. Illustrate your "points" by long anecdotes and accounts of personal experiences. Never hesitate to make a few appropriate "patriotic" comments. (3) When possible, refer all matters to committees, for "further study and consideration." Attempt to make the committees as large as possible - never less than five. (4) Bring up irrelevant issues as frequently as possible. (5) Haggle over precise wordings of communications, minutes, resolutions. (6) Refer back to matters decided upon at the last meeting and attempt to reopen the question of the advisability of that decision. (7) Advocate "caution." Be "reasonable" and urge your fellow-conferees to be "reasonable" and avoid haste which might result in embarrassments or difficulties later on. (8) Be worried about the propriety of any decision -raise the question of whether such action as is contemplated lies within the jurisdiction of the group or whether it might conflict with the policy of some higher echelon.

Read the full sections 11,12 and for reference, also the entire manual. As some have suggested, it reads like a modern management manual, perhaps proving that people don't change over time!

Hide & seek in the terrorist battle

Court cases often give us glimpses of security issues. A court in Britain has just convicted three from the liquid explosives gang, and now that it is over, there are press reports of the evidence. It looks now like the intelligence services achieved one of two possible victories by stopping the plot. Wired reports that NSA intercepts of emails have been entered in as evidence.

According to Channel 4, the NSA had previously shown the e-mails to their British counterparts, but refused to let prosecutors use the evidence in the first trial, because the agency didn’t want to tip off an alleged accomplice in Pakistan named Rashid Rauf that his e-mail was being monitored. U.S. intelligence agents said Rauf was al Qaeda’s director of European operations at the time and that the bomb plot was being directed by Rauf and others in Pakistan.

The NSA later changed its mind and allowed the evidence to be introduced in the second trial, which was crucial to getting the jury conviction. Channel 4 suggests the NSA’s change of mind occurred after Rauf, a Briton born of Pakistani parents, was reportedly killed last year by a U.S. drone missile that struck a house where he was staying in northern Pakistan.

Although British prosecutors were eager to use the e-mails in their second trial against the three plotters, British courts prohibit the use of evidence obtained through interception. So last January, a U.S. court issued warrants directly to Yahoo to hand over the same correspondence.

So there are some barriers between intercept and use in trial. The reason they came from the NSA is probably that old trick of avoiding prohibitions on domestic surveillance: if the trial had been in the USA, GCHQ might have provided the intercepts.

What however was more interesting is the content of the alleged messages. This BBC article includes 7 of them, here's one:

4 July 2006: Abdulla Ahmed Ali to Pakistan Accused plotter Abdulla Ahmed Ali

Listen dude, when is your mate gonna bring the projectors and the taxis to me? I got all my bits and bobs. Tell your mate to make sure the projectors and taxis are fully ready and proper I don't want my presentation messing up.

WHAT PROSECUTORS SAID IT MEANT Prosecutors said that projectors and taxis were code for knowledge and equipment because Ahmed Ali still needed some guidance. The word "presentation" could mean attack.

The others also have interesting use of code words, such as Calvin Klein aftershave for hydrogen peroxide (hair bleach). The use of such codes (as opposed to ciphers) is not new; historically they were well known. Code words tend not to be used now because ciphers cover more of the problem space, and once you know something of the activity, the listener can guess at the meanings.

In theory at least, and code words clearly didn't work to protect the liquid bombers. Worse for them, it probably made their conviction easier, because Muslims discussing the purchase of 4 litres of aftershave with other Mulsims in Pakistan seems very odd.

One remaining question was whether the plot would actually work. We all know that the airlines banned liquids because of this event. Many amateurs have opined that it is simply too hard to do liquid explosives. However, the BBC employed an expert to try it, and using what amounts to between half a litre to a liter of finished product, they got this result:

Certainly a dramatic explosion, enough to kill people within a few metres, and enough to blow a 2m hole in the fuselage. (The BBC video is only a minute long, well worth watching.)

Would this have brought down the aircraft? Not necessarily as there are many examples of airlines with such damage that have survived. Perhaps if the bomb was in a strategic spot (over wing? or near the fuel lines?) or the aircraft was stuck over the Atlantic with no easy vector. Either way, a bad day to fly, and as the explosives guy said, pity the passengers that didn't have their seat belt on.

Score one for the intel agencies. But the terrorists still achieved their second victory out of two: passengers are still terrorised in their millions when they forget to dispose of their innocent drinking water. What is somewhat of a surprise is that the terrorists have not as yet seized on the disruptive path that is clearly available, a la John Robb. I read somewhere that it only takes a 7% "security tax" on a city to destroy it over time, and we already know that the airport security tax has to be in that ballpark.

the state of the CAPTCHA nation:

The biggest flaw with all CAPTCHA systems is that they are, by definition, susceptible to attack by humans who are paid to solve them. Teams of people based in developing countries can be hired online for $3 per 1,000 CAPTCHAs solved. Several forums exist both to offer such services and parcel out jobs. But not all attackers are willing to pay even this small sum; whether it is worth doing so depends on how much revenue their activities bring in. “If the benefit a spammer is getting from obtaining an e-mail account is less than $3 per 1,000, then CAPTCHA is doing a perfect job,” says Dr von Ahn.

And here, outside our normal programme, is news from RAH that people pay for the privilege of being a suicide bomber:

A second analysis with Palantir uncovered more details of the Syrian networks, including profiles of their top coordinators, which led analysts to conclude there wasn't one Syrian network, but many. Analysts identified key facilitators, how much they charged people who wanted to become suicide bombers, and where many of the fighters came from. Fighters from Saudi Arabia, for example, paid the most -- $1,088 -- for the opportunity to become suicide bombers.

It's important to examine security models remote to our own, because it it gives us neutral lessons on how the economics effects the result. An odd comparison there, that number $1088 is about the value required to acquire a good-but-false set of identity documents.

trouble in PKI land

The CA and PKI business is busy this week. CAcert, a community Certification Authority, has a special general meeting to resolve the trauma of the collapse of their audit process. Depending on who you ask, my resignation as auditor was either the symptom or the cause.

In my opinion, the process wasn't working, so now I'm switching to the other side of the tracks. I'll work to get the audit done from the inside. Whether it will be faster or easier this way is difficult to say, we only get to run the experiment once.

Meanwhile, Mike Zusman and Alex Sotirov are claiming to have breached the EV green bar thing used by some higher end websites. No details available yet, it's the normal tease before a BlabHat style presentation by academics. Rumour has it that they've exploited weaknesses in the browsers. Some details emerging:

With control of the DNS for the access point, the attackers can establish their machines as men-in-the-middle, monitoring what victims logged into the access point are up to. They can let victims connect to EV SSL sites - turning the address bars green. Subsequently, they can redirect the connection to a DV SSL sessions under a certificates they have gotten illicitly, but the browser will still show the green bar.

Ah that old chestnut: if you slice your site down the middle and do security on the left and no or lesser security on the right, guess where the attacker comes in? Not the left or the right, but up the middle, between the two. He exploits the gap. Which is why elsewhere, we say "there is only one mode and it is secure."

Aside from that, this is an interesting data point. It might be considered that this is proof that the process is working (following the GP theory), or it might be proof that the process is broken (following the sleeping-dogs-lie model of security).

Although EV represents a good documentation of what the USA/Canada region (not Europe) would subscribe as "best practices," it fails in some disappointing ways. And in some ways it has made matters worse. Here's one: because the closed proprietary group CA/B Forum didn't really agree to fix the real problems, those real problems are still there. As Extended Validation has held itself up as a sort of gold standard, this means that attackers now have something fun to focus on. We all knew that SSL was sort of facade-ware in the real security game, and didn't bother to mention it. But now that the bigger CAs have bought into the marketing campaign, they'll get a steady stream of attention from academics and press.

I would guess less so from real attackers, because there are easier pickings elsewhere, but maybe I'm wrong:

"From May to June 2009 the total number of fraudulent website URLs using VeriSign SSL certificates represented 26% of all SSL certificate attacks, while the previous six months presented only a single occurrence," Raza wrote on the Symantec Security blogs.

... MarkMonitor found more than 7,300 domains exploited four top U.S. and international bank brands with 16% of them registered since September 2008.
.... But in the latest spate of phishing attempts, the SSL certificates were legitimate because "they matched the URL of the fake pages that were mimicking the target brands," Raza wrote.

VeriSign Inc., which sells SSL certificates, points out that SSL certificate fraud currently represents a tiny percentage of overall phishing attacks. Only two domains, and two VeriSign certificates were compromised in the attacks identified by Symantec, which targeted seven different brands.

"This activity falls well within the normal variability you would see on a very infrequent occurrence," said Tim Callan, a product marketing executive for VeriSign's SSL business unit. "If these were the results of a coin flip, with heads yielding 1 and tails yielding 0, we wouldn't be surprised to see this sequence at all, and certainly wouldn't conclude that there's any upward trend towards heads coming up on the coin."

Well, we hope that nobody's head is flipped in an unsurprising fashion....

It remains to be seen whether this makes any difference. I must admit, I check the green bar on my browser when online-banking, but annoyingly it makes me click to see who signed it. For real users, Firefox says that it is the website, and this is wrong and annoying, but Mozilla has not shown itself adept at understanding the legal and business side of security. I've heard Safari has been fixed up so probably time to try that again and report sometime.

Then, over to Germany, where a snafu with a HSM ("high security module") caused a root key to be lost (also in German). Over in the crypto lists, there are PKI opponents pointing out how this means it doesn't work, and there are PKI proponents pointing out how they should have employed better consultants. Both sides are right of course, so what to conclude?

Test runs with Germany's first-generation electronic health cards and doctors' "health professional cards" have suffered a serious setback. After the failure of a hardware security module (HSM) holding the private keys for the root Certificate Authority (root CA) for the first-generation cards, it emerged that the data had not been backed up. Consequently, if additional new cards are required for field testing, all of the cards previously produced for the tests will have to be replaced, because a new root CA will have to be generated. ... Besides its use in authentication, the root CA is also important for card withdrawal (the revocation service).

The first thing to realise was that this was a test rollout and not the real thing. So the test discovered a major weakness; in that sense it is successful, albeit highly embarrassing because it reached the press.

The second thing is the HSM issue. As we know, PKI is constructed as a hierarchy, or a tree. At the root of the tree is the root key of course. If this breaks, everything else collapses.

Hence there is a terrible fear of the root breaking. This feeds into the wishes of suppliers of high security modules, who make hardware that protect the root from being stolen. But, in this case, the HSM broke, and there was no backup. So a protection for one fear -- theft -- resulted in a vulnerability to another fear -- data loss.

A moment's thought and we realise that the HSM has to have a backup. Which has to be at least as good as the HSM. Which means we then have some rather cute conundrums, based on the Alice in Wonderland concept of having one single root except we need multiple single roots... In practice, how do we create the root inside the HSM (for security protection) and get it to another HSM (for recovery protection)?

Serious engineers and architects will be reaching for one word: BRITTLE! And so it is. Yes, it is possible to do this, but only by breaking the hierarchical principle of PKI itself. It is hard to break fundamental principles, and the result is that PKI will always be brittle, the implementations will always have contradictions that are swept under the carpet by the managers, auditors and salesmen. The PKI design is simply not real world engineering, and the only thing that keeps it going is the institutional deadly embrace of governments, standards committees, developers and security companies.

Not the market demand. But, not all has been bad in the PKI world. Actually, since the bottoming out of the dotcom collapse, certs have been on the uptake, and market demand is present albeit not anything beyond compliance-driven. Here comes a minor item of success:

VeriSign, Inc. [SNIP] today reported it has topped the 1 billion mark for daily Online Certificate Status Protocol (OCSP) checks.

[SNIP] A key link in the online security chain, OCSP offers the most timely and efficient way for Web browsers to determine whether a Secure Sockets Layer (SSL) or user certificate is still valid or has been revoked. Generally, when a browser initiates an SSL session, OCSP servers receive a query to check to see if the certificate in use is valid. Likewise, when a user initiates actions such as smartcard logon, VPN access or Web authentication, OCSP servers check the validity of the user certificate that is presented. OSCP servers are operated by Certificate Authorities, and VeriSign is the world's leading Certificate Authority.

[SNIP] VeriSign is the EV SSL Certificate provider of choice for more than 10,000 Internet domain names, representing 74 percent of the entire EV SSL Certificate market worldwide.

(In the above, I've snipped the self-serving marketing and one blatant misrepresentation.)

Certificates are static statements. They can be revoked, but the old design of downloading complete lists of all revocations was not really workable (some CAs ship megabyte-sized lists). We now have a new thing whereby if you are in possession of a certificate, you can do an online check of its status, called OCSP.

The fundamental problem with this, and the reason why it took the industry so long to get around to making revocation a real-time thing, is that once you have that architecture in place, you no longer need certificates. If you know the website, you simply go to a trusted provider and get the public key. The problem with this approach is that it doesn't allow the CA business to sell certificates to web site owners. As it lacks any business model for CAs, the CAs will fight it tooth & nail.

Just another conundrum from the office of security Kafkaism.

Here's another one, this time from the world of code signing. The idea is that updates and plugins can be sent to you with a digital signature. This means variously that the code is good and won't hurt you, or someone knows who the attacker is, and you can't hurt him. Whatever it means, developers put great store in the apparent ability of the digital signature to protect themselves from something or other.

But it doesn't work with Blackberry users. Allegedly, a Blackberry provider sent a signed code update to all users in United Arab Emirates:

Yesterday it was reported by various media outlets that a recent BlackBerry software update from Etisalat (a UAE-based carrier) contained spyware that would intercept emails and text messages and send copies to a central Etisalat server. We decided to take a look to find out more.

...
Whenever a message is received on the device, the Recv class first inspects it to determine if it contains an embedded command — more on this later. If not, it UTF-8 encodes the message, GZIPs it, AES encrypts it using a static key (”EtisalatIsAProviderForBlackBerry”), and Base64 encodes the result. It then adds this bundle to a transmit queue. The main app polls this queue every five seconds using a Timer, and when there are items in the queue to transmit, it calls this function to forward the message to a hardcoded server via HTTP (see below). The call to http.sendData() simply constructs the POST request and sends it over the wire with the proper headers.

Oops! A signed spyware from the provider that copies all your private email and sends it to a server. Sounds simple, but there's a gotcha...

The most alarming part about this whole situation is that people only noticed the malware because it was draining their batteries. The server receiving the initial registration packets (i.e. “Here I am, software is installed!”) got overloaded. Devices kept trying to connect every five seconds to empty the outbound message queue, thereby causing a battery drain. Some people were reporting on official BlackBerry forums that their batteries were being depleted from full charge in as little as half an hour.

So, even though the spyware provider had a way to turn it on and off:

It doesn’t seem to execute arbitrary commands, just packages up device information such as IMEI, IMSI, phone number, etc. and sends it back to the central server, the same way it does for received messages. It also provides a way to remotely enable/disable the spyware itself using the commands “start” and “stop”.

There was something wrong with the design, and everyone's blackberry went mad. Two points: if you want to spy on your own customers, be careful, and test it. Get quality engineers on to that part, because you are perverting a brittle design, and that is tricky stuff.

Second point. If you want to control a large portion of the population who has these devices, the centralised hierarchy of PKI and its one root to bind them all principle would seem to be perfectly designed. Nobody can control it except the center, which puts you in charge. In this case, the center can use its powerful code-signing abilities to deliver whatever you trust to it. (You trust what it tells you to trust, of course.)

Which has led some wits to label the CAs as centralised vulnerability partners. Which is odd, because some organisations that should know better than to outsource the keys to their security continue to do so.

But who cares, as long as the work flows for the consultants, the committees, the HSM providers and the CAs?

Are the "brightest minds in finance" finally onto something?

[Lynn writes somewhere else, copied without shame:]

A repeated theme in the Madoff hearing (by the person trying for a decade to get SEC to do something about Madoff) was that while new legislation and regulation was required, it was much more important to have transparency and visibility; crooks are inventive and will always be ahead of regulation.

however ... from The Quiet Coup:

But there's a deeper and more disturbing similarity: elite business interests -- financiers, in the case of the U.S. -- played a central role in creating the crisis, making ever-larger gambles, with the implicit backing of the government, until the inevitable collapse. More alarming, they are now using their influence to prevent precisely the sorts of reforms that are needed, and fast, to pull the economy out of its nosedive. The government seems helpless, or unwilling, to act against them.

From The DNA of Corruption:

While the scale of venality of Wall Street dwarfs that of the Pentagon's, I submit that many of the central qualities shaping America's Defense Meltdown (an important new book with this title, also written by insiders, can be found here) can be found in Simon Johnson's exegesis of America's even more profound Financial Meltdown.

... and related to above, Mark-to-Market Lobby Buoys Bank Profits 20% as FASB May Say Yes:

Officials at Norwalk, Connecticut-based FASB were under "tremendous pressure" and "more or less eviscerated mark-to-market accounting," said Robert Willens, a former managing director at Lehman Brothers Holdings Inc. who runs his own tax and accounting advisory firm in New York. "I'd say there was a pretty close cause and effect."

From Now-needy FDIC collected little in premiums:

The federal agency that insures bank deposits, which is asking for emergency powers to borrow up to $500 billion to take over failed banks, is facing a potential major shortfall in part because it collected no insurance premiums from most banks from 1996 to 2006.

with respect to taxes, there was roundtable of "leading expert" economists last summer about current economic mess. their solution was "flat rate" tax. the justification was:

1. eliminates possibly majority of current graft & corruption in washington that is related to current tax code structure, lobbying and special interests
2. picks up 3-5% productivity in GNP. current 65,000 page taxcode is reduced to 600 pages ... that frees up huge amount of people-hrs in lost productivity involved in dealing directly with the taxcode as well as lost productivity because of non-optimal business decisions.

their bottom line was that it probably would only be temporary before the special interests reestablish the current pervasive atmosphere of graft & corruption.

a semi-humorous comment was that a special interest that has lobbied against such a change has been Ireland ... supposedly because some number of US operations have been motivated to move to Ireland because of their much simpler business environment.

with respect to feedback processes ... I (Lynn) had done a lot with dynamic adaptive (feedback) control algorithms as an undergraduate in the 60s ... which was used in some products shipped in the 70s & 80s. In theearly 80s, I had a chance to meet John Boyd and sponsor his briefings. I found quite a bit of affinity to John's OODA-loop concept (observe, orient, decide, act) that is now starting to be taught in some MBA programs.

this one's significant: 49 cities in 30 minutes!

No, not this stupidity: "The Breach of All Breaches?" but this one, spotted by JP (and also see Fraud, Phishing and Financial Misdeeds, scary, flashmob, and fbi wanted poster seen to right):

* Reported by John Deutzman

Photos from security video (see photo gallery at left at bottom right) obtained by Fox 5 show of a small piece of a huge scam that took place all in one day in a matter of hours. According to the FBI , ATMs from 49 cities were hit -- including Atlanta, Chicago, New York, Montreal, Moscow and Hong Kong.

"We've seen similar attempts to defraud a bank through ATM machines but not, not anywhere near the scale we have here," FBI Agent Ross Rice told Fox 5.
....

"Over 130 different ATM machines in 49 cities worldwide were accessed in a 30-minute period on November 8," Agents Rice said. "So you can get an idea of the number of people involved in this and the scope of the operation."

Here is the amazing part: With these cashers ready to do their dirty work around the world, the hacker somehow had the ability to lift those limits we all have on our ATM cards. For example, I'm only allowed to take out $500 a day, but the cashers were able to cash once, twice, three times over and over again. When it was all over, they only used 100 cards but they ripped off $9 million.

This lifts the level of capability of the attacker several notches up. This is a huge coordinated effort. Are we awake now to the problems that we created for ourselves a decade ago?

(Apologies, no time to do the real research and commentary today! Thanks, JP!)

Microsoft: Phishing losses greatly over-estimated

Seen on the net:

09 Jan 2009 14:21

Phishers make much less from their scams than analysts have estimated, according to research from the software maker. The financial losses experienced by victims of phishing scams may be up to 50 times less than estimated by analysts, according to a Microsoft study. Previous studies by organisations such as Gartner, which in 2007 estimated US phishing losses at $3.2bn (£2bn), "crumble upon inspection", Microsoft researchers said in their report, published on Tuesday.

Nevertheless, stories of easy money may be encouraging a phishing "gold rush" effect, where large numbers of newcomers enter the phishing business expecting huge returns, only to be preyed upon by more experienced phishers, according to A Profitless Endeavor: Phishing as Tragedy of the Commons.

The study, undertaken by Microsoft researchers Cormac Herley and Dinei Florencio, also suggests there is less profit than thought in phishing because there is only a limited number of people who will be fooled by the scams, and that pool gets smaller as the scams claim victims.

"Phishing is a classic example of tragedy of the commons, where there is open access to a resource that has limited ability to regenerate," the authors say in their report. "Since each phisher independently seeks to maximise his return, the resource is over-grazed and [on average] yields far less than it is capable of." Instead of getting a maximum return for a minimum effort, the majority of phishers make a weekly wage of hundreds, rather than thousands, of dollars, the researchers said.

....

No comment from here, because I haven't read the source as yet.

Unwinding secrecy -- how to do it?

The next question on unwinding secrecy is how to actually do it. It isn't as trivial as it sounds. Perhaps this is because the concept of "need-to-know" is so well embedded in the systems and managerial DNA that it takes a long time to root it out.

At LISA I was asked how to do this; but I don't have much of an answer. Here's what I have observed:

• Do a little at a time.
• Pick a small area and start re-organising it. Choose an area where there is lots of frustration and lots of people to help. Open it up by doing something like a wiki, and work the information. It will take a lot of work and pushing by yourself, mostly because people won't know what you are doing or why (even if you tell them).
• What is needed is a success. That is, a previously secret area is opened up, and as a result, good work gets done that was otherwise inhibited. People need to see the end-to-end journey in order to appreciate the message. (And, obviously, it should be clear at the end of it that you don't need the secrecy as much as you thought.)
• Whenever some story comes out about a successful opening of secrecy, spread it around. The story probably isn't relevant to your organisation, but it gets people thinking about the concept. E.g., that which I posted recently was done to get people thinking. Another from Chandler.
• Whenever there is a success on openness inside your organisation, help to make this a showcase (here are three). Take the story and spread it around; explain how the openness made it possible.
• When some decision comes up about "and this must be kept secret," discuss it. Challenge it, make it prove itself. Remind people that we are an open organisation and there is benefit in treating all as open as possible.
• Get a top-level decision that "we are open." Make it broad, make it serious, and incorporate the exceptions. "No, we really are open; all of our processes are open except when a specific exception is argued for, and that must be documented and open!" Once this is done, from top-level, you can remind people in any discussion. This might take years to get, so have a copy of a resolution in your back pocket for a moment when suddenly, the board is faced with it, and minded to pass a broad, sweeping decision.
• Use phrases like "security-by-obscurity." Normally, I am not a fan of these as they are very often wrongly used; so-called security-by-obscurity often tans the behinds of supposed open standards models. But it is a useful catchphrase if it causes the listener to challenge the obscure security benefits of secrecy.
• Create an opening protocol. Here's an idea I have seen: when someone comes across a secret document (generally after much discussion ...) that should not have been kept secret, let them engage in the Opening-Up Protocol without any further ado. Instead of grumbling or asking, put the ball in their court. Flip it around, and take the default as to be open:

  "I can't see why document X is secret, it seems wrong. Therefore, in 1 month, I intend to publish it. If there is any real reason, let me know before then."

  This protocol avoids the endless discussions as to why and whether.

Well, that's what I have thought about so far. I am sure there is more.

Unwinding secrecy -- busting the covert attack

Have a read of this. Quick summary: Altimo thinks Telenor may be using espionage tactics to cause problems.

Altimo alleges the interception of emails and tapping of telephone calls, surveillance of executives and shareholders, and payments to journalists to write damaging articles.

So instead of getting its knickers in a knot (court case or whatever) Altimo simply writes to Telenor and suggests that this is going on, and asks for confirmation that they know nothing about it, do not endorse it, etc.

Who ya bluffin?

...Andrei Kosogov, Altimo's chairman, wrote an open letter to Telenor's chairman, Harald Norvik, asking him to explain what Telenor's role has been and "what activity your agents have directed at Altimo". He said that he was "reluctant to believe" that Mr Norvik or his colleagues would have sanctioned any of the activities complained of.

.... Mr Kosogov said he first wrote to Telenor in October asking if the company knew of the alleged campaign, but received no reply. In yesterday's letter to Mr Norvik, Mr Kosogov writes: "We would welcome your reassurance that Telenor's future dealings with Altimo will be conducted within a legal and ethical framework."

Think about it: This open disclosure locks down Telenor completely. It draws a firm line in time, as also, gives Telenor a face-saving way to back out of any "exuberance" it might have previously "endorsed." If indeed Telenor does not take this chance to stop the activity, it would be negligent. If it is later found out that Telenor's board of directors knew, then it becomes a slam-dunk in court. And, if Telenor is indeed innocent of any action, it engages them in the fight to also chase the perpetrator. The bluff is called, as it were.

This is good use of game theory. Note also that the Advisory Board of Altimo includes some high-powered people:

Evidence of an alleged campaign was contained in documents sent to each member of Altimo's advisory board some time before October. The board is chaired by ex-GCHQ director Sir Francis Richards, and includes Lord Hurd, a former UK Foreign Secretary, and Sir Julian Horn-Smith, a founder of Vodafone.

We could speculate that those players -- the spooks and mandarins -- know how powerful open disclosure is in locking down the options of nefarious players. A salutory lesson!

Unwinding secrecy -- how far?

One of the things that I've gradually come to believe in is that secrecy in anything is more likely to be a danger to you and yours than a help. The reasons for this are many, but include:

• hard to get anything done
• your attacker laughs!
• ideal cover for laziness, a mess or incompetence

There are no good reasons for secrecy, only less bad ones. If we accept that proposition, and start unwinding the secrecy so common in organisations today, there appear to be two questions: how far to open up, and how do we do it?

How far to open up appears to be a personal-organisational issue, and perhaps the easiest thing to do is to look at some examples. I've seen three in recent days which I'd like to share.

First the Intelligence agencies: in the USA, they are now winding back the concept of "need-to-know" and replacing it with "responsibility-to-share".

Implementing Intellipedia Within a "Need to Know" Culture

Sean Dennehy, Chief of Intellipedia Development, Directorate of Intelligence, U.S. Central Intelligence Agency

Sean will share the technical and cultural changes underway at the CIA involving the adoption of wikis, blogs, and social bookmarking tools. In 2005, Dr. Calvin Andrus published The Wiki and The Blog: Toward a Complex Adaptive Intelligence Community. Three years later, a vibrant and rapidly growing community has transformed how the CIA aggregates, communicates, and organizes intelligence information. These tools are being used to improve information sharing across the U.S. intelligence community by moving information out of traditional channels.

The way they are doing this is to run a community-wide suite of social network tools: blogs, wikis, youtube-copies, etc. The access is controlled at the session level by the username/password/TLS and at the person level by sponsoring. That latter means that even contractors can be sponsored in to access the tools, and all sorts of people in the field can contribute directly to the collection of information.

The big problem that this switch has is that not only is intelligence information controlled by "need to know" but also it is controlled in horizontal layers. For same of this discussion, there are three: TOP SECRET / SECRET / UNCLASSIFIED-CONTROLLED. The intel community's solution to this is to have 3 separate networks in parallel, one for each, and to control access to each of these. So in effect, contractors might be easily sponsored into the lowest level, but less likely in the others.

What happens in practice? The best coverage is found in the network that has the largest number of people, which of course is the lowest, UNCLASSIFIED-CONTROLLED network. So, regardless of the intention, most of the good stuff is found in there, and where higher layer stuff adds value, there are little pointers embedded to how to find it.

In a nutshell, the result is that anyone who is "in" can see most everything, and modify everything. Anyone who is "out" cannot. Hence, a spectacular success if the mission was to share; it seems so obvious that one wonders why they didn't do it before.

As it turns out, the second example is quite similar: Google. A couple of chaps from there explained to me around the dinner table that the process is basically this: everyone inside google can talk about any project to any other insider. But, one should not talk about projects to outsiders (presumably there are some exceptions). It seems that SEC (Securities and Exchange Commission in USA) provisions for a public corporation lead to some sensitivity, and rather than try and stop the internal discussion, google chose to make it very simple and draw a boundary at the obvious place.

The third example is CAcert. In order to deal with various issues, the Board chose to take it totally open last year. This means that all the decisions, all the strategies, all the processes should be published and discussable to all. Some things aren't out there, but they should be; if an exception is needed it must be argued and put into policies.

The curious thing is why CAcert did not choose to set a boundary at some point, like google and the intelligence agencies. Unlike google, there is no regulator to say "you must not reveal inside info of financial import." Unlike the CIA, CAcert is not engaging in a war with an enemy where the bad guys might be tipped off to some secret mission.

However, CAcert does have other problems, and it has one problem that tips it in the balance of total disclosure: the presence of valuable and tempting privacy assets. These seem to attract a steady stream of interested parties, and some of these parties are after private gain. I have now counted 4 attempts to do this in my time related to CAcert, and although each had their interesting differences, they each in their own way sought to employ CAcert's natural secrecy to own advantage. From a commercial perspective, this was fairly obvious as the interested parties sought to keep their negotiations confidential, and this allowed them to pursue the sales process and sell the insiders without wiser heads putting a stop to it. To the extent that there are incentives for various agencies to insert different agendas into the inner core, then the CA needs a way to manage that process.

How to defend against that? Well, one way is to let the enemy of your enemy know who we are talking to. Let's take a benign example which happened (sort of): a USB security stick manufacturer might want to ship extra stuff like CAcert's roots on the stick. Does he want the negotiations to be private because other competitors might deal for equal access, or does he want it private because wiser heads will figure out that he is really after CAcert's customer list? CAcert might care more about one than they other, but they are both threats to someone. As the managers aren't smart enough to see every angle, every time, they need help. One defence is many eyeballs and this is something that CAcert does have available to it. Perhaps if sufficient info of the emerging deal is published, then the rest of the community can figure it out. Perhaps, if the enemy's enemy notices what is going on, he can explain the tactic.

A more poignant example might be someone seeking to pervert the systems and get some false certificates issued. In order to deal with those, CAcert's evolving Security Manual says all conflicts of interest have to be declared broadly and in advance, so that we can all mull over them and watch for how these might be a problem. This serves up a dilemma to the secret attacker: either keep private and lie, and risk exposure later on, or tell all upfront and lose the element of surprise.

This method, if adopted, would involve sacrifices. It means that any agency that is looking to impact the systems is encouraged to open up, and this really puts the finger on them: are they trying to help us or themselves? Also, it means that all people in critical roles might have to sacrifice their privacy. This latter sacrifice, if made, is to preserve the privacy of others, and it is the greater for it.

Clickjacking -- the new browser wipe-out

News is circulating about Clickjacking, an undisclosed vulnerability that effects all browsers (with the exception of Lynx, which you don't use :) . Apparently although exploit code is somewhat hard, it is an impressive result. Your browser is owned, once again.

Hattip to BigMac, who might be the last person on the planet using Lynx. There appears to be limited options right now:

• Install NoScript: "NoScript would prevent most of the really bad clickjacking PoC, not 100%, which should be good enough to limit most risk."
• "If you’re desperate for a way to patch your browser from the issue, disable scripting and plugins for the time being."

From my side, I wonder whether another possibility is to close all tabs, restart the browser, do your sensitive work, then shut it all down again.

OK, that's just idle speculation on my part, but it is worth thinking about. A large component of the current breaches are a result of the browser being a general purpose tool with not only cross-admin-border protocols, but also parallel applications in play. Not generally a good idea in security thinking, and it means that the browser can only ever work in medium security modes.

Also, I have another open question: should NoScript become standard recommendations for Mon'N'Pop ?

another way to track their citizens

Passports were always meant to help track citizens. According to lore, they were invented in the 19th century to stop Frenchmen evading the draft (conscription), which is still an issue in some countries. BigMac points to a Dutch working paper "Fingerprinting Passports," that indicates that passports can now be used to discriminate against the bearer's country of issue, to a distance of maybe 25cm. Future Napoleons will be happy.

Because terrorising the reader over breakfast is currently good writing style by governments and media alike, let's highlight the dangers first. The paper speculates:

Given that we can remotely detect the presence of a passport of a particular country, how could this functionality be abused? One abuse case that has been suggested is a passport bomb, designed to go off if someone with a passport of a certain nationality comes close. One could even send such a bomb by post, say to an embassy. A less spectacular, but possibly more realistic, use of this functionality would by passport thieves, who can remotely check if someone is carrying passport and if it is of a ‘suitable’ nationality, before they decide to rob them.

From the general fear department, we can also add that overseas travellers sometimes have a fear of being mugged, kidnapped, hijacked or simply shot because of their mere membership of a favourable or unfavourable country.

Now that we have the FUD off our chest, let's talk details. The trick involves sending a series of commands (up to 4) to the RFID in the passport, each of which are presumably rejected by the passport. The manner of rejection differs from country to country, so a precise fingerprint-of-country can be formed simply by examining each rejection, and then choosing a different command to further narrow the choices.

How did this happen? I would speculate that the root failure is derived from bureaucrats' never-ending appetite for complex technological solutions to simple problems. In this case, the first root cause is the use of the RFID, being by intention and design something that can be read from up to 10 cm.

It is inherently attackable, and therefore by definition a very odd choice for security. The second complexity, then, involved implementing something to stop the attackers reading off the RFIDs without permission. The solution to an active read-off attack is encryption, of course! Which leads to our third complexity, a secret key, which is written inside the passport, of course! Which immediately raises issues of brute-forcing (of course!) and, as the paper references, it turns out, brute forcing attacks work on some countries' passports because the secret key is .. poorly chosen.

All of this complexity, er, solution, means something called Basic Access Control is added to the RFID in order to ensure the use of the secret key. Which means a series of commands meant to defend the RFID. If we factor in the tendency for each country to implement passports entirely alone (because they are more scared of each other than they are of their citizens), we can see that each solution is proprietary and home-grown. To cope with this, the standard was written to be very flexible (of course!). Hence, it permits wide diversity in response to errors.

Whoops! Security error. In the world of security, we say that one should be precise in what we send, and precise in what we return.

From that point of view, this is poor security work by the governments of the world, but that's to be expected. The US State Department can now derive some satisfaction from earlier blunders; because of their failure to implement any form of encryption or access control, American passports can be read by all (terrorists and borderists alike), which apparently forced them to add aluminium foil into the passport cover to act as a Faraday cage. Likely, the other countries will now have to follow suit, and the smugness of being sophisticated and advanced in security terms ("we've got BAC!") will be replaced by a dawning realisation that they should have adopted the simpler solutions in the first place.

Economics not repealed, just slow: Paypal blames Browsers for Phishing

Well, it had to happen one day. A major player has finally broken the code of silence and blamed the browsers. In this case, it is PayPal, and Safari.

Infoworld last week quoted Michael Barrett, PayPal’s CIO, saying the following:

“Apple, unfortunately, is lagging behind what they need to do, to protect their customers. Our recommendation at this point, to our customers, is use Internet Explorer 7 or 8 when it comes out, or Firefox 2 or Firefox 3, or indeed Opera.”

The browser is the user's security tool. The browser is the only thing between you and the phisher. The browser is the point of all attack attention. The browser is it. That's why it had SSL built in -- to correctly identify the website as the one you wanted to go to.

So above, Paypal blames Safari for not doing enough about phishing. It's true, Safari does nothing (as I found out recently and had to switch back to Firefox). It likely had to be Paypal because the regulated banks won't say boo without permission, and Paypal might be supposed to be net-savvy. It had to be Safari because (a) there is that popular alternate now, and (b) Apple is still small enough not to be offended, and (c) others have done something in the phishing area.

A take-away then is not the names involved, but the fact that a large player has finally lost patience and is pointing fingers at those who are not addressing phishing:

At issue is the fact that Safari lacks a built-in phishing filter to warn users about shady Web sites. Safari also doesn’t support so-called Extended Validation certificates, which turn the address bar green if a site is legit. Extended Validation certificates aren’t the complete answer but are a help.

OK, so those are some ideas, and Safari could do something. However there may be more to this than meets the eye:

An emerging technology, EV certificates are already supported in Internet Explorer 7, and they've been used on PayPal's Web site for more than a year now. When IE 7 visits PayPal, the browser's address bar turns green -- a sign to users that the site is legitimate. Upcoming versions of Firefox and Opera are expected to support the technology.

Aha! It's not a general complaint to Apple at all. It is a complaint that EV has not been implemented in Safari. It's a very specific complaint!

( Long term readers know that EV implements the basic steps necessary to complete the SSL security model: By naming the CA that makes the claim, it clearly encapsulates the statement. By making it more clear what was going on to the user the final step was made to the risk-bearing party. )

Paypal has purchased a green certificate. And now they want it to work. It works on IE, but not on others. (Firefox and Opera say "soon" and so are given a pass. For now.) Apple rarely comments on its plans, so it has been named and shamed for not adopting the agreed solution. More for not playing the game than anything.

The sad thing about the EV is that it is (approximately) what the browsers should have done years ago, when phishing became apparent.

But nothing could be done. I know, I tried. If there is any more elegant proof of the market for silver bullets, I'm hard pressed to find it. To break the equilibrium around SSL+cert-user-CA (that reads SSL plus cert minus user minus CA), EV had to be packaged as an industry consortium agreeing on an expensive product. Once so packaged, it was then sold to Microsoft and to some major websites. Once in the major places, influence is then brought to bear to get the rest to come into line.

The problem with this, as I lay out in silver bullets, is that shifting from one equilibrium to another is a strictly weaker strategy. Firstly, we are not that confident in our choice of equilibrium. That's by definition; we wouldn't play this game if we knew how to play the game. Secondly, and to spin a leaf from John Boyd, the attacker can turn inside our OODA loop. Which is to say, he can create and modify his attacks faster than we can change equilibrium. Or, he is better at playing his game than we are.

You can read a much more extended argument in the essay (new, improved with extra added focus!). But for now, what I find interesting is the questions we don't yet have answers to.

What would be the attacker's best strategy, knowing all we do about the market and our claim that this is equilibrium shifting? Would the attacker destroy EV? Would he protect EV? Would he milk it?

Another question is, what is Apple's best strategy? It is currently outside the consortium, but has been attacked. Should it join and implement EV? Go it alone? Ignore? Invent an own strategy?

Why Security Modelling doesn't work -- the OODA loop of today's battle

Editor's note: now with a Chinese translation

I've been watching a security modelling project for a while now, and aside from the internal trials & tribulations that any such project goes through, it occurs to me that there are explanations of why there should be doubts. Frequent readers of FC will know that we frequently challenge the old wisdom. E.g., a year ago I penned an explanation of why, for simple money reasons, you cannot build security into the business from the early days.

Another way of expressing this doubt surrounding Security Modelling is by reference to Col. Boyd's OODA loop. That stands for Observe, Orient, Decide, Act and it expresses Boyd's view of fighter combat. His thesis was that this was a loop of continuous cycles that characterised the fighter pilot's essential tactics.

Two things made it more sexy: firstly, as a loop, he was able to suggest that the pilot with the tighter OODA loop would turn inside the other. This was a powerful metaphor because turning inside the enemy in fighter combat is as basic as it gets; every schoolboy knew how Spitfires could turn inside Messerschmitt 109s, and thus was won the Battle of Britain.

Obviously things aren't quite so simple, but this made it easy to understand what Boyd was getting at. The second thing that made the concept sexy was that he then went on to show it applied to just about every form of combat. And, that's true: I recall from early soldiering lessons on soviet army doctrine, that the russkies could turn their defence into a counter-attack faster than our own army could turn our attack into a defence. At all unit sizes, the instructors pointed out.

Taking a leaf from Sun Tzu's Art of War, the OODA loop concept may also be applied to other quasi-combat scenarios such as security and business. If we were to translate it to security modelling, we can break the process simply into four phases:

• threat modelling
• security modelling
• architecture
• implementation & deployment

To do it properly, each of these phases is important. You can't skip them, says the classical wisdom. We can agree with that, at a simple level. Which leaves us a problem: each of those phases costs time and effort.

A proper threat model for a medium sized project should take a month or so. A proper security model, I'd suggest 3 months and up. The other two phases are also 3 months and climbing, with overruns. So, for anything serious, we are talking a year, in total, for the project.

Now consider the attacker. Today's aggressor appears very fast. So-called 0-day viruses, month-long migration cycles, etc. A couple of days ago, there was this report that talked about the ability of Storm and Son-of-Storm's ability to migrate dynamically: "what emerges is a picture of a group of skilled, professional software developers learning from their mistakes, improving their code on a weekly basis and making a lot of money in the process."

Which means that the enemy is turning in his OODA loop in less than a month, sometimes as quickly as a day. Either way, the enemy today is turning faster than any security model-driven project is capable of doing.

What to do? Adolf Galland apocryphally told Reichsmarschall Göring that he could win the Battle of Britain with a squadron of Spitfires, but he was only behind by a few percentage points. In security terms we are looking at an order of magnitude, at least, which seems to lead to two possible conclusions: either your security model results in perfect security, there are no weaknesses, and it matters not how fast the enemy spins on his own dime. Or, classical security modelling is simply and utterly too slow to help in today's battle.

We need a new model. Now, this isn't to say "stop all security modelling." Even in the worst case, if the technique is completely outdated, it will remain a tremendously useful pedagogical discipline.

Instead, what I am suggesting is that the conventional wisdom doesn't hold scrutiny; something has to break. Whatever it is, security modelling is likely to have to change its practices and wisdoms, if it is to survive as the wisdom of the future.

Quite dramatically, indeed, as it possibly needs to achieve a 10-100 fold increase in its OODA loop performance in order to match the current enemy. In other words, a revolution in security thinking.

Editor's note: now with a Chinese translation

MITM spotted in Tor

Bruce Schneier wrote in cryptogram:

Man-in-the-middle attack by Tor exit node. So often man-in-the-middle attacks are theoretical; it's fascinating to see one in the wild. The guy claims that he just misconfigured his Tor node. I don't know enough about Tor to have any comment about this. [German commetary.] I've written about anonymity and the Tor network before.

Can't agree more! MITMs are so rare that they really should not drive any threat model until shown to be economic. Making that mistake was one of the core failures that led to phishing (thanks guys!). Here's a more simple sniffing attack on the same network:

I previously wrote about Dan Egerstad, a security researcher who ran a Tor anonymity network and was able to sniff some pretty impressive usernames and passwords. Swedish police arrested him last month.

Pure eavesdropping is also worth recording because we need to establish the frequency so as to calculate how much attention to pay to it. For the interest of financial cryptographers here, let's add this one from the same source, pointing to BoingBoing pointing to b.wsj:

In 1941, the British Secret Service asked the game's British licensee John Waddington Ltd. to add secret extras to some sets, which had become standard elements of the aid packages that the Red Cross delivered to allied prisoners of war. Along with the usual dog, top hat and and thimble, the sets had a metal file, compass, and silk maps of safe houses (silk, because it folds into small spaces and unfolds silently). Even better, real French, German and Italian currency was hidden underneath the game's fake money. Departing allied soldiers and pilots were told that if they were captured they should look out for the special editions, identified by a red dot in the Free Parking space. Any sets remaining in the U.K. were destroyed after the war. Of the 35,000 prisoners of war who escaped German prison camps by the end of the war, "more than a few of those certainly owe their breakout to the classic board game," says Mr. McMahon.

Threatwatch - more data on cost of your identity

In the long-running threatwatch theme of how much a set of identity documents will cost you, Dave Birch spots new data:

Other than data breaches, another useful rule-of-thumb figure, I reckon, might come from identity card fraud since an identity card is a much better representation of a persons identity than a credit card record. Luckily, one of the countries with a national smart ID card just had a police bust: in Malyasia, the police seized fake MyKad, foreign workers identity cards, work permits and Indonesian passports and said that they thought the fake documents were sold for between RM300 and RM500 (somewhere between $100 to $150) each. That gives us a rule-of-thumb of $20 for a "credit card identity" and $100, say, for a "full identity". Since we don't yet have ID cards in the U.K., I thought that fake passports might be my best proxy. Here, the police says that 1,800 alleged counterfeit passports recovered in raid in North London were valued at £1m. If we round it up to 2,000 fakes, then that's £500 each. This, incidentally, was the largest seizure of fake passports in the U.K. so far and vincluded 200 U.K. passports, which, according to police, are often considered by counterfeiters to be too difficult to reproduce. Not!

The point I actually wanted make is not that these figures a very variable, which they are, but that they're not comparing apples with apples. Hence the simplistic "what's your identity worth?" question cannot be answered with a simple number.

OK, that's consistent with my long-standing estimate of 1000 (in the major units, pounds, dollars, euros) to get a set of docs. It is important to track this because if you are building a system based on identity, this gives you a solid number on which to base your economic security. E.g., don't protect much more than 1000 on the basis of identity, alone.

As a curious footnote, I recently acquired a new high-quality document from the proper source, and it cost me around 1000, once all the checking, rechecking, couriered documents and double phase costs were all added up. If a data set of one could be extrapolated, this would tell us that it makes no difference to the user whether she goes for a fully authentic set or not!

Luckily my experiences are probably an outlier, but we can see a fairly damning data point here: the cost of an "informal" document is far to similar to the cost of a "formal" document.

Postscript: It turns out that there is no way to go through FC archives and see all the various categories, so I've added a button at the right which allows you to see (for example) the cost of your identity, in full posted-archive form.

Threatwatch: how much to MITM, how quickly, how much lost

It costs $500 for a kit to launch an MITM phishing attack. (Don't forget to add labour costs at 3rd world rates...)

David Franklin, vice president for the Europe, Middle East and Africa told IT PRO that these sites are proliferating because they are actually easier for hackers to set up than traditional 'fake' phishing sites because they don't even have to maintain a fake website. He also said man-in-the-middle attacks defeat weak authentication methods including passwords, internet protocol (IP) geolocation, device fingerprinting, cookies and personal security images and tokens, for example.

"A lot of the attacks you hear about are just the tip of the iceberg. Banks often won't even tell an affected customer that they have been a victim of these man-in-the-middle attacks," said Franklin, adding that kits that guide cybercriminals through setting up a man-in-the-middle attack are now so popular they can be bought for as little as $500 (£250) on the black market now.

He also said "man-in-the-browser" attacks are emerging to compete in popularity with middleman threat.

A couple of interesting notes from the above: it is now accepted that MITM is what phishing is (in the form mentioned above, the original email form, and the DNS form). These MITMs defeat the identity protection of SSL secure browsing, a claim made hereabouts first. and one that is still widely misunderstood: This is significant because SSL is engineered to defeat MITMs, but it only defeats internal or protocol MITMs, and can not stop the application itself being MITM'd. This typical "bypass attack" has important economic ramifications, such that SSL is now shown to be too heavy-weight to deliver value, unless it is totally free of cost and setup.

Secondly, note that the mainstream news has picked up the MITB threat (also reported and documented here first). It's still rare, but in the next 6 months, expect your boss to ask what it's about, because he read it in Yahoo.

More juicy threat modelling numbers:

Analysts at RSA Security early last month spotted a single piece of PHP code that installs a phishing site on a compromised server in about two seconds,

And....

Despite efforts to quickly shut sites down, phishing sites averaged a 3.8-day life span in May, according to the Anti-Phishing Working Group, which released its latest statistics on Sunday.

Data from market analyst Gartner released last month showed that phishing attacks have doubled over the last two years.

Gartner said 3.5 million adults remembered revealing sensitive personal or financial information to a phisher, while 2.3 million said that they had lost money because of phishing. The average loss is US$1,250 per victim, Gartner said.

In the past (June 2004: 1, 2), I've reported that phishing costs around one billion per year. Multiply those last two numbers above from Gartner, and we get around a billion over the last three years. Still a good rule of thumb then.

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."

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...

Threatwatch - bots, selling Ameritradelity, all your DNS belong to US

In our side project of collecting reported threat statistics, here's lots of them:

MessageLabs, a company that counts spam, recently stopped counting bot-infected computers because it literally could not keep up. It says it quit when the figure passed about 10 million a year ago. Symantec Corp. recently said it counted 6.7 million active bots during an Internet scan. Since all bots are not active at any given time, the number of infected computers is likely much higher. And Dave Dagon, who recently left Georgia Tech University to start a bot-fighting company named Damballa, pegs the number at closer to 30 million. The firm uses a "capture, mark, and release," strategy borrowed from environmental science to study the movement of bot armies and estimate their size.

"It's like asking how many people are on the planet, you are wrong the second you give the answer. : But the number is in the tens of millions," Dagon said. "Had you told me five years ago that organized crime would control 1 out of every 10 home machines on the Internet, I would have not have believed that. And yet we are in an era where this is something that is happening."

This transcript of a trading account fencing ("selling of stolen goods") spree reveals:

Two accounts on TD Ameritrade. One has $7,000, $2,000 on the other. Plus I have a us.etrade.com account which has $1,300. I will sell all for $250. I also have a Fidelity valued at $50,000 that I'll sell for $350. Purse on webmoney Zxxxxxxxxxxxx. I can send them in parts so you can be sure I am not a fraud, but you make the first transaction, and then I send you the money.

Funnily enough, the "fence" wasn't that smart, as the TV Intern doing the 'buying' tipped him off fairly early that he was probably an investigator.

Not a number, but a threat (posted by Duane, pointed out by Philipp):

DNSSec is poorly adopted already, and now the US Gov wants IANA to hand over private keys, giving people even less incentive to adopt.

"At an ICANN meeting in Lisbon, the US Department of Homeland Security made it clear that it has requested the master key for the DNS root zone. The key will play an important role in the new DNSSec security extension, because it will make spoofing IP-addresses impossible. By forcing the IANA to hand out a copy of the master key, the US government will be the only institution that is able to spoof IP addresses and be able to break into computers connected to the Internet without much effort. There's a further complication, of course, because even 'if the IANA retains the key ... the US government still reserves the right to oversee ICANN/IANA. If the keys are then handed over to ICANN/IANA, there would be even less of an incentive [for the U.S.] to give up this role as a monitor. As a result, the DHS's demands will probably only heat up the debate about US dominance of the control of Internet resources.'"

A Cook Report around 1997 laid out the basic case that it is US government formal but unstated policy that the net is controlled and kept as a US-managed institution. That makes the above an old and well understood threat; serious high security Internet systems do their "own DNS," including Skype, eCash, WebMoney, Ricardo. (All except the last are from memory and anecdotes.)

The above can be seen as a power play between the overseers of the poodle ICANN (Commerce Dept?) and the DHS, being the new kid on the block. The solution to the above problem is simply to issue the DNS root zone master key to every government agency that asks for it. If the crazies in DHS have a right to it (as they will argue) then so do the mad mullahs of Persia ... and all points in between.

Then, the root key moves to where Spire put it: 150,000 people with legitimate access to it, so no longer a security tool. Problem solved.

Addendum: dead link was this:

March 20, 2007- -

Hacker (March 9, 10:44 AM): Hello Svetlana! You need TD Ameritrade accounts?
I have a couple and Fidelity.com as well. On one there is 7k for cash
trading/withdrawal. How much are you willing to offer for it? Write me and
we will discuss )

Svetlana (11:42 AM): Hello! Thank you for responding...what percent do you
usually take for the information and what exactly will you give me if we
make a deal? Is the 7K in TD Ameritrade or in Fidelity.com?

Hacker (11:46 AM): Ok 7k is on the Ameritrade and I do not take a
percentage. I can just simply sell you the account. I am not a fraud you can
ask Egold he knows me. A couple of hundred dollars will satisfy me
completely.

Svetlana (11:53 AM): Ok, do you have the password and the number of that
account? And is this account American? How much money is in the Fidelity? A
couple of hundred is feasible, how much exactly do you want?

Hacker (12:03 PM): Two accounts on TD Ameritrade. One has $7,000, $2,000 on
the other. Plus I have a us.etrade.com account which has $1,300. I will sell
all for $250. I also have a Fidelity valued at $50,000 that I'll sell for
$350. Purse on webmoney Zxxxxxxxxxxxx. I can send them in parts so you can
be sure I am not a fraud, but you make the first transaction, and then I
send you the money.

Hacker (12:05 PM): Yes, all the accounts are American.

Svetlana (12:14 PM): Ok, so I will send you the money, and you will give me
1) username 2) password?

Hacker (12:16 PM): Of course, I have these accounts from time to time and if
you need them we can work together permanently. As soon as you make the
transaction I will send you the information in the email.

Hacker (12:34 PM): Svetlana, how do you like my offer? Are you going to buy,
I need to know that they are yours so I don't sell them. Write back.

Svetlana (12:52 PM): I will pay you double if along with this information
you have the names of these people and their SS #.

Hacker (12:56 PM): Ok when you enter you will see the owner's information.
When are you planning to buy the accounts? Today?

Hacker (1:00 PM): I also have two trading.scottrade.com accounts valued a
little under $40,000. Need them?

Svetlana (1:09 PM): Yes, I DEFINITELY need them. I never used a webmoney
account, how do I sign up to it?

Hacker (1:23 PM): Ok fine Svetlana I will help you make the transfer. Go to
www.roboxchange.com, select "exchange electronic money," "forward," in the
window select USD e-gold. For the receiver choose WMZ. Type in the amount in
your e-golds and below it will say how much that equals in webmoney. Copy
the number of the purse from the email Zxxxxxxxxxxxx. That's it, press
"exchange," the money will be instantaneously transferred to me and I will
send you the information for accessing the accounts, which will complete the
transaction.

Hacker (1:45 PM) So Svetlata, did you understand? Write back as soon as you
send.

Hacker (2:07 PM): Svetlana...

Svetlana (2:07 PM) Ok I signed up. However, $600 is big money, how would I
know FOR SURE that you will send them to me? Can you give me some kind of
proof?

Hacker (2:11 PM): I told you, Egold works with me, write him, he serves as
the guarantee during transactions. He is also the forum's moderator on which
you made the announcement. This is guarantee in itself. Believe me, I am not
a fraud, I am a salesperson of accounts. I make money from this, I have no
reason to ruin my reputation, especially since you are paying me good money
and there is no point to lose you as a client, which I have to find anyway.

Hacker (2:13 PM): My nickname is koloxxxx, he knows.

Hacker (2:38 PM): Svetlana, did you make the transaction, or am I
misunderstanding something?

Hacker (2:40 PM): For proof, I can send you one small account. Look and
understand that I am a real seller, this is my fraud-free business.
[https://wwws.ameritrade.com/cgi-bin/apps/LogIn]
Log on to TD AMERITRADE
USERID=xxxxxxxxx
PASSWORD=xxxxxxxxxxx

Svetlana (2:50 PM): I can not find the person's name and SSN# on this
account.

Hacker (2:54 PM): Ok this is just with Ameritrades, Fidelity has them. Make
the transfer and I will send you the rest, then we will talk in detail.

Hacker (2:56 PM): Fidelity has the SS #.

Svetlana (3:02 PM): So Ameritrades never have SSN#'s? I need the people's
names and their SSN#'s.

Hacker (3:11 PM): Ok Svetlana you wrote: "I need to access Schwab, E-trade,
TD Ameritrade accounts. I do not need credit cards -- only savings accounts
or 401(K)s. Pay good money, willing to make a deal. Write back asap, or
email me at Sveta.xxxx@gmail.com". So I showed you an account,
Ameritrade...unfortunately it lacks the information you need, specifically
the name of the owner, but on the Fidelity I have that information plus the
SS#. I also have us.etrade.com where the person's information can be seen. I
am completing my part of the deal, and am awaiting the same on your part.
Svetlana, what do you want from me, let's make the exchange and and I will
send you your accounts, or consequently I will open them up for sale. Make a
decision...

Hacker (3:31 PM): Do you need them or not?

Hacker (3:37 PM): Svetlana, are you still there?

Svetlana (3:47 PM): Yes, I need them but I will not have the money till
Monday (I am awaiting a transfer), can you wait till then? If not, will you
have anything remaining or will you have anything new on Monday?

Hacker (3:51 PM): Of course, and I will keep this material for you. It would
be nice if you would send me at least $50 as a sort of a guarantee for me.
If not then not...I will keep the accounts till Monday and I will be online
at that time so feel free to write me. Good luck Svetlana.

Svetlana (4:06 PM): I would rather send you the total amount on
Monday...thank you very much for your patience...talk to you soon!!

Hacker (March 12, 11:44 AM): Hello Svetlana! How are you today? Are you able
to make the transfer to the purse? As I promised I left you those accounts
and I also have 6-8 new fidelity each valued at $20-40k. Of course each has
a SS# and FIO of the owner as you needed. Write back as soon as you get
this.

Svetlana (11:54 AM): Hello! Yes I have the money, but how do I extract the
money from these accounts?

Hacker (12:01 PM): Svetlana I merely sell the accounts, the people that
purchase them they do everything as they wish and I have nothing to do with
it...You asked me to find accounts and I found them for you, will you be
buying those for $600?

Svetlana (12:08 PM): Sergey, actually I work for ABC News in New York. We
are doing a report on hackers that break into accounts. What you showed me
is very interesting, and we would like to interview you about your business.

Hacker (12:11 PM): ) Best of luck to you.

This exchange was translated from Russian to English.

Copyright © 2007 ABC News Internet Ventures
http://abcnews.go.com/wnt/print?id=2966583

Cost of an identity

Some figures on the cost to build a new identity:

In all, seven defendants pleaded guilty in Corpus Christi this past week to charges of selling their birth certificates and Social Security cards for $100 each. Seven other defendants pleaded guilty to buying or reselling those documents as part of a ring that sold documents to illegal immigrants seeking jobs in Dodge City, Kan.

One other figure:

Tim Counts, an Immigration and Customs Enforcement spokesman in Bloomington, Minn., said that investigation revealed documents were available for a price in places as open as Kmart parking lots. He said genuine documents were the most expensive, costing up to $1,500, and the most effective against detection.

That remark looks suspicious, I'd guess he's talking about something else than SS cards and birth certificates.

Also over in that center of expertise in identity theft, USA, a blog entry by Spire says:

1. For as long as we continue to pretend that SSNs are secret and therefore may be used as authenticators, they will be.
2. There are over 150,000 people (my estimate) with "defendable" access to your SSN right now. They aren't secret.
3. You are more likely by a factor of 10 to be a victim of identity fraud via one of these "authorized" folks.
4. The real problem is not how easy it is to get your SSN, but how creditors et.al. allow the SSN to be used as an authenticator (See #1).
5. The SSN is fine as an identifier. No, it is not perfect, but its main benefit is that it is already used in so many places.

Right. That's a number we wanted: 150k people in that country have access (legal, he says defendable) to the SSN. Presumably they have access to all the other PII as well.

Finally, someone gets done for Money Laundering....

Money Laundering (ML) was once tightly defined as washing the proceeds of (very) serious crime through an organised cycle.

How you could tell was supposed to be that there was (a) an awful lot of it, (b) there was a hot-button crime like drugs, and (c) an organisation that processed the cash. That's what the big drugs rings did; in effect, they outsourced the money problem to the professionals.

This is "real" money laundering:

Three members of a money laundering gang were jailed for a total of 15 years at Ipswich Crown Court today. Between June 2003 and September 2005 the gang laundered more than £100 million in cash for criminal organisations and individuals throughout the United Kingdom.

The court heard that this large scale money laundering operation was centred around a Money Services Bureau (MSB) on the London Road in Croydon, called Deans Exchange. This was run by Zaka Ud Din, with the assistance of Sabz Ali Khojo. As well as offering legitimate money services to the local community, Deans Exchange was being used as a front for a much larger operation, offering the laundering of cash.

My hat off to the guys who busted that ring.

These days, however, ML is a catch-all crime of no semantic meaning, given the massive preponderance of convictions where the only relationship was that it was a crime of some trivial amount of value. ML these days is more likely to mean a well-off professional goes down for one count of slapping his wife and 6 counts of ML.

Technically, this is the best it gets:

BRITAIN'S biggest and most feared gangster got away with murder yesterday when he was jailed for just seven years. Terry Adams, linked by police to 25 unsolved killings, was finally brought to justice after running a £200million crime empire for more than 25 years.

Like Al Capone, police were unable to make any serious charges stick against the crime kingpin and it was a financial scam that proved his downfall. Adams pleaded guilty to a single charge of money laundering - but was told he will be eligible for parole in three and a half years.

More public applaud to the British criminal authorities (and MI5 apparently). That was the case that AML (anti-money laundering) was designed for: get a notorious crime boss on the financials, because he killed all the witnesses (25 in the above case). You can't kill the flow of money, so the theory goes.

La Procuraduría General de la República investiga los vínculos internacionales de la compañía Unimed Pharm Chem de México, la cual fue fachada para que por lo menos desde 2004 un grupo de presuntos productores de drogas sintéticas acumulara en una residencia de las Lomas de Chapultepec más de 205 millones de dólares en efectivo, así como unos 200 mil euros y 157 mil pesos FOTO Ap /PGR

(Sorry about the spanish, haven't found an english article yet.) Which is why there was a rationale that if you could seize the cash, you did the crimeboss harm. The $205 million in cash in the photo above was seized this week in Mexico in some sort of financing deal for a complete factory to produce drugs.

When cash like that gets seized from MLers, this helps. Nobody can object to that!

But the more popular meaning of ML seizures is "police need money to finance more ML seizures." When someone you know gets accused of 5 counts of ML and 1 count of using the postal service, all because he rubbed the local FBI agent up the wrong way, AML becomes the enemy of civil society.

Relevance to FC: as we design systems of value, we must protect our users from illegal ML and from immoral AML. No easy task, given the lack of discrimination in the tools. Above, all the cases are clearly bad guys being caught by the good guys, and we applaud. Indeed, an honest ML bust is so rare that it's worth posting about.

An ordinary crime: stock manipulation

Sometimes when we can't seem to get anywhere on analysing our own sector of criminal activity, it helps to look at some ordinary stuff. Here's one:

According to the Commission's complaint, between July and November 2006, the Defendants repeatedly hijacked the online brokerage accounts of unwitting investors using stolen usernames and passwords. Prior to intruding into these accounts, the Defendants acquired positions in the securities of at least fourteen securities, including Sun Microsystems, Inc., and "out of the money" put options on shares of Google, Inc. Then, without the accountholders' knowledge, and using the victims' own accounts and funds, the Defendants placed scores of unauthorized buy orders at above-market prices. After these unauthorized buy orders were placed, the Defendants sold the positions held in their own accounts at the artificially inflated prices, realizing profits of over $121,500.

To achieve this benefit, the prosecution alleges that $875,000 of damage was done.

It's a point worth underscoring: a criminal attack in our world often involves doing much more damage than the gain to the criminal. For that reason, we must focus on the overall result and not on the headline number. Here's a more aggressive damages number:

The pump and dump scheme, which occured between July and November 2006, has cost one brokerage firm at least $2m in losses. An estimated 60 customers and nine US brokerage firms were identified as victims.

Also, funds seized.

Any good definitions of Phishing?

Somehow I ended up on Wikipedia's entry on phishing, and added a link from the AOL playtime era to its more modern incarnation of the rape & pillage of a financial district swollen with multi-nationals, conglomerates and fat, bloated merchant banks:

Transition from AOL to Financial Institutions

Capture of AOL account information may have led phishers to capture and misuse of (real) credit card information, which then evolved to attacks against online payment systems. The first direct attempt against a payment system may have been against e-gold, "going out of biz," June 2001, and was followed by "post-911 id check" shortly after 9/11.[14] Both were viewed at the time as failures, but can now be seen as early experiments towards more fruitful attacks against mainstream banks. By 2004, phishing was recognised as fully industrialised, in the sense of an economy of crime: specialisations emerged on a global scale and provided components for cash which were assembled into a finished attack. [15][16]

[edit]

Anyone can edit that page, honest injun! Also, at the top, it defines:

In computing, phishing is a criminal activity using social engineering techniques.[1]

Come on, surely we can do better than that!? What happened to the successful MITM? What happened to the failure of the browser security model? I think at least we need to inject some hubris in there: security designs failed. Sorry about that, let's get it fixed.

What are the potential definitions of phishing, then?

Posted by iang at 03:27 PM | Comments (1) | TrackBack

Threatwatch: $400 to 'own' your account

Some numbers from Guillaume Lovet on what it costs to gain control of an online bank account:

The most straightforward is to buy the 'finished product'. In this case we'll use the example of an online bank account. The product takes the form of information necessary to gain authorised control over a bank account with a six-figure balance. The cost to obtain this information is $400 (cybercriminals always deal in dollars).

Also, roles:

Coders - comparative veterans of the hacking community. With a few years' experience at the art and a list of established contacts, 'coders' produce ready-to-use tools (i.e. Trojans, mailers, custom bots) or services (such as making a binary code undetectable to AV engines) to the cybercrime labour force - the 'kids'. Coders can make a few hundred dollars for every criminal activity they engage in.

Kids - so-called because of their tender age: most are under 18. They buy, trade and resell the elementary building blocks of effective cyber-scams such as spam lists, php mailers, proxies, credit card numbers, hacked hosts, scam pages etc. 'Kids' will make less than $100 a month, largely because of the frequency of being 'ripped off' by one another.

Drops - the individuals who convert the 'virtual money' obtained in cybercrime into real cash. Usually located in countries with lax e-crime laws (Bolivia, Indonesia and Malaysia are currently very popular), they represent 'safe' addresses for goods purchased with stolen financial details to be sent, or else 'safe' legitimate bank accounts for money to be transferred into illegally, and paid out of legitimately.

Mobs - professionally operating criminal organisations combining or utilising all of the functions covered by the above. Organised crime makes particularly good use of safe 'drops', as well as recruiting accomplished 'coders' onto their payrolls.

And now for the big picture:

All of the following phishing tools can be acquired very cheaply: a scam letter and scam page in your chosen language, a fresh spam list, a selection of php mailers to spam-out 100,000 mails for six hours, a hacked website for hosting the scam page for a few days, and finally a stolen but valid credit card with which to register a domain name. With all this taken care of, the total costs for sending out 100,000 phishing emails can be as little as $60. This kind of 'phishing trip' will uncover at least 20 bank accounts of varying cash balances, giving a 'market value' of $200 - $2,000 in e-gold if the details were simply sold to another cybercriminal. The worst-case scenario is a 300% return on the investment, but it could be ten times that.

Better returns can be accomplished by using 'drops' to cash the money. The risks are high, though: drops may take as much as 50% of the value of the account as commission, and instances of 'ripping off' or 'grassing up' to the police are not uncommon. Cautious phishers often separate themselves from the physical cashing of their spoils via a series of 'drops' that do not know one another. However, even taking into account the 50% commission, and a 50% 'rip-off' rate, if we assume a single stolen balance of $10,000 - $100,000, then the phisher is still looking at a return of between 40 and 400 times the meagre outlay of his/her phishing trip.

Good foundation for the risk analysis.

CFP: 6W on the Economics of Information Security (WEIS 2007)

How much should we spend on security? What incentives really drive privacy decisions? What are the trade-offs that individuals, firms, and governments face when allocating resources to protect data assets? Are there good ways to distribute risks and align goals when securing information systems?

The 2007 Workshop on the Economics of Information Security builds on the success of the previous five Workshops and invites original research papers on topics related to the economics of information security and the economics of privacy. Security and privacy threats rarely have purely technical causes. Economic, behavioral, and legal factors often contribute as much as technology to the dependability of information and information systems. Until recently, research in security and dependability focused almost exclusively on technical factors, rather than incentives. The application of economic analysis to these problems has now become an exciting and fruitful area of research.

We encourage economists, computer scientists, business school researchers, law scholars, security and privacy specialists, as well as industry experts to submit their research and attend the Workshop. Suggested topics include (but are not limited to) empirical and theoretical economic studies of:

- Optimal security investment
- Software and system dependability
- Privacy, confidentiality, and anonymity
- Vulnerabilities, patching, and disclosure
- DRM and trusted computing
- Trust and reputation systems
- Security models and metrics
- Behavioral security and privacy
- Information systems liability and insurance
- Information threat modeling and risk management
- Phishing and spam

**Important dates**

- Submissions due: March 1, 2007
- Notification of acceptance: April 10, 2007
- Workshop: June 7-8, 2007

For more information visit http://weis2007.econinfosec.org/.

Tracking email - the disappearing myth, the #1 threat, versus ultra rare sighting of eavesdropping attack

Shades of OTR -- off-the-record -- a protocol that claims to provide plausible deniability.

A START-UP communications outfit is flogging a web-based email system that destroys the message after it has been read.

VaporStream system from Void Communications, which apparently is not a euphemism for VapourWare, works from an encrypted webpage. A punter visits the site, lists the person they want to talk too and chats away.

The names of the parties, or their messages are not stored anywhere and details can't be cut and pasted. Instead it is held on a temporary memory segment in a VaporStream server. When it is delivered, the server forgets that it ever existed.

The big problem is that these approaches completely fail to understand the real threat models for real people, and arguably make matters worse by creating a false sense of security, and encouraging people to deny the truths that can be proved in other ways.

The non-sexy #1 threat to email is breach of the node, and that threat breaches both of those approaches. Here's a reminder:

Last fall, agents on the FBI's public corruption squad faced a problem: They couldn't read encrypted e-mail seized from State Sen. Vincent J. Fumo's offices.

On Oct. 18, they got a break. Donald Wilson, a state Senate computer technician who had been granted immunity, suddenly remembered something, according to a newly unsealed FBI affidavit. He still had two portable data cards - with all the passwords to open the e-mail.

Wilson's lawyer called authorities and turned over the passwords. The feds were in.

With that breakthrough, the affidavit said, agents were able to read more Fumo office e-mails talking about destroying records and fretting about the FBI - a trail that helped lead to obstruction-of-justice charges against two other Fumo computer technicians, Leonard Luchko and Mark Eister.

An actual eavesdropping attack on "aircraft email" spotted by Steve Bellovin:

... ACARS is like an automated email system used by aircraft and ground control. An ACARS-enabled plane will transmit all kinds of information about what the plane is doing: where it is and where it's going, how much fuel it has, what the weather is like, and so on. These automated "emails" between aircraft and their ground controllers are encoded into radio signals clustered around the 131 megahertz and 136 megahertz frequencies.

A good scanner can receive these radio signals. To the ear, the transmissions sound like noise, but when filtered through a computer equipped with a software-based decoder the information contained in the airplanes' messages becomes comprehensible. Like notebooks filled with tail numbers and landing times, ACARS monitoring produces an endless stream of ridiculously detailed information, which ACARS enthusiasts from around the world dutifully post online.

The "open source" attack (c.f. John Robb) on the CIA's illegal renditions -- known as the torture taxi -- makes for fascinating reading. How relevant is such a threat model to general FC? In the past I would have said not relevant due to the context, but the recent open source work on the AOL privacy breach makes me think it is a valid threat, and the article is therefore valid case material.

It is curious to see how they would solve the ACARS problem. The only way that I can see is to use open source techniques of opportunistic cryptography, something that obviously has been fought against by the CIA and others. So the eavesdropping attack on plane traffic can be considered to be yet another example of how the USG's policy of low Internet security bites back. Chalk up another "Own Goal" like the Israeli "Defence" Force (IDF) results of last month (1, 2).

Threatwatch - the Feds are back, Israel finds it cuts both ways, Cybersecurity Enemy #1

A while back I postulated that email spying was now a present danger, and only lacking in clarity before it becomes a full-blooded validated threat. This sets us the task of tracking the trackers of email, so that we can create a model to predict how that threat effects us and our designs.

I haven't seen statistics on email snooping as yet, but here's some related news. The FBI is back with intent to spy:

The FBI has drafted sweeping legislation that would require Internet service providers to create wiretapping hubs for police surveillance and force makers of networking gear to build in backdoors for eavesdropping, CNET News.com has learned.

FBI Agent Barry Smith distributed the proposal at a private meeting last Friday with industry representatives and indicated it would be introduced by Sen. Mike DeWine, an Ohio Republican, according to two sources familiar with the meeting.

News of tracking email in US universities aimed at those protesting against unpopular policies:

The Department of Defense monitored e-mail messages from college students who were planning protests against the war in Iraq and against the military's "don't ask, don't tell" policy against gay and lesbian members of the armed forces, according to surveillance reports released last month. While the department had previously acknowledged monitoring protests on campuses as national-security threats, it was not until recently that evidence surfaced showing that the department was also monitoring e-mail communications that were submitted by campus sources.

The surveillance reports -- which were released to lawyers for the Servicemembers Legal Defense Network on June 15 in response to a Freedom of Information Act request filed by the organization last December -- concern government surveillance at the State University of New York at Albany, Southern Connecticut State University, the University of California at Berkeley, and William Paterson University of New Jersey. The documents contain copies of e-mail messages sent in the spring semester of 2005 detailing students' plans to protest on-campus military recruitment.

The reports are part of a government database known as Talon that the Department of Defense established in 2003 to keep track of potential terrorist threats. Civilians and military personnel can report suspicious activities through the Talon system using a Web-based entry form. A Pentagon spokesman, Greg Hicks, would not verify whether the reports released last month were follow-ups to tips from military or government personnel, or from civilians at the universities.

This is a little different in that civilians seem to monitor and report the emails to the Pentagon. Universities are places were one would expect at least passing familiarity with civil rights and so forth, so it is somewhat curious to speculate who on campuses would be tipping off the authorities about protests against on-campus military activities...

The Talon reporting system gained national attention in December 2005 when NBC News obtained a copy of a 400-page Department of Defense document listing more than 1,500 "suspicious incidents" that had taken place across the country. Only 21 pages were released to the Servicemembers Legal Defense Network, since the group requested only documents related to lesbian, gay, bisexual, and transgender individuals and student groups. Mr. Hicks would not disclose the total number of reports that have been filed under the Talon program.

OK, Numbers! We can conclude that minority sexual preferences represent 5% of the current threat level to the DoD. If each page has an email on it, that gives 1500 emails reported in the programme -- that's not a particularly robust estimate but it might represent a lower bound.

And, wait until they get their mits on phone viruses, which store all that juicy lovetalk.

A company, Trust Digital of McLean, Va., bought 10 different phones on eBay this summer to test phone-security tools it sells for businesses. The phones all were fairly sophisticated models capable of working with corporate e-mail systems.

Curious software experts at Trust Digital resurrected information on nearly all the used phones, including the racy exchanges between guarded lovers. The other phones contained:

1. One company's plans to win a multimillion-dollar federal transportation contract.
2. E-mails about another firm's $50,000 payment for a software license.
3. Bank accounts and passwords.
4. Details of prescriptions and receipts for one worker's utility payments.

A while back I reported that people worrying about cell/mob/handy phone tapping where missing the point - there is tracking ability which is far more useful than tapping ability. Sad to say, that battle is pretty much all over as phones move to include GPS by default.

One Facebook user, signing the petition opposing the recent changes, noted: "I find it sad this is one of the few issues our generation can band together, complain online and take little real action over. (ROFL)". Therein lies the crux about privacy and tracking: most vehement complaining takes place after people feel they have been victimised by technology, and long after it has been popularised.

We are moving as a society to total tracking, and the privacy community didn't notice until it was all over.

So who loses? Well, the Israeli Defence Force, for one. Alexander Klimov made the connection on the crypto list (which I missed even as I reported on the Sigint story):

My guess that at least some information was leaked due to cellular phones (the solders were routinely calling their families).

"Besides radio transmissions, the official said Hezbollah also monitored cell phone calls among Israeli troops. But cell phones are usually easier to intercept than military radio, and officials said Israeli forces were under strict orders not to divulge sensitive information over the phone."

Even if one don't care what was said over the phone, a lot of information can be extracted from mere location of a phone (especially, if one knows the owner of each phone):

"Israeli officials said the base also had detailed maps of northern Israel, lists of Israeli patrols along the border and cell phone numbers for Israeli commanders."

The Hezbollah tracking was on the individuals. They tracked the commanders as indicative of where the units were. Oops. I'd just love to be part of the design exercise to fix that blooper :)

This is the core failure that the US government foistered on the world. Since time immemorial, the USG has maintained crypto as a munition, and thus it is to be suppressed. This has led to two effects: firstly, the civilian Internet infrastructure is weak and brittle, due to the effect of lots of little barriers against crypto. Our best ally in security suffered the "death of a thousand cuts," as it were.

Secondly, as the civilian infrastructure overtook the military infrastructure, it left the military operations vulnerable when inevitably civilian assets were used for military tasks. If you've ever used military radio gear, you know you have a big problem when every soldier carries a much more powerful device in his pocket, albeit one deliberately weakened by government intervention.

Without dwelling on these points, we can also suggest that this explains why the job of Cybersecurity Czar is a woftam: the employer is cybersecurity's enemy number one.

Threatwatch - sigint by Hezbollah, nyms by torture units, closed source weaponry

Felix points to a Newsday article that describes signals intelligence in the recent Lebanon battle.

Hezbollah guerrillas were able to hack into Israeli radio communications during last month's battles in south Lebanon, an intelligence breakthrough that helped them thwart Israeli tank assaults, according to Hezbollah and Lebanese officials.

Using technology most likely supplied by Iran, special Hezbollah teams monitored the constantly changing radio frequencies of Israeli troops on the ground. That gave guerrillas a picture of Israeli movements, casualty reports and supply routes. It also allowed Hezbollah anti-tank units to more effectively target advancing Israeli armor, according to the officials.

"We were able to monitor Israeli communications, and we used this information to adjust our planning," said a Hezbollah commander involved in the battles, speaking on the condition of anonymity.

First off, article tries and fails to make the case that the codes were cracked. If that article is anything to go by, it was straightforward -- and well done -- signals intelligence, not code cracking. (El Reg describes it more fairly.) Secondly, it provides more evidence for the reasons behind the Israeli defeat at the hands of the Hezbollah (defeat in straight military mission terms):

"The Israelis did not realize that they were facing a guerrilla force with the capabilities of a regular army," said a senior Lebanese security official who asked not to be identified. "Hezbollah invested a lot of resources into eavesdropping and signals interception."

The Israelis like many modern political movements have been so well fed on a diet of terrorism that they missed the transition. Hezbollah has moved from terrorism through guerilla and up to army status, as laid out in the theory of guerilla warfare. The depth of sigint capability bears this out.

Aside from minor criticisms, a good article. Why talk matters military on an FC blog? One of the reasons that the Internet is so messed up, security wise, is that the threat models derived from military and spook lore. For example, the MITM is more of a threat in the military, less of a threat on the net (rising commercial use of wireless might have been expected to change that, but there isn't much empirical evidence). This failure to understand the different threat models caused massive rollouts of unneeded infrastructure, stuff that could help us now but is instead being slowly built around by banks, merchants and other institutions.

Just because we were fooled once doesn't mean we can't be fooled again, so it is important to keep an eye on related threat fields. Here's some older notes on recent threats in the military world.

In the ongoing saga of institutional torture in the US forces, the NYT published a new case regarding an elite terrorist unit known briefly as Task-Force 6-26 (SMH). Not only does the unit change its name from time to time the individual soldiers have picked up the trick:

Army investigators were forced to close their inquiry in June 2005 after they said task force members used battlefield pseudonyms that made it impossible to identify and locate the soldiers involved. The unit also asserted that 70 percent of its computer files had been lost.

Pseudonyms are not perfect. But, they can do a lot to help privacy, in that they break the chain of investigation. It's not so easy in digital systems, because the pseudonyms are generally used to communicate with other pseudonyms or persons, and that leaves a chain to track back, as well as the tendency for server software to log lots of events. But with persons, it is a grand trick.

Military and legal experts say the full breadth of abuses committed by Task Force 6-26 may never be known because of the secrecy surrounding the unit, and the likelihood that some allegations went unreported. In the summer of 2004, Camp Nama closed and the unit moved to a new headquarters in Balad, 45 miles north of Baghdad. The unit's operations are now shrouded in even tighter secrecy.

Secrecy is always a threat to your operations. It may bring benefits, but the costs are severe as secrecy hides weaknesses from yourself as well as your enemy, and there is no easy way to know who can breach that veil. It is the canonical two-edged sword, and we generally address such threats-to-self with governance techniques - separation of roles also known as the 4 eyes principle, publication of key events, entangled logging, shared signed receipts, and so forth.

Which leads us to the age-old problem of buying stuff from people you don't trust. Ben pointed to:

The UK has warned America that it will cancel its £12bn order for the Joint Strike Fighter if the US does not hand over full access to the computer software code that controls the jets. Lord Drayson, minister for defence procurement, told the The Daily Telegraph that the planes were useless without control of the software as they could effectively be "switched off" by the Americans without warning.

Well, of course. The software for those planes is quite something, and only the source code is going to give you some confidence that there aren't any backdoors.

In a related episode, Washington DC discovered around the same timeframe that there may be an issue with the Boeing 787, so they have asked Boeing to not hand over any military or secret related material to the Chinese. Whoops, too late, it turns out the wing is being manufactured in China ... for those who don't know, in avionics terms, the wing is the prize as it is the one component that limits and dominates everything else, design wise.

Threatwatch - "you again operate impulsively in the manner"

Apparently, I sent this email to someone, and it bounced, possibly because of the attached viruses!

Subject: Re: The Proof !!!
From: iang
Date: Tue, 18 Jul 2006 09:26:04 +0200
To: anton

Hello,

Monday, July 17, 2006,3:14:35 PM, you wrote:

> >I think that you again operate impulsively in the manner
> >calm down and tell though that any that simply more than
> >simple charges your jealousy does not know a limit!!!!!

I do not understand why you still screen its all.
I have collected already so much proofs, that
listening to your remarks is inclined to think
as at you with it something too was.
Now I already avoiding half-words send photos
where it does sucked to my boss!
Well, also what you to me on it will tell?

P.S. To anybody it do not show.
If I from your neighbour learn as you have transformed it into a
circus, I to you guarantee troubles. Within the next few days
do not write, I have already drunk in office and I think
to go for city that and you I wish.

--
Best regards,
iang mailto:iang

What answer is there to that?

Threatwatch - 2-factor tokens attacked by phishers - another "must-have" security tool shown to be fighting the last war

Lance James points out that Phishers have moved on to attacking 2-factor authentication tokens:

The site asks for your user name and password, as well as the token-generated key. If you visit the site and enter bogus information to test whether the site is legit -- a tactic used by some security-savvy people -- you might be fooled. That's because this site acts as the "man in the middle" -- it submits data provided by the user to the actual Citibusiness login site. If that data generates an error, so does the phishing site, thus making it look more real.

This news (Brian Krebs in a Washington Post blog) has been expected (#10.3) for a long time. It's a timeline point -- we've moved to that stage.

More bad news for suppliers of 2-factor tokens and also US Banks which got a quasi-recommendation to implement something like this. I say, quasi-something, because the FDIC carefully did not recommend any specific technology, choosing instead to recommend that banks carefully review their risk-based exposure (although I also called it wrongly, initially). The banks themselves may have assumed tokens or similar, for whatever reason.

It has been interesting to watch RSASecurity deal with this. I'd say they saw the writing on the wall maybe a year or two ago. They aggressively expanded from their older PKI roots and their staple SecureId 2-factor token by buying more modern companies such as Cyota in Britain. It was Cyota that pushed them into "defence in depth" which involved transaction monitoring and risk-graduated authentication mechanisms.

RSASecurity also purchased PassMark which had a big deal to provide Bank Of America with unique pictures for each account user, in what they call their "2-factor-2way" solution. Between the two of them, these two companies buried the older "2-way authentication" system known as SSL which RSASecurity had had so much to do with in the early days (the one the phishers showed to be a Maginot defence).

Now the phishers count coup again -- PassMark's technology is also vulnerable to the new phishing attack. Being bought out by EMC might have been a good move alround.

Now, the casual marketeer will take this as gloating. We've predicted this for so long, we must be overjoyed. No such. That would be their own lack of familiarity at open criticism, an essential tool in risk management, because attackers brook no marketing fools. Here's where we are at.

Firstly, the industry is in dire straights and the sooner we recognise it the better. RSASecurity, or Cyota as it happens, recognised the broken SSL system a while back.

Secondly, it is absolutely vital that this information be put out in to the wider community. European banks have been working like mad for 6 months. American banks are still fighting the last war, and while they are looking backwards, there are more enemies coming up. American banks, for lethargy and bad advice, and American security suppliers, for liability *1, 2) and overzealous histories, are especially vulnerable.

It is American account holders to whom this column is devoted, today.

• Chandler at Not Bad for a Cubicle including some interesting debate in comments
• John Quarterman at Perilocity

Galileo (EuroGPS) cracked

Darren points to a development reminiscent of satellite TV: the codes to protect the European Galileo satellite's positioning signals have been cracked by a team from Cornell University in USA. Full story below:

Cracking the secret codes of Europe's Galileo satellite

Members of Cornell's Global Positioning System (GPS) Laboratory have cracked the so-called pseudo random number (PRN) codes of Europe's first global navigation satellite, despite efforts to keep the codes secret. That means free access for consumers who use navigation devices -- including handheld receivers and systems installed in vehicles -- that need PRNs to listen to satellites.

The codes and the methods used to extract them were published in the June issue of GPS World.

The navigational satellite, GIOVE-A (Galileo In-Orbit Validation Element-A), is a prototype for 30 satellites that by 2010 will compose Galileo, a $4 billion joint venture of the European Union, European Space Agency and private investors. Galileo is Europe's answer to the United States' GPS.

Because GPS satellites, which were put into orbit by the Department of Defense, are funded by U.S. taxpayers, the signal is free -- consumers need only purchase a receiver. Galileo, on the other hand, must make money to reimburse its investors -- presumably by charging a fee for PRN codes. Because Galileo and GPS will share frequency bandwidths, Europe and the United States signed an agreement whereby some of Galileo's PRN codes must be "open source." Nevertheless, after broadcasting its first signals on Jan. 12, 2006, none of GIOVE-A's codes had been made public.

In late January, Mark Psiaki, associate professor of mechanical and aerospace engineering at Cornell and co-leader of Cornell's GPS Laboratory, requested the codes from Martin Unwin at Surrey Space Technologies Ltd., one of three privileged groups in the world with the PRN codes.

"In a very polite way, he said, 'Sorry, goodbye,'" recalled Psiaki. Next Psiaki contacted Oliver Montenbruck, a friend and colleague in Germany, and discovered that he also wanted the codes. "Even Europeans were being frustrated," said Psiaki. "Then it dawned on me: Maybe we can pull these things off the air, just with an antenna and lots of signal processing."

Within one week Psiaki's team developed a basic algorithm to extract the codes. Two weeks later they had their first signal from the satellite, but were thrown off track because the signal's repeat rate was twice that expected. By mid-March they derived their first estimates of the code, and -- with clever detective work and an important tip from Montenbruck -- published final versions on their Web site (http://gps.ece.cornell.edu/galileo) on April 1. The next day, NovAtel Inc., a Canadian-based major manufacturer of GPS receivers, downloaded the codes from the Web site and within 20 minutes began tracking GIOVE-A for the first time.

Galileo eventually published PRN codes in mid-April, but they weren't the codes currently used by the GIOVE-A satellite. Furthermore, the same publication labeled the open source codes as intellectual property, claiming a license is required for any commercial receiver. "That caught my eye right away," said Psiaki. "Apparently they were trying to make money on the open source code."

Afraid that cracking the code might have been copyright infringement, Psiaki's group consulted with Cornell's university counsel. "We were told that cracking the encryption of creative content, like music or a movie, is illegal, but the encryption used by a navigation signal is fair game," said Psiaki. The upshot: The Europeans cannot copyright basic data about the physical world, even if the data are coming from a satellite that they built.

"Imagine someone builds a lighthouse," argued Psiaki. "And I've gone by and see how often the light flashes and measured where the coordinates are. Can the owner charge me a licensing fee for looking at the light? … No. How is looking at the Galileo satellite any different?"

Adam pointed to more here and slashdot.

FC++3 - Concepts against Man-in-the-Browser Attacks

This emerging threat has sent a wave of fear through the banks. Different strategies have been formulated and discussed in depth, and just this month the first roll-outs have been seen in Germany and Austria. This information cries out for release as there are probably 10,000 other banks out there that would have to go through and do the work again.

Philipp Gühring has collected the current best understanding together in a position paper entitled "Concepts against Man-in-the-Browser Attacks."

Abstract. A new threat is emerging that attacks browsers by means of trojan horses. The new breed of new trojan horses can modify the transactions on-the-fly, as they are formed in in browsers, and still display the user's intended transaction to her. Structurally they are a man-in-the-middle attack between the the user and the security mechanisms of the browser. Distinct from Phishing attacks which rely upon similar but fraudulent websites, these new attacks cannot be detected by the user at all, as they are use real services, the user is correctly logged-in as normal, and there is no difference to be seen.

The WYSIWYG concept of the browser is successfully broken. No advanced authentication method (PIN, TAN, iTAN, Client certificates, Secure-ID, SmartCards, Class3 Readers, OTP, ...) can defend against these attacks, because the attacks are working on the transaction level, not on the authentication level. PKI and other security measures are simply bypassed, and are therefore rendered obsolete.

If you are not aware of these emerging threats, you need to be. You can either get it from sellers of private information or you can get it from open source information sharing circles like FC++ !

SWIFT breached - Big Badda Boom - will this hasten dollar shift?

SWIFT has been breached. We can argue about the definition of this, but we'll knock that one right on the head:

CIA operatives trying to track Osama bin Laden's money in the late 1990s figured out clandestine ways to access the SWIFT network. But a former CIA official said Treasury officials blocked the effort because they did not want to anger the banking community.
...
Unlike telephone lines and e-mail communications, the SWIFT network cannot be easily tapped. It uses secure log-ins and state-of-the-art encryption technology to prevent intercepted messages from being deciphered. "It is arguably the most secure network on the planet," said the former SWIFT executive who spoke on condition of anonymity. "This thing is locked down like Fort Knox."

So what was holding back the CIA from tracing Osama's cash through SWIFT in the late 1990s? The Treasury department, that's who:

Historically, "there was always a line of contention" inside the government, said Paul Pillar, former deputy director of the CIA's counterterrorism center. "The Treasury position was placing a high priority on the integrity of the banking system. There was considerable concern from that side about anything that could be seen as compromising the integrity of international banking."

The money system is the be-all and end-all. It is the rock on which society is built - it intermediates all transactions. It counts all wealth, at the end of the day. It delivers the information that makes the economy work. So when the Treasury said to the spooks "mitts off" it was speaking with more than ordinary concern.

Which all vanished when 9/11 came along. The economy -- the money system -- became second priority, and the US isn't a country for second places. Damage control is immediate by John Snow, Treasury Secretary:

"President Bush has made it clear that ensuring the safety of the American people and citizens around the globe must be our number one priority.

"Consistent with this charge, one of the most important things we at Treasury do is to follow the flow of terrorist monies. They don't lie. Skillfully followed, they lead us to terrorists themselves, thereby protecting our citizens.

Some more damage control here.

The danger of breaching SWIFT and putting the database into the hands of the various and many US agencies is still present, or the US Treasury was talking out its hat to the CIA in the 1990s. This is obviously going to surprise the banks around the world, not to mention governments like Iran which are "by US fiat" terrorist supporting, China that is locked in a resource battle, and Russia which is emerging from the old cold war days as power that wants reckoning with. Even in the cold war, Russia and allies like Cuba dealt in dollars.

Does this system work? Does John Snow have the picture? We have to make a judgement call here. Every official will leap to the defence, but these are the same officials that kept it secret in the first place. But we can expect some ex-officials to express their skepticism:

Current and former U.S. officials said the effort has been only marginally successful against Al Qaeda, which long ago began transferring money through other means, including the highly informal banking system common in Islamic countries.

The value of the program, Levey and others said, has been in tracking lower- and mid-level terrorist operatives and financiers who believe they have not been detected, and militant groups, such as Hezbollah, Hamas and Palestinian Islamic Jihad, that also operate political and social welfare organizations.

Of course there is another reason why this won't be much good: If Osama Bin Laden or his team were congenitally stupid, they might imagine that SWIFT had not been breached, and the somewhat famed Belgian penchant for banking secrecy would protect them. Sadly for all his victims, we have plenty of evidence that he is fairly smart, he is very far from dumb, and even if this were the case, even the stupidist and thuggiest of drugs dealers seem to be quite adept at hiring good money launderers, if the claimed growth of that money flow is any guide.

(To be frank, I'm a bit surprised at the blow up of this one. I suppose I simply assumed from way back that SWIFT records were already being funnelled to the UST. Consider any outrage written here to be journalistic.)

In effect, the Bush administration have taken on the ire of the banking world, for no gain. It remains to be seen what will be made of this in other countries. John Snow, Treasury Secretary, says response is isolated to the Press. Keep reading those papers, Mr Snow - Banks normally do not signal their displeasure so openly, so you can be sure that you won't have too much worry there...

Moving on from the mild gossip stuff, let's get to the harder governance questions.

We can imagine that many banks and many governments will be going through that "Big Badda Boom" moment as they realise who's reading their traffic. Expect more pressure on the dollar, and more pressure for independent systems. The islamic world will almost certainly push for something, but probably not Sealand, which burnt out today. Any country on the axis-of-evil list is a gonna, as they are by US-definition terrorist-related.

Examine the case of SWIFT. In comes the subpoena, which they make great stress of as compulsory. But let's make no bones about it -- this was a force-based subpoena, and probably an illegal one at that, or backed up by an Executive Order that was probably itself "presidential writ of the novel kind."

What then to do? Comply, probably, in the instance. There is no point in SWIFT leaving the United States, as there are more banks there than the rest of the world put together (an artifact of State banking, not necessarily anything else.) But, in the meantime, design of systems to very carefuly limit the damage would be appreciated. Minimal information, and oversight.

Oversight? Let's talk about oversight.

In a major departure from traditional methods of obtaining financial records, the Treasury Department uses a little-known power - administrative subpoenas - to collect data from the SWIFT network, which has operations in the U.S., including a main computer hub in Manassas, Va. The subpoenas are secret and not reviewed by judges or grand juries, as are most criminal subpoenas. ... Treasury shares the data with the CIA, the FBI and analysts from other agencies, who can run queries on specific individuals and accounts believed to have terrorist connections, Levey said Thursday in an interview with The Times. ... Levey said the program is subject to "robust" checks and balances designed to prevent misuse of the data. He noted that requests to access the data are reviewed by Treasury's assistant secretary for intelligence; that analysts can only access the data for terrorism-related searches; and that records are kept of each search and are reviewed by an outside auditor for compliance.

Levey said there had been one instance of abuse in which an analyst had conducted a search that did not meet the terrorist-related criteria. The analyst was subsequently denied access to the database, he said. New safeguards have been added, he said, noting that SWIFT officials are now allowed to be present when analysts search the data and to raise objections with top officials.

Officials from other government agencies have raised the issue of accessing the records for other investigative purposes, but Levey said such proposals have been rejected - largely out of concern that doing so might erode support for the program.

Asked what would prevent the data from being used for other purposes in the future, Levey said doing so would likely trigger objections from SWIFT and the outside auditor. A SWIFT representative said that Booz Allen Hamilton, an international consulting firm, is the auditor, but provided no further details on how the oversight process works.

OK, so this time they have taken data sharing seriously. They know this data is hot, hot, hot, given the unprecedented step to protect it before being caught. They have 3 sets of guardians (2 better than hapless Sealand).

Unfortunately the oversight is crippled: An internal review of requests. SWIFT officers, who are already compromised and an auditor who is unlikely to blow the lid on it, as he's covered by national security, secrecy, and great pay. In short, nothing independent, nothing open and nothing with teeth. No judge, not even FISA. Signs are Congressional oversight is limited to the extent that they cannot see what it does:

Lee Hamilton, a former congressman and co-chairman of the commission who said he has been briefed on the SWIFT program, said U.S. intelligence agencies have made significant progress in recent years, but are still falling short. "I still cannot point to specific successes of our efforts here on terrorist financing," he said.

I'd give it 3 years before it is comprehensively breached. If they didn't want that then they would have set up the tracking in Brussels, and put in international oversight. Curiously, maybe Congress will wake up at this point and realise that they've got a tiger by the tail. When that transaction tracking starts getting used for non-terrorist purposes, there are going to be some very annoyed people.

White Helicopter - Is eavesdropping a "Clear and Present Danger" - the definition of a validated threat?

We have often discussed how threats arise and impact security models. The hugely big question is whether to include this threat or this other threat? I think there is a metaphor to address part of this question - whether a threat is a clear and present danger. Let me meander in that general direction before I try and define it.

We cannot include all threats as to some extent everything is a threat - a chance of stubbing ones toe, a harsh word from your spouse, a neighbour looking over the fence, the theft of your notebook. Removal of all threats would result in death of the soul, and can probably only be accomplished by death of the body.

So we must choose - which threats to protect against and which to accept. We give it the exotic title of risk management, but a more common definition is real life: we can only live by choosing to accept the greater body of the minor threats to us, and minimising the dangerous ones.

How we choose which threats to address is based on many factors. Some are easy - we can defend against them for free. Others are so cheap that we don't notice, or they come with substantial other benefits. So, to preserve our modesty, we wear clothes - and that keeps us warm so we get the security for free. Except in summer, where humans are exposed to interesting social games between the threat model of modesty and the heat of the sun, which raise for some deep questions as to whether nudity is the threat, or is the modesty? But then winter comes again and the argument is shelved for another year.

Other threats are not so easy nor so endearing to discuss. These are the ones that run slap bang into costs. The canonical case in financial cryptography is the MITM - the man in the middle attack -- and its defence in the SSL protocol. I think I have shown in compelling, albeit long winded, terms, that this threat was not valid and not worth protecting against in the application sometimes known as ecommerce. It raised many costs, one amongst them being a heightened risk of MITM in another form - phishing. See many rants on that elsewhere.

One of the things that came out of that long research into SSL and its failure to preserve the very harm it was intended to protect is the concept that a threat should be validated. I only had a hazy idea that this meant that we should be able to prove its danger to us, clearly, enough for us to protect against it.

Now, in addressing the emerging threat of eavesdropping, the question arises whether it is validated? We can see it, we can feel it - it is in the papers and the blogs and in the "denials." But is it validated?

I think not. Until we know how much it is, we don't know how what the risk of it happening to us is, and therefore we do not know how much to spend protecting against it. We simply do not know -- yet -- how much the eavesdropping is going to cost us, either individually or as a society. So we are not informed enough to make economic decisions.

But wait! I've laid out a case that the danger of eavesdropping is right there in front of us -- how can we possibly ignore it? Let's look a little further.

The possibility of eavesdropping by national agencies has always been there. I first heard of Echelon in the early 80s -- so far back in time that I can't recall where or when it was mentioned. But, I also knew -- or discovered at that time -- that it was ineffective. That is, it did not achieve the dream of the technologists at the UKUSA agencies. (For the answer to why you probably need to resort to computer science and the emergence of datamining.)

So we know that eavesdropping has always been there, in Internet time. It is present. But also, we know that traditionally, societies did not permit the eavesdroppers to share that information. History is replete with examples where the spooks were not permitted to pass valuable local intelligence to the authorities, and no doubt they all have stories about how they know who the killer was in this or that unsolved murder case.

So we know that however effective the eavesdropping was, it wasn't dangerous to us because it was so tightly constrained that it would never be passed into general society. That was the quid pro quo, the deal with the devil.

And indeed, that is what has changed -- the eavesdropping information is now being shared across a wide group of agencies. It's only a step away from being commercially shared, once you can pick and choose which agency to pervert. So it is now dangerous to society - to you, me and everyone - because there is always someone with money to pay for data that we are trying to keep private.

But we lack clarity. As a community of Internet engineers, we still do not know how much this danger is going to cost us. I simply do not know whether to drop everything I'm doing and start working on cryptoplumbing again, or whether for the most part, someone can still hide in the noise levels of the net? We lack clarity, or clearness, in our threat.

Out of which thoughts gives me a general definition for a validated threat: Is it a clear and present danger?

• It is Clear if I can measure it and risk-analyse it, so as to present a cost model to drive our economic choices.
• It is Present if I can show it to exist, actively, today.
• It is a Danger if it can do our beneficiaries harm.

Eavesdropping is Present and Dangerous. It is not yet Clear, so we are now challenged as a community to measure it. Once we can inform ourselves of the clarity of the threat, we can declare it to be a validated threat - a clear and present danger. We're not there yet, but at least I can propose a definition on how to get there!

Black Helicopter #2 (ThreatWatch) - It's official - Internet Eavesdropping is now a present danger!

A group of American cryptographers and Internet engineers have
criticised the FCC for issuing an order that amounts to a wiretap instruction for all VoIP providers.

For many people, Voice over Internet Protocol (VoIP) looks like a nimble way of using a computer to make phone calls. Download the software, pick an identifier and then wherever there is an Internet connection, you can make a phone call. From this perspective, it makes perfect sense that anything that can be done with a telephone, including the graceful accommodation of wiretapping, should be able to be done readily with VoIP as well.

The FCC has issued an order for all ``interconnected'' and all broadband access VoIP services to comply with Communications Assistance for Law Enforcement Act (CALEA) --- without specific regulations on what compliance would mean. The FBI has suggested that CALEA should apply to all forms of VoIP, regardless of the technology involved in the VoIP implementation.

In brief the crypto community's complaint is that it is very difficult to implement such enforced access, and to do so may introduce risks. I certainly agree with the claim of risks, as any system that has confused requirements becomes brittle. But I wouldn't bet on a company not coming out with a solution to these issues, if the right way to place the money was found. I've previously pointed out that Skype left in a Centralised Vulnerability Party (CVP, sometimes called a TTP), and last week we were reminded of the PGP Inc blunder by strange and bewildering news over in Mozilla's camp.

So where are we? The NSA has opened up the ability to pen-trace all US phones, more or less. Anyone who believes this is as far as it goes must be disconnected from the net. The EFF's suit alleges special boxes that split out the backbone fibre and suck it down to Maryland in real time. The FBI has got the FCC to order all the VoIP suppliers into line. Mighty Skype has been brought to heel by the mighty dollar, so it's only a phone call away.

Over in other countries - where are they, again? - there is some evidence that police in European countries have routine access to all cellphone records. There is other evidence that the EU may already have provided the same call records to the US (but not the other way around, how peculiar of those otherwise charming Europeans) in much the same way as last week the EU were found to be illegally passing private data on air travellers. To bring this into perspective, China of course leads the *public* battle for most prominent and open eavesdropper with their Cisco Specials, but one wonders whether they would be actually somewhat embarrassed if their capabilities were audited and compared?

If you are a citizen of any country, it seems, you need not feel proud. What can we conclude?

1. Eavesdropping has now moved to a real threat for at least email and VoIP, in some sense or other.
2. Can we say that it is a validated threat? No, I think not. We have not measured the frequency and cost levels so we have no actuarial picture. We know it is present, but we don't know how big it is. I'll write more on this shortly.
3. The *who* that is doing it is no longer the secure, secret world of the spooks who aren't interested in you. The who now includes the various other agencies, and they *are* interested in you.
4. Which means we are already in a world of widespread sharing across a wide range of government agencies. (As if sharing intel has not been a headline since 9/11 !)
5. it is only one step from open commercial access. Albeit almost certainly illegal, there isn't likely to be anything you can do about illegally shared data, because it is the very agents of the law which are responsible for the breach, and they will utter the defence of "national security," to you, and the price, to your attacker.
6. An assault on crypto can't be that far off. The crypto wars are either already here again, or so close we can smell them.
7. We are not arguing here, today, whether this is a good thing for the mission to keep us safe from terrorists, or a bad thing. Which is just as well, because it appears that when they are given the guy's head on a plate, the law enforcement officers still prefer to send out for takeaway.

My prediction #1for 2006 that government will charge into cyberspace in a big way is pretty much confirmed at this stage. Obviously this was happening all along, so it was going to come out. How important is this to you the individual? Here's an answer: quite important. And here's
some evidence:

What is Political Intelligence?Political intelligence is information collected by the government about individuals and groups.
Files secure under the Freedom of Information Act disclose that government officials have long been
interested in all forms of data. Information gathered by government agents ranges from the most personal data about sexual liaisons and preferences to estimates of the strength of groups opposing U.S. policies. Over the years, groups and individuals have developed various ways of limiting the collection of information and preventing such intelligence gathering from harming their work.

It has now become routine for political activists -- those expressing their rights under democracy -- to be investigated by the FBI. In what is a blowback to the days of J.Edgar Hoover, these activists now routinely advising their own people on how to lawfully defend themselves.

Hence the pamphlet above. There are two reasons for gathering information on 'sexual liasons and preferences.' Firstly, blackmail or extortion. Once an investigator has secret information on someone, the investigator can blackmail -- reveal that information -- in order to extort the victim to turn on someone else. Secondly, there may be some act that is against the law somewhere, which gives a really easy weapon against the person. Actually, they are both the same reason.

If there is anyone on the planet who thinks that such information shouldn't be protected then, I personally choose not to be persuaded by that person's logic ("I've got nothing to hide") and I believe that we now have a danger. It's not only from the harvesting by the various authorities:

Peter G, 41, asked for a divorce from his wife of six years, Lori G, 38, in March 2001. ... Lori G filed a counterclaim alleging the following: <snip...> and wiretapping. The wiretapping charges are what make this unfortunate case relevant to Police Blotter. ... But Peter admitted to "wiretapping" Lori's computer.

The description is general: Peter used an unspecified monitoring device to track his wife's computer transactions and record her e-mails. Lori was granted $7,500 on the wiretapping claim. ...

This is hardly the first time computer monitoring claims have surfaced in marital spats. As previously reported by CNET News.com, a Florida court ruled last year that a wife who installed spyware on her husband's computer to secretly record evidence of an extramarital affair violated state law.

Some hints on how to deal with that danger. Skype is probably good for the short term in talking to your loved one while he still loves you, notwithstanding their CVP, as that involves an expensive, active aggressive act which incurs a risk for the attacker. However, try and agree to keep the message history off - you have to trust each other on this, as the node and your partner's node remain at greater danger. Email remains poor because of the rather horrible integration of crypto into standard clients - so use Skype or other protected chat tools.

Oh, and buy a Mac laptop. Although we do expect Macs to come under increased attention as they garner more market share, there is still a benefit in being part of a smaller population, and the Mac OS is based on Unix and BSD, which has approximately 30 years of attention to security. Windows has approximately 3 years, and that makes a big difference.

(Disclosure: I do not own a Mac myself, but I do sometimes use one. I hate the GUI, and the MacMini keyboards are trash.)

Black Helicoptor #1 - Is the data theft epidemic more than coincidental?

[Note - don't normally post speculative or black helicoptor stuff, but this one is at least tantalisingly plausible, and deserves to be debunked. Darren posts:]

According to Wayne Madsen http://www.waynemadsenreport.com/

"June 17, 2006 -- What's behind all the personal data thefts?

Populating the surveillance databases specified by John Poindexter's Total Information Awareness (TIA) system. WMR has learned that the thefts of personal data from corporations and government agencies, most of which were accomplished by stealing computer hard drive devices, is more than coincidental. Intelligence sources report that many of the large scale thefts are part of a well-planned covert intelligence operation to obtain data on hundreds of millions of people in order to accomplish what former Defense Advanced Research Projects Agency (DARPA) official John Poindexter was not able to bring about through his defunct (but secretly restored) Total Information Awareness (TIA) system -- the population of intelligence and surveillance databases with files on the financial, medical, employment, telecommunications, and other sensitive data of Americans and foreigners. Much of the new TIA work is being conducted under the umbrella of the National Security Agency and Department of Homeland Security Advanced Research Projects Agency.

A number of computer security experts have said the recent rash of data thefts is unprecedented in scope, method, and frequency. Some claim that the thefts appear to be coordinated and targeted at
specific data types."

Huge Table, followed by ...

"Amid all the above personal data thefts, WMR has learned from a U.S. intelligence source that these data thefts pale in comparison to the largest, and as yet, largely unreported, personal data theft in history. Some 30 million Americans were affected and they included customers of Citigroup, Bank of America, and SunTrust. The thefts were conducted between March and April of this year."

Firefox to check in with Google-central - Is Mozilla in unconstrained commercial rampage already?

It would be remiss of me not to pass on news that Mozilla have finally crafted a strategy for phishing protection in Firefox. It actually took me a few days to realise this is news, indeed, the news we had been working towards for when the fight against phishing was still browser-centric. But I'm no longer looking in that area as the threats have moved on - frequent readers of FC need no reminder of that - and Mozilla's actions may be welcome albeit late.

Unfortunately, Mozilla appear to be shooting themselves in the feet. At least, they have taken a direction that is mysterious to those of us in the open source world: They have partnered with Google to use their central database to monitor for phishing sites.

The more I think of it, the only way to understand it is if one considers Mozilla Corporation as a commercial entity, only. They have partnered with another big player, rather than work with the community of software developers. This is what companies do - there is a preference to work with players larger than themselves if possible as that improves their brand and strength, and which helps them for the next deal. As Google and Mozilla have a strong relationship, and much funding has come via their google search box placement and other deals, it makes sense to further the relationship rather than go with Netcraft or Microsoft or the other central database players. And if one considers the offerings of other parties in the central database wars, it may well be that Google's are the best, or the least bad, depending on how you view it.

This all makes good business sense. But it comes with dangers - serious if not blindingly obvious ones. Firstly, Google's reputation has shifted from being the honest white knight riding in to save us from the evil Microsoft with amazing googley solutions .. to one of being the sneaky invader of all our data. Although not yet seen as 'evil' as Microsoft, their original strong capital from the 'do no evil' motto is now frittered away and they are seen as somewhere like 'evil in evolution' or perhaps 'evil in training'. (I see this a lot in the arts community where there are many projects looking at a future world of Google as master of our data - Google's recent foray in court against USG helped some there, but not enough to sway the undercurrent of concern.)

Mozilla for their part had a fantastic image in the public's mind as being a volunteer, open source, public minded organisation. But this view has also suffered, perhaps inevitably due to growth and the runaway success of Firefox, but also due to decisions made. Now, Mozilla is quite happily planning to pass all the URLs across without even debating it with the users ... Mozilla's good reputation can only suffer from this arrogance.

Mozilla's support base still believes that it is an open source operation, and this is a second danger. Such deals are not acceptable in that world and over on Mitchell's blog, she tussles with that dilemma:

A number of the comments I received refer to the dangers of doing anything with money. They express the concern that any programs involving money run the risk of contaminating our community, or of turning it into a mercenary group interested only in money. I understand the risks. I also believe there are risks in ignoring money. Firefox generates revenue now, that's a fact. So we need to deal with money. (And we have the privilege of being able to employ people to work full time on Mozilla, which I believe is necessary for a project of our size and scope. Not all open source projects believe this however, and some are wary of employees or almost any activity that requires the distribution of funds.)

When volunteers work for free and take away slices of their own lives to devote to the cause of getting good, free software out there, they do not expect someone else to then take it and rape it for their own profit. Especially, in preferring a good financial deal over the user's needs for privacy, and ignoring the free offerings of their own community, these decisions will only serve to exacerbate the split between Mozilla Corp's newly discovered commerciality and the original long-term support-base of volunteers.

This calls for a quite serious change management exercise, and also has severe ramifications for the brand. It's pretty clear that Mozilla knows as much about branding as the average brand manager knows about software. E.g., so close to nothing it is worthless or dangerous, notwithstanding their accidental acquiring of the stunning Firefox brand. Or, perhaps that underscores the point - the brand was as much or more built by community efforts.

To their credit, Mozilla now seems to know this: MBA preferred. Thank heavens for that. Some tips, to be violently ignored like all the earlier free "community" advice, no doubt: MBAs know the basics of branding but they are not specialists, and Mozilla probably needs a specialist in this area now, as well as a PR specialist. Evidently... Further, MBAs are just as useful over on the tech side. Some recent writings by Mitchell may also indicate that the coding monoculture that is Mozilla's archilles heel is finally being addressed:

Another issue is that we don't have an established path to meritocracy for non-technical roles. For potential developers, we know about several paths for getting involved and developing legitimacy - we know about the Quality Assurance path, we know about fixing bugs, we know something about hacking on the code, we know about writing a great extension and so on. We also have clear ways of identifying a person's known expertise -- they may be a peer for code, a "module owner" for code, etc. All of these are reasonably well understood roles within the project that convey a person's expertise.

We don't have analogous paths for non-engineering roles. We don’t yet have ways for the non-engineering staff to indicate the scope of expertise of their colleagues.

Why is this Mozilla's archillies heel? It's been two years since people outside the above formal 'meritocracy' paths have been suggesting the path that was announced last week!

All that said, and drying our eyes over spilt milk, I'm not sure you need an MBA to tell you that handing over data is not a good strategy for the today's market. If you read the newspapers (any of them in America at least since February of 2005) you would have known that the hot issue for the public mind when it comes to IT and the net was and remains data safety - identity theft and the like.

So at a minimum, there must be some expectation that this has to have been discussed at great length within the company. So why no realisation that this could be a PR disaster?

ThreatWatch - the war on our own fears

Several articles on scary, ooo, so scary cyberwar scenarios. We will see a steady stream of this nonsense as the terrorist-watchers, china-watchers and every-other-bogeyman-watchers all combine in a war on our own fears.

A hyperventilating special from the US DHS:

According to cyber-security experts, the terror attacks of 11 September and 7 July could be seen as mere staging posts compared to the havoc and devastation that might be unleashed if terrorists turn their focus from the physical to the digital world.

Scott Borg, the director and chief economist of the US Cyber Consequences Unit (CCU), a Department of Homeland Security advisory group, believes that attacks on computer networks are poised to escalate to full-scale disasters that could bring down companies and kill people. He warns that intelligence "chatter" increasingly points to possible criminal or terrorist plans to destroy physical infrastructure, such as power grids. Al-Qa'ida, he stresses, is becoming capable of carrying out such attacks.

Summarised over on risks, the US DOD also partakes liberally of the oxygen tank:

From the nation that enjoys U.S. Most Favored Nation trade status, and a permanent member of the WTO...

China is stepping up its information warfare and computer network attack capabilities, according to a Department of Defense (DoD) report released last week. The Chinese People's Liberation Army (PLA) is developing information warfare reserve and militia units and has begun incorporating them into broader exercises and training. Also, China is developing the ability to launch preemptive attacks against enemy computer networks in a crisis, according to the document, ...

The tendency for public officials to try and scare the public into more funding is never-ending. The positive feedback loop is stunningly safe for them - if there is a cyber attack, they are proved right. If there isn't a cyber attack, it's just about to happen and they'll be proven right. And every one of our enemies is ... Huff, puff, huff!

Is D.C. ready for terrorist attack? Two unrelated traffic accidents within an hour of each other yesterday in Northeast shut down two major highways during the busy morning commute, causing massive gridlock and seemingly endless delays -- but also providing an ominous warning: What if it had been a terrorist attack?

About the best we can do is patiently point out that what they are talking about doesn't happen because in most cases it is evidently uneconomic. When the economic attack develops, we'll deal with it. Londoners walked home, that one day, and those that were a bit late that morning like me stayed home. The next day everyone went back to work, the same way as before. The next week, nobody noticed. It's not a particularly economic attack.

Some things you deal with by preparation. But other things you just have to let happen, because the attack goes around your preparations. By definition. Can anybody guess what would have happened if instead of a couple of traffic accidents, it was a couple of bombs? All of the greater Washington area would probably enter gridlock, because the authorities would hand it to the terrorists.

How much is all my email worth?

I have a research question. How much is all my email worth? As a risk / threat / management question.

Of course, that's a difficult thing to price. Normally we would price a thing by checking the market for the thing. So what market deals with such things?

We could look at the various black markets but they are more focussed on specific things not massive data. Sorry, bad guys, not your day.

Alternatively, let's look at the US data brokers market. There, lots and lots of data is shared without necessarily concentrating on tiny pickings like credit theft identifiers. (Some of it you might know about, and you may even be rewarded for some of it. Much is just plain stolen out of sight. But that's not today's question.) So how much would one of those data broker's pay for *full* access to my mailbox?

Let's assume I'm a standard boring rich country middle class worker bee.

Another way to look at this is to look at google. It makes most of the money in advertising, and it does this on the tiny hook of your search query. It is also experimenting with "catalogue your hard drive" products (as with Apple's spotlight and no doubt Microsoft and Yahoo are hyperventilating over this already). So it must have a view as to the value of *everything*.

So, what would it be worth to those companies to *sell* the entire monitoring contents of my email, etc, for a year to Yahoo, Google, Microsoft, or Apple? Imagine a market where instead of credit card offers to my dog clogging up mailbox, I get data sharing agreements from the big friendly net media conglomerates.