Financial Cryptography

The Economist on the FATF - a net 'bad'

I haven't time to write a proper blog entry on the net 'bad' that is the FATF and the anti-money laundering people. Economists know that anti-money laundering is unlikely to work just from common sense - the procedures proposed and implemented will probably cause more costs than benefits.

But nobody wants to be the messenger writing against one of the world's most powerful, entrenched - and now damaging - bureaucracies. Which makes the Economist's recent article all the more welcome. Read it and spread it:

For now the burden of implementation appears likely to rest with the private sector. “Banks are going to have to start behaving like the FBI and CIA,” contends David Porter of Detica, a Britain-based consultancy with expertise in financial crime. “They need to start connecting the dots.” This “risk-based” approach—concentrating time and energy on checking a smaller number of individuals or businesses based upon their transaction histories, sources of funding and other factors—is gaining wider acceptance.

For KPMG's Mr Dillon, the resources already spent on the effort have handed a victory to the terrorists. “The cost to our global economy is so large, they've already had the effect they wanted,” he says. “The increasing costs of compliance and technology are a form of terrorism. We're damaging ourselves.”

The championing of terrorism is an easy soundbite - it can't possibly be wrong can it? Unfortunately, it's dead wrong and in time people will come to think about terrorism in an common sense way. Anyone who is familiar with finance, war or expatriatism can tell you that trying to control flows that small is futile, and all you are doing is adding costs to your own people while arguably providing cover to the people you are trying to catch.

The Economist pulls its punches - but that's because no economist wants to sit down and take the risky job of documenting how the FATF and the OECD are damaging the economy and life in general. As Financial Cryptographers we know how this is the case because we see the rules and regulations, and we see real crooks. There is little connection! But sometimes we can also spot where the anti-money laundering agencies have done palpable and painful damage. Here's such a case:

The gang reportedly stole customer login ids and passwords using keylogging software and then used the information to steal cash from Web banking accounts. The stolen funds were then transferred into the accounts of "mules" who were offered cash in exchange for the use of their bank accounts.

I first spotted this new money laundering technique a year or so back, and no doubt it has been used more extensively before that. What happens is that innocent people are approached with a business deal that just happens to launder funds. The deal is dressed up in such a fashion that the innocent can't tell what the real purpose is, so they go for it. Everyone needs a job, and maybe your lucky break just turned up?

The damage done by the FATF has been to move money laundering out of the domain of the banks - where it can be watched - into the domain of the people. Goodhart's Law, in other words. People who have no clue what is happening are now being used as 'mules' in a crime which when uncovered - and of course that's a very high probability - will do immense damage to their lives and livelihoods.

I've seen it used on students, on expats and others. If you asked those people whether they'd preferred not to have to deal with such a complex fraud, then I'm sure they'd have begged for the chance.

Our thanks go to the FATF and OECD for making business unsafe for all of us. Is asking us all to behave like the FBI and the CIA really worth it? When you do get around to doing the benefit analysis, don't forget the costs that we have to pick up.

Breaking Payment Systems and other bog standard essentials

Many people have sent me pointers to How ATM fraud nearly brought down British banking. It's well worth reading as a governance story, it's as good a one as I've ever seen! In this case, a fairly bog standard insider operation in a major brit bank (not revealed but I guess everyone knows which one) raided some 2000 user accounts and probably more. They did all this through the bank's supposedly fool proof transaction system, and the bank aided and abetted by refusing to believe there was an issue! Further, given the courts willingness to protect the banks' secrecy, one can say that the courts also aided and abetted the crooks.

This is the story of how the UK banking system could have collapsed in the early 1990s, but for the forbearance of a junior barrister who also happened to be an expert in computer law - and who discovered that at that time the computing department of one of the banks issuing ATM cards had "gone rogue", cracking PINs and taking money from customers' accounts with abandon.

This is bog standard. Once a system grows to a certain point, insider fraud is almost a given, and it is to this that the wiser FCer turns. As I say, this is a must-read, especially if you are new to FC. Here's news for local currency pundits on how easy it is to forge basic paper tokens.

In a world of home laser printers and multimedia PCs, counterfeiting has become increasingly easy. With materials available at any office supply store, those with a cursory knowledge of photo-editing software can duplicate the business-card-size rewards cards once punched at Cold Stone Creamery or the stamps once given out at Subway sandwich sho........

Steven Bellovin reports that Skype have responded to criticisms over their "secret cryptoprotocol."

Skype has released an external security evaluation of its product; you can find it at http://www.skype.com/security/files/2005-031%20security%20evaluation.pdf (Skype was also clueful enough to publish the PGP signature of the report, an excellent touch -- see http://www.skype.com/security/files/2005-031%20security%20evaluation.pdf.sig) The author of the report, Tom Berson, has been in this business for many years; I have a great deal of respect for him.

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

Predictibly, people have pored over the report and criticised that, but most have missed the point that unless you happen to have an NSA-built phone on your desk, it's still more secure than anything else you have available. More usefully, Cubicle reports that there is an update to Skype that repairs a few bugs. As he includes some analysis of how to exploit and create some worms... it might be worth it to plan on updating:

The Blackhat in me salivates at the prospect. It’s beautiful security judo, leveraging tools designed to protect confidentiality (crypto) and Availability (peer-to-peer) to better hide my nefarious doings. Combine it with a skype API-based payload and you’ve got a Skype worm that can leverage the implicit trust relationship of contact lists to propagate further, all potentially wrapped inside Skype’s own crypto.

Too bad the first that most of Skype’s 60 million-and-growing users will ever hear of it will be after someone who does pay attention to these sorts of things decides they want to see if it’s possible to create a 60-million node botnet or retire after making The One Big Score with SkypeOut and toll fraud.

Hey Skype, Ignoring Risk is Accepting Risk–NOT Avoiding it. Put this on your main page while upgrading is still prevention rather than incident response.

A little hyperventilated, but consider yourself in need of a Skype upgrade.

Microsoft scores in anti-phishing!

Finally, some good news! Matthias points out that Microsoft has announced that they are switching to TLS in browsers. Hooray! This means no more SSL v2, and the other laxidaisical dinosaurs of the browser world can be expected to shuffle into line (Mozilla, Safari, Konqueror, Opera... yes, you may well look down in shame, especially Mozilla which was facing a bombardment of clues).

I have a sneaking suspicion that Microsoft actually are thinking a bit - not hugely but a bit - about phishing and are looking at some of the easier ways to deal with it. First, they acknowledged that phishing was a browser problem, and no other browser supplier to my knowledge has done that. Secondly, they mention from time to time phishing and security in the same breath, while the other guys are still stuck on patch counts and bug statistics and similar side issues. Thirdly:

As part of Microsoft's "secure by default" design philosophy, IE7 will block encrypted web sessions to sites with problematic (untrusted, revoked or expired) digital certificates. Users will receive a warning when they visit potentially insecure sites, which users can choose to ignore, except where certificates are revoked. "If the user clicks through a certificate error page, the address bar will flood-fill with red to serve as a persistent notification of the problem," Lawrence explained.

Huh. Not a bad idea, that, although note that it is logically the reverse of what the Petname and Trustbar people do! (Debates can be had, and more could be done, but a start is a start!) Fourthly:

The Beta 2 version of IE7 also changes the way non secure content is rendered in a secure web page. IE7 renders only the secure content by default but it offers surfers the chance to unblock the nonsecure content on a secure page using the Information Bar.

Fifthly, dropping SSL v2 as default: it's hard to concisely draw the complex connection between TLS and phishing, but it's easy to show its general or two-step effects. Microsoft makes a game attempt at this:

Lastly, the TLS implementation has been updated to support Extensions as described in RFC 3546. TLS extensions improve performance, and add capabilities to the TLS protocol. The most interesting of the extensions is the Server Name Indication (SNI) extension, as it resolves one of the long-standing limitations for HTTPS hosting.

A little background: When a web browser initiates a HTTPS handshake with a web server, the server immediately sends down a digital certificate. The hostname of the server is listed inside the digital certificate, and the browser compares it to the hostname it was attempting to reach. If these hostnames do not match, the browser raises an error.

The matching-hostnames requirement causes a problem if a single-IP is configured to host multiple sites (sometimes known as “virtual-hosting”). Ordinarily, a virtual-hosting server examines the HTTP Host request header to determine what HTTP content to return. However, in the HTTPS case, the server must provide a digital certificate before it receives the HTTP headers from the browser. SNI resolves this problem by listing the target server’s hostname in the SNI extension field of the initial client handshake with the secure server. A virtual-hosting server may examine the SNI extension to determine which digital certificate to send back to the client.

I told you it wasn't easy to explain ... in short, this means that many more ordinary sites can now use HTTPS to protect content, which speeds up the general availability of TLS (was SSL) which then kicks back and means browsers and plugins can protect against phishing. Top banana!

Last week there was a general panic issued at core Internet level - SSL v2 in OpenSSL had a flaw in it. Unfortunately, as there was no capability to turn off SSL v2 within OpenSSL, the problem turned into a schmozzle as OpenSSL is both incorporated in many packages, and also distributed in many forms. Maybe this discussion tipped the balance: get rid of SSL v2 everywhere.

Hat tip to Microsoft for having the guts to do what no other company or open source group did.

Security Professionals Advised to Button Lips

Nick pointed me to his Cuthbert post, and I asked where the RSS feed was, adding "I cannot see it on the page, and I'm not clued enough to invent it." To which he dryly commented "if you tried to invent it you'd arguably end up creating many 'unauthorized' URLs in the process...."

Welcome to the world of security post-Cuthbert. He raises many points:

Under these statutes, the Web equivalent of pushing on the door of a grocery store to see if it's still open has been made a crime. These vague and overly broad statutes put security professionals and other curious web users at risk. We depend on network security professionals to protect us from cyberterrorism, phishing, and many other on-line threats. These statutes, as currently worded and applied, threaten them with career ruin for carrying out their jobs. Cuthbert was convicted for attempting to determine whether a web site that looked like British Telecom's payment site was actually a phishing site, by adding just the characters "../.." to the BT site's URL. If we are to defeat phishing and prevent cyberterrorism, we need more curious and public-spirited people like Cuthbert.

Meanwhile, these statutes generally require "knowledge" that the access was "unauthorized." It is thus crucial for your future liberty and career that, if you suspect that you are suspected of any sort of "unauthorized access," take advantage of your Miranda (hopefully you have some similar right if you are overseas) right to remain silent. This is a very sad thing to have to recommend to network security professionals, because the world loses a great deal of security when security professionals can no longer speak frankly to law-enforcement authorities. But until the law is fixed you are a complete idiot if you flap your lips [my emphasis].

Point! I had not thought so far, although I had pointed out that security professionals are now going to have to raise fingers from keyboards whenever in the course of their work they are asked to "investigate a fraud."

Consider the ramifications of an inadvertant hit on a site - what are you going to do when the Met Police comes around for a little chat? Counsel would probably suggest "say nothing." Or more neutrally, "I do not recollect doing anything on that day .. to that site .. on this planet!" as the concept of Miranda rights is not so widely encouraged outside the US. Unfortunately, the knock on effect of Cuthbert is that until you are appraised of the case in detail -- something that never happens -- then you will not know whether you are suspect or not, and your only safe choice is to keep your lips buttoned.

Nick goes on to discuss ways to repair the law, and while I agree that this would be potentially welcome, I am not sure whether it is necessary. Discussion with the cap-talk people (the most scientific security group that I am aware of, but not the least argumentive!) has led to the following theory: the judgement was flawed because it was claimed that the access was unauthorised. This was false. Specifically, the RFC authorises the access, and there is no reasonably theory to the alternate, including any sign on the site that explains what is authorised and what not. The best that could be argued - in a spirited defence by devil's advocate Sandro Magi - is that any link not provided by the site is unauthorised by default.

In contrast, there is a view among some security consultants that you should never do anything you shouldn't ever do, which is more or less what the "unauthorised" claim espouses. On the surface this sounds reasonable, but it has intractable difficulties. What shouldn't you ever do? Where does it say this? What happens if it *is* a phishing site? This view is neither widely understood by the user public nor plausibly explained by the proponents of that view, and it would appear to be a cop-out in all senses.

Worse, it blows a hole in the waterline of any phishing defence known to actually work - how are we going to help users to defend themselves if we ourselves are skating within cracking distance of the thin ice of Cuthbert? Unfortunately, explaining why it is not a rational theory in legal, economic or user terms is about as difficult as having an honest discussion about phishing. Score Cuthbert up as an own-goal for the anti-phishing side.

What happens when you don't do due diligence...

A story doing the rounds (1, 2) shows how money laundering is now being used to open up security in banks that don't do DD. The power of the money laundering bureaucrats is now so unquestioned that mere mention of it and a plausible pretence at it allows anyone to do the craziest things to you.

AN INGENIOUS fraudster is believed to be sunning himself on a beach after persuading leading banks to pay him more than €5 million (£3.5 million) in the belief that he was a secret service agent engaged in the fight against terrorist money-laundering. The man, described by detectives as the greatest conman they had encountered, convinced one bank manager to leave him €358,000 in the lavatories of a Parisian bar. "This man is going to become a hero if he isn't caught quickly," an officer said. "The case is exceptional, perfectly unbelievable and surreal."

In another case he did it with wires to Estonia, but had to sacrifice his wife and mother-in-law in the process:

A third payment of €5.18 million was made to an account in Estonia. This time Gilbert was quicker. Police identified him by tracing his calls, but by the time they caught up with him he was in Israel. They arrested his wife and mother-in-law at the family home outside Paris. They deny acting as accomplices.

Can you hear the mother-in-law screaming "I told you he was a SCHMUCK!?!" Read the whole thing - it's a salutory lesson in how governance is done not by blindly doing what bureaucrats and experts think is a good idea, but by thinking on your feet and doing your own due diligence. In this case, it is somewhat unbelievable that the banks did not do the due diligence on this chap, but I suppose they were waiting for an invitation!

Penny Payment Systems

Google's plans on a payment system are giving some people amusement. (1, 2, 3). Synopsis: it's a merchant oriented system, based on credit card. Direct "Paypal" model in other words. (This is a little unfair to those who invented the model, before Paypal, but hey, history sucks.)

Question is, would you or I do any different? That's a tricky question. Probably not, because Paypal is about as vulnerable as a unchaperoned princess on the way to her first ball. I'd be keen to migrate that model away for fraud reasons, but the "standard approach" has a lot of merit going for it right now.

This column waxes on without limit about how the planet will spin faster and the sun will shine brighter when google releases, due to all the hook-ins with other google products. Roight. But seeing as I murmured that eBay was looking ok the other day, I feel compelled to point out this statement: "Since eBay is already in deep trouble, it poses no threat to Google either way." Huh!

(More on eBay at the end.)

Introducing:

WhoPay: : a Scalable and Anonymous Payment System for Peer-to-Peer Environments Kai Wei, Yih-Farn Chen, Alan J. Smith and Binh Vo

EECS Department
University of California, Berkeley
Technical Report No. UCB/CSD-05-1386 2005

http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/CSD-05-1386.pdf

An electronic payment system ideally should provide security, anonymity, fairness, transferability and scalability. Existing payment schemes often lack either anonymity or scalability. In this paper we propose WhoPay, a peer-to-peer payment system that provides all the above properties. For anonymity, we represent coins with public keys; for scalability, we distribute coin transfer load across all peers, rather than rely on a central entity such as the broker. This basic version of WhoPay is as secure and scalable as existing peer-to-peer payment schemes such as PPay, while providing a much higher level of user anonymity. We also introduce the idea of real-time double spending detection by making use of distributed hash tables (DHT), which further improves the security level of WhoPay. To evaluate how well WhoPay distributes load among peers, we have run simulations with several different configurations. The simulation results show that the majority of the system load is handled by the peers under typical peer availability, indicating that WhoPay should scale well.

http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/5650.html

To which, Daniel comments that "the main idea is simple: rollovers are handled by the first user who received a coin rather than directly by the issuer. If the user goes off-line, the issuer can temporarily take care of the rollovers. This is the innovation of PPay. This WhoPay is basically an anonimization layer on top of PPay." As commented from time to time, a lot of good research is going on in p2p space.

In more PayPal/eBay news, PaymentNews reports that the AuctionBytes.com's Ina Steiner has commented on the new eBay policy of banning other payment systems from auctions. Ostensibly for user safety, there is some user skepticism, and notions that this is positioning in advance of google are going to be hard to shake. Read this snippet and make your own mind up:

From time to time, as new payment services arise, eBay will evaluate them to determine whether they may present trust and safety concerns and are appropriate for the marketplace. eBay will consider the following factors, among others, in making its determination:

• Whether the payment model offers substantial financial, privacy and anti-fraud protection for buyers and sellers
• Whether the payment model raises the potential for confusion among eBay users, or involves incentives that may present fraud concerns
• Whether the payment model involves precious metals, or other non-cash (points, miles, minutes, coupons, discounts) as consideration
• Whether the payment service has a substantial historical track record of providing safe and reliable financial and/or banking related services (new services without such a track record generally cannot be promoted on eBay)
• The identity, background and other business interests of the payment service sponsor
• The license/regulatory status of the payment provider in the countries where it provides payment services

The gold community will get a kick out that one! Also recently reported was PayPal's year summary. Payment News says:

PayPal's parent eBay announced third quarter financial results this afternoon. The following highlights regarding PayPal's third quarter financial performance were included:

• Payments net revenues grew to $247.1 million, an increase of 44 percent year over the same quarter last year and up 1.3 percent vs. the prior quarter.
• PayPal's user accounts grew to 86.6 million accounts, up 53 percent year over year and up 9.8 percent vs. the prior quarter. Active accounts grew to 24.5 million, up 41 percent year over year and 7 percent vs. the prior quarter.
• Total gross payment volume handled by PayPal grew to $6.7 billion, up 44 percent year over year and 3 percent vs. the prior quarter. Total number of payments grew to 117.4 million, up 41 percent year over year and 4 percent vs. the prior quarter. 69 percent of PayPal's payment volume was eBay-related.
• PayPal earned revenues of 3.60% on payment volume totaling $247.1 million, had expenses of 1.11% of payment volume totaling $74 million and losses of 24 basis points totaling approximately $16 million.

Roundup on News

In the developing story of the "Cuthbert case" the ripples continue to spread as security experts disect the result. Curiously, it hasn't hit the mainstream much, probably because popular press can't work out what the fuss is about but the blogs seem to have it. Adam points at Samizdata.net Diana Quaver, who has followed and documented the case in much more detail. Also dropsafe has a nice roundup. Here's one article from ZDNet:

"Nobody thought he was doing anything significant or malicious, and there was a strong argument that the police should have given him a slap on the wrists and not prosecuted," said Sommer, senior research fellow at the London School of Economics' Information Systems Integrity Group.

Sort of. More usefully, what we are not confident about is that we can describe in terms that users will understand and that matches the web's ethos just what is "unauthorised" and what is not. We've now got a good theory as to what BT thought was unauthorised - but it isn't a theory that makes any sense to the user or the web, nor is it a theory promulgated much further than the minds of corporate security experts.

In terms of a trespassing analogue, there is no sign, no fence, and BT prosecuted the trespasser on the basis of finding his wallet dropped inside the facility. As the owner admitted to being inside, this was considered good enough for a criminal conviction - but it isn't good enough for trespassing!

This is a complete mess. I'd suggest not going anywhere near the DEC / BT.donate.com site to donate; or indeed anywhere near BT until they explain in terms understandable to users just what the difference between their website and the RFC is.

Read on for more news!

It's official: we now have a duopoly in CPUs as AMD has reached 50% of one particular market. This was a classic story that I picked when I realised that Intel had broken the golden rule that had established its hegemony - and started on the fatal journey to design another chip that wasn't Intel-compatible. AMD saw it too and went the other route of Intel-compatible-and-64 bits and won. By the time Intel had realised their mistake it was too late, and thanks to their mistake we all win with cheaper chips and more aggressive progress. Now if only Steve Ballmer would get distracted on ... dunno, how about DRM?

Interesting post about side-channel attacks on games software, a timing difference gave a player a way to clean up. Also, a curious finding for ISPs - DDOS is the #1 hassle:

Over 90 percent of ISPs surveyed cited simple "brute force" TCP SYN and UDP datagram DDoS floods from zombie PC networks as their biggest day-to-day hassle, a finding which should apply equally to their corporate clients. This puts DDoS ahead of more recent attack types such as fast-spreading worms and DNS poisoning, which were ranked second and third respectively, in terms of prevalence. Even then, worm attacks were often most hazardous in terms of their original effect on traffic. "The primary threat from worms is not the payloads but the network congestion they cause," the report noted.

Surprisingly, given the prevalence of this type of attack in recent years, only 29 percent of ISPs offered services to counter and trace DDoS in an automated way at the ISP level. The majority only discovered such events when a customer contacted them for help. The main means of defending against DDoS remains the use of Access Control Lists (ACLs), but these come with the downside of shutting off network access. The DDoS attack is stopped but only by replicating much the same effect as the original traffic blocking.

The reported motivations for DDoS attacks clusters around issues such as cyber-extortion, electronic protests against companies, and even corporate espionage. Few, if any, of such attacks are reported to result in criminal action against the instigator, which could account for its continued popularity.

Nice the way they characterise it as a "hassle" and ignore the actual damage done to the target, which is presumably under some extortion play.

A very nice piece of Open Governance; eBay shareholders go through the annual report and talk about the stated risks there. Some good stuff on Paypal woes for payment systems people.

And finally a welcome sounding of the alarm: CIOs and vendors are complicit.

Those who've read my draft on silver bullets will know what this is about, but it is good to see someone else looking at the problem. Here's what Ed Lazowska (who holds the Bill & Melinda Gates Chair in Computer Science & Engineering at the University of Washington !!!) says:

Q: Some of the problems, such as software not being designed with security in mind, indicate that CIOs are somehow complicit. In your opinion, are CIOs victims or are they part of the problem?

A: The answer surely is both. CIOs are partially responsible for the insecure state of today's operating systems, because they failed to see the handwriting on the wall and prioritize security. Vendors produce what we are willing to purchase. CIOs are largely responsible for the failure of their organizations to operate at the current state of the art with respect to cybersecurity, and very few organizations operate at the current state of the art.

Now, the problem is that you can't suddenly decide that you want something like security and expect to be able to buy it, because the technology doesn't necessarily exist. Almost no IT company looks ahead more than one or two product cycles. And historically in IT, those ideas comes from research programs that the federal government underwrites. Just think about e-commerce: You need the Internet, Web browsers, encryption for secure credit card transactions and a high-performance database for back-end systems. The ideas that underlie all of these can trace their roots to federally funded R&D programs.

That's how this relates to the R&D agenda. Long-range R&D has always been the role of the national government. And the trend, despite repeated denials from the White House to the Department of Defense, has decreased funding for R&D. And of the R&D that does get funded, more and more of it is on the development side as opposed to longer-range research, which is where the big payoffs are in the long term. That's a more fundamental problem that CIOs aren't responsible for.

I do not agree with the second part of his answer, but left it in for contrast!

Ben Laurie on Identity

Ben Laurie enters the world of blogs in typical style ("Anyone who knows me knows I hate blogs") and also shows that the feeling's mutual ( ... unprintable!).

More apropos, there are some interesting posts on how to turn the MD5 collision attack into a useful attack involving primes. John Kelsey suggested one and several posts pursue it. Start here.

Even more useful, Ben's Laws of Identity and a paper to better describe. Systems must be:

• Verifiable. There’s often no point in making a statement unless the relying party has some way of checking it is true. Note that this isn’t always a requirement - I don’t have to prove my address is mine to Amazon, because its up to me where my good get delivered. But I may have to prove I’m over 18 to get the porn delivered.
• Minimal. This is the privacy preserving bit - I want to tell the relying party the very least he needs to know. I shouldn’t have to reveal my date of birth, just prove I’m over 18 somehow.
• Unlinkable. If the relying party or parties, or other actors in the system, can collude to link together my various assertions, then I’ve blown the minimality requirement out of the water.

Which is looking good and it is nice to see some critical attention to Kim Cameron's Laws on Identify(ing Microsoft's Future Customers). (See also here Stefan Brands' blog for more on Identity.)

Mind you, Ben claims that x.509 is not suitable because "standard X.509 statements are verifiable, but not minimal nor unlinkable." I'm troubled by that word "verifiable." Either an x.509 cert points to somewhere else and therefore it in itself is not verifiable, just a reliable pointer to somewhere else, or the somewhere else is included in which case we are no longer talking about x.509.

Still, this is one of those debates where words twist their meaning faster than the average security guy can think, so let's save that for the bar.

Welcome!

The Mojo Nation Story

[Guest post by Steve Schear] Mojo Nation was the brainchild of Jim McCoy (then formerly of Yahoo) and Doug Barnes (then formerly of C2Net). Their vision was a fully distributed peer-to-peer network with a financial mechanism that offered efficient cost recovery and discouraged the free-riding known to P2P people as leeching (a problem that continues to plague P2P).

The most radical element of MN was its method of pricing all activities in terms of network resources. It was also one of the first attempts at a P2P network using a fully distributed approach and a publishing versus a file sharing metaphor.

Unfortunately, MN was never fully operational. It never reached a point of deployment that allowed many of its novel architectural and technological assumptions, especially the mint, to be truly tested. It's not clear what economic lessons to draw from its operational vision, but here are some of the reasons behind its business failure:

• MN failed because it failed to get continued funding. It only received seed money from its founder, Jim McCoy. MN was in development before Napster but its greater complexity caused a delayed public release. Jim had the foresight to thoroughly investigate the legal aspects of P2P and architecture MN to segregate tracking and file storage and distance itself from either. Nevertheless, Napster's negative publicity closed the door on VC funding and development beyond beta testing.
• It failed because the UI never reached a point of maturity that enabled mostly automated meta-data tags (e.g., from mp3) to be generated from published content. This required users to tediously enter this data (and re-enter it when they were forced to republish, see below).
• It failed because software instabilities prevented its distributed servers from accumulating and retaining enough content and becoming stable (network effects). This instability required constant, manual, republishing of content by users who soon fatigued (user churn).

The most notable result from MN was Bram's Bit Torrent. Though, as we saw, Bram failed to heed warnings (and discussion at MN) about protecting the trackers until the MPAA/RIAA were able to shut many down. Its been reported that many of these shortcomings have been fixed but I still can't seem to get Azureus (the most popular BT client) to work as expected with the distributed tracking. Since the demise of eDonkey, et al, due to the MGM vs. Grokster BT has been given a shot at reassuming the P2P leadership mantle. I hope it succeeds. Or perhaps P2P's next growth will have to wait until enough its users discover the advantages of an anonymizing transport layers, like TOR and I2P.

Steve

Addendum: see Part 2 from Jim McCoy himself.

It's official - doing due diligence is a criminal offence!

I wrote before about rising barriers in security. We now have the spectre of our worst nightmare in security turned haptic: the British have convicted a security person for doing due diligence on a potential scam site. If you work at a British Financial Institution, be very very aware of how this is going to effect security.

[writes El Reg] On December 31, 2004, Cuthbert, using an Apple laptop and Safari browser, became concerned that a website collecting credit card details for donations to the Tsunami appeal could be a phishing site. After making a donation, and not seeing a final confirmation or thank-you page, Cuthbert put ../../../ into the address line. If the site had been unprotected this would have allowed him to move up three directories.

After running the two tests, at between 15.12 and 15.15 on New Year's Eve, Cuthbert took no further action. In fact his action set off an Intrusion Detection System at BT's offices in Edinburgh and the telco called the police.

It may well be that the facts of the case are not well preserved in the above reporting; no journalist avoids a good story, and El Reg is no exception. A reading of other reports didn't disagree, so I'll assume the facts as written:

[El Reg again] DC Robert Burls of the Met's Computer Crime Unit said afterwards: "We welcome today's verdict in a case which fully tested the computer crime legislation and hope it sends a reassuring message to the general public that in this particular case the appropriate security measures were in place thus enabling donations to be made securely to the Tsunami Appeal via the DEC website."

The message is loud and clear, but it is not the one that they wanted. The Metropolitan's Computer Crime Unit is blissfully unaware of the unintended consequences it has unleashed... Let's walk through it.

According to the testimony, the site gave some bad responses and raised red flags. A routine event, in other words. Cuthbert checked it out a little to make sure it wasn't a phishing site, and apparently found it wasn't. This would have been a very valuable act for him, as otherwise he might have had to change all his card and other details if they had been compromised by a real phishing attack (of which we have seen many).

The 'victim' in the case was named as Disasters Emergency Committee (DEC). From Cuthbert, DEC received a 30 pound donation via donate.bt.com and then said (after he was charged):

[more] There's no suggestion any money was stolen and the Disasters Emergency Committee has issued a statement reassuring the public that the internet remains a safe way to donate money to victims of the 26 December disaster.

The real victim may well be the British public who now only have BT's IDS and the Metropolitan Computer Crime Unit between them and phishing. Let's imagine we are tasked to teach users or banks or whoever how to defend themselves against phishing and other Internet frauds. What is it that we'd like to suggest? Is it:

a. be careful and look for signs of fraud by checking the domain name whois record, tracerouting to see where the server is located, probing the webserver for oddities?

Or

b. don't do anything that might be considered a security breach?

Either way, the user is in trouble because the user has no capability to determine what is and what is not an "unauthorised access". Banks won't be able to look at phishing sites because that would break the law and invite prosecution; after this treatment, security professionals are going to be throwing their hands up saying, "sorry, liability insurance doesn't cover criminal behaviour." The Metropolitan Computer Crime Unit will likewise be hamstrung by not being able to breach the very laws they prosecute.

There is a blatant choice here not only for security professionals and banks, but also for the hapless email user. Follow the law, and perform due diligence without the use of ping, traceroute, telnet, whois, or even browsers ... Or follow the protocols and send the recognised and documented requests to respond according to the letter and spirit of the RFCs, and in the meantime discover just how bona fide a site is. Tyler dug up the appropriate document in this case:

So RFC 3986 explicitly lists this construction as a valid URL. See section 5.4.2.:

5.4.2. Abnormal Examples

Although the following abnormal examples are unlikely to occur in
normal practice, all URI parsers should be capable of resolving them
consistently. Each example uses the same base as that above.

Parsers must be careful in handling cases where there are more ".."
segments in a relative-path reference than there are hierarchical
levels in the base URI's path. Note that the ".." syntax cannot be
used to change the authority component of a URI.

"../../../g" = "http://a/g"
"../../../../g" = "http://a/g"

The way the security bureaucrats are treating this war, possession of an RFC will become evidence of criminal thoughts! The battle for British cybersecurity looks over before it has begun.

Addendum: Due diligence defined and reasonably duty of care discussed. Also see Alice in Credit-Card Land and also Phishing and Pharming and Phraud - Oh My for discussions in more depth. Also, I forgot to tip my hat to Gerv for the original link.

SSL v2 SNAFU

The net is buzzing about an "OpenSSL Potential SSL 2.0 Rollback Vulnerability" (1, 2) where you can trick your SSL v3 to roll back to SSL v2. There are then some security weaknesses in SSL v2 that can be exploited to break in.

Annoyingly, none of the security advisories that I saw said what should be the obvious workaround: *TURN OFF SSL V2! NOW!* It's an old protocol, it's done its job and deserves to be put out to pasture. Give it an apple a day and let it enjoy its last few years without shame.

The presence of SSL v2 continues to embarrass us with insecurity. This security advisory is the least of worries, by far the greater effect is that with SSL v2 delivered as a default protocol, all browsers and all web servers end up negotiating SSL v2. That's because the HELLO negotiation can only cope with both v2 and v3 nodes if it assumes the first, and both nodes will then fall back to SSL v2. Maybe the security advisory should be extended to all the browsers and web servers out there?

Meanwhile, the reason we care is not because an MITM could break into SSL v2 (fat chance of that happening) but because we can't do virtual hosts without SSL v3. This is a good solid pragmatic user and business reason and cryptoengineers, security experts and the like are not expected to understand this: Without virtual hosts, we can't spread SSL to be a *routine* protection for all web sites. And without SSL being a *routine* protection, the security model in the browser won't get fixed and phishing rampantly pillages its way through suburban america like a bad 90s music revival. Depressing, expensive and accompanied by lots of screaming and wailing when people realise their wallets just got emptied by ... well, like any revival, we don't really want to admit we know who it was by.

Anway, the upshot is that the security advisory misses the chance to deliver any security to people. SSL remains SNAFU: Situation Normal, All F**ked Up.

Is technical trading a Schelling point?

When I first learnt of technical trading I puzzled over it for a long time. By own admission it ignored the rules of theory; yet the technical traders believe in it immensely, and profitably one supposes, and they consider the alternate to be useless. (In this at least, they are in agreement with the efficient markets hypothesis.)

I eventually came to the conclusion that in the absence of any good theory, then a theory of another sort must evolve. Some sort of shared understanding must evolve to permit a small interested community to communicate on a sort of insider basis. There is probably, I postulated, some economics or psychology law somewhere that says that a group of insiders is somewhat contiguous with a shared language, shared theory and eventually shared beliefs.

That sounds like a Schelling point. Is technical trading - flags, pennants, head&shoulders, etc - a Schelling point?

Footnote: wikipedia describes technical analysis which is close. In the above I'm more referring to what they describe as charting.

Schelling points

Thomas Schelling and Robert Aumann have won this year's Nobel Prize in Economics for "having enhanced our understanding of conflict and cooperation through game-theory analysis."

See Adam's blog for an explanation of Schelling points, which I was to learn as a daily strategy in Spain. There, when meeting for some social event, various factors made all plans unreliable and sophisticated strategies based on shared knowledge were required just to meet up and have a beer. For example, on finding one bar shut, a thirsty traveller would spiral outwards from that bar to the nearest, and then to the next until the crowd had been found.

Their work goes well beyond such triflings and one day I might find time to understand even a little of it. For now, I cut & paste wiser words:

[Their work] was essential in developing non-cooperative game theory further and bringing it to bear on major questions in the social sciences. Approaching the subject from different angles -- Aumann from mathematics and Schelling from economics -- they both perceived that the game-theoretic perspective had the potential to reshape the analysis of human interaction. Perhaps most importantly, Schelling showed that many familiar social interactions could be viewed as non-cooperative games that involve both common and conflicting interests, and Aumann demonstrated that long-run social interaction could be comprehensively analyzed using formal non-cooperative game theory.

While on economics, Jean sends news that Jimmy Tseng is looking for a PhD candidate to work on the economic aspects of privacy. It is a fully funded position for 4 years in the Netherlands. full details.

Given political news from the lowlands, the Dutch are hell-bent on tarnishing their reputation on privacy, so well done, Jimmy and Jean.

Journal of Internet Banking and Commerce

Vol 10 No. 2 Summer 2005 of JIBC is out now:

• From JIBC Publisher Nahum Goldmann
• From Editor-in-Chief Nikhil Agarwal

General and Review Articles

• Belgium EEMA: Focus on Technical and Legal Issues of e-Business in the European Union (By: Edwin JACOBS,University of Leuven)
• China Current Development Situation of E-Commerce in China (By: Alamusi, ChinaEClaw.com)
• USA B2B Marketers Integrate Precision Search to Boost Profitability and Increase Satisfaction Across the eCommerce Value Chain (By: Larry R. Harris, EasyAsk, a division of Progress Software)
• Canada Trust and Confidence and the Digital Economy: Issues and Challenges (By: Prabir K. Neogi and Arthur J. Cordell, Industry Canada)

Research Papers

• Belgium Security as a Legal Obligation: About EU Legislation Related to Security and Sarbanes Oxley in the European Union (By: Edwin JACOBS, University of Leuven)
• Belgium The Law on Electronic Medical Prescription (By: Francis de Clippele, Lawyer in Antwerp, Assistant Lecturer at the University of Antwerp)
• Canada Trust and Confidence and the Digital Economy: Issues and Challenges (By: Prabir K. Neogi, Arthur J. Cordell, Electronic Commerce Branch, Industry Canada)
• India Technical and Entrepreneurial Research Information System: An Applied e-Model for Sustainable Entrepreneurship Development (By: Dhrupad Mathur, S P Jain Institute of Management & Research, Mumbai)
• India A Framework for Evaluating e-Business Models and Productivity Analysis for Banking Sector in India (By: NVM Rao, Prakash Singh, and Neeru Maheshwari, BITS, Pilani)
• Malaysia Do Foreign Banks Lead in Internet Banking Services (By: Boon Han YEAP, Monash University Malaysia, and Kooi Guan CHEAH, Universiti Sains, Malaysia)
• Malaysia Marketing Mix: A Review of 'P' (By: Chai Lee GOI, Curtin University of Technology, Malaysia)
• Qatar E-banking Service Quality: Gaps in the Qatari Banking Industry (By: Norizan M. Kassim, University of Qatar)
• USA and Singapore A Case Study of Electronic Bill Presentment and Payment (EBPP) Integration Using the COIN Mediation Technology (By: Sajindra Jayasena, National University of Singapore, Stephane Bressan, Sloan School of Management and Stuart Madnick, Massachussets Institute of Technology)

Read on for abstracts....

General and Review Articles

BELGIUM: EEMA: Focus on Technical and Legal Issues of e-Business in the European Union
(By Edwin Jacobs)
http://www.aaraydev.com/commerce/JIBC/EdwinJacobs_EEMA_210705,asp

EEMA is Europe's leading independent association for e-Business and promotes collaboration concerning all technical (ICT), legal and business aspects of e-business. EEMA puts the emphasis on today's practical issues. In this respect, EEMA's Legal Interest Group, headed by Prof. Jos Dumortier, focuses on all legal aspects of e-business, i.e. electronic signature, e-invoice, identity management, security legislation (e.g. Sarbanes Oxley in the EU), privacy, etc. On November 22nd and 23 rd this year EEMA will organise a two-day seminar about electronic invoicing and electronic archiving in Brussels.

CHINA: Current Development Situation of e-Commerce in China
(By Alamusi)
http://www.arraydev.com/commerce/JIBC/2005-08/china.htm

The Chinese government puts a great deal of emphasis on E-Commerce work extremely. Generally speaking, the China E-Commerce market contains huge commercial opportunity, the development prospect of which is extremely broad. The relevant organizations are complying with and guiding commercial transformation tendency, absorbing latest international achievement of technical platform, payment system, creditability system, platform construction and safety guarantee system in E-Commerce, further optimizing the external environment, and speeding up development and innovating application complying with national features.

USA: B2B Marketers Integrate Precision Search to Boost Profitability and Increase Satisfaction Across the e-Commerce Value Chain
(By Larry R. Harris)
http://arraydev.com/commerce/JIBC/2005-08/Harris.asp

This article will describe the central role that site search and navigation plays in B2B eCommerce, as well as the defining characteristics of a successful search implementation from both a technical and marketing perspective. This article will also outline how integrating precision search into an existing eCommerce infrastructure can result in higher productivity, streamlined processes, increased conversion rates, greater commercial buyer and partner satisfaction, and higher profits per transaction.

Research Papers

BELGIUM: Security as a Legal Obligation: About EU Legislation Related to Security and Sarbanes Oxley in the European Union
(By Edwin Jacobs)
http://www.arraydev.com/commerce/JIBC/2005-08/security.htm

Since the Sarbanes-Oxley Act there is a worldwide focus on security issues in general. This new focus seems to emphasize that security is a new kind of legal obligation. However, security is already a legal obligation for all EU companies since the early nineties. On top of that, in electronic banking there is a whole range of legal obligations in some way related to security, that were already (and remain) applicable, notwithstanding a possible application of the Sarbanes-Oxley Act on some EU companies. The criterion of what can be 'reasonably expected' as 'bonus pater familias' from service providers, but equally also from their customers, becomes increasingly important.

BELGIUM: The Law on Electronic Medical Prescription
(By Francois de Clippele)
http://www.arraydev.com/commerce/JIBC/2005-08/EMV.HTM

Health care is one of the most important economic and business areas. The European Union has therefore worked out an e-health care strategy to achieving stronger growth and increased effectiveness of services. The application of information and communications technologies (ICT) that affect the health care sector is developing fast in Europe. In this respect various countries have launched pilot projects in order to modernize their medical prescription practices. A model of the electronic medical prescription must respect patient's rights and can only be deployed in a system of security in order to protect the confidentiality.

CANADA: Trust and Confidence and the Digital Economy: Issues and Challenges
(By Prabir K. Neogi and Arthur J. Cordell)
http://www.arraydev.com/commerce/JIBC/2005-08/Negi.htm

Globalization and technological change continue to profoundly affect economic growth and wealth creation. Information and Communications Technologies (ICTs) have been a key enabler and driver of globalization, which is likely to continue as trade and investment barriers continue to fall and communications become ever cheaper, easier and more functional. Every economy requires a physical, institutional and legal infrastructure, as well as understandable and enforceable marketplace rules, in order to function smoothly. In this paper the authors maintain that such an infrastructure must be developed for the new digital economy and society, one that provides trust and confidence for all those who operate in or are affected by it.

INDIA: Technical and Entrepreneurial Research Information System: An Applied e-Model for Sustainable Entrepreneurship Development
(By Dhrupad Mathur)
http://www.arraydev.com/commerce/JIBC/2005-08/DhrupadMathur.asp

This article stresses on the need for an e-application like Technical and Entrepreneurial Research Information System (TERIS), which enables interaction among academia, industry and various agencies related to researchers for sustainable entrepreneurship development. The functional details of the model are also discussed. This article is based on inputs with reference to the state of Rajasthan. However, the model can very well be replicated elsewhere.

INDIA: A Framework for Evaluating e-Business Models and Productivity Analysis for Banking Sector in India
(BY N.V.M. Rao, Prakash Singh ans Neeru Maheshwari)
http://www.arraydev.com/commerce/JIBC/2005-08/maheshwari.htm

This study is an effort to draw together some of the e-Business models and real-life experiments that has been circling around the e-business models. To study the sweeping changes brought about by e-initiative measures in the banking sector some banks were chosen, from public sector like SBI, BOB etc and from private sector like ICICI, HDFC etc.

MALAYSIA: Do Foreign Banks Lead in Internet Banking Services
(By Boon Han Yeap and Kooi Guan Cheah)
http://www.arraydev.com/commerce/JIBC/2005-08/JIBC_yeap%20&%20cheah.asp

Internet banking has been increasingly used as a delivery channel in retail consumer banking. As far as the provision of internet banking services in developing countries is concerned, foreign banks definitely enjoy distinct advantages over domestic banks due to their experiences in other, more advanced financial markets. This paper reports a study that examined the levels of retail internet banking services provided by foreign and domestic commercial banks in Malaysia over a period of two years. The study found that while foreign banks are marginally more sophisticated at information provision level, domestic banks offer a significantly higher level of transactional facilities in both years.

MALYASIA: Marketing Mix: A Review of "P"
(By Chai Lee Goi)
http://www.arraydev.com/commerce/JIBC/2005-08/goi.HTM

There has been a lot of debate in identifying the list of marketing mix elements. The traditional marketing mix by McCarthy (1964) has regrouped Borden's (1965) 12 elements and has comprised to four elements of product, price, promotion and place. A number of researchers have additionally suggested adding people, process and physical evidence decisions (Booms and Bitner, 1981; Fifield and Gilligan, 1996). The other suggested Ps are personnel, physical assets and procedures (Lovelock, 1996; Goldsmith, 1999); personalization (Goldsmith, 1999); publications (Melewar and Saunders, 2000); partnerships (Reppel, 2003); premium price, preference of company or product, portion of overall customer budget and permanence of overall relationship longevity (Arussy, 2005); and 2P+2C+3S formula (Otlacan, 2005), therefore personalisation, privacy, customer Service, community, site, security and sales promotion.

QATAR: E-Banking Service Quality: Gaps in the Qatari Banking Industry
(By Norizan M. Kassim)
http://www.arraydev.com/commerce/JIBC/2005-08/KassimTry.asp

Financial liberalization and technology revolution have allowed the developments of new and more efficient delivery and processing channels as well as more innovative products and services in banking industry. Banking institutions are facing competition not only from each other but also from non-bank financial intermediaries as well as from alternative sources of financing, such as the capital markets. Another strategic challenge facing banking institutions today is the growing and changing needs and expectations of consumers in tandem with increased education levels and growing wealth. Consumers are becoming increasingly discerning and have become more involved in their financial decisions. For this reason, they are demanding a broader range of products and services at more competitive prices through more efficient and convenient channels. This study investigates the discrepancy between customer's expectation and perception towards the e-banking services.

USA/SINGAPORE: A Case Study of electronic Bill Presentment and Payment (EBPP) Integration Using the CON Mediation Technology
(By Sajindra Jayasena and Stephane Bressan)
http://arraydev.com/commerce/JIBC/2005-08/Jayasema.asp

By its very nature, financial information, like the money that it represents, changes hands. Therefore the interoperation of financial information systems is the cornerstone of the financial services they support. In this paper we illustrate the nature of the problem in the Electronic Bill Presentment and Payment industry. In particular, we describe and analyze the difficulty of the integration of services using four different formats: IFX, OFX and SWIFT standards, and an example proprietary format. We then propose an improved way to accomplish this integration using the Context Interchange (COIN) framework.

Administrative Notice

Journal of Internet Banking and Commerce

JIBC is a leading edge publication that informs banking and electronic commerce professionals and executives on principal developments, benchmark practices, and future trends in the Internet-based marketing practices of governments and industry. This free online interactive journal is a way to keep in touch, to share information, and to establish business contacts (networking) for worldwide professionals that specialize in electronic commerce, governance and banking
solutions.

In JIBC you will find informed discussion of the latest internet-based banking and electronic trends and practices from around the world. Our priority is quality, not quantity. We want to maintain JIBC as a service that provides substantial information and an effective forum for your articles, your letters, your insights and ideas.

JIBC invites banking and electronic commerce professionals, academicians and publishers to submit important announcements, original articles, guest columns and significant feature presentations. We also welcome surveys, book reviews and letters to the Editor. Technical discussions in highly specialized areas of expertise will be kept to an absolute minimum.

JIBC is formally issued three to four times a year when an email summary of current articles is distributed to subscribers. The full text of current articles is posted on the JIBC Web site at
http://www.ARRAYdev.com/commerce/JIBC/current.asp.

The publication is complemented by the Compendium of Internet Banking and Commerce Initiatives at:
http://www.arraydev.com/frames/f-guest_comp.htm.
We invite readers to provide brief descriptions of products, books, and services that they think others will find interesting.

The Journal of Internet Banking and Commerce (JIBC) is provided as a service by ARRAY Development based in Ottawa, Canada. Views expressed are those of the authors and are not necessarily shared by ARRAY Development. Firms or individuals interested in sharing sponsorship of this project may contact array (at) ARRAYdev.com.

The JIBC Web Archive
http://www.arraydev.com/commerce/jibc/articles.htm contains all articles published to date.

You can reach the Editor-in-Chief Nikhil Agarwal with any questions or comments by email at:
nikhil.jibc (at) gmail.com

Publisher Nahum Goldmann is at:
Nahum.Goldmann (at) ARRAYdev.com.

Editorial Board

Publisher and Member of the Editorial Board: Nahum Goldmann

Chief Editor: Nikhil Agarwal

Founding Chief Editor Emeritus and Member of the Editorial Board: Gord Jenkins

Assistant Editor: Xin "Robert" Luo

Mailing List Managing Editor: Anne-Marie Jennings

Contributing Editors
U.K. Contributing Editor: David G.W.Birch
Australia Contributing Editor: Dale Pinto
Japan Contributing Editor: Carin Holroyd
Nordic Countries Contributing Editor: Minna Mattila
Legal Contributing Editor: Edwin Jacobs
Middle East Contributing Editor: Raed Awamleh
Africa Contributing Editor: Alemayehu Molla
France Contributing Editor: Jean-Michel Sahut

Please send any questions related to maintenance of this Web site to:
array (at) ARRAYdev.com

Information and subscription for JIBC mailing list is available via:
http://groups.yahoo.com/group/JIBC/

On Digital Cash-like Payment Systems

Just presented (slides) at ICETE2005 by Daniel Nagy: On Digital Cash-like Payment Systems:

Abstract. In present paper a novel approach to on-line payment is presented that tackles some issues of digital cash that have, in the author s opinion, contributed to the fact that despite the availability of the technology for more than a decade, it has not achieved even a fraction of the anticipated popularity. The basic assumptions and requirements for such a system are revisited, clear (economic) objectives are formulated and cryptographic techniques to achieve them are proposed.

Introduction. Chaum et al. begin their seminal paper (D. Chaum, 1988) with the observation that the use of credit cards is an act of faith on the part of all concerned, exposing all parties to fraud. Indeed, almost two decades later, the credit card business is still plagued by all these problems and credit card fraud has become a major obstacle to the normal development of electronic commerce, but digital cash-like payment systems similar to those proposed (and implemented) by D. Chaum have never become viable competitors, let alone replacements for credit cards or paper-based cash.

One of the reasons, in the author s opinion, is that payment systems based on similar schemes lack some key characteristics of paper-based cash, rendering them economically infeasible. Let us quickly enumerate the most important properties of cash:

1. "Money doesn't smell." Cash payments are -- potentially -- anonymous and untraceable by third parties (including the issuer).

2. Cash payments are final. After the fact, the paying party has no means to reverse the payment. We call this property of cash transactions irreversibility.

3. Cash payments are _peer-to-peer_. There is no distinction between merchants and customers; anyone can pay anyone. In particular, anybody can receive cash payments without contracts with third parties.

4. Cash allows for "acts of faith" or naive transactions. Those who are not familiar with all the antiforgery measures of a particular banknote or do not have the necessary equipment to verify them, can still transact with cash relying on the fact that what they do not verify is nonetheless verifiable in principle.

5. The amount of cash issued by the issuing authority is public information that can be verified through an auditing process.

The payment system proposed in (D. Chaum, 1988) focuses on the first characteristic while partially or totally lacking all the others. The same holds, to some extent, for all existing cash-like digital payment systems based on untraceable blind signatures (Brands, 1993a; Brands, 1993b; A. Lysyanskaya, 1998), rendering them unpractical.
...

[bulk of paper proposes a new system...]

Conclusion. The proposed digital payment system is more similar to cash than the existing digital payment solutions. It offers reasonable measures to protect the privacy of the users and to guarantee the transparency of the issuer s operations. With an appropriate business model, where the provider of the technical part of the issuing service is independent of the financial providers and serves more than one of the latter, the issuer has sufficient incentives not to exploit the vulnerability described in 4.3, even if the implementation of the cryptographic challenge allowed for it. This parallels the case of the issuing bank and the printing service responsible for printing the banknotes.

The author believes that an implementation of such a system would stand a better chance on the market than the existing alternatives, none of which has lived up to the expectations, precisely because it matches paper-based cash more closely in its most important properties.

Open-source implementations of the necessary software are being actively developed as parts of the ePoint project. For details, please see http://sf.net/projects/epoint

Blaming the Banks won't work

Bruce Schneier outlines some of the factors behind phishing and then tries to stick it on the banks. Sorry, won't work - the Banks are victims in this too, and what's more they are not in the direct loop.

Make Banks Responsible for Phishers

...
Push the responsibility -- all of it -- for identity theft onto the financial institutions, and phishing will go away. This fraud will go away not because people will suddenly get smart and quit responding to phishing e-mails, because California has new criminal penalties for phishing, or because ISPs will recognize and delete the e-mails. It will go away because the information a criminal can get from a phishing attack won't be enough for him to commit fraud -- because the companies won't stand for all those losses.

If there's one general precept of security policy that is universally true, it is that security works best when the entity that is in the best position to mitigate the risk is responsible for that risk. Making financial institutions responsible for losses due to phishing and identity theft is the only way to deal with the problem. And not just the direct financial losses -- they need to make it less painful to resolve identity theft issues, enabling people to truly clear their names and credit histories. Money to reimburse losses is cheap compared with the expense of redesigning their systems, but anything less won't work.

You can't push all of the responsibility onto the FIs. Here's why:

1. Phishing is an attack on the user primarily and only secondarily on the FI. Consider what happens: the phisher sends a request (by email) to the user to have her send her details to him (using her browser). The parts in parentheses are optional but key: phishing is an attack on the browser using email to deliver the phish. We can more or less change the email to chat or SMS for example, but it is harder to change the browser component.

What's constant about all those issues is that the banks aren't in that primary loop as yet. So even if they have all the responsibility they are strictly limited in how they tell the user to "not do that."

2. FIs aren't the only target of phishing. Amazon and eBay are both big targets. So any attempt to stick it to the banks is just going to shift the attention to all sorts of other areas. Expect Amazon and every other merchant to prefer not to have that happen.

3. If you want to stick it to anyone, go looking for where this came from. The banks picked up this security model from somewhere. Here's where: the browser security model that was built on a miscast threat analysis, the server security model that was subject to big company's agendas, and the client security model which is simply best described as "Insecurity by Microsoft." All of these elements are broken, in the security jargon.

If you want someone to blame for phishing in the wider sense, look to who pushed the tech (Microsoft, three times over. RSADSI, Verisign, Netscape for the browser security model. For server side, Sun, IBM, and thousands of security experts who said that as long as you buy our firewall you'll be OK. And don't forget whoever audited these systems and said they were secure. Yes, you four, or is it three... you know who I'm talking about.)

Ask this long list of beneficiaries how much liability *they* have for a breach. The answer may surprise: Nix, zip, nada, zilch. Zero in all currencies. So if you stick it to the banks, guess who's next on the list?

4. Taking a risk truism and extending it to a particular case is dangerous. It may be that security works best when those in the best position take on responsibility for those risks they can best mitigate. And it's clear that the banks are the larger party here and well capable of doing something to address phishing.

But if you put *all* the responsibility onto one party, not only do you have a measurement problem, you'll also have a moral hazard problem. Users will then shop and hook with gay abandon. How are banks supposed to keep up with attacks by both users and phishers? Turn off online banking is the only answer I can think of.

The Tipping Point - How Good Companies Go Bad and Executives Become Rogues

A new book by Sayles and Smith looking at governance from the angle of Corporate Executives being the bad guys is worth a look. It may do a good job of documenting the problems occuring in US business at the moment and the first chapter is online here:

To find their prescriptions one would presumably have to buy the book. I'm not sure I will as they are very keen to blame the executive, which isn't really going to help. Agency theory suggests that your employees do what you incentivise them to do, and executives are no different. Look instead at the incentives that have been created would be my prescription.

By way of example, on the mutual funds scandal (one that I'm at least passingly familiar with from the US Senate hearings) they write:

What Could Management Have Been Thinking? Here is an example of executives "shooting themselves in the foot," deception and cheating that comes back to whack the originator:

Numerous mutual funds destroyed their reputation by allowing a small number of investors to misuse the funds (by overnight trading and buying and selling at "stale" prices). Funds earned very modest extra management fees by granting these special privileges to hedge funds and a few "select" clients. Their corrupt trading and wrongful pricing cost the other 99% of the funds’ investors dearly. When the corrupt practices were revealed, some funds lost half of the investors’ money. In one case, the value of a fund family to its owners dropped half a billion dollars in a matter of weeks.

Yet as has been pointed out by the founder of Vanguard, John Bogle, in his testimony before the same Senate hearings the problems started when greedy investors forced mutual funds from percentage reward scales over to fixed reward scales. Bogle led Vanguard to be a dominating force in mutual funds and is to some extent viewed as the father of the post-war Mutual Funds industry; his words are worth reading:

March 21, 2004, less than two months from today, will mark the 80th anniversary of America’s first mutual fund. Organized in Boston, Massachusetts Investors Trust (MIT) was a Massachusetts trust managed by its own trustees, who held the power “in their absolute and uncontrolled discretion” to invest its assets. The trustees were to be compensated at “the current bank rate for trustees,” 6% of the investment income earned by the trust.

Our industry began, then, with the formation of a truly mutual mutual fund, one organized, operated and managed, not by a separate management company with its own commercial interests, but by its own trustees; compensated not on the basis of the trust’s principal, but, under traditional fiduciary standards, its income.

Has there been any suggestion that the funds industry go back to percentage rewards and thus encourage the managers to think of the investor?

Nope. Expect more problems then. And the emboldened question above is easily answered: Management was thinking of what you told them to think.

Security Software faces rising barriers

Signs abound that it is becoming more difficult to do basic security and stay clean oneself. An indictment for selling software was issued in the US, and this opens up the pandora's box of what is reasonable behaviour in writing and selling.

Can writing software be a crime? By Mark Rasch, SecurityFocus (MarkRasch at solutionary.com) Published Tuesday 4th October 2005 10:05 GMT

Can writing software be a crime? A recent indictment in San Diego, California indicates that the answer to that question may be yes. We all know that launching certain types of malicious code - viruses, worms, Trojans, even spyware or sending out spam - may violate the law. But on July 21, 2005 a federal grand jury in the Southern District of California indicted 25 year old Carlos Enrique Perez-Melara for writing, advertising and selling a computer program called "Loverspy," a key logging program designed to allow users to capture keystrokes of any computer onto which it is installed. The indictment raises a host of questions about the criminalization of code, and the rights of privacy for users of the Internet and computers in general.

We all might agree that what the defendent is doing is distasteful at some level, but the real danger here is that what is created as a precedent against key loggers will be used against other things. Check your local security software package list, and mark about half of them for badness at some level. I'd this is as so inevitable that any attention paid to the case itself ("we need to stop this!") is somewhere between ignorance and willful blindness.

On a similar front, recall the crypto regulations that US security authors struggle under. My view is that the US government's continuing cryptopogrom feeds eventually into the US weakness against cyber threats, so they've only themselves to blame. Which might be ok for them, but as software without crypto also effects the general strength of the Internet at large, it's yet another case of society at large v. USG. Poking around over on PRZ's xFone site I found yet another development that will hamper US security producers from securing themselves and us:

Downloading the Prototype

Since announcing this project at the Black Hat conference, a lot of people have been asking to download the prototype just to play with it, even though I warned them it was not a real product yet. In order to make it available for download, I must take care of a few details regarding export controls. After years of struggle in the 1990's, we finally prevailed in our efforts to get the US Government to drop the export controls in 2000. However, there are still some residual export controls in place, namely, to prevent the software from being exported to a few embargoed nations-- Cuba, Iran, Libya, North Korea, Sudan, and Syria. And there are now requirements to check customers against government watch lists as well, which is something that companies such as PGP have to comply with these days. I will have to have my server do these checks before allowing a download to proceed. It will take some time to work out the details on how to do this, and it's turning out to be more complicated than it first appeared.

(My emphasis.) Shipping security software now needs to check against a customer list as well? Especially one as bogus as the flying-while-arab list? Phil is well used to being at the bleeding edge of the crypto distribution business, so his commentary indicates that the situation exists, and he expects to be pursued on any bureaucratic fronts that might exist. Another sign of increasing cryptoparanoia:

The proposal by the Defense Department covers "deemed" exports. According to the Commerce Department, "An export of technology or source code (except encryption source code) is 'deemed' to take place when it is released to a foreign national within the United States."

The Pentagon wants to tighten restrictions on deemed exports to restrict the flow of technical knowledge to potential enemies.

A further issue that has given me much thought is the suggestion by some that security people should not break any laws in doing their work. I saw an article a few days back on Lynn's list (was lost now found), that described how the FBI cooperates with security workers who commit illegal or questionable acts in chasing bad guys, in this case extortionists in Russia (this para heavily rewritten now that I've found the article):

The N.H.T.C.U. has never explicitly credited Prolexic’s engineers with Maksakov’s arrest. “The identification of the offenders in this came about through a number of lines of inquiry,” Deats said. “Prolexic’s was one of them, but not the only one.” In retrospect, Lyon said, “The N.H.T.C.U. and the F.B.I. were kind of using us. The agents aren’t allowed to do an Nmap, a port scan”—techniques that he and Dayton Turner had used to find Ivan’s zombies. “It’s not illegal; it’s just a little intrusive. And then we had to yank the zombie software off a computer, and the F.B.I. turned a blind eye to that. They kind of said, ‘We can’t tell you to do that—we can’t even suggest it. But if that data were to come to us we wouldn’t complain.’ We could do things outside of their jurisdiction.” He added that although his company still maintained relationships with law-enforcement agencies, they had grown more cautious about accepting help.

What a contrast to the view that security workers should never commit a "federal offence" in doing their work.

I find the whole debate surrealistic as the laws that create these offences are so broad and sweeping that it is not clear to me that a security person can do any job without breaking some laws; or is this just another sign that most security people are more bureaucrats than thinkers? I recently observed a case where in order to find some security hardware, a techie ran a portscan on a local net and hard-crashed the very equipment he was looking for. In the ensuing hue and cry over the crashed equipment (I never heard if they ever recovered the poor stricken device...), the voice that was heard loudest was that "he shouldn't be doing that!" The voice that went almost unheard was that the equipment wasn't resiliant enough to do the job of securing the facility if it fell over when a mere port scan hit it.

Barriers are rising in the security business. Which is precisely the wrong thing to do; security is mostly a bottom-up activity, and making it difficult for the small players and the techies at the coalface will reduce overall security for all. The puzzling thing is why other people do not see that; why we have to go through the pain of Sarbanes-Oxley, expensive CA models, suits against small software manufacturers, putting software tool-makers and crypto protocol designers in jail and the like in order to discover that inflexible rules and blind bureaucracy have only a limited place to play in security.

Addendum: Security consultant convicted for ... wait for it: doing due diligence on a charity site in case it was a scam!

Extra Financial Cryptographic Engineering

Patrick announces his Loom system, which basically (AFAICS) allows slicing and dicing amounts into URLs that are distinguished by a SHA1 hash. Each piece of value can be placed into a new location with a new SHA1 hash, and as long as the SHA1 hash is kept secret, so is the dosh. (Also discussed on Venkat's blog.)

This bears comparison to epointsystem.org's ePoints which employ a similer slicing and dicing method. This system is heavily crypto-oriented but by repute employs a simple server that only offers two primitives: split, and combine.

Also, the use of SHA1 numbers as essentially big random numbers is what I use in my BRN extension to Ricardo, which is designed to do all the infrastructure behind blinded token money, without the blinding. (Serious students of FC will know that the blinding is about 2000 lines of code, and the rest is about two orders of magnitude larger, depending... so BRN creates an independent break between the precise blinding formula and the code that deals the tokens.)

What then is perhaps more interesting to the financial cryptographer is not the mechanism but the metaphor. By describing the BRN as a "location" in cyberspace, and the transfer as a placing of gold in a secret place, Patrick seems to have inspired his nearby supporters more than any description of crypto blah blah ever could.

There appears to be a new generation of hackers coming forth with money systems. I suspect this is because of the rise of p2p systems, which bring with them horrific problems in economic coordination. To my knowledge, only MojoNet (now MNET) addressed these challenges seriously with techniques known here but that story remains undocumented in FC annals (*hint*, *hint* !!!).

Meanwhile, in the Community currency field, there are now several systems offering basic accounting mechanisms (Cyclos, CCLite, MRS). These have a much lower security threshold, befitting their community heritage. Although some would argue this is mistake as community currencies often collapse at the point of success (as measured by being valuable enough to steal), I don't see it so dogmatically; like all communities, the CC world has to experiment, win a few and lose a few, in order to find out which of their assumptions were right and which wrong.

So my question is whether we now have sufficient FC activity to run another EFCE? Have the doldrums of FC passed, and is it time to make the pilgrimage to the hallowed halls of the Signet Library, or do we need another E-First City in Europe?