Financial Cryptography

Paymer Anatomy - anyone an issuer

Editor's note: Daniel Nagy translates an article on Paymer by N. Senchenko. This system is related to WebMoney, and emulates the "anyone can be an issuer" model.

Written by Nikita Senchenko in Russian
("Анатомия Paymer" at http://owebmoney.ru/paymer.shtml),
translated into English by Daniel A. Nagy for educational purposes, without permission.

Contents

1. What is Paymer and how do they serve it for lunch
2. More about agents
3. We are issuinig e-currency agent cheques
4. Operations with cheques
5. WM-cards are also Paymer cheques
6. Additional services
7. Business at the speed of Paymer

Why "anatomy"? Why the choice of such a strange title for an article about the Paymer service? The reason is that all users of WebMoney already know about its existence. They know or suspect what functions it is supposed to fullfill. However, as it turns out, Paymer is a subtle instrument, not only having its own philosophy (like everything else within the WebMoney system), but also a whole spectrum of nuances and details, which remain out of sight for superficial observers.

1. What is Paymer and how do they serve it for lunch

Any one of you, dear readers, is able to issue your own payment promises using Paymer. In other words, digital money emission is within anyone's reach. What for? This is a separate question, which we will illuminate in the last part of this article. For now, just imagine that youo want to create your own mini-paymen system. Or raise capital, for example.

How is it going to happen? You are issuing digital cheques -- payment requisites of some sort. Each cheque has its own unique number and code, the number of digits in which are determined by the issuer. You can back your electronic cheques by digital currencies such has WebMoney or e-gold or by US dollars on a bank account. You can also choose not to back them. Paymer records your promises and accepts backing deposits (if they exist). The accounting of your promises, the safekeeping of your backing assets and the redemption of the promises by handing out these assets is done by so-called Paymer Agents, of which there are currently three in our system. We will talk about them a bit later. Each cheque has a nominal value, which is determined by the issuer in the process of emission. The nominal value of the cheque is the amount of money, goods or services that one can receive in exchange for it.

So, the cheques have been issued, their value is backed either by reserved assets or simply the promise of the issuer. From this moment on, any holder of the cheque (in other words, one who knows both its number and its code) can return it to the issuer and receive the valuables that are due to him: WebMoney, e-gold or those goods/services, which the issuer promised to hand over/render to the bearers of his cheques. This is called redemption of cheques; in essence the exchange of promises for backing.

The requisites of cheques can be handed over multiple times from one person to another, using any means of communication: e-mail, fax, telephone, ICQ, on a piece of paper from hand to hand -- that is, as you please, over the Net or outside of it. By telling the number and the code of the cheque, you are handing it over to the new holder. Unlike banks' cheques, Paymer cheques do not have any fixed physical embodyment. The requisites can be stored in any way in any place -- on paper, in a file or in the memory of the holder.

Cheques constitute value, as they imply benefits to the holders. Thus, they can be used as payment. In order to facilitate the acceptance of cheques over the Internet for commercial entities in exchange for their goods or services, Payment provides them with a special interface Paymer Merchant [link: https://www.paymer.com/merchant/default.aspx?lang=en-US], using which the process can be automated.

Paymer lets the holders verify the validity of cheques and their nominal value using the number of the cheque or the number and theh code. This lets sellers avoid accepting "counterfeit" cheques for their goods. Additionally, cheques can be split into several smaller ones with the same summary nominal value. One can merge several smaller cheques of the same issue into one with the nominal value equal to their summary nominal value. One can exchange the requisits, for example, when accepting cheques thereby becoming the new exclusive owner, as the new requisits will be known to you alone.

The emission and the servicing of the cheques is paid for by the issuer; Paymer takes 1% of the sum of the emission. However, there is no comission whatsoever for the verification, splitting, merging and exchange of requisits. Therefore, cheques can be handed over from one holder to the next multiple times, verified, split, etc. without losing their nominal value.

Paymer, in essence, is that same "digital cash" in its purest form, about which its father and chief ideologue, David Chaum has dreamt. Quite possibly, to this date it is the only one of the practically functioning automata realizing almost all functions of digital cash. Its characteristic properties are as follows:

* Unencumbered access to "emission button" for anyone willing to issue.

* Innovativeness. Paymer cheques are a new generation of money from a financial point of view.

* Protection. It is not feasible to counterfeit cheques or quess their codes.

* Anonymity of digital cheques (a characteristic property of cash).

* Instantaneous clearing. Redeeming a cheque or paying with it takes mere seconds.

* Irreversible payment and clearing.

* Free transactions for users (as opposed to cashless transactions, for example).

* Workable in any communication environment (online or offline). Paymer cheques can be used for payment within the Internet and outside of it.

* Openness and accessibility for each person, without any limitations. In order to use cheques, there is no need to show your ID, to register or to open an account anywhere, etc.

In this article, we will tell you in detail how to issue your own cheques, how to transact with others' cheques and what additional services exist in the Paymer system. Finally, we will tell how is Paymer useful for businesspeople and other enterprising comrades. But first, we describe Paymer Agents in detail.

GP4.3 - Growth and Fraud - Case #3 - Phishing

We would be remiss if we didn't also measure the theory of GP (GP1, GP2, GP3) against that old hobby horse, phishing.

When ecommerce burst on the scene as an adjunct to browsing, it pretty quickly emerged as "taking credit card orders over the net." This took off fairly easily as the FORM in HTML allowed ready collection of these data, and many existing credit card merchants simply shipped as if the new orders were MOTO - mail-order/telephone-order ones.

There were a few niggles around though. Security was thought to be a bit loose, as all these credit cards were flashing around on the open net. Compare this to the existing usage where credit cards were handed over to waiters and waitresses for copying back at the counter, or where orders taken over telephone resulted in goods generally being shipped to billing addresses, and it was either scary or not scary, depending on how closely you really understood the cycle. Nobody ever showed that credit cards were being snooped on the net, although telnet passwords were being scarfed up in large numbers (a threat that led separately to the development of hyper-successful SSH) so we can see here the seeds of a GP-problem.

Obviously a little crypto would have helped, and SSL in its first version ("v1") was duly floated to the crypto community sometime in 1994. All things being equal, this would have been acceptable to deal with the potential of fraud, but not all things were equal. In fact, so many things were not equal that this minor case has become what amounts to a major history lesson.

In order to understand SSL it is necessary then to digress and understand the environment of the times. I present this as forces, a sort of institutional approach from economics (c.f., Michael Porter's Five Forces analysis). Here's the list of forces that were pushing around in 1994:

1. Netscape's stellar growth, capped by the dotcom fairy story of their IPO, had put Netscape firmly in the driver's seat of ecommerce. Unfortunately, they couldn't sell their flagship product because they had set a price tag of $50 for the browser but nicely left it free for personal use or somesuch. (As events were to show, Microsoft simply boxed them in by shipping their browser for free. Only Microsoft could afford to win that battle.) Force: Netscape needed big friends, big products, big revenues and something to spend its IPO cash on. Result: the pressure was on the ecommerce division to save Netscape's bacon.
2. Porn! Insiders report that fully half of early SSL use was by adult sites which needed to reduce the risks of delivering the product to the wrong party. Paying for certs or secured servers was chicken feed compared to being shown to deliver to the wrong "customer." However, what they didn't want was the load that ground their servers into the dust - megabyte images being far different animals to kilobyte credit card transfers. Hence, cue in some early hard engineering questions: load balancing, page caching, proxy servers, page pre-loading from customers who's interest in security was unusual and unpredicted.
3. Fear and Loathing and the Payments Industry. The credit card companies were scared witless by the arisal of new payment companies like First Virtual (a sort of forerunner to PayPal) and before them, DigiCash, and lobbied to anyone who would listen to get some 'protection' for ecommerce. One idea that they liked was the certificate, that some had mused on as being the "missing link" in the security of SSL. Better yet, those that controlled lots of merchants (MCI and AT&T in this case) could envisage delivering the certificates to the merchants, and leaving the outsiders to fend for themselves; in other words, a classic barrier to entry. But it also appealed to Netscape because pushing certificates not only boosted sales of their secure server, it maintained their control over the protocol and found them some great new friends. Briefly.
4. The crypto wars! The protagonists were the United States government in the person of Loius Freeh on the one hand and the network libertarians on the other. Although the USG was prepared to compromise on weak crypto which would have been fine for ecommerce, this wasn't good enough for the cypherpunks. Nothing short of complete freedom to implement super-strong crypto against any threat for any application was anything short of acceptable. As a side-effect to their religious war against "national technical means," any merchant who implemented anything short of 100% absolutely secure no risk guaranteed and certified crypto was hit by the indiscriminate pogrom of the free crypto crowd; the result of this "all or nothing" security approach was more often nothing than all.
5. Hence another short footnote in the history of ecommerce arrived in the form of SSL being required to run at full crypto strength against the man who wasn't in the middle and against Eve who wasn't listening. Unfortunately, the machines of the time were not strong enough to push through sessions fast enough. Inevitably, as nothing short of full strength was adequate, and certs and triple DES were dimming the lights of ecommerceville by about 80-90%, the security space again split into SSL-mode for collecting credit cards and non-SSL mode for the rest. This made security itself inordinately difficult, as in classical military terms, there was now a gap between security models through which to attack, and security itself was now firewalled off from the main shopping process.
6. The US Department of Defense's "COTS" dream. In the 90s, the DoD procurement monolith took on a new mission. In brief, they decided to offset their R&D costs onto general society, and move to purchasing commercial off-the-shelf equipment, albeit directed towards government needs. The unwritten offer given to suppliers like Netscape was to sell DoD standard COTS software, split off portions of the revenue stream at appropriate points to fund government-specific development, and then sell DoD "COTS" with additional new "GOTS" features. Recalling that the US government was the single largest source of Netscape revenues, this was no small offer!
7. The NSA's PKI dream. The American spook community decided to bet the farm on PKI as a way to slip into place a crypto regime dependent on a pre-rigged infrastructure. In perhaps following the COTS dream of their peers over at DoD, NSA pushed procurement into the direction of requiring and acquiring large PKI structures and they pushed certain suppliers - you know who I mean - into valuable PKI nodes and roles so as to make sure the(ir) infrastructure was in place. The theory was that this would then explode into life, we'd all "get PKI" religiously and then find ourselves hooked.
8. The DoJ's non-repudiation dream. Some legal people (and not a few techies) believed that a digital signature was in some ways analogous to a human signature. They reasoned that if they could get the non-repudiation aspects slipped into the Internet, they'd be able to control and prosecute the criminals to come. This meant laws, structure, authorities, and above all, control.
9. Identity Solves Every Security Problem. Once people realised that the certificate was like an identity, business plans bloomed like a thousand flowers based on the right to sell these identities back to their owners. Billion dollar cash flows based on the ability to sell a $100 cert to 100 million Americans floated around Wall Street. We say in (real) warfare that no plan of battle survives the first shot, etc etc, and in relatively short order, the certificate authority space was turned upside down by competitors diving in and demanding access. Netscape lost control of the space, and made all CAs equivalent so it wasn't seen to favour anyone. Inevitably, this reduced the security of the system to where certificates acquired popup-avoidance status, because there was no differentiation and certificates became a bottom-feeding business.
10. The patent wars! RSADSI and Cylink were engaged in battle over public key crypto standards. Also sparring was NIST with DSA and that Canadian company with EC. Ultimately won by RSA, this also saw a whole bunch of weird and wonderful licensing agreements forced on customers. No points for guessing what features were withheld in the licences offered to which customers!

fig 8. the Battle for Ecommerce

Heady stuff for conspiracy theorists! Now, the beauty of the above forces is that they don't all have to be true even though I believe them to be fair if one-sided representations. Sufficient of these forces still sum to a statistically relevant picture. We can reach the conclusions we need, so let's go there right now.

In the face of all these pressures, Netscape found itself adding certificate-based protection with a new upgraded form of SSL called v2. (Even SSL v2 was a little loose, so they quickly hired an external consultant to come in and do v3, although that form of SSL still hasn't properly deployed in your default secure sessions as yet, so it must have been OK to secure ecommerce with v2!)

The end result was the balkanisation of the Internet's security space. Various large and famous companies carved up the space amongst them and created the CA structure that we know today. Certificates went from full-PKI-wholesome-trust mode to popup-avoidance certificate manufacturing mode in the blink of a venture capitalist's eye. Verisign made out like bandits on the stock market. The USG chipped in with some worry about enemies of the state, and forced a mishmash of cipher suites and options and above all, the certificates that a dozen agencies put so much store by. The cypherpunks added their "all or nothing" politics to the mix and created the "all and nothing" nightmare. Netscape themselves were soon embroiled in a bid for survival as Microsoft defeated them on their own ground and went on to all but own ecommerce space. And out in ecommerceville itself, they ruined the security by breaking the model down the center.

So what was all that about, in summary form? SSL v1 was put in place for a predicted, but so far unvalidated threat. The lack of focus on a clear validated threat left the space vulnerable to capture - and SSL v2 duly became the battle ground of many, none of whom had much concern about security of the browser users' sessions but were quite willing to use it as a cassus belli in the war against someone or other.

The question that I often pondered on was why certificates were added to SSL. From a technical pov, they are too expensive for the mission, too heavy. Now that I've investigated the forces and listed them out, I can see the error of my ways - obviously this had nothing to do with security, and the question is best off couched as "how could Netscape have possibly avoided putting a certificate-based PKI into the security protocol?" And that's the conclusion we need: there is no way they could have avoided it. The forces were just too strong.

Back to security. A little-known small-time fraud turned up with the name of phishing. Originally, this was a very crude and old claims scam on AOL, where the A.O.Lusers were sold some bogus product and had their credit cards re-used elsewhere. By the time AOL had been all phished out, the model was well understood and well tested, so it was natural to start somewhere else.

fig 9. the Battle of Online Banking

Fast forward to the new millenium, and that somewhere else was online payment systems and banks. I.e., where the money is. The first known phishing attack on a financial operator was June 2001 against e-gold. Delivered using spam techniques, users were tricked into entering their passwords into near-enough websites. And it was here that the browser security model was first challenged and failed within moments. The one thing that the certificate was supposed to do was tell the user that they were on the right site, plus or minus some details. But by the time the attackers arrived, the security model had been so abused by other agendas that it wasn't capable of putting up a fight against a real criminal.

Worse, the huge infrastructure that had been built up - crypto libraries, protocol libraries, browser manufacturers, web server manufacturers, standards committees, certificate authorities, auditors, audit standards models, digital signature laws, PKI rollouts and a cast of a thousand onlookers - proved itself simply incapable of accepting the threat for what it was - a successful attack on the browser's security model.

We're still there - working with a security model that was envisaged as a nice quick and dirty fix for credit cards in the first instance, in the second instance squabbled over by a bunch of disparate interests, and in the third instance broken like a child's toy sword the day after Christmas when the first bully turned up and wacked it with a stick. Worse, in the fourth instance, phishing has invested its proceeds and diversified into the trojan / malware and data breach spaces so any fixes delivered are not going to stem the tide of red ink losses.

It might be hard to tell when GP was reached in ecommerce. But the real underlying conclusion to draw from this case is this: do not put the security model in place too early! In the case of phishing by the time the model was needed, it was incapable of protecting and of adjusting against the threat. The cost to this impatience can be measured by integrating the red curve in fig. 9 - it's all the area under the curve.

This case study concludes the story of Growth and Fraud:

• GP1 - Meet at the Grigg Point
• GP2 - Instructing Security at GP
• GP3 - How to Book a Table
• GP4: Case Studies:
  • #1: Mutual Funds
  • #2: e-gold
  • #3: Phishing

2006 - The Year of the Bull

2005 was when the Snail lost its identity. What is to come in 2006? Prediction always being a fool's game compared to the wiser trick of waiting until it happens and then claiming credit, here's a list of strategic plays for the year to come.

1. Government will charge into cybersecurity. So far, the notion of government involvement has been muted, as there have been enough voices pointing out that while the private sector may not have a good idea, it certainly has a less bad idea than the government. Cybersecurity departments have been duly and thankfully restricted.

I suspect in 2006, the Bull will begin to Roar through our China Shop. Calls seem to be escalating in all areas. This is a reflection of many factors:

• the failure of private sector security to dampen the data breaches, phishing, viruses, malware, etc...
• countries have woken up to the fact that at the end of the day, the USA controls enough of the core to have its way, and as a policy won't give that up. This annoys some and worries others, so expect on Internet governance to be well stoked, along with a dozen other global copycats.
• especially, we live in the interesting times of White House insensitivity to the law, logic and history. Those that read America better than I point out that the reason it's getting worse is that ... the Democrats are just as bad as the Republicans, which means that the opposition is unlikely to care too much about opposing.
• people -- that's users to you and me -- have shifted in their perceptions from the Internet as a benign but fun place to a dangerous wild wild west.
• all sorts of academics and legal folks from outside the field are pointing out how we solve these things elsewhere, and these methods all require laws, agencies, police, training, budgets, ...

For all that, calls to send in the cavalry will increase. Oh course, we know that we the user will be more insecure and poorer as a result of the Bull market for cybersecurity. What we don't know is how much worse it will be, and I daren't predict that :)

2. Anti-virus manufacturers will have a bad year. Not so much in profits, which might perversely go up, but in terms of their ability to make a difference. Kapersky of eponymously named company points out that it is getting much harder. We know the crooks are getting much more focussed due to their revenues cycle. Also of note is that Microsoft has entered the game of selling you (not me) protection for their OS breaches - bringing with it a whole messy smelly pile of conflicts which will make it even harder for the "independent" anti-virus providers.

3. Firefox will continue to grow. My guess is that it will get past 15%, probably to 20%. Microsoft won't fight back seriously, they have other battles, even though this would leave them at say 70-75% (Safari, Opera, Konqueror take 5-10%).

3.b But sometime by the end of the 2006, Firefox will be seriously bloodied as it runs into security attacks targetted directly at it. What does this mean? Firefox crosses GP sometime soon, in terms of financial fraud. The only ones this will surprise will be Mozilla. Most observers with a clue have realised that Firefox has enjoyed its reputation due to reasonably sound factors, but these factors are just basic engineering issues like a re-write and solid coding practices, not those high level practices that distinguish the security projects (BSD, PGP, etc). This probably won't hold back Firefox's growth, as their mission to give browser users a choice remains aligned with our needs, and it remains tremendously useful even if the security rep takes a knock. So be it. But by the end of the year, expect some hand-wringing and moaning and more than usually confusing comments from Mozo Central's revolving security spokesman of the day.

3.c Also expect Mozilla to start talking about the next step in commercialisation -- the IPO. The discipline of the public company will start to look very attractive to those tasked with sorting out intractable internal conflicts inherited from the touchy-feely open source world.

4. In payments, the number of non-bank payment systems looks like it will increase dramatically. Gift card systems are exploding as companies discover that they take the money up front so they get financing at a better rate than the bank offers -- Free! -- and the wastage rate is better than any retail margin seen outside monopoly products. It doesn't take much for these to be integrated into an online account system - after all, what is a gift card but a psuedonymous account identifier. Then, once the alignment takes place, adding user-to-user payments is just a switch to throw one the weekend when your bank isn't looking. Maybe 2006 will be the year of the indie payment system?

5. No predictions for the gold sector. Even though the gold unit is skyrocketing and will continue to do that, there are continuing woes facing the issuers which they haven't sorted out long term. The bounty of people rushing up the gold price curve is offset by the cowboy image of the gold issuers.

6. Mac OSX will get to 7 or 8% of the market, maybe 10% if the intel change goes well. Given the aggressiveness of the PC world, that can be considered to be a stunning result. The BSDs and the Linuxes still won't penetrate the desktop as much as we'd like, but it will become reasonable to talk about a Microsoft-free environment. 6.b I might finally acquire a Mac. Not because I want to -- I hate the UI, the keyboards suck, and they haven't got the reliability of the old thinkpad workhorses -- but for reasons too irrelevent and arcane to go into today.

7. Google will grow and prosper and survive. This might be an odd thing to predict, but the thing with Google is that it is a bit like a Netscape with an endless supply of revenue. As one insider put it to me recently, it was a boon to the world when Netscape was cleaned out as that meant we could get on with business. Unfortunately, google has lots of revenue, so the mad cats will be financed and the projects just go on and on and on... I expect by the end of the year, though, we'll see adverts for cat herders as long term insiders realise that some chaos is good but most is just chaos.

8. Microsoft will not succeed in sorting out its security mess and will continue to lose market share. Let's get this in perspective - it will probably drop down from around 90% to around 80% allround. Nothing worth crying over, and indeed, it will give the company some sorely lacking focus. Some time around the end of 2006, some soul searching will result in serious investigation of other operating systems. So, who wants to bet on what OS Microsoft will pick up? Here's my anti-picks: it won't be Unix, and it won't be Java (which in its J2EE form is more or less a server OS, and then there's Swing...).

9. Macs won't be seriously hit by security issues, but will suffer a few minor embarrassments which will be trumped up in the press. The Mac application space will come under attack. On the other hand, Apple doesn't look ready for a security war, and will muff it, regardless. Welcome to the Hotel California!

10. I've predicted these before and not seen them so I'll predict them again: class action suites on security against suppliers. the perfect phish - one that includes the SSL+certs within, rather than goes around Also look for a real-time phish to defeat the two-factor authentication tools that the banks are rushing out now. In the security world, it is important to avoid the disclosure of being completely and utterly wrong; these above predictions are my way of avoiding that terrible fate. Neat, huh? On the other hand, I probably needn't have bothered. The security discipline is missing, presumed dead. Experts have hummed and hahed and shuffled feet over the mess for so long that it is now at the point where when anyone hears a so-called 'security expert' talk, they mentally discount most of what is said.

Try it! By the end of the year, I predict open derision of anyone who pretends to be a security professional. Dilbert, anyone?

11. By the end of 2006, the secure browsing system that we know and love to hate -- SSL, $30 certificates, popup madness and that sodding padlock -- will have been bypassed. By the good guys, I mean -- it's been bypassed by the bad guys for several years, already. It will no longer be part of the security model for browsing. What will become the security model will depend on what sector is doing the securing: banks will have their two-factor tokens because they were told to, smart users (and their mothers) will have their Trustbars and Petnames, smart companies will customise the above plugins, and even smarter operators will send out confirmations by email and by cell/mob

That's for the lightweight stuff. For the heavyweight stuff, look for alternate plaforms, like....

12. We'll see the much more use of two-factor authentication by cellular or mobile phone. I.e., SMS messages, or downloadable programs on phones to calculate the challenge/response. Why? Everyone's got a phone and they are a separate means of communication. (Why it's taking so long bothers me - is there something I'm missing?)

13. Unluckily for authors, artists, and blog writers, nothing much will change in DRM. Music sellers will sue file swappers, concentrating on the demographic of 12-17. File swappers will continue to swap, and learn how much better their own music is. The techniques of both sides will advance and both will be widely copied and nobody will make any money. My bulls here are courtesy images.google.com, and if I made any money from this blog, I'd be one sorry matador. Some time around 2007, all IP owners will realise they cannot win this war, and all swappers will get religious about DRM. A papal bull will be issued and a property love-in will ensue. Nobody will fight over the rights for the book, musical, philosophical or TV. By then we will have worked out the killer rights paradigm - convenience.

Hopefully we will be invited back for the love-in. Merry Xmas, Happy New Year, Season's Greetings, and may your packets move at Kelvin speed. I wish you a happy Year of the Bull.

---

Some other predictions:

• Matasano

Early History of SSL - guess who invented the colour bar?

There's been a bit of chat about how Microsoft picked up Firefox picked up the yellow HTTPS indicator and changed the colour. Some people have pointed out that Firefox invented it, but it turns out to have been present in the earliest versions. This 1996 document found by Frank Hecker reveals:

You can also verify the security of a document by examining the security icon in the bottom-left corner of the Netscape Navigator window and the colorbar across the top of the content area. The icon consists of a doorkey on a blue background to show secure documents and a broken doorkey on a gray background to show insecure documents. The colorbar across the top of the content area is blue for secure and gray for insecure.

(My emphasis.) I've often pointed out that the Netscape browser reputedly started out with the CA's name printed on the chrome. It must have lost the colour bar too! So perhaps we should just stop whining and download and get going the original Netscape beta and see what it does?

Brickbats and Plaudits

Occasionally people actually write in to say how they love or hate the blog or the various other rants! Rather than lose these, I'll publish them here in most recent order:

From Chat, Hasan says:

Here's an unexpected comment from Frank Trotter:

The post on Diamond Governance sparked some contoversy! I'll dogmatically work up an unprejudiced reply :)

Christmas Day - the first day of this entry - is probably a good day to post good news:

This is a dynamic entry.

A VPN for the common man!

In the rumbling debate about VPNs and how they should be done, here's a new entrant as found in an interview with Damien Miller (spotted on Matasano):

The upcoming OpenSSH version 4.3 will add support for tunneling. What type of uses is this feature suited for?

Damien Miller: Reyk and Markus' new tunneling support allows you to make a real VPN using OpenSSH without the need for any additional software. This goes well beyond the TCP port forwarding that we have supported for years - each end of a ssh connection that uses the new tunnel support gets a tun(4) interface which can pass packets between them. This is similar to the type of VPN supported by OpenVPN or other SSL-VPN systems, only it runs over SSH. It is therefore really easy to set up and automatically inherit the ability to use all of the authentication schemes supported by SSH (password, public key, Kerberos, etc.)

The tunnel interfaces that form the endpoints of the tunnel can be configured as either a layer-3 or a layer-2 link. In layer-3 mode you can configure the tun(4) interfaces with IP or IPv6 addresses and route packets over them like any other interface - you could even run a dynamic routing protocol like OSPF over them if you were so inclined. In layer-2 mode, you can make them part of a bridge(4) group to bridge raw ethernet frames between the two ends.

A practical use of this might be securely linking back to your home network while connected to an untrusted wireless net, being able to send and receive ICMP pings and to use UDP based services like DNS.

Like any VPN system that uses a reliable transport like TCP, an OpenSSH's tunnel can alter packet delivery dynamics (e.g. a dropped transport packet will stall all tunnelled traffic), so it probably isn't so good for things like VOIP over a lossy network (use IPsec for that), but it is still very useful for most other things.

The problem with VPNs has been partly key management nightmares (a.k.a x.509) and partly install and configuration nightmares. For those reasons, VPNs only really made it into areas where corporates could pay people to get them up and going.

Adding it to SSH solves both those issues and promises to bring about VPNs for the common Unix machine (including all Macs now).

Crazy Prediction Time :- within a year of this being released and available, SSH will be the most popular VPN. Within two years, we'll even forget that VPN stood for anything other than a way in which we use SSH.

Diamond governance

In news of a big scandal in the diamond world, the rating agency was found to be inflating valuations prior to sale. I find this a good example of what we mean when relying on "trusted third parties" means we are more vulnerable:

The Gemological Institute of America, which grades diamonds for independent dealers and big retailers, fired four employees and shuffled top management after an internal investigation of its policies, the Wall Street Journal said.

The institute's internal probe started after a jewelry dealer who was also the former head of retail operations at luxury jeweler Harry Winston claimed that the institute and two diamond dealers conspired to inflate the grade of two diamonds that he sold to members of the Saudi royal family.

The diamonds, which were sold for $15 million, were taken to an independent appraiser and found to have a lower grade that made them worth much less, the paper said.

The dealer alleged that lab workers took bribes to inflate the quality of diamonds in grading reports, according to the news report, which cited people familiar with the situation.

Bribes, Saudi royals, diamonds, it's got it all! Only problem is, this is an old plot.

When we create an agency of such power, we all become vulnerable to it (a point credited I believe to Mark Miller to many -- see comments). That which we call the Trusted Third Party is no more than a hack that leaves us vulnerable to the TP in exchange for maybe being secure against something else; whether that is a good exchange is highly dependent on the circumstances (see for e.g., Nick on TTPs).

In that case, when we say "trust" we mean you have no choice but to trust this arrangement - in other words you are highly vulnerable. The business about trust being nice and warm and consumer-oriented is simply marketing designed to lull us to sleep while others sleep not. (Auditors, CAs, Issuers, take note.)

We need to guard the guardians and watch the watchers as if they are untrustworthy. Because, frankly, if we do not, they will be. Oh, and for those who think it can't happen to them because they have structured it "properly" please take note:

"Fees depend on a diamond's size; grading a one-carat round diamond costs about $100. In 2004, the institute, a nonprofit, had income of $104 million, the paper said.

Non-profits are likely to have poorer governance as they have a better ability to hide information from stake holders. Why? They don't have shareholders, they only have employees. That means the guardians and watchers cannot be guarded and cannot be watched. Who'd trust a nonprofit voluntarily?

GP3 - Growth and Fraud - How to Book a Table

Previously, we talked about the Growth and Fraud's GP which is the place where growth kicks off into a self-sustained value growth machine (Parts 1,2) . Then I made some remarks on how to instruct security strategy, which lead to a rather keen need to know where this point is. That's because by the time we hit GP we really want to protect it, but not a moment earlier.

Where is GP? Obviously in a different place for every story. But there are some patterns. Assuming again that we are talking about a value system, we can predict the following indicators of GP by looking for the arisal of these factors:

• An independant exchange network. That is, other companies without any especial permission from the lead company engaging in arbitrage and value exchange.


• Delivered independant super-services such as plugins to popular clients. Think Eclipse, Skype, Firefox here.


• New business models and/or activities by third parties that were not originally envisaged by the Founders. Note here that as a founder, you don't need to admit to the world that you didn't envisage a new model arising, but you do need to admit it to yourself.


• Participants that founders don't know find other participants that founders don't know and ... trade! What this means is that no longer is the activity dependent on you, as founder, and your core network. You've exhausted your contacts, you've beaten up your relations, blackmailed your business partners and extorted your church. And it's still growing, with people you've never met and can't quite divine how they came to be in the system.
  
• Fraud!

Noticeable among those is the absence of journalism, blog posts, coolness ratings, cute crypto features, show awards, recommendations by experts, endorsements, government regulation or permissions, what your mate thinks, etc etc. They all suck, in large part because they can all be bought, and are often negative indicators of GP, not positive ones. On the other hand what is present in all the above is:

• Someone else's capital has been independently invested in the subsystem's potential,
• that capital has delivered separate and persistent value exchanges,
• and done so many times over to the extent that it is not an aberation, but more an economy.

These things cannot be bought. The importance is to see many independent events that indicate independent traders are putting their money where their mouths are, enough times such that it would take a major mistake on the part of original founders to break it now.

Thinking about fraudsters as investors might be confusing, but that's what they are at least as far as this analysis goes. Fraudsters invest their time and effort in a fraud, and some frauds pay off whereas others do not. Fraud is just a business where the more positive is the supply side, the more negative is the demand side.

Fraud is also a very good indicator of success. One reason for this is that fraud has a very short cycle of gratification. Unlike honest biz, most small frauds either pay off quickly or more generally not at all, so if you see a marked and noticeable incidence of fraud, that means the frauds are paying off. Thieves are very economically tuned, they move on to the next if this one isn't working, and stay and play if it is working.

Now that we've got a view that we can pick GP, what do we do about it? The previous section talked at length about security, so if it hasn't twigged by now, we start by ramping up our anti-fraud efforts. As we've included fraud on the list above, we are hopefully staring at the first efforts of fraudsters, so we should actually have some good, market driven data on what fraud matters and what is just crypto blah blah security hype.

The next thing we have to worry about is ... the whole business. Before GP we had not proven the model. After GP, we have, and this apocalypse changes our entire strategy. Before GP we were doing everything possible to push the model, but we had no real reason to keep it. After GP we switch to doing everything possible to preserve the business and user base without overly slowing down the model.

The switch is subtle, but it has quite dramatic connotations. Firstly, we now know where to spend money. So GP is the time to go for the big Venture Capital round! In fact, I'd say that the question to be asked at the VC meeting is "how do you know you've reached GP?" Anything before GP is seed money, as it is simply experimental funding to try out different ideas and different models.

Then, when we get the money, we know where to spend it: supporting the model. Extending it, expanding it, adding to it, and very important for those security guys that are still with us: protecting it.

Finally, this takes a very different mindset. This means a new team - in general, from a Human Resources perspective, most entrepreneurs don't cross over well from the mad chaos of pre-GP to the mindless protectionism of post-GP.

It's probably not wise to announce GP on your own. That might be tempting fate as those deep inside their own business have a tendency to migrate their beliefs to suit their desires, and I don't want to be blamed for them getting it wrong. At some point the market - your strong and critical fans especially - will agree one day that GP is passed. At that point these same critical fans will be strongly looking for signs of management team change, security overhaul, and serious understanding of the revenue and finance model.

They'll also be looking for people who have a bit more of a wider view than your average security geek, accountant or salesman with a great idea! And it is breadth to which we turn in our final installment (of 3 parts), in an attempt to show how relevant this concept is.

This is Part 3 of Growth and Fraud:

• GP1 - Meet at the Grigg Point
• GP2 - Instructing Security at GP
• GP3 - How to Book a Table
• GP4: Case Studies:
  • #1: Mutual Funds
  • #2: e-gold
  • #1: Phishing

OpenPGP supports any Trust Model that you desire!

[editorial note - this is a guest post by Ed Gerck]

James A. Donald wrote:
>     --
> From:               Werner Koch 
>
>> You need to clarify the trust model.  The OpenPGP
>> standard does not define any trust model at all.  The
>> standard merely defines fatures useful to implement a
>> trust model.
>
>
> "Clarifying the trust model" sounds suspiciously like
> designers telling customers to conform to designer
> procedures.  This has not had much success in the past.
>
> People using PGP in practice verify keys out of band,
> not through web of trust.

James,

Yes. Your observation on out-of-band PGP key verification is very important and actually exemplifies what Werner wrote. Exactly because there's no trust model defined a priori, uses can choose the model they want including one-on-one trust.

This is important because it eliminates the need for a common root of trust -- with a significant usability improvement.

If the web of trust is used, the sender and recipient must a priori trust each other's key signers, requiring a common root of trust -- that may not even exist to begin with.

So, instead of worrying about what trust model PGP uses, the answer is that you can use any trust model you want -- including a hierarchical trust model as used with X.509.

Jon Callas and I had several conversations on trust in May '97, when Jon visited me for two weeks while I was in Brazil at the time, I think before the OpenPGP WG was
even working on these issues. This is one of the comments Jon wrote in a listserv then, with a great insight that might be useful today:

As I understand it, then, I've been thinking about some of the wrong issues. For example, I have been wondering about how exactly the trust model works, and what trust model can possibly do all the things Dr Gerck is claiming. I think my confusion comes from my asking the wrong question. The real answer seems to be, 'what trust model would you like?' There is a built in notion (the 'archetypical model' in the abstract class) of the meta-rules that a trust model has to follow, but I might buy a trust model from someone and add that, design my own, or even augment one I bought. Thus, I can ask for a fingerprint and check it against the FBI, Scotland Yard, and Surite databases, check their PGP key to make sure that it was signed my Mother Theresa, ask for a letter of recommendation from either the Pope or the Dalai Lama (except during Ramadan, when only approval by the Taliban will do), and then reject them out of hand if I haven't had my second cup of coffee.

Cheers,
Ed Gerck

How much will it cost you to lose your customer's data?

This one popped up and adds actual numbers to the debates on losses of data by companies. I can do no better than Chandler on this and will simply copy his snippets:

The first report is a survey of 14 organizations that lost confidential customer information and had a regulatory requirement to notify the affected individuals. The 14 organizations primarily hailed from the financial services arena but also included retailers, insurance companies, telecom firms, higher education and healthcare.

To cope and recover from a single security breach cost on average $14 million per company per breach or $140 per lost customer record. The direct costs in incremental spending for outside legal counsel, increased call-center costs and related items alone were $5 million.

Chandler went to PGP and in a supreme irony, entered his personal details in order to get the actual reports:

Breaches included in the survey ranged from 1,500 records to 900,000 records from 11 different industry sectors. In general, the largest breaches occurred in financial services, data integration, and retail; the smallest were in higher education and health care. Information in this study covers the costs of almost 1.4 million customer records compromised.

Among the study's key findings:

• Total costs to recover from a data breach averaged $14 million per company or $140 per lost customer record
• Direct costs for incremental, out-of-pocket, unbudgeted spending averaged $5 million per company or $50 per lost customer record for outside legal counsel, mail notification letters, calls to individual customers, increased call center costs, and discounted product offers
• Indirect costs for lost employee productivity averaged $1.5 million per company or $15 per customer record
• Opportunity costs covering loss of existing customers and increased difficulty in recruiting new customers averaged $7.5 million per company or $75 per lost customer record. Overall customer loss averaged 2.6% of all customers and ranged as high as 11%.

These cost estimates include recovery costs only and do not include the cost of putting in place technology and procedures to ensure such breaches do not occur in the future.

Those are hard numbers, not in the sense that they are fixed for you, but in the sense that they can not easily be ignored in NPV calculations. Now, if we were able to calculate the risk of this breach happening then we could simply multiple the two and get the expected loss. Which then could be compared and contrasted with our security expenditure!

Or, in simple terms, you might consider spending up to $140 per customer on security if you are 100% likely to lose the data, and your security is guaranteed to reduce that likelihood to zero. Leaves a lot of open territory, I know, but any numbers are better than no numbers.