Financial Cryptography

More Pennies

Stefan posted a bunch of materials on a phone based ecash system.

On Identity theft, America's cartoonists are striking back. Click here and then send me your credit card number....

On the HCI thread of how users view web security, Chris points out that "Simson Garfinkel's dissertation is worth looking at in this context." This relates to the earlier two papers on what users think on web security.

Scott reports ``Visa International has published a white paper titled "Financial Flows and Supply Chain Efficiency" (sorry, in PDF) authored by Professor Warren H. Hausman of Stanford University.'' It's interesting if somewhat self-serving, and feeds into the whole message is the payment thread.

Stefan via Adam pointed me to a new blog on risks called Not Bad For a Cubicle. I shall pretend to know what that means, especially as the blogger in question claims knowledge of FC ... but meanwhile, the author takes task with persistent but poor usage of the word security, where 'risks' should be preferred. This makes a lot of sense. Maybe I should change all uses of the word over?

Because it's more secure becomes ... because it's less risky! Nice. But, wait! That would mean I'd have to change the name of my new paper over to Pareto-risk-free ... Hmm, let's think about this some more.

What users think about web security

A security model generally includes the human in the loop; totally automated security models are generally disruptable. As we move into our new era of persistent attacks on web browsers, research on human failure is very useful. Ping points to two papers done around 2001 on what web browsing security means to users.

Users Conceptions of Web Security explored how users treat the browser's security display. Unsurprisingly, non-technical users showed poor recognition of spoof pages, based on the presence of a false padlock/key icon. Perhaps more surprisingly, users derived a different view of security: they interpreted security as meaning it was safe to put their information in. Worse, they tended to derive this information as much from the padlock as from the presence of a form:

"That at least has the indication of a secure connection; I mean, it's obviously asking for a social security number and a password."

Which is clearly wrong. But consider the distance between what is correct - the web security model protects the information on the wire - and what it is that is relevant to the user. For the user, they want to keep their information safe from harm, any harm, and they will assume that any signal sent will be to that end.

But as the threat to information is almost entirely at the end node, and not on the wire, users are faced with an odd choice: interpret the signal according to the harms that they know about, which is wrong, or ignoring the signal because it is irrelevent to the harms. Which is unexpected.

It is therefore understandable that users misinterpret the signals they are given.

The second paper, User's Conceptions of Risks and Harms on the Web is also worth reading, but it was conducted in a period of relative peace. It would be very interesting to see the same study conducted again, now that we are in a state of perpetual attack.

Tegam uses courts to signal bad security

In the ongoing thread of Adam's question - how do we signal good security - it's important to also list signals of bad security. CoCo writes that Tegam, a French anti-virus maker, has secured a conviction against a security researcher for reverse engineering and publishing weaknesses.

This seems to be a signal that Tegam has bad security. If they had good security, then why would they care what a security researcher said? They could just show him to be wrong. Or fix it.

There are two other possibilities. Firstly, Tegam has bad security, and they know it. This is the most likely, and their aggressive focus on preserving the revenue base would perhaps lead them to prefer suppression of future researches into the product. CoCo points to a claim that Tegam accused the researcher of being a terrorist in a French advertisement, which indicates an attempt to disguise the suppression and validate it in the minds of their buying public. In French and google translates to quixotic english. Tegam responds that this article makes their case, but comments by flacks do no such thing. However the response makes for interesting reading and may balance their case.

Alternatively (secondly) they just don't know. And, I don't think we need to show the proof of "don't know" is equivalent to "insecure."

CoCo also comments on how the chilling effect will raise insecurity in general. But if enough companies decline to pursue avenues of prosecution, this might balance out in our favour: we might then end up with a new signal of those that prosecute and those that do not.

Texas Instruments recently signalled desire for good security in the RFID breach, as well as an understanding of the risks to the user. Tegam has signalled the reverse. Are they saying that their product has known weaknesses, and they wish to hide these from the users? You be the judge, and while you're at it, ponder on which side of this fence your own company sits?

NSA gets data mined - not the right crowd to steal a payment system from

I'm jacking into net in some random office in downtown Vienna, and I'm introduced to the payment-system-in-a-jar. Paper and tokens and IOUs thrown in a big vase serves to manage coordination on an office wide scale of coffee, beer and juice. For my talk on community currencies I thought this would make a great example of a payment system on a local basis, so I lifted the entire thing, and carried the 40cm high jar, money, tokens, and paper included to the presentation.

This payment system (as I presented) can be stolen. It can be broken. Nice good Internet ones don't have that problem. It was a nice example, it worked and my audience enjoyed the huge jar of purloined coffee money. But as I walked back to the office I wondered whether they'd mind me purloining their payment system.

I needn't have worried. There was a party in progress, the local technical community was in a happy mood. As I pulled the huge jar out of my laptop bag, luckily unbroken, there were smiles and laughter, and I had to explain what I wanted it for.

And then, as I was explaining, I detected a complete lack of interest... with austrian lingo and one word sneaking through repeatedly: NSA. After some confusion, I found out that I was at the post-success party of the group that had just data mined the NSA.

How this happened was gathered in scattered conversations slipped between explanations of payment systems and crypto cert systems. People had signed up for a semi-secret mailing list, and when the archives were put online, they'd been downloaded. Now they're up online in some fashion, and there is discussion on what to do next. The next phases were explained ... but in some sense this was subject to change, so I'll skip that part.

It looks like the NSA made a few mistakes in migration of internal forums to external availability. That's not a bad thing; but they left a lot of internal stuff in the archives. Also, it looks to me like the stories that are being discussed are really a bad use of secrecy - the sort of political manouvering that was discovered on the lists should not have been secret, but subject to public review. It is after all the money of the taxpayer that is being abused in this debate.

The one story I did hear was a bureaucratic fight among the FBI, NSA and the Brits over who gets to set the biometrics standard. According to the mail list, the FBI is based on fingerprints so they want that. The NSA loves voice recognition, so that's their baby. But the Brits are all hot on iris recognition and they have the world wide patent.

Good one guys - this is the sort of debate that really needs to be conducted in the open, not under secrecy. We follow with interest, and now, I must go use the local payment system again to mine some more beers.

Microsoft's negative rep leads to startling new security strategy

Triage is one thing, security is another. Last week's ground-shifting news was widely ignored in the press. Scanning a bunch of links, the closest I found to any acknowledgement of what Microsoft announced is this:

In announcing the plan, Gates acknowledged something that many outside the company had been arguing for some time--that the browser itself has become a security risk. "Browsing is definitely a point of vulnerability," Gates said.

Yet no discussion on what that actually meant. Still, to his sole credit, author Steven Musil admitted he didn't follow what Microsoft were up to. The rest of media speculated on compatibility, Firefox as a competitor and Microsoft's pay-me-don't-pay-me plans for anti-virus services, which I guess is easier to understand as there are competitors who can explain how they're not scared.

So what does this mean? Microsoft has zero, zip, nada credibility in security.

...earlier this week the chairman of the World's Most Important Software Company looked an auditorium full of IT security professionals in the eye and solemnly assured them that "security is the most important thing we're doing."

And this time he really means it.

That, of course, is the problem: IT pros have heard this from Bill Gates and Microsoft many times before ...

Whatever they say is not only discounted, it's even reversed in the minds of the press. Even when they get one right, it is assumed there must have been another reason! The above article goes on to say:

Indeed, it's no accident that Microsoft is mounting another security PR blitz now, for the company is trying to reverse the steady loss of IE's browser market share to Mozilla's Firefox 1.0.

Microsoft is now the proud owner of a negative reputation in security,

Which leads to the following strategy: actions not words. Every word said from now until the problem is solved will just generate wheel spinning for no productivity, at a minimum (and not withstanding Gartner's need to sell those same words on). The only way that Microsoft can change their reputation for insecurity is to actually change their product to be secure. And then be patient.

Microsoft should shut up and and do some security. Which isn't entirely impossible. If it is a browser v. browser question, it is not as if the competition has an insurmountable lead in security. Yes, Firefox has a reputation for security, but showing that objectively is difficult: their brand is indistinguishable from "hasn't got a large enough market share to be worth attacking as yet."

Some agree:

"This is a work in progress," Wilcox says. "The best thing for Microsoft to do is simply not talk about what it's going to do with the browser."

IEEE's Economics of Information Security

IEEE Security & Privacy magazine has a special on _Economics of Information Security_ this month. Best bet is to simple read the editor's intro.

There are two on economimcs of disclosure, a theme touched upon recently:

Plans for Scams

Gervase Markham has written "a plan for scams," a series of steps for different module owners to start defending. First up, the browser, and the list will be fairly agreeable to FCers: Make everything SSL, create a history of access by SSL, notify when on a new site! I like the addition of a heuristics bar (note that Thunderbird already does this).

Meanwhile, Mozilla Foundation has decided to pull IDNs - the international domain names that were victimised by the Shmoo exploit. How they reached this decision wasn't clear, as it was taken on insider's lists, and minutes aren't released (I was informed). But Gervase announced the decision on his blog and the security group, and the responses ran hot.

I don't care about IDNs - that's just me - but apparently some do. Axel points to Paul Hoffman, an author of IDN, who pointed out how he had IDN spoofing solutions with balance. Like him, I'm more interested in the process, and I'm also thinking of the big security risks to come and also the meta-risks. IDN is a storm in a teacup, as it is no real risk beyond what we already have (and no, the digits 0,1 in domains have not been turned off).

Referring this back to Frank Hecker's essay on the foundation of a disclosure policy does not help, because the disclosure was already done in this case. But at the end he talks about how disclosure arguments fell into three classes:

Literacy: “What are the words?”

Numeracy: “What are the numbers?”

Ecolacy: “And then what?”

"To that end [Frank suggests] to those studying the “economics of disclosure” that we also have to study the “politics of disclosure” and the “ecology of disclosure” as well."

Food for thought! On a final note, a new development has occurred in certs: a CA in Europe has issued certs with the critical bit set. What this means is that without the code (nominally) to deal with the cert, it is meant to be rejected. And Mozilla's crypto module follows the letter of the RFC in this.

IE and Opera do not it seems (see #17 in bugzilla), and I'd have to say, they have good arguments for rejecting the RFC and not the cert. Too long to go into tonight, but think of the crit ("critical bit") as an option on a future attack. Also, think of the game play that can go on. We shall see, and coincidentally, this leads straight back into phishing because it is asking the browser to ... display stuff about the cert to the user!

What stuff? In this case, the value of the liability in Euros. Now, you can't get more FC than that - it drags in about 6 layers of our stack, which leaves me with a real problem allocating a category to this post!

Disclosure - "no stupid embargos" says Linus

The Linux community just set up a new way to report security bugs. In the debate, it transpires that Linus Torvalds laid down a firm position of "no delay on fix disclosures." Having had a look at some security systems lately, I'm inclined to agree. It may be that delays make sense to let vendors catch up. That's the reason most quoted, and it makes entire logical sense. But, that's not what happens.

The process then gets hijacked for other agendas, and security gets obscured. Thinking about it, I'm now viewing the notion of security being discussed behind closed doors with some suspicion; it's just not clear how security by obscure committees divides their time between "ignoring the squeeky wheels" and "create space to fix the bugs." I've sent messages on important security issues to several closed security groups in the last 6 months, and universally they've been ignored.

So, zero days disclosure is my current benchmark. Don't like it? Use a closed product. Especially when considered that 90% of the actual implementations out there never get patched in any useful time anyway...

The Weakest Link

Full disclosure: for and against

How to address Internet security in an open source world is a simmering topic. Frank Hecker has documented his view of the Mozilla Full Disclosure debate that led to their current security policy. He makes the point that the parties are different: with open source there are many vendors, which complicates the notion of disclosure. Further, the bug fixers can be anyone, following the many eyeballs theory. This then devolves into the creation of a search for a policy where anyone can be an insider, Mozilla's current policy is that result; and we are very fortunate to have the story recorded.

Meanwhile, Adam points at an attempt by Microsoft to slow down open disclosure of exploits. In this case they are attacking the release of source code to exploit, Adam responds that this is perhaps more in the interests of defenders than attackers. My view: it looks less dramatic if treated as gameplay by Microsoft. The short term end goal is to get the patches out there, and Microsoft have succumbed to the easy blame opportunity to create a sense of urgency.

(Thread: Towards an Economic Analysis of Disclosure and papers listed there, additional costs, and consumer's adjusting risk profile.)

Top 18 Security Papers - add "the 3 laws of security"

Adam found a "top 18 security papers" list. My suggestion is to add Adi Shamir's recent Turing Award Lecture to the list. I recorded the important slides here, and at least once a week I find myself coping one or other of the components from it for posting somewhere on the net. And I'm writing an entire paper on just one line...

Adam reports the list is already up to 28, perhaps what the list keeper needs is some sort of market determined mechanism. Perhaps every security blog could trackback to their top 3 selections,and thus create a voting circle? (Hmmm, scanning the list, I see some ones that I wouldn't vote for, so how about some negative votes as well?)

To be fair, I'm not sure I've read any of them, which either augers badly for me or badly for the list :-) Which brings up another point. If someone is going to promote some paper or other, far*&%$ake put the URL of the HTML up there... If it ain't in HTML it can't reach an audience and it can't then be in any top 18. So there! That's it from me this week.

Unintended Consequences and the Case of the $100 Superbill

Axel points to a rather good article on Unintended Consequences with lots of good examples for the security thinker. If there is one cause that one had to put ones finger on, it is this: the attacker is smart, and can be expected to think about how to attack your system. Once you think like an attacker, you have a chance. If not, forget it.

Notwithstanding that minor ommission, here's the rather nice FC example, that of the mysterious $100 superbills.

Back in the 1970s, long before the revolution that would eventually topple him from power, the Shah of Iran was one of America's best friends (he was a dictator who brutally repressed his people, but he was anti-communist, and that made him OK in our book). Wanting to help out a good friend, the United States government agreed to sell Iran the very same intaglio presses used to print American currency so that the Shah could print his own high quality money for his country. Soon enough, the Shah was the proud owner of some of the best money printing machines in the world, and beautiful Iranian Rials proceeded to flow off the presses.

All things must come to an end, and the Shah was forced to flee Iran in 1979 when the Ayatollah Khomeini's rebellion brought theocratic rule to Iran. Everyone reading this undoubtedly knows the terrible events that followed: students took American embassy workers hostage for over a year as Iran declared America to be the "Great Satan," while evidence of US complicity in the Shah's oppression of his people became obvious, leading to a break in relations between the two countries that continues to worsen to this day.

During the early 90s, counterfeit $100 bills began to flood the Mideast, eventually spreading around the world. Known as "superbills" or "superdollars" by the US Treasury due to the astounding quality of the forgeries, these $100 bills became a tremendous headache not only for the US and its economy, but also for people all over the world that depend on the surety of American money. Several culprits have been suggested as responsible for the superbills, including North Korea and Syria, but many observers think the real culprit is the most obvious suspect: an Iranian government deeply hostile to the United States ... and even worse, an Iranian government possessing the very same printing presses used to create American money.

If you've ever wondered just why American currency was redesigned in the 1990s, now you know. In the 1970s, the US rewarded an ally with a special machine; in the 1990s, the US had to change its money because that ally was no longer an ally, and that special machine was now a weapon used to attack the US's money supply, where it really hurts. As an example of the law of unintended consequences, it's powerful, and it illustrates one of the main results of that law: that those unintended consequences can really bite back when you least expect them.

Read the rest... Unintended Consequences.

The Green Shoots of Opportunistic Cryptography

In a New Scientist article, mainstream popular press is starting to take notice that the big Wi-Fi standards have awful crypto. But there are some signs that the remedy is being pondered - I'll go out on a limb and predict that within a year, opportunistic cryptography will be all the rage. (links: 1, 2, 3,4 5)

(Quick explanation - opportunistic cryptography is where you generate what you need to talk to the other party on the fly, and don't accept any assumptions that it isn't good enough. That is, you take on a small risk of a theoretical attack up front, in order to reach cryptographic security quickly and cheaply. The alternate, no-risk cryptography, has failed as a model because its expense means people don't deploy it. Hence, it may be no-risk, but it also doesn't deliver security.)

Here's what has been seen in the article:

Security experts say that the solution lies in educating people about the risks involved in going wireless, and making the software to protect them easier to use. "Blaming the consumer is wrong. Computers are too complex for the average person to secure. It's the fault of the network, the operating system and the software vendors," says California-based cryptographer Bruce Schneier in the US. "Products need to be secure out of the box," he says.

Skipping the contradiction between "educating people" and "blaming the consumer", it is encouraging to see security people pushing for "secure out of the box." Keys should be generated opportunistically and on install, the SSH model (an SSH blog?). If more is wanted, then the expert can arrange that, but there is little point in asking an average user to go through that process. They won't.

Schneier is pessimistic. "When convenience and features are in opposition to security, security generally loses. As wireless networks become more common, security will get worse."

Schneier is unduly pessimistic. The mistake in the above logic is to consider the opposition between convenience and security as an invioble assumption. The devil is in those assumptions, and as Modadugu and Rescorla said recently:

"Considering the complexity of modern security protocols and the current state of proof techniques, it is rarely possible to completely prove the security of a protocol without making at least some unrealistic assumptions about the attack model."

(Apologies, but it's buried in a PDF. Post.) That's a green shoot, right there! Adi Shamir says that absolutely secure systems do not exist, so as soon as we get over that false assumption that we can arrange things perfectly, we can start to work out what benefits us most, in an imperfect world.

There's no reason why security and convenience can't walk hand in hand. In the 90s, security was miscast as needing to be perfect regardless of convenience. This simply resulted in lost sales and thus much less security. Better to think of security as what we can offer in alignment with convenience - how much security can we deliver for our convenience dollar? A lot, as it turns out.

Do security breaches drop the share value?

According to those that think WiKID thoughts, yes. Quoting a paper by Campbell et al, there can be measured a 5% drop in stock price when confidentiality is breached. Adam demurs, thinking the market is unconcerned about the breaches of confidentiality, rather, is concerned about a) loss of customers or b) lawsuits.

I demur over both! I don't think the market cares about any of those things.

In this case, I think the market is responding to the unknown. In other words, fear. It has long been observed that once a cost is understood, it becomes factored in, and I guess that's what is happening with DDOS and defacements/viruses/worms. But large scale breaches of confidentiality are a new thing. Previously buried, they are now surfaced, and are new and scary to the market.

And the California law makes them even scarier, forcing the companies into the unknown of future litigation. But, I think once these attacks have run their course in the public mind, they will stop causing any market reaction. That isn't to say that the attacks stop, or the breaches in confidentiality stop, but the market will be so used to them that they will be ignored.

Otherwise I have a problem with a 5% drop in value. How is it that confidentiality is worth 5% of a company? If that were the case, companies like DigiCash and Zero-Knowledge would have scored big time, but we know they didn't. Confidentiality just isn't worth that much, ITMO (in the market's opinion).

The full details:

"The economic cost of publicly announced information security breaches: empirical evidence from the stock market," Katherine Campbell, Lawrence A. Gordon, Martin P. Loeb and Lei Zhou Accounting and Information Assurance, Robert H. Smith School of Business, University of Maryland, 2003.

Abstract This study examines the economic effect of information security breaches reported in newspapers or publicly traded US corporations. We find limited evidence of an overall negative stock market reaction to public announcements of information security breaches. However, further investigation reveals that the nature of the breach affects this result. We find a highly significant negative market reaction for information security breaches involving unauthorized access to confidential data, but no significant reaction when the breach does not involve confidential information. Thus, stock market participants appear to discriminate across types of breaches when assessing their economic impact on affected firms. These findings are consistent with the argument that the economic consequences of information security breaches vary according to the nature of the underlying assets affected by the breach.

Also over on Ross Anderson's Econ & Security page there are these:

Two papers, "Economic Consequences of Sharing Security Information" (by Esther Gal-Or and and Anindya Ghose) and "An Economics Perspective on the Sharing of Information Related to Security Breaches" (by Larry Gordon), analyse the incentives that firms have to share information on security breaches within the context of the ISACs set up recently by the US government. Theoretical tools developed to model trade associations and research joint ventures can be applied to work out optimal membership fees and other incentives. There are interesting results on the type of firms that benefit, and questions as to whether the associations act as social planners or joint profit maximisers.

Which leads to "How Much Security is Enough to Stop a Thief?," Stuart Schechter and Michael Smith, FC03 .

Thunderbird Gains Phishing Dectection (Too)

Through a long chain of blogs (evidence that users care about phishing at least: gemal.dk MozIne, LWN, Addict) comes news that Thunderbird is also to have click-thru protection. The hero of the day is one Scott MacGregor. Easiest just to read his bug report and gfx:

Get a phishing detector going for Thunderbird. I'm sure it can be improved quite a bit but this starts to catch some of the more obvious scams.

When the user clicks on a URL that we think is a phishing URL, he now gets prompted before we open it. Handles two cases so far. Hopefully we can add more as we figure out how. The host name of the actual URL is an IP address. The link text is a URL whose host name does not match the host name of the actual URL.. I added support for a silentMode so later on we can hopefully walk an existing message DOM and call into this routine on each link element in the DOM. This would allow us to insert an email scam warning bar in the message window down the road.

That's good stuff! It is similar to the fix that JPM reported a couple of days ago. Momentum is building to fix the tools, so it we might soon start to see work in browsers - that which is being attacked - to address phishing. So far, Firefox has made a small start with a yellow SSL bar and SSL domain name on the bottom right . More will follow, especially as the fixes outside the browser force phishers towards more "correct" URLs and SSL attacks.

The Big Lie - does it apply to 2005's security problems?

I've been focussed on a big project that finally came together last night, so am now able to relax a little and post. Adam picked up on this comment on haplass Salman Rushdie still suffering from his maybe-fatwa. Which led to a link on the Big Lie and this definition:

"All this was inspired by the principle - which is quite true in itself - that in the big lie there is always a certain force of credibility; because the broad masses of a nation are always more easily corrupted in the deeper strata of their emotional nature than consciously or voluntarily; and thus in the primitive simplicity of their minds they more readily fall victims to the big lie than the small lie, since they themselves often tell small lies in little matters but would be ashamed to resort to large-scale falsehoods. It would never come into their heads to fabricate colossal untruths, and they would not believe that others could have the impudence to distort the truth so infamously."

Today's pop quiz is: Who wrote that?

I'll let in one little hint, he was one of the great orators of the 20th century. If you the impatient sort that can't handle a little suspense, you can click on the WikiPedia link to see, but let's analyse his theory first.

To his big lie. The concept is breathtaking in its arrogance, but it's also difficult to deny. I'm sure you can think of a few in politics, right now, but this is an FC forum, so let's think like that. I can think of two cases where the big lie has occurred.

The first was in the security of a payment system I worked with back in the 90s. It was totally secure, as everyone agreed. Yet it wasn't, and watching that unravel led to fascinating observations as the organisation had to face up to its deepest secrets being revealed to the world. (In this case, some bright upstart from California had patented the secrets, which should give you enough of a clue...).

The second big lie was the secure browsing system. SSL in browsers, in other words. It was supposed to be secure, but the security started unravelling a few years back as phishing started to get going. Before that, I'd been poking at it and unwinding some of the assumptions in order to show it wasn't secure. It was a hobby, back then, as what we do in the security world is hone our skills by taking apart someone else's system.

To little avail. And I now wonder if what I was facing was the big lie? A community of Internet security people had created the belief that it was secure. And this enabled them to ignore any particular challenge to that security. Hence if, by way of example, we pointed out that, say, a breach on any certificate authority would cause all CAs to be breached, this was easily fobbed off onto some area of the intricate web (e.g., CAs are audited, therefore...).

Now, that area could also easily be shown to be weak as well, but by that time people had lost interest in our arguments. They had done their job, perhaps, or they simply relied on other people to assure them that those other areas were safe. My own view is that when one steps outside the discipline, all subtlety disappears and the truth becomes, well, gospel. (Auditing makes companies safe, right? That's what Sarbanes-Oxley and Basel II and all that is about!)

Our orator from the past goes on to say:

"Even though the facts which prove this to be so may be brought clearly to their minds, they will still doubt and waver and will continue to think that there may be some other explanation. For the grossly impudent lie always leaves traces behind it, even after it has been nailed down, a fact which is known to all expert liars in this world and to all who conspire together in the art of lying."

Now, he conveniently pins the blame on a conspiracy of expert liars, which we'll leave for the moment. But notice how even as the lie "leaves traces behind it" the power of the mind turns to seaching for the explanation that keeps it "true." And so it is with phishing and web browser's security against a spoofed site. Even as phishing reaches and enjoys institutional scope, the basic facts of the matter - it's an attack on the secure browser - are ignored.

There must be some other explanation! If we were to say that the browser should identify the site, and it doesn't, then that would mean that secure browsing isn't secure, and that can't be right, can it? There must be some other explanation... and all of the associations and cartels and standards organisations and committees are rushing around in ever enlarging circles proposing server software, secure hardware tokens, user education, and bigger fines.

The big lie is an extraordinarily powerful thing. In closing, I'll post the last part of that extract, which might alert you to the author. Call it clue #2. But keep an open mind as to what he is saying, because I'll challenge you on it!

"These people know only too well how to use falsehood for the basest purposes. From time immemorial, however, the Jews have known better than any others how falsehood and calumny can be exploited. Is not their very existence founded on one great lie, namely, that they are a religious community, where as in reality they are a race? And what a race! One of the greatest thinkers that mankind has produced has branded the Jews for all time with a statement which is profoundly and exactly true. Schopenhauer called the Jew 'The Great Master of Lies.' Those who do not realize the truth of that statement, or do not wish to believe it, will never be able to lend a hand in helping Truth to prevail."

Now, we all know that isn't true. Or do we? Just exactly how did our orator create such a fascinating big lie, and how many people do you know that can unravel the above and work out what he did?

Here's what I think he did. Firstly, he described the big lie. Then, he attributed the big lie to his targeted victims. In that way, he hid the fact that he himself was creating another big lie set squarely against the first one.

So our hapless citizen has to not only unravel one big lie, but two big lies. Not only that, but the first big lie has probably been around for yonks, and just has to be true, right?

Offering a defence to Adolf Hitler's inspiration is tough. (Yes, it was he, writing in Mein Kampf, if you haven't already guessed it. WikiPedia.) Two big lies do not a big truth make? Nice, pithy, and will not be understood by our 99% target population. It takes a big lie to defeat a big lie?

A puzzler to be sure. For now, I'll leave you with the big thought that it's time for a big coffee.

T-mobile cracker also hacks Proportionality with Embarrassment

All the blogs (1, 2, 3) are buzzing about the T-Mobile cracker. 21 year old Nicolas Jacobsen hacked into the phone company's database and lifted identity information for some 400 customers, and also scarfed up a photos taken by various phone users. He sold these and presumably made some money. He was at it for at least 6 months, and was picked up in an international sweep that netted 28 people.

No doubt the celebrity photos were embarrassing, but what was cuter was that he also lifted documents from the Secret Service and attempted to sell them on IRC chat rooms!

One would suppose that he would find himself in hot water. Consider the young guy who tried to steal a few credit cards from a hardware store by parking outside and using his laptop to wirelessly hack in and install a trojan. He didn't succeed in stealing anything, as they caught him beforehand. Even then, the maximum he was looking at was 6 credit card numbers. Clearly, a kid mucking around and hoping to strike lucky, this was no real criminal.

He got 12 years. That's 2 years for every credit card he failed to steal.

If proportionality means anything, Jacobsen is never ever going to see sunlight again. So where are we now? Well, the case is being kept secret, and the Secret Service claim they can't talk about it. This is a complete break with tradition, as normally the prosecution will organise a press circus in order to boost their ratings. It's also somewhat at odds with the press release they put out on the other 19 guys they picked up.

The answer is probably that which "a source" offers: "the Secret Service, the source says, has offered to put the hacker to work, pleading him out to a single felony, then enlisting him to catch other computer criminals in the same manner in which he himself was caught. The source says that Jacobsen, facing the prospect of prison time, is favorably considering the offer."

Which is fine, except the hardware shop hacker also helped the hardware store to fix up their network and still got 12 years. The way I read this message is that proportionality - the punishment matching the crime - is out the window, and if you are going to hack, make sure you hack the people who will come after you to the point of ridicule.

Security by Obscurity blooper - Cameras caught on Google

Those of you who shudder over my aggressive adoration of "security by obscurity" will cheer the article in the Register that reveals the latest on-camera bloopers.

It seems that thousands of webcams (little cameras for PCs) install and open up webservers by default. Now, this is a fine thing to do if you can keep your webserver "hidden" from view. (That's what we mean by security by obscurity!) But recall that google and/or others have been shipping spyware tools that capture secret URLs from chat sessions and email sessions, and then forward them to search engines! Well, it was only a matter of time before someone figured out a way to search google for all those secret cameras ...

Suddenly, the age old trick of using a secret webserver or URL to distribute a private document no longer works. Whoops. Security by obscurity just flipped that trick on its head.

But, let's not throw out the baby with the bathwater. Anyone using that trick should have known that they were taking a risk. Now we know the risk is dramatically enhanced by spyware snaffling secret URLs. So, stop doing it. But, while it lasted, it was a good trick, and it saved lots of people lots of costs.

Oh, for the victims - those companies shipping the webserver camera setups that are unsecure by default - well, you deserve to be embarrassed. And the people spyed upon by the bloggers ... consider the greater good of teaching us how to secure our world as your compensation. And let's hope you weren't doing anything too embarrassing.

Accountants list the tech problems, Security and Sarbanes-Oxley take pole positions

A tech survey by accountants gives some interesting tips on security. The reason it is credible is because the authors aren't from our industry, so they can be expected to approach this without the normal baggage of some security product to sell. Of course their own is for sale, but that's easy to factor out in this case.

Security is still the Number One concern that accountants are seeing out there. That makes sense. It accords with everything we've seen about the phishing and identity theft explosions over the last couple of years.

Second is electronic document management. Why now? This issue has been around for yonks, and businesses have been basically doing the paperless office as and when they could. My guess is that things like Sarbanes-Oxley, Basel II and various lesser well named regulatory attacks on governance have pushed this to the fore. Now, if you haven't got your documents under control (whatever that means) you have a big risk on your hands.

Third is Data Integration. This echoes what I've seen in finance circles of late; they have gone through a phase of automating everything with every system under the sun. Now, they're faced with tieing them all together. The companies selling product at the moment are those with tools to ease the tying of things together. But so far, the companies are not exactly enticed, with many companies dreading yet another cycle based on the current web services hype.

Spam has slipped to Fourth in the rankings of the "biggest concerns". The article tries to hint at this as a general easing of the problem, but I'd suggest caution: there are far too many ways in which this can be misinterpreted. For example, the huge increase in security concerns over the last year have probably and simply overshadowed spam to the extent that spam may well have doubled and we'd not have cared. Identity Theft is now on the agenda, and that puts the spam into context. One's a nuisance and the other's a theft. Internet security experts may be bemused, but users and accountants can tell the difference.

For the rest, read on...

Information Security Once Again Tops AICPA Tech List

Jan. 3, 2005 (SmartPros) For the third consecutive year, information
security is the country's number one technology concern, according to the
results of the 2005 Top Technologies survey of the American Institute of
Certified Public Accountants.

The survey, conducted annually since 1990, seeks to determine the 10 most
important technology issues for the coming year. There were more than 300
participants in the 2005 survey, a 30 percent increase over the previous
year.

Interestingly, spam technology -- an issue closely associated with
information security -- apparently has lost some currency. It made its debut
on the 2004 list at number two. On the new list, it falls to number four.

"Because our work and personal lives are now inextricably linked to
information systems, security will always be top of mind," said Roman
Kepczyk, CPA/CITP, Chair of the AICPA's Information Technology Executive
Committee. Commenting on spam technology's lower placement on the list, he
said, "We've seen major improvements to filtering systems, which have
allowed us to bring spam under greater control. This most likely is the
reason that spam technology doesn't command the importance it did in the
previous survey."

A different issue closely allied with information security -- electronic
data management, or the paperless office -- moved up to second place. It was
number three last year.

There are two debuts on the Top Technologies list: authentication
technologies and storage technologies. Another issue, learning and training
competency, reappears at number 10 after an absence of three years.

The following are the 2005 Top 10 Technologies:

1.. Information Security: The hardware, software, processes and procedures
in place to protect an organization's information systems from internal and
external threats.

2.. Electronic Document Management (paperless or less-paper office): The
process of capturing, indexing, storing, retrieving, searching and managing
documents electronically. Formats include PDF, digital and image store
database technologies.

3.. Data Integration: The ability to update one field and have it
automatically synchronize between multiple databases, such as the
automatic/seamless transfer of client information between all systems. In
this instance, only the data flows across systems from platform to platform
or application to application. Data integration also involves the
application-neutral exchange of information. For example, the increased use
of XBRL (eXtensible Business Reporting Language) by companies worldwide
provides for the seamless exchange and aggregation of financial data to meet
the needs of different user groups using different applications to read,
present and analyze data.

4.. Spam Technology: The use of technology to reduce or eliminate unwanted
e-mail commonly known as Spam.

5.. Disaster Recovery: The development, monitoring and updating of the
process by which organizations plan for continuity of their business in the
event of a loss of business information resources through theft,
virus/malware infestation, weather damage, accidents or other malicious
destruction. Disaster recovery includes business continuation, contingency
planning and disk recovery technologies and processes.

6.. Collaboration and Messaging Applications: Applications that allow
users to communicate electronically, including e-mail, voicemail, universal
messaging, instant messaging, e-mailed voice messages and digital faxing.
Examples include a computer conference using the keyboard (a keyboard chat)
over the Internet between two or more people.

7.. Wireless Technologies: The transfer of voice or data from one machine
to another via the airwaves and without physical connectivity. Examples
include cellular, satellite, infrared, Bluetooth, WiFi, 3G, 2-way paging,
CDMA, Wireless/WiMax and others.

8.. Authentication Technologies (new): The hardware, software, processes
and procedures to protect a person's privacy and identity from internal and
external threats, including digital identity, privacy and biometric
authentication.

9.. Storage Technologies (new): Storage area networks (SAN) include mass
storage, CD-recordable, DVD, data compression, near field recording,
electronic document storage and network attached storage (NAS), as well as
small personal storage devices like USB drives.

10.. Learning and Training Competency (End Users): The methodology and
curriculum by which personnel learn to understand and use technology. This
includes measuring competency, learning plans to increase the knowledge of
individuals, and hiring and retaining qualified personnel with career
opportunities that retain the stars.

Also, each year the AICPA Top Technologies Task Force prepares a "watch
list" of five emerging technologies [...]

http://accounting.smartpros.com/x46436.xml

Frank Abagnale at CSI - Know me if you can

Axel's blog points to a storm in a teacup over at a professional association called the Computer Security Institute. It seems that they invited Frank Abagnale to keynote at their conference. Abagnale, if you recall, is the infamous fraudster portrayed in the movie Catch me if you can.

Many of the other speakers kicked up a fuss. It seems they had ethical qualms about speaking at a conference where the 'enemy' was also presenting. Much debate ensued, alleges Alex, about forgiveness, holier than thou attitudes and cashing in on notoriety.

I have a different perspective, based on Carl von Clausewitz's famous aphorism. He said something to the extent of "Know yourself and you will win half your battles. Know your enemy and you will win 99 battles out of a hundred." Those speakers who complained or withdrew have cast themselves as limited to the first group, the self-knowers, and revealed themselves as reliable only to win every second battle.

Still, even practitioners of narrow horizons should not be above learning from those who see further. So why is there such a paranoia of only dealing with the honest side in the security industry? This is the never-ending white-hat versus black-hat debate. I think the answer can be found in guildthink.

People who are truly great at what they do can afford to be magnaminous about the achievements of others, even those they fight. But most are not like that, they are continually trapped in a sort of middle level process-oriented tier, implementing that which the truly great have invented. As such, they are always on the defensive for attacks on their capabilities, because they are unable to deal at the level where they can cope with change and revolution.

This leads the professional tiers to always be on the lookout for ways to create "us" and "them." Creating a professional association is one way, or a guild, to use the historical term.

Someone like Frank Abagnale - a truly gifted fraudster - has the ability to make them look like fools. Thus, he scares them. The natural response to this is to search out rational and defensible ways to keep him and his ilk on the outside, in order to protect the delicate balance of trade. For that reason, it is convenient to pretend to be morally and ethically opposed to dealing with those that are convicted. What they are really saying is that his ability to show up the members for what they are - middle ranking professionals - is against their economic interests.

In essence, all professionals do this, and it should come as no surprise. All associations of professionals spend a lot of their time enhancing the credibility of their members and the dangers of doing business with those outside the association. So much so that you won't find any association - medical, accounting, engineering, or security - that will admit that this is all normal competitive behaviour. (A quick check of the CSI site confirms that they sell training, and they had a cyberterrorism panel. Say no more...)

So more kudos to the CSI for breaking out of the mold of us and them! It seems that common sense won over and Frank attended. He can be seen here in a photo op, confirming his ability to charm the ladies, and giving "us" yet another excuse to exclude him from our limited opportunities with "them" !

Security Signalling - the market for Lemmings

Adam continues to grind away at his problem: how to signal good security. It's a good question, as we know that the market for security is highly inefficient, some would say dysfunctional. E.g., we perceive that many security products are good but ignored, and others are bad but extraordinarily popular, and despite repeated evidence of breaches, en masse, users flock to it with lemming-like behaviour.

I think a real part of this is that the underlying question of just what security really is remains unstudied. So, what is security? Or, in more formal economics terms, what is the product that is sold in the market for security?

This is not such an easy question from an economist's point of view. It's a bit like the market for lemons, which was thought to be just anomalous and weird until some bright economist sat down and studied it. AFAIK, nobody's studied the market for security, although I admit to only having asked one economist, and his answer was "there's no definition for *that* product that I know of!"

Let's give it a go. Here's the basic issue: security as a product lacks good testability. That is, when you purchase your standard security product, there is no easy way to show that it achieves its core goal, which is to secure you against the threat.

Well, actually, that's not quite correct; there are obviously two sorts of security products, those that are testable and those that are not. Consider a gate that is meant to guard against dogs. You can install this in a fence, then watch the rabid canines try and beat against the gate. With a certain amount of confidence you can determine that the gate is secure against dogs.

But, now consider a burglar alarm. You can also install it with about the same degree of effort. You can conduct the basic workability tests, same as a gate. One opens and goes click on closing; the other sets and resets, with beeping.

But there the comparison gets into trouble, as once you've shown the burglar alarm to work, you still have no real way of determining that it achieves its goal. How do you know it stops burglars?

The threat that is being addressed cannot be easily simulated. Yes, you can pretend to be a burglar, but non-burglars are pretty poor at that. Whereas one doesn't need to be a dog to pretend to be a dog, and do so well enough to test a gate.

What then is one supposed to do? Hire a burglar? Well, let's try that: put an ad in the paper, or more digitally, hang around IRC and learn some NuWordz. And your test burglar gets in and ... does what? If he's a real burglar, he might tell you or he might just take the stuff. Or, both, it's not unreasonable to imagine a real burglar telling you *and* coming back a month later...

Or he fails to get in. What does that tell you? Only that *that* burglar can't get in! Or that he's lying.

Let's summarise. We have these characteristics in the market for security:

• a test of the product by a simulated threat is:
  • expensive, and
  • the results cannot be relied upon to predict defence against a real threat;
• a test of the product by a real threat is:
  • difficult to arrange,
  • could be destructive, and
  • the results cannot be relied upon to predict defence against any _other_ real threat.

Perhaps some examples might help. Consider a security product such as Microsoft Windows Operating System. Clearly they write it as well as they can, and then test it as much as they can afford. Yet, it always ships with bugs in it, and in time those bugs are exploited. So their testing - their simulated threats - is unsatisfactory. And their ability to arrange testing by real threats is limited by the inefficient market for blackhats (another topic in itself, but one beyond today's scope).

Closer to (my) home, let's look at crypto protocols as a security product. We can see that it is fairly close as well: The simulated threat is the review by analysts, the open source cryptologists and cryptoplumbers that pore through the code and specs looking for weaknesses. Yet, it's expensive to purchase review of crypto, which is why so many people go open source and hope that someone finds it interesting enough. And, even when you can attract someone to review your code, it is never ever a complete review. It's just what they had time for; no amount of money buys a complete review of everything that is possible.

And, if we were to have any luck in finding a real attacker, then it would only be by deploying the protocol in vast numbers of implementations or in a few implementations of such value that it would be worth his time to try and attack it. So, after crossing that barrier, we are probably rather ill-suited to watching for his arrival as a threat, simply due to the time and effort already undertaken to get that far. (E.g., the protocol designers are long since transferred to other duties.) And almost by default, the energy spent in cracking our protocol is an investment that can only be recouped by aggressive acquisition of assets on the breach.

(Protocol design has always been known to have highly asymmetric characteristics in security. It is for this reason that the last few years have shown a big interest in provability of security statements. But this is a relatively young art; if it is anything like the provability of coding that I did at University it can be summarised as "showing great potential" for many decades to come.)

Having established these characteristics, a whole bunch of questions are raised. What then can we predict about the market for Lemmings? (Or is it the market for Pied Pipers?) If we cannot determine its efficacy as a product, why is it that we continue to buy? What is it that we can do to make this market respond more ... responsibly? And finally, we might actually get a chance to address Adam's original question, to whit, how do we go about signalling security, anyway?

Lucky we have a year ahead of us to muse on these issues.

Netcraft breaks ranks and points the crooked black claw of doom at the SSL security model

In a show of remarkable adeptness, Netcraft have released an anti-phishing plugin for IE. Firefox is coming, so they say. This was exciting enough to make it on Slashdot, as David at Mozilla pointed out to me.

There are now dozens of plugins floating around designed to address phishing. (If that doesn't say this is a browser issue, I don't know what will. Yes, the phish are growing wings and trialling cell phones, pagers and any other thing they can get at, but the main casting action is still a browser game.) The trustbar one is my favourite, although it doesn't work on my Firefox.

So, what about Netcraft? Well, it's quite inspired. Netcraft have this big database of all the webservers in existance, and quite a few that are not. The plugin simply pops on over to the Netcraft database and asks for the vital stats on that website.

Well, hey ho! Why didn't we think of that?

There's a very good reason why not. Several in fact. Firstly, this puts Netcraft into your browser in an important position; if they succeed at this, then they have entre into the user's hearts and minds. That means some sort of advertising revenue model, etc etc, as clearly permitted in their licence. Or worse, like their own little spyware programs which may or may not be permitted under their Privacy clause.

(So one reason we didn't think of that is because we all hate advertising models ... just so we're clear on that point!)

But more interesting is that Netcraft is a player in the security industry. At least, they are a collector of CA and SSL statistics, and their reports sell for mighty big bucks. So one might expect them to pay attention to those suggestions that supported the SSL industry, like the ones that I frequently ... propose.

But, no. What they have done is completely bypassed the SSL security model and crafted a new one based on a database of known information. If one has followed the CA security debate, it bears a stunning similarity to the notions of what we'd do if we were attempting to fix the model. It's the endgame: to fix the revocation problem you add online checking which means you don't need the CAs any more.

Boom. If Netcraft succeeds in this approach (and there is no reason why others can't copy it!) then we don't need CAs any more. Well, that's not quite true, what this implies is that Netcraft just became a CA. But, they are a CA according to their rules, not those historical artifacts popularised by accounting entities such as WebTrust.

So it's another way to become a CA: give away the service for free, acquire the user base, and figure out how to charge for it later. A classic dotcom boom strategy, right? Bypass the browser policy completely because it is struggling under the weight of the WebTrust legacy, and the security wood can't be seen for the policy trees.

(Now, some will be scratching their heads about the apparent lack of a cert in the plugin. Don't worry, that's an implementation detail. They can add that later, for now they offer a free certificate service with no cert. Think of the upgrade potential here. The important thing is to see if this works as a *business* model first.)

So this takes aim at the very group that they sell reports to. Of course, the people who want to buy reports on certificate use are the CAs, and their various suppliers of CA toolkits.

That's why it's a significant event. (And another reason why we didn't think of it!)

Netcraft have obviously worked out several things: the CAs are powerless to do anything about phishing, and that's a much bigger revenue stream than a few boring reports. Further, the security model is stagnant at best and a crock at worst, so why not try something new? And, the browser manufacturers aren't playing their part, with narry a one admitting that the problem is in their patch. So their users are also vulnerable to a takeover by someone with some marketing and security sense.

Well done Netcraft, is all I can say! Which is to say that I have no idea whether the plugin itself will work as advertised. But the concept, now, that's grand!

Simple Tips on Computer Security

Recently, it's become fashionable to write an article on how to protect yourself from all the malware, phishing, spyware, viruses, spam, espionage and bad disk drives out there. Here's some: [IBM], [Schneier], [GetLuky].

Unfortunately, most of them go over the heads of ordinary users, and many of them challenge even experienced users! So I've been keeping my eye out for succinct tips, the sort for car owners who don't know what an oil change is. I have two which I've posted here before, being Buy a Mac and download FireFox. Both good things, but I feel the lack of any good tip for phishing; there just isn't a good way to deal with that yet.

There they are, sitting in a box in the right of the blog.

1. Buy a Mac - Uses BSD as its secure operating system...
2. Download FireFox - Re-engineered for security...
3. Check name of site - written on bottom right of FireFox, next to padlock...
4. Write Passwords Down - In a safe place...

People do ask me from time to time what to do. I feel mightily embarrassed because I have no Windows machine, but I also find myself empathising with ordinary users who ask what it means to upgrade the software! So my tips are designed for people who know not what SP2 means.

Let me know your suggestions, but be warned: they'd better be very very simple. Coz that's all that counts for the user.

User education: worse than useless

Cypherpunk askes a) why has phishing gone beyond "don't click that link" and b) why we can't educate the users?

A lot of what I wrote in The Year of the Snail is apropos to that first question. In economic terms, we would say that Phishing is now institutionalised. In more general parlance, and in criminal terms, it would be better expressed as organised crime. Phishing is now a factory approach, if you like, with lots of different phases, and different actors all working together. Which is to say that it is now very serious, it's not a simple net bug like viruses or spam, and that generally means telling people to avoid it will be inadequate.

We can look at the second question much more scientifically. The notion of teaching people not to click has been tried for so long now that we have a lot of experience just how effective the approach of 'user education' is. For example, see the research by Ye and Smith and also Herzberg and Gbara, who tested users in user interface security questions. Bottom line: education is worse than useless.

Users defy every effort to be educated. They use common sense and their own eyes: and they click a link that has been sent to them. If they didn't do that, then we wouldn't have all these darn viruses and all this phishing! But viruses spread, and users get phished, so we know that they don't follow any instructions that we might give them.

So why does this silly notion of user education persist? Why is every security expert out there recommending that 'users be educated' with not the least blush of embarrassment at the inadequacy of their words?

I think it's a case of complexity, feedback and some fairly normal cognitive dissonance. It tends to work like this: a security expert obviously receives his training from some place, which we'll call received wisdom. Let's call him Trent, because he is trusted. He then goes out and employs this wisdom on users. Our user, Alice, hears the words of "don't click that link" and because of the presence of Trent, our trusted teacher, she decides to follow this advice.

Then, Alice goes out into the world and ... well, does productive work, something us Internet geeks know very little about. In her office every day she dutifully does not click, until she notices two thing. Firstly, everyone else is clicking away like mad, and indeed sending lots of Word documents and photos of kids and those corny jokes that swill around the office environment.

And, secondly, she notices that nobody else seems to suffer. So she starts clicking and enjoying the life that Microsoft taught her: this stuff is good, click here to see my special message. It all becomes a blur and some time later she has totally forgotten *why* she shouldn't click, and cannot work out what the problem is anyway.

(Then of course a virus sweeps the whole office into the seas ...)

So what's going on here? Well, several factors.

1. Trent successfully educated Alice. So he runs around with the notion that user education is a fine tool and it works A-OK! Yes, he believes that we can achieve results this way. He promotes user education as the answer to our security needs.
2. Alice more or less left her education session successfully educated. But it doesn't last, because everyone else doesn't do it, and she can't see the sense in it anyway. That is to say, in systems theory, Alice cannot close the loop. She cannot see the action she is asked for as causing any additional security. As there is no reinforcing feedback, after a while it breaks, and never gets renewed.
3. Trent only managed to impress a small group of users. The vast majority of users out there however are 'the masses'. Many people don't actually know any computer experts, and they go into a retail store like Walmart to buy their computer. They have enough trouble coping with the fact that the parts need to be connected together in order to work ... and esoteric notions of clicks and security and viruses just go right over their heads.
4. When a virus or other plague like phishing does sweep through and wash the users into the sea, it's very unclear who to blame. Was it the bank? Was it Microsoft? Was it Sally-Anne who clicked on too many links? Or the Simon the systems administrator who installed a new Virus filter? Or, maybe it was Hamisch the terrible eastern European hacker again? Or ... , or ..... Just exactly why it happens is totally difficult to determine, and *that* means that the distance between the crime and any adequate defences is so great that there is no real feedback to reinforce the defences. Why defend when it is not doing anything?
5. If only a small subset of users are 'educated' this achieves nothing other than the minor effect of them potentially being protected. That's because if a virus sweeps through, we all suffer, even if we have protected ourselves. Yet, to stop the virus, we *all* have to follow the discipline. So we have a sort of free-rider problem: we have no way to make sure that all the users are 'educated' and thus there is no real incentive for anyone to educate.
6. Getting back to Trent, of course, he is secure. Everyone reading this blog is secure. Unless they are real users, in which case they didn't understand a word of it and didn't get this far (sorry about that!). So for Trent and our sort of person, we don't see the problem because it doesn't directly effect us. We are shut off from the real world of users.

Hence, cognitive dissonance. In this case, the security industry has an unfounded view that education is a critical component of a security system. Out in the real world, though, that doesn't happen. Not only doesn't the education happen, but when it does happen, it isn't effective.

Perhaps a better way to look at this is to use Microsoft as a barometer. What they do is generally what the user asks for. The user wants to click on mail coming in, so that's what Microsoft gives them, regardless of the wider consequences.

And, the user does not want to be educated, so eventually, Microsoft took away that awful bloody paperclip. Which leaves us with the lesson of inbuilt, intiutive, as-delivered security. If you want a system to be secure, you have to build it so that it is so intiutively to the user. Each obvious action should be secure. And you have to deliver it so that it operates out of the box, securely. (Mozilla have recently made some important steps in this direction by establishing a policy of delivery to the average user. It's a first welcome step which will eventually lead them to delivering a secure browser.)

If these steps aren't taken, then it doesn't help to say to the user, don't click there. Which brings me to the last point: why is user education *worse* than useless? Well, every time a so-called security expert calls for the users to be educated, he is avoiding the real problems, and he is shifting the blame away from the software to the users. In this sense, he is the problem, and until we can get him out of the way, we can't start thinking of the solutions.

Security Coding Best Practices - Java adds yet another little check, and boom...

Over on Adam's blog he has a developing theme on 'security signalling.' He asks whether a code-checking program like RATS would signal to the world that a product is a good secure product? It's an important question, and if you need a reason, consider this: when/if Microsoft gets done rewriting its current poisoned chalice of an operating system, how is it going to tell the world that it's done the job?

Last night I had occasion to feel the wrath of such a check, so can now respond with at least one sample point. The story starts earlier in the week, when I reinstalled my laptop with FreeBSD 5.3. This was quite a massive change for me, up from 4.9 which had slowly been dying under the imposition of too many forward-compatible ports. It also of course retriggered a reinstall of languages, but this should have been no trouble as I already had jdk1.4.2 installed, and that was still the current. (Well, I say no trouble ... as Java is "unsupported" on FreeBSD, mostly because of Sun's control freak policies creating a "write once, run twice" environment.)

Anyway, my code went crazy (*). A minor change in the compiler checking brought out a squillion errors. Four hours later, and I'd edited about 100 files and changed about 500 lines of code. My eyes were glazed, my brain frizzled and the only cognitive capability I had left was to open beers and dispose of them.

Now, this morning, I can look at the effect, hopefully in the cold hard light of a northern winter's sunny day. At least for another hour.

It's security code (hard crypto payments) so am I more secure? No. Probably actually less secure, because the changes were so many and so trivial that the robot masquerading as me made them without thinking; just trying to get the darn thing to compile so I could get back to my life.

So one answer to whether the RATS proposal could make any difference is that it could make things worse: If thrown at a project, the rush to get the RATS thing to come out clean could cause more harm than good.

Which is a once-off effect or a singularity. But what if you didn't have a singularity, and you instead just had "good coding checks" all the time?

Well. This is just like the old days of C where some shops used Lint and others didn't. (Lint was an old tool for cleaning out "fluff" from your C code.) Unfortunately there wasn't enough of a real discernable difference that I ever saw to be able to conclude that a Lint-using shop was more secure.

What one could tell is that the Lint-using shop had some coding practices in place. Were they good practices? Sometimes, yes. Maybe. On the whole Lint did good stuff, but it also did some stupid things, and the net result was that either you used Lint or you were careful, and not using Lint was either a signal that you were careful and knew more, or you weren't careful, and knew less; whereas using Lint was a signal that you didn't know enough to be careful, but at least you knew that!

We could debate for years on which is better.

As an example of this, at a tender age, I rewrote the infamous strcpy(3) set of routines to eliminate buffer overflows. Doing so cost me a day or two of coding. But from there on in, I never had a buffer overflow, and my code was easy to audit. Massive benefit, and I preferred that to using Lint, simply because *I* knew what I was doing was much safer.

But how to convince the world of that? I don't know ... still an open question. But, I'm glad Adam has brought up the question, and I have the chance to say "that won't work," because the answer is probably worth an extra percentage point on Microsoft's market cap, in a couple of years, maybe.

* The code is WebFunds which is about 100kloc (kilo-lines-of-code) chock full of hard crypto, RTGS payments and various other financial cryptography applications like secure net storage and secure chat.

PKI's mission: sell certs or die in the attempt!

Back in the early 90s, some Bright Spark had the idea that if a certificate authority could sign a certificate, and this certificate could be used to secure logins, payments, emails and ... well, everything, then obviously everyone would want one. And everyone was a lot of people, even back in the days before mainstream Internet.

There was a slight problem, though. The certificate wasn't really the only way to do things. In fact, it was one of the poorer ways to do things, because of that pesky complexity argument. But this didn't present an unsurmountable challenge to our Mr. B.S., as crypto and security are devilish complex things, *however* you do them.

All that was needed was a threat to hang the hat of certificate security on, and the rest could be written into history. This bogeyman turned out to be the wicked thief of credit cards, who would conduct a thing of great evil called a Man-In-The-Middle attack on poor innocent Internet consumers. This threat (cut to images of virginal shoppers tied to the rails before the oncoming train of rapacious gangsters) made the whole lot hang together, cohesively enough to fool all but the most skeptical security experts.

And so PKI was born. Public Key Infrastructure involved lots of crypto, lots of complexity, lots of software, and of course, oodles and oodles of certs, all for sale. Boom! Literally, at least in stock market terms, as certificate sellers went through the Internet IPO roof.

Their mission was to sell certs or die in the attempt, and they did. By the end of the dotcom boom, all but one of them were smoking carcasses. The one that survived cleverly used its stock market money to buy some businesses with real cash flow. But even it danced with stock prices that were 1-2% of its peak. Now it's up in the 10% range.

Unfortunately, even though the PKI companies died exotic and flashy deaths, the mission did not. Now, one insider has crawled out from the ashes to write an anonymous article that isn't exactly waving a white flag. As he reveals his inner dreams, it's stunning to realise that this insider *still* believes that PKI can do it, even when he admits that the mission was to sell certs. How pervasive a marketing myth is that?

Anyways, here's the link. For those students of Internet security, you be the judge: how much of the following makes sense when you consider their mission was to sell certs? How much of it makes sense if you take away that mission?

Revenge of the PKI Nerds

Wherein a very patient CSO hatches a plan to revive a technology thought to be dead

BY ANONYMOUS

I recently noticed a curious phenomenon. Public Key Infrastructure, once rumored to be dead, is making a comeback. Several high-profile institutions are now deploying a technology that I assumed had been extinct since the dot-bomb era. It's sort of technology's version of the coelacanth. This was a fish that was assumed to have been extinct for hundreds of thousands of years and then-bam!-one turns up in a fisherman's net off the coast of Madagascar.

I admit I have a certain fondness for Public Key Infrastructure, or PKI as it is commonly known-at least that is the three-letter version. PKI is commonly described using choice four-letter words as well. That's because it came into favor-and just as ingloriously fell out of it-with the boom of the '90s.

I should know, because I cut my security teeth on the bleeding edge of PKI. In 1992, I took a position as the director of electronic commerce with a company that sought to deploy a global certificate authority (CA) that would issue the digital certificates used to process PKI. Under our plan, all other CAs would be subordinate to us, and we would sit atop a giant pyramid scheme raking in monopoly profits by charging pennies on all the billions of e-commerce transactions around the world.

The only problem was tha