Life With Alacrity

On Being an Angel

In the last month or so I've received a number of links to Life With Alacrity as a venture capital blog, and to myself as a venture capitalist.

However, I don't consider myself a venture capitalist. Instead, I am what is known as an "angel investor".

This week has also seen a new topic enter the blog zeitgeist: the topic of reforming or reinventing venture capital. This topic was initially raised by Dave Winer, followed by Robert Scoble, Doc Searls, Jeff Nolan, Michael Arrington, Thatedeguy and many more.

All types of venture investment -- seed, angel, venture, and institutional alike -- carry with it great risks and great rewards. But before we can reinvent venture capital and related venture funding methods like angel capital, we need to understand how it works.

So What is a Venture Capitalist?

A venture capitalist is a partner or associate in a venture capital management firm, which manages money on behalf of large institutional investors.

Basically, a large institutional investor (such as a pension fund or an insurance company) can statistically afford to invest a small part of their portfolio -- perhaps from 1% to as much as 5% -- in high-risk, long-term investments. If they lose the money outright, their other more stable investments have a good chance of making up the loss. But if the high risk investment does well, they can substantially improve their IRR (internal rate of return). To a certain extent they can't lose if they are careful. So these institutional investors invest in a number of types of high-risk funds, including such investments as venture capital funds.

A venture capital management company will manage one or more of these funds, investing in private companies. These VC management firms operate off of a management fee, from 2% to 3% of the capital invested to date. Thus all of the salaries for the staff of a VC management firm are paid, even if the investments are a failure. In addition, if any of the investments are successful, the VC management company earns 20% off of the top of the gain (called a "carry"), which is distributed to all of the full partners in the VC management firm, and sometimes a little of it to the associates.

It is the VC associates that do the brunt of the work for a VC management firm. They make a good salary, but the real return is if they are able to do well in identifying, managing, and selling new startups; then they are invited to become a partner the next time the VC management firm raises a fund. Then if the fund that they are a partner in does well, they can make a true fortune, or even start their own VC management firm.

However, the odds are against the VC associate. It's common wisdom that an associate can't easily manage more the 7 firms at a time. Other common wisdom says that 1 in 5 investments will survive to break even and that 1 in 20 will "make the fund", i.e. pay for all the losses in the other 19 investments. Some newer firms say 1 in 10, but I'll go with the older more conservative numbers. Thus associates are incentivized to try to manage more then 7 investments and to be smarter than their peers in the firm, so that at least one of their investments will be the 1 in 20 that makes the fund. This makes it easier for the associate to become a partner in the future, as at best 1 in 3 or 1 in 5 associates becomes a partner. Cutthroat competition between associates exists in some firms. This pressure often adds the perception that associates don't give enough attention to companies in their portfolio; they want their startups to do well, but the odds are it is another company that will make it, or a startup managed by peer associates. So they divide their attention. This is not unrelated to the Dunbar Triage problem.

Another problem that VC management firms face is the number of investments they are able to effectively handle. If there are 5-6 associates and 2-4 partners, there is probably a max of 50 investments that they have time to manage. If they are managing a $500 million dollar fund, that means that they have to invest at least $10M in a company, but in fact that is more likely to be $25M over time. If 1 in 20 makes the fund, that $25.0M has to give a return of $250M.  Thus when entrepreneurs complain that VCs will not invest in their company, it is often because the VCs can't figure out how to invest a minimum of $25M and turn out at the end with $250M. A related problem is that a startup that might have a successful business model that could grow into a profitable $50M annual revenues will be encouraged to take a more risky route so that they can go public, which requires a minimum of $100-200M annual revenues.

There is a lot of variety in VC management firms; some VCs have smaller funds under management, others give their associates more of a share, others have different management fees or carry percentages, and most specialize in some way: either vertically in a particular field, or horizontally in a particular stage of investment. For instance, there are some VC firms known as mezzanine firms that only invest in your company right before they think it can go public.

This is the way most VC management firms work. Periodically a new VC management firms will explore and push the limits of the above boundary conditions, but the more edges they attempt, the more likely they will fail.

My Three Angels

So what is an angel investor? I learned a lot of what I know from the 3 angel investors that invested in my software startup, Consensus Development.

Gifford Pinchot -- Partner Angel

Gifford Pinchot, with his wife Libba, was my first angel investor in Consensus Development. We met at a Maxis meeting where Gifford had been asked to facilitate the formation of a new startup to create simulation software. At the end of the meeting we left frustrated with the results of the meeting, but Gifford liked what he heard about my broader vision. Gifford flew me to San Diego, where we walked the beach and discussed my vision for collaborative software. He liked what he heard, and later in the month flew me to his home in Connecticut, where I stayed for a month in a barn guest house near his home while we worked on our first business plan.

Gifford only invested a low 5 figures, which got me started. However, it wasn't his money that was his most valuable contribution -- it was his time. Over the years he probably put 5-10% of his into time as Chairman of Consensus Development working with me, talking to me, advising me, and coached me. When our first software effort, InfoLog (a folksonomy tagging program like del.icio.us that was a decade too early) failed, he didn't walk away and instead encouraged me to continue. I dug deeper into the problem, discovered that trust and security were a key obstacle, and created a profitable consulting business. But Gifford encouraged me when I said we were going to take the risk of dropping all of our profitable consulting and focusing on a product, SSL Plus. Later, when this company was being shopped around to various buyers, Gifford spent lots of time doing due diligence, and ultimately came on half-time as CEO so that I could concentrate on selling the business.

In the end, Gifford earned probably 7 figures on his initial 5 figure investment, close to a hundred-fold return on the dollars he invested. However, his real investment was the time he spent with me -- almost 10 years of never giving up.

Scott Loftesness -- Seed Angel

I met Scott Loftesness when he was the executive vice president at Visa International. We learned of each other through CompuServe, where we both were sysops in the 80s. I did some consulting for him at Visa in the groupware area over a couple of years and we grew to respect and trust each other. I came to him when I branched out from groupware consulting and began to include consulting on cryptographic security. I'd seen an opportunity--I had a potential contract from RSA Data Security to be a distributor of RSAREF--but in order to take advantage of this opportunity I needed some seed capital.

Scott invested over twice what Gifford invested, but still 5 figures. However, like Gifford, what I gained from my association with Scott was a lot more then the seed capital. He had a respected name in the industry -- a friend at Visa USA told me "Scott is where all innovation at Visa flows from." He joined my board of directors, supported our risky choice to drop all groupware and cryptographic consulting to focus on our SSL project, helped tremendously in doing due diligence on potential buyers, and was pivotal to the negotiations to close our final sale of Consensus Development.

In the end, Scott Loftesness also did quite well in his investment in Consensus Development. His involvement on the day-to-day operation of Consensus Development was significantly less, but he was always around to support and advise us when we needed him.

Jim Bidzos -- Hands-Off Angel

Jim Bidzos was the CEO of RSA Data Security, whose firm had a critical patent on almost all meaningful cryptographic security. Over the years I did a lot of consulting for him to support various projects like RSAREF in standards, to create client tools for their Certificate Services Division, and to help with the founding of Verisign.

One day I told Jim that RSAREF would never be successful in his goal of promoting the RSA algorithm in security standards as long as it could only be sold through RSA salespeople. They preferred to sell RSA's premiere toolkit, BSAFE. I somewhat jokingly proposed that maybe Consensus Development should sell it instead. To my surprise, he agreed.

A couple of years later I leveraged the fact that Consensus Development had the only RSA toolkit available other then RSA's own to get the contract to develop the reference implementation of SSL 3.0 for Netscape. I took this Netscape contract back to Jim and said that I needed some investment to make this successfully. He invested a middle six figures in Consensus Development in return for a percentage that was roughly equivalent to that of Gifford and Scott, but because of his involvement as CEO of RSA Data Security he could not be on our board of directors.

After this investment, Jim had very little to do with Consensus Development. In fact, he had spread his angel money so widely in the cryptographic security industry that he was also invested in a couple of our competitors. In the end his investment was worth roughly 10 times what he invested, but the cachet of being able to tell others that Jim Bidzos was an investor made Consensus Development much more "legitimate", which also added significant value to us.

Founding of Alacrity Ventures

After I left Certicom, the company that had purchased my firm, Consensus Development (see Bad Business of Fear for more info), I wondered what I should do next. I could theoretically retire if I abandoned the Bay Area, but I was not ready for that and I thought I had maybe enough capital to start one more business of my own instead. Under a non-compete from Certicom, I was not sure what type of non-cryptographic business I wanted to start. So I decided that one thing I could do was some angel investing. In part this was to make money, but a larger part of it was that I enjoyed working with entrepreneurs. I wanted to do for others what Gifford Pinchot had done for me.

I did some study about how venture economics works, how angels and venture capital firms invest, and became concerned. I saw that being an angel investor in many ways is much harder then being a venture capitalist.

One of the biggest challenges is that angels share all the problems of the institutional investor, of the VC management firm, and of the VC associate.

The first challenge is deciding how much to invest. The institutional investors only risk 1%-5% of their capital. If I limited myself to that amount I could maybe invest in a couple of companies. I decided I was still young and could risk investing more.

The second problem was no management fee -- unlike a VC firm, angels don't get a management fee to cover salaries, legal fees, other expenses.

The third problem was my time. Most angels still work for a living -- being an angel investor is part-time, a venture capitalist typically works full-time. If only 1 in 20 investments "make the fund", but I could at most manage 7 investments, that meant that I had a 2/3rd's chance of losing my entire investment. I might be able to argue that for some kinds of businesses I might more informed than the average VC, and thus might be able to make better choices, but not that much better.

The key, I decided, was to work with at least 2 other angel investors. That would theoretically allow us to invest in 21 companies, diversify our portfolios, and split the work. I approached my first angel investor, Gifford Pinchot, and he agreed to be one of the partners. The second was Harold Shattuck, who had done some due diligence and operations consulting for Consensus Development, and had been VC once before, but enjoyed being closer to the actual building of a new company with some operating interaction. I was the managing partner for files and accounting, but we all brought to the table our "deal flow", performed due diligence together, and worked closely with each other.

Lessons from Alacrity Ventures

Alacrity Ventures is over 6 years old, and I have learned many lessons from it.

First, I feel that we did a good job selecting our investments, during a time in which being an angel investor was very difficult. I discovered that Gifford, Harold and I were really good at due diligence; our differing skills, Gifford's in coaching and evaluating the management team, Harold's in operations and business models, and mine in technology truly complemented each other.

For a long time I could say that the good news was that that out of 13 investments, all but 1 were still in business. However, we were never able to invest in the 21 investments that we planned because we discovered a significant problem in angel investing: the VC.

The angel investor can only really afford to invest early on, as a seed investor, or in an early investment round such as series A. However, the firms we invested in needed more money along the way; in fact, almost all firms need money at more then one point. The venture climate at the time was such that the VCs required in their term sheets that previous investment rounds lose their liquidation preferences, and ultimately their investment.

Let me give a specific example -- we invested in a first round of an enterprise software company in 2000 that is still around today. In 2002 they needed more money, and because of the difficulty in getting VC investment, the lead VC insisted that the preferences from the previous rounds be removed, effectively making us common stock, unless we participated in this subsequent round. We reluctantly did invest some more, but because we don't have the funds that a VC has, we were only able to protect some of our preferred stock. A year and half later, the software company needed more money, and the VC did it again. This time, all our stock was converted to common. Now it is 2006, and the company might be acquired this year; however the VCs, because of their liquidation preferences, will get the first $65 million (or more). As I doubt the firm is worth more then $50M, we will not get anything, nor will any of the other founders that are no longer involved with the firm.

This has repeated itself over and over again. We made a decent choice and did our due diligence well, but subsequent VC investors have pushed us out. A few of our ventures have failed outright. That is understandable given our original 1 in 20 expectations. But what we didn't expect was how difficult it was going to be to participate in the upside. Yes, we had preferences in our early rounds that should have protected us, but they didn't.

So of our 13 investments, only 2 remain that may "make the fund": a very innovative high-tech titanium powder manufacturer ITT, and a high-tech manufacturer of ceramic devices Vapore. But even as these two investments survive, they are still vulnerable to requiring additional investment and possibly forcing us out.

Of the rest: one of our early investments sold to VeriSign at a 50% premium, our investment in Salon.com will give us a small return, MG Taylor paid off its loan, and Skotos may someday pay back its original investment. The other 8 are being written off as a loss.

Advice to Angels

So in spite of the odds, you still want to become an angel investor? Here is some advice...

Collaborate with other angels: Going it alone is dangerous -- there are a number of angel investor networks, such as Gathering of Angels, Band of Angels and others in listed the Directory of Angel-Investor Networks. Be careful, though, the enthusiasm of others can be contagious -- don't always go with the herd.

Do your own due diligence: I can't emphasize this enough. Talk to the entrepreneurs and meet their staff. Read their business plan and tear it apart. Find the hidden assumptions. Understand their business model. It needs to feel realistic. Try to get more eyes on the job: different people see different things. Don't follow others; they may have different investment criteria then your own.

Be an advisor first: Be an advisor first -- if the entrepreneurs don't listen to your advice, don't invest. If you have to invest to become an advisor, invest only a small amount, or have part of the money be contingent on a meaningful goal.

Guard your upside: When negotiating terms, don't worry about the downside. It is the VCs that need items on the term sheet for when things go wrong -- what you need to guard is for when things go right. Watch for changes in the executive staff -- they may be incentivized differently than you are.

Consider a secured loan: Somewhat contrary to the "guard your upside" advice, rather then investing only in stock, consider investing via a secured loan as well. The security can not only be on hard company assets, but intellectual property such as copyrights, trademarks or patents. Your return will be lower on the loan, but if you can get all of your investment back early and get a small percentage of the company, it can be a good way to balance risk. Just remember to file the property documents to make sure that the assets are properly secured, and be prepared that someday you may own that asset.

Save $2 for every $1: Almost every company you invest in, even if successful, will need additional funding. Make sure that you keep on hand $2 for every $1 initially invested. This will also help you from being squeezed out by later VC investors.

Invest in acquisition targets: Let the VCs take companies public -- the companies that you should be interested are the companies that will eventually be acquired. Creating an acquisition target requires the management to think differently -- coach them to do so.

Understand the founders dilemma: There are many founders dilemmas, however, one is particularly important to the angel investor. A founder may be incentivized to sell sooner then his early investors. Remember that most often, the only significant asset that a founder has is his company. If the founder has an opportunity to sell early and buy a house, he might, even if it may not be enough return on investment for the risk that the angel took. Find ways to keep your interest aligned with that of the founders, which may include even buying some stock directly from the founder.

Consider alternative exits: There are lots of boutique opportunities that are too small for VCs. I know of a local Berkeley software company that was number one in their market, but too small to go public. They had $20M in annual revenues, and profits of almost $10M, but little opportunity for growth -- early investors could have gotten their money back in dividends rather than sale of the company.

Time the cycle: We didn't invest at the ideal time for the angel investor. We picked well considering the times, but had we waited for a few years it would have been easier. Not to say that timing is everything; we'd have lost our titanium powder opportunity if we'd waited for better market timing.

Respect people: Treat the people you invest in like a paying client. Respect their time and concerns.

Be prepared that the plan will change: I've never been involved with a business where the business plan doesn't significantly change. As an angel investor you need to help your businesses to plan for those changes.

Advice to Entrepreneurs

So you want investment from an angel investor? Some advice...

Recognize the odds: The angel investor is taking a substantial risk investing in your company -- you need to be able show a scenario where the investor might be able to make 10x or 20x their investment. So if you are looking for $100K, you need to show how the angel can ultimately have stock worth $1M to $2M.

Consider their advice: Angel investors may not always be right, but show them that you are listening. If you use angels for more then just a source of money, you'll get a lot more value from them.

Draft your business plan: An angel investor does not need as complete a business plan as a VC does, but they need to see how you think. You should clearly identify what the product or service is, who is going to buy it, what is the marketplace that those buyers may find it in, what differentiates your product or service and why your team is good enough to deliver. Angel investors know that your plan will change, probably drastically, but if they understand your thinking process they can be more confident that your company will survive change.

It takes time: Don't count on the money from an angel investor (or any investor) until you get the check. Investors are always selecting from a number of choices, often very competitive choices. No matter how optimistic you are, it is likely it will take 6 months or likely more to raise angel money.

Team with Many Hats: Angel investors don't recruit new team members for you. You don't necessarily have to have your whole team in place, but there at least needs to be someone who has experience managing, someone with development experience, someone with marketing experience, and someone with sales experience. Whatever team is there, they need to be able to juggle all of those hats. Financial, HR, and administrative positions can all be part-time or farmed out.

Advice to Venture Capitalists

Value the angel investor: The angel investor serves a point in the marketplace that you are not able to serve. Rather then driving them out, find some way for them to continue to participate so that they can find other ventures for you.

Angels are not VCs: The angel investor can't afford to invest in later rounds -- their model is different than yours. It may make sense to force participation in subsequent rounds by other VCs, but carve out some room for angels.

The future of Alacrity Ventures

Though I've enjoyed some aspects of being an angel investor, I enjoy working with creative people to innovate new products more. I expect to spend most of my time in the next few years continuing to explore social software and collaboration tools, and the new product opportunities that may evolve from them.

Thus I expect that any future angel investments I make will be more along the lines of Gifford's style of investment in Consensus Development: a small investment of money and a large investment of time. Harold and Gifford both feel the same way. Currently we plan to continue monitoring our existing investments, but don't plan any new investments unless we can take a more active role in the firm -- for instance Harold is a board member in Vapore.

Gifford is now dedicating his life to building a better world by transforming business education. He is a co-founder and President of the Bainbridge Graduate Institute, which provides an MBA program integrating sustainability, green economics, the internet, and open source within a traditional MBA program. As an open source school, he helps other schools to use BGI’s curriculum. Check out his blog entry on Angel Philanthropy.

If there's one thing we've learned from six years of angel investing, one thing that may be more valuable than all the nuts and bolts I describe here, it's that Gifford Pinchot's partner-style of angel investment is what suits our investing style, not Jim Bidzos' style of hands-off angel investing, and that's a lesson that we're going to carry forward with Alacrity Ventures.

Future Topics

I've been working on an ambitious list of topics that I'd like to cover over the next year. I offer them to you here so you can have some idea the areas that I am thinking about.

Office Architecture for Innovation -- Over the years I've built or converted three offices to my specifications. From this I have learned a number of things about about how to create a productive environment innovation-oriented businesses. These include some of the obvious suggestions such as fresh air and natural light, but also include not so obvious ideas such as using magnetic paint and providing a small washer-dryer.

Requisite Variety -- This concept from cybernetics applies to social systems as well. "The larger the variety of actions available to a control system, the larger the variety of perturbations it is able to compensate." More people, as well as a diversity of thinking styles and experience, give social software more "variety of actions", thus this is part of the reason why social software can be so effective.

The Art and Craft of Meme Design -- We are learning more about how to create an effective meme. Creating memes has always been an art performed by publicists, marketers, politicians, the press, and to a lesser extent by scientists and other academics. Have we learned enough to turn this art into an explicit craft?

Wiki Editing Dichotomy -- One interesting possible barrier of entry to active participation in a wiki is what I call the "wiki editing dichotomy". You have to be proud enough to believe what you are contributing is generally worthwhile to others (or at least worth your effort), but you also have to be humble enough to understand that others can improve it. I don't know of many other collaborative media that requires both pride and humility.

Choice & Neuroeconomics -- There are some that say at the root of every decision is emotion. Even a 'rational' decision appeals to a sense of balance or beauty. Recent studies using PET are establishing a neurological basis for emotions, and some reveal interesting facts about how we make choices.

Assessing Risk -- There are a variety of areas where we as humans have a difficult time being completely rational. One of these is risk assessment. It turns out we may be hard-wired to not be able toeasily understand risk that is greater then one in a hundred or so. Thus a very rare risk, say one in a thousand, will often be emotionally interpreted as having a much higher risk.

Persuasive Computing -- BJ Fogg's group at Stanford has done some interesting research on how computers can persuade you to do something. There are a number of useful ideas that come from this research. There are also some ethical considerations that should be discussed.

Cognitive Dissonance -- This technique is central to many forms of persuasion intended to change beliefs, values, attitudes and behaviors. It is used by facilitators, businesses, military organizations, and even cults. It can be used positively or negatively. How might it be used in social software?

The Dark Side of the Force -- The same social tools that we use for good, can also be used for harm. How do we ethically use what we are learning about social software? Some say that almost by definition social software attracts spammers, trolls, and innappropriate sexuality. What can we do to prevent these misuses of social software?

Conversation vs Communication -- Update and rewrite of my 1990 essay on how social software design needs to balance conversation vs communication.

Social Emotions -- We appear to have evolved a number of emotions that appear primarily to exist to support a common good, rather then to ensure our individual success. These include schadenfreude, mirth, naches, revenge, shame, pride, outrage, approbation, admiration, elevation, etc. Studies by Eckman on unconscious facial gestures, studies on the neurological basis for emotions, and studies on emotions in games, are proving that these social emotions exist. A number of them have interesting implications on social software.

Glances & Strokes -- There is some old work on the amount of eye contact we make with others in small groups, as well as some research from transactional analysis on strokes, which are the amount of recognition given to others through words and deeds. Is there a neurological basis for needing a certain number of glances and strokes each day? How does this concept apply to social software?

Weak Links -- There are some interesting social implications behind what we've learned about weak links in social networks. How do we identify and encourage weak links in our social software systems?

Negativity vs Positivity -- It is far easier for someone to respond negativel than positively. In political systems it is far easier to say no rather then yes. What social software encourages positivity, and is it possible to design social software to do so?

Time Economy -- Our ultimate most unrenewable resource is time. How time and attention are a basic economic unit that should be considered when looking at social software.

Group Life Cycle -- We often focus on how groups form, emerge, and grow. Yet there are many lessons to be learned from how groups die, including that it isn't necessarily a bad thing and that keeping a group from death can be dysfunctional.

Groupthink -- What causes groupthink? When is it good and when is it bad?

Two Thresholds in the Value of Knowledge -- In order for knowledge to be valuable, it must at minimum be more valuable then the costs to find and absorb it (costs which include bandwidth and attention). Tools like Google have tremendously increased the amount of knowledge that is worth the time and attention to find it. What types of knowledge fall below this threshold of value? Is there a limit to how much we can lower this line? Furthermore, there is another threshold where the knowledge is significantly more valuable than only bandwidth and attention. How much have internet tools impacted this second threshold? Many internet business models, in particular content models, require some ability to offer value in this upper threshold -- can they survive as this upper threshold changes?

Intimacy and Social Networks -- Social Networks Analysis tends to focus on the connections between people, either explicitly through acknowledgement of connections (LinkedIn, Friendster) or implicitly through analysis of your communication (Spoke). None are able to measure intimacy. Yet our intimate social networks are an important component of our overall happiness and contentment within both our professional and personal lives. How does intimacy work in social networks? Also there are some concepts in psychology known as communal vs exchange relationships by Clark & Mills from late 70's that may apply here.

Social Games -- A recap of Shannon Appelcline's and my analysis of the basic forms of social games types. These include relatively well understood ones like majority control, voting, meta-voting (Nomic), auctioning, etc., but also include less well understood games like playing of roles, dominance and submission, etc. There are also links to social emotions, such as mirth and schadenfraude.

Lessons from Castle Marrach -- We released the Castle Marrach online game in September of 2000, and it was designed from the beginning to be a game for the Bartle-type known as "the socializer". What lessons did we learn in the five years since the release of the game? What tools are in my social software toolbox today that might have helped with the design?

Lessons from F2F Facilitation -- There are many skilled practitioners of face-to-face facilitation, some of which are paid very high fees for their skills. What lessons can we learn from their experience that we can apply to social software? Why have so many of these facilitators failed to have success online?

More Human vs More Than Human -- Many futurists seek to offer us augmentation of our minds and bodies through technology. Many of these ideas may fundamentally change what it is to be human, and may even have unforeseen complications unanticipated by their creators. One interesting approach to looking at these technologies is to examine which make us "more human", rather then "more than human".

Lessons from Mental Disorders -- Most, if not all, mental disorders have their roots in survival strategies; however, they are over-expressed because of genetic or other causes. Examining the healthy behaviors hiding behind depression, autism, mania, schizophrenia, paranoia, etc. offer a number of insights on how we think.

Joy of being a Primate -- If you scan the surface of my writing, you may observe that I have a strong belief that our animal nature and genetics form an essential and often unconscious part of what it is to be human. You could interpret these "nature" over "nurture" ideas as limiting us to being just animals. Instead, I believe that by becoming aware of our primate nature, and choosing to leverage it or suppress it by conscious choice rather then letting it drive us unaware, is what makes us more powerful.

Smart Contracts -- Nick Szabo popularized the idea of using some of the primitives of cryptography in unique ways to create what he calls "smart contracts". He hypothesized approaches to cryptographic handling of collateral, bonding, delineation of property, bearer certificates, and much more. Others have proposed various auction protocols using these concepts. One of the fundamental atomic elements of many of these smart contracts is something called a "reusable proof of work", which Hal Finney recently demoed a version of at CodeCon 2005. What are the possibilities offered by smart contracts? What are the barriers to implementation?

Club System -- In the 80's, development of Ted Nelson's Xanadu vision was being financed by Autodesk. Unfortunately, for a variety of reasons Xanadu failed to deliver any technology. However, a couple of their ideas could be valuable today, one of which is the concept of an alternative to the "user and groups" metaphor for computer security. Xanadu turned that idea upside down and called the result the "club system". The club system approach is particularly suited to the internet based collaboration tools, in particular wikis. I also have some insights to offer a cryptographic approach to the club system, which might allow P2P distribution of collaborative documents, while preserving group privileges.

Edges of Cryptographic Security -- The SSL cryptographic protocol offers a choice of a number of security properties: integrity, confidentiality, encryption, one-party authentication, and two-party authentication. But there are a number of security properties that very few deployed cryptographic protocols offer. These include perfect forward secrecy, undeniability, deniability, authorization, delegation, multi-party authentication, shared secrets, etc. What are these security properties and how are they useful? Why have they not been successfully broadly deployed?

The SSL Story -- When SSL was first proposed it was broken within an hour. Even when Netscape fixed those problems, it wasn't clear that SSL was going to win the battle of security protocols. SSL was competing against SHTTP which had backing of RSA and an industry consortium. The credit card companies merged their standards and were backing SET. The internet community was moving toward SSH. Microsoft was doing its own embrace and extend protocol PCT. So how did SSL win to become the broadest deployed cryptographic security protocol? The answers may surprise you.

I welcome any comments or suggestions for links on these topics, or any new topics that you feel are closely related.

Progressive Trust

I believe that as we evolve social software to better serve our needs and the needs of the groups that we are involved in, we need to figure out how to apply an understanding of how human groups behave and work.

One useful concept I use I call "Progressive Trust". The basic idea is to model how trust works in the real world, between real people, rather then solely relying on mathematical or cryptographic trust.

This is how I typically explain progressive trust when I meet someone in-person at a conference:

You are now spending your most precious resource, that most unrenewable commodity -- time, in order to listen and understand what I have to say.

Why do you do so? Because by the act of us being here in this common space, at this conference, you have found a very simple credential from me--that I'm willing to spend time here in a place that you are interested in as well. In turn, I'm willing to spend more time chatting with you for the same reason.

Why do we continue to chat, and not move on to other people to discuss with? Because as we chat we are exchanging a number of credentials -- people we know in common, common interests, meaningful ideas, etc. We may also present credentials typically issued by others, like our business cards, or explain our relationship to the host.

As our unspoken agreement to continue discussion evolves, we typically will unconsciously check to see if others are listening, and adapt our conversation thereafter. If the discussion becomes more personal or serious, we will often find ourselves moving to a more private portion of the room. As our discussions become deeper, we may begin to speak of things that hint at a mutual respect for confidentiality.

Also early on we'll begin to scope out the nature of our time together. Is it only professional, or a potential friendship? Even intimate relationships go through this phase -- are we with someone who wants to date? Is is possible that a future date lead to something more?

If we agree to meet later to discuss more, before we meet again we may go authenticate some of the credentials given us. We'll not authenticate all of them, only enough to substantiate the level of assurance that we need for the risk we are taking (which may only be the future loss due to wasted time, but even that is a form of risk.) This authentication can consist simply of confirming information given, or it can be as complex as asking for an endorsement from a mutual colleague.

As our collaboration grows, we will find ourselves seeking more and more credentials, endorsements, etc., but they will not be enough. The next level of trust can only be established by experience of commitment -- for instance do we call back when we said we would? These tests typically start with small things, and then grow to larger things. At some point this may ultimately grow to form simple verbal contracts; over time richer, deeper social contracts are agreed upon that might not be written down.

Ultimately we may bring in third parties to witness, and thus possibly enforce our mutual obligations, whether it is just having a mutual colleague view our handshake or friends see us kiss, or whether it is having a legal, signed document.

At some point our mutual interests may be so large that we decide not just to collaborate, but to share assets, whether through a partnership, a corporation, or a marriage. Before this is complete there will be more credentials and authentication of those credentials (talk to former employees, engage in credit checks, visit each others' families, take blood tests), endorsements, and less risky tests of the full contract (signing a term sheet, or a marriage engagement).

This is the way human trust works. It also very similar to the way that groups work -- a corporation will collaborate with another corporation in the same way, starting with small trust, going on to tests, and leading ultimately up to partnerships and mergers.

Computer trust rarely works the way that human trust does. It starts with mathematical proofs--that such and such a mathematical algorithm is extremely difficult, thus something built on it must also be difficult. These are then built on top of each other until a system is created. It often seeks a level of "perfect trust" that is rarely required by human trust.

One of the reasons why I chose to back the then nascent SSL (Secure Sockets Layer) Standard back in 1992-3, was that I felt that it much better mapped to the progressive trust model, and thus to human trust, then did its competitors.

At the time, the SET standard was backed by all the major players--Visa, Mastercard, Microsoft, etc. However, it not only required strong mutual authentication, but it also require multiple authentications. HTTPS was backed by RSA, required digital signatures, preferably by both parties. SSL was not necessarily a clear winner.

But SSL starts out very simple--first it just connects two parties, then it establishes simple confidentiality between them. If one party wants more confidentiality, they can upgrade to a stronger algorithm. Then one party can request a credential from the other, or both can. Either party has the option to request authentication of those credentials. Ultimately you could use SSL to come close to the level trust that SET tried to establish, but SSL isn't generally used that way because the market decided that only one party needed to send a credential--the merchant. SSL also proved to be more flexible then for use just with web pages or credit cards -- now it is used for things like securing email, creating VPNs, and playing online games.

Thus progressive trust is a useful conceptual model for understanding how trust might be built using online tools. Look at the tools that you are using now -- do they support various levels of trust, and a natural path between them? Or is trust more binary -- someone is only trusted, or not trusted. Are there implicit levels of progressive trust that are part of the culture of your group that might not embodied in the software itself?

Progressive trust also maps well to an user-interface design technique called Progressive Disclosure. It sequences information and actions across several different windows in order not overwhelm the user. You disclose basic information and choices first, then revealing progressively more complex information and choices. Thus you help the user manage the complexity of the application. Navigating group interactions and culture is also complex, thus progressive trust allows you to hide some of initial complexity of the trust model behind your tools, and thus lower barriers of entry to your software.

Post RSA Conference Wrapup

I spent most of last week at the RSA Conference in San Francisco.

Like last year, I found little that excited me. I overheard from a convention staffer that they had 30% more attendees, so the conference is growing again, but my week there also reinforced my opinions regarding the industry as a whole as I describe in my previous blog posting The Bad Business of Fear.

I asked a number of random people what they thought of the conference. Some agreed with me, saying that they were troubled by the lack of innovation. Others said that they actually liked it -- it showed that the industry was being run by businessmen finally, and not by geeks. Others said that it was just the inevitable maturation of an industry. Tim Oren wrote in his blog Due Diligence:

Every year the show is less about cryptography per se. I'm sure this has something to do with RSA's attempts to diversify as its patents expire, but I do think it reflects the state of the field. Crypto has become a standardized component of security solutions, and the biggest perceived threats are not in the privacy area.

The hilight of the conference to me was hearing respected cryptographer Whitfield Diffie say to me that he had read my The Bad Business of Fear and that he liked it. Apparently it had been sent to him by someone at Sun who had thought that it was saying many of the things that Diffie has been saying as well. Diffie said that he had some specific criticisms, so I hope that he'll comment here someday on them.

Caller-ID for Email

The big announcement of the week was that Microsoft will be be releasing their own spam solution, a Caller ID for email addresses, starting this summer in HotMail and in their mail servers. Basically the way this works is that every domain holder publishes inside their DNS records the IP addresses of any valid outbound email server. This information is stored using XML in a special signed format. After a mail is sent, the receiving system queries the DNS to confirm that the outbound server is not being spoofed.

This is a very similar technique to what a number of other companies are proposing, for instance AOL is backing a proposal called SPF (Sender Policy Framework) or sometimes "Sender Permitted From", and Yahoo is backing Domain Keys. Unfortunately, Microsoft's Caller-ID proposal requires XML, which makes implementation much more complicated. It requires the entire email to be received by the server first, before looking up the DNS record, then validating a signature -- all of which introduces more burdens on the mail server. Lastly, this XML may exceed the 512-character limit for DNS requests, which can cause DNS servers to send via TCP rather then UDP, which may introduces even more uncertainty.

It is good to see that Microsoft, AOL and Yahoo are taking spam seriously, but I do worry that that the burden of supporting more then one of these standards may be significant. This could mean that only large corporations, educational institutions, and ISPs could host email, whereas small companies, third-world organizations, and individuals could not. I would prefer that one solution be broadly and easily adopted. Daniel Goldman Yakov Shafranovich in NetWizard's blog is also concerned about patent claims and lack of IETF participation:

At the same time none of these proposals have been submitted to any standards bodies such as the IETF, and as a matter of fact Microsoft was invited to submit "Caller ID" and participate in this week's meeting at the IETF on the subject, but they declined. At the same time the community had jumped on Caller ID's patent license by declaring a (and a possible incompatibility with the GPL). Of course it remains to be seen what exactly does Caller ID claim to patent since RMX and other prior art existed at least since 1998, and if Caller ID ever makes it to the IETF, Microsoft will have to deal with the new IPR guidelines (RFC 3669) which favor non-patented technologies.

I'm also not convinced that even if these techniques are deployed (Gartner group predicts less then 25% will implement these in the next two years) that they will not return us to early 1990's levels of spam, only just slow down the onslaught. For instance, in a similar fashion to current WiFi war-chalking, a spammer could wait until an authenticated user logged in a mail server and hijack that connection. Unless the link is encrypted and authenticated, it is possible for a spammer to impersonate the legitimate user without anyone being the wiser. Related, these techniques do not necessarily help with the growing threat of "phishing" -- emails that lure unsuspecting users to enter credit card or bank account information into fake web sites.

I am also concerned that all of these standards require some measure of public-key infrastructure, including management of public-keys, which many security analysts believe that we are not doing a good enough job now.

There is some good thoughtful analysis of these three standards by Larry Seltzer of eWeek in Who will Win the SMTP Authentication Wars.

More Security in Windows XP SP2

Bill Gates also discussed new security features in the upcoming Windows XP SP2. In addition to some interesting "Active Protection Technology" to prevent overflow attacks, he discussed built-in virus protection and an improved built-in firewall that also warns of outbound connections.

Out in the hall I heard some people saying that announcement was a good basis for selling Symantec short, while others countered that Microsoft never gets these type of things right and there would always be business for Symantec. Companies that offer more minor features like preventing browser popups will be hurt. However, as these solutions are already free and ubiquitous, this is one of the few cases where I prefer for these to be in the default Microsoft install. However, I do worry for the smaller but more innovative security vendors like ZoneAlarm.

Sessions

Over the years the sessions at RSA have become more managerial and corporate in nature, but there were a couple of good technical sessions that I attended or friends commented on.

I was pleased by the Cryptographer's Panel response to Bill Gates' announcements: "We have a lot of great levers in cryptography, but we're missing the OSes and platforms that can really serve our keys," said Ronald Rivest. "Bill Gates didn't talk about simplifying things, but that's the only way we are going to get security. We're not smart enough to handle the complexity of this stuff. You have to get the complexity out of there," continued Paul Kocher. Whitfield Diffie criticized security the upcoming Windows Longhorn release because "For the first time, you will have a PC that does NOT do what you tell it to."

The Cryptographer's Panel also spoke on the topic of electronic voting, and supported calls for paper ballots to supplement and verify votes cast with new electronic voting technology. Rivest cautioned "We know only too well the difficulties of securing complex electronic systems."

I also heard good things about the "Hacking VM Machines" and "Analyzing Topologies of Trust" sessions, and the closing keynote by PJ O'Rouke, but I missed them -- anyone have any notes? Where there some other good sessions I missed?

Exhibits

The exhibit floor was again a bit droll for me. Like in previous years the floor was dominated by vendors selling rather high-end corporate systems that might have excited me more if I was in the market for one, but I was looking for less expensive systems for smaller businesses. Like last year there were lots of dedicated devices, such as firewalls, spam prevention, VPN and intrusion detection hardware, and fewer companies offering software to use with my existing hardware.

I did like some of the biometric hard drives, but investigating more deeply I just can't trust them yet. No one yet offers a good solution for redundant key storage yet for these, as a backup in case of a physical failure.

I did see one company Authenex that was offering free USB keys that supposedly allow you to encrypt files on your system and email them to someone else with a different key -- it looks like some public key technique is being used, with the key serving as a pre-generated private key storage. More interestingly, they claim that if you register your USB key at their website, they can send you a replacement key that you can use to decrypt your old files. I'll have to do some more investigation of the technology behind this, and if they've had adequate study by cryptographers that I trust. If they have, and they start offering storage on those keys as well, they may have something useful that I'll buy.

RSA had an demo of it's prototype RFID blocker tag that they suggest is a possible solution to some of the fears that some of us privacy advocates have been worrying about. Scott Mace has a good description of the demo:

Each booth visitor selects from one of three demo prescriptions -- "tranquility pills," "wisdom pills," or "happiness pills." (I chose wisdom, naturally.) The RSA Labs crew requests a name from the visitor, then hands over an appropriately-tagged bottle (mine contained jellybeans). They scan the bottle on an RFID tabletop scanner and visitors see the details of the prescription, including type of prescription and patient's name. Then, they insert the bottle into an ordinary paper pharmacy bag that happens to contain a paper "blocker tag" that then blocks any attempt for an RFID reader to scan the bottle while it's in the bag.

Though a cool demo, I'm not as confident that this solution will work. Now in addition to the previous "foil bag" theft techniques, what prevents someone from building one of these into a watch or a PDA? Sending a signal to burn-out the RFID is one of the other proposals out there, it has similar problems -- what if someone goes into a WalMart and burns-out every RFID in the place?

RSA was also demoing its latest SecurID integration with Windows, which will extend the life of this security token for RSA customers for many years. I spoke to Scott Schnell, VP of Marketing, afterwards at a party and he explained to me some of the details of how they made it work with Windows laptops. Apparently the system will cache up to several weeks worth of SecurID information such that the laptop owner can use his SecurID token to log on to his laptop even though he is not connected to the network. I neat trick, though I'd like to see some more security reviews before I'd deploy it broadly.

Probably the most interesting, but least useful to me, was a booth for Magiq Technology, who offer a commercial quantum cryptography solution. Quantum cryptography is the ultimate in secret key exchange at a distance -- you can sort of say that the universe protects you from snoopers. However, you have to have a fiber-optic connection between the two devices, which limits its practicality. But it is still cool.

Security & Cryptography: The Bad Business of Fear

As I head out next week to the RSA Conference I realized that it has been 13 years since I attended the first one. I remember fondly the potential and power of cryptography technology in 1991 -- public keys, digital certificates, new possibilities for privacy, digital cash, etc.

After 8 more years I left the compujter security industry on March 15, 1999. The computer security industry also seemed to be filled with as much potential as it did back in 1991. Amazon, EBay, and other Internet notables were still riding high, and driving before them the need for secure Internet transactions. The government's attempt to cripple the industry through their Clipper chip initiative was all but dead, and we were slowly winning the rights to export our technologies without severe and unnecessary government restrictions. We were beginning to truly see how Certificate Authorities worked in practical usage, and were coming up with plans for smaller, more efficient certs, to help bring security to wireless devices and set-top boxes.

It may seem strange that I left the industry at such a height, but I'd accomplished my own personal goals. I helped midwife the startup of VeriSign, and digital certificates were now broadly available for both servers and clients. I'd helped fight Clipper, and freed RSAREF so that it could be used by Open Source software before the expiration of the patent. I'd grown Consensus Development, a company I founded almost a decade before, from a small engineering house into the premiere SSL developer. I'd lead the team that developed the SSL Reference version for Netscape, and had completed the IETF's RFC 2246 that described the future of SSL called TLS.

Thus I found myself at the heart of a burgeoning Internet commerce industry. When Certicom, a leading cryptography company, had expressed a desire to purchase my company, I considered the returns for my investors, the value to my employees -- I was pleased with the results, and agreed. So I made an exit from the security industry, and as part of my agreement with Certicom I signed a non-compete which gave them a few years' head start before I dipped my foot back into the security industry.

Now, five years more have gone by. My non-compete with Certicom has expired and for over a year I have slowly been easing my way back into the world of security and cryptography. I must admit, I was a bit uncertain at first. Five years ago I had seen the industry perched on the edge of the next big change. It had been prepared to secure the hundreds of new applications that were proliferating on the net; to broadly adopt TLS, the newest version of SSL; to really look at the practical applications of certificate authorities and recreate the entire concept as a second generation of ideas. I wondered how far behind I would be, if I'd recognize the industry at all. Internet time had still been moving fast back in 1999 and I wasn't sure how many generations had gone by in the security industry. One, two, more?

So last year I started attending security related conferences again, such as IETF Meetings, the RSA Conference, and others. I was ready to come as a student, to soak up the new knowledge imparted in the talks and tutorials, to glory in the changes that the last five years had brought. Instead I discovered, almost nothing had changed. If anything, the industry had been moving backward, just a tiny bit.

What had happened to an industry that just five years ago had been rapidly pushing forward the frontiers of technology?

And, more important, how could it move forward?

The State of the Industry: Living off of Fear

Overall, I find the state of the security industry to be a bit sobering for its lack of momentum in recent years. This slowdown can be seen nowhere as easily as upon the exhibit floor of RSA Conference, the premiere conference for this industry, which I attended last year and will attend again next week.

Walking the floors of RSA last year, in the immense exhibit hall at the San Jose Convention Center, I did feel a sense of energy. The floor was still packed, and the carefully cut kiosks and the garish banners bespoke the millions put into the show by the exhibitors. The constant chatter was a deafening white noise, and whenever I veered too near a booth, there was a salesman very eager to tell me about his company's latest and greatest.

But, to a certain extent, that energy felt to me like a facade. There was nothing new; instead all the exhibitors were showing off the same technology that they were displaying five years ago. There was a bit of glitz and some extra chrome, perhaps a carefully redesigned product name, but beyond that there was a weird feeling of deja vu.

There were the same old tools that we've been using to deter hackers since the advent of the Morris Worm way back in 1989: products to detect intruders and safeguard your machines against them; firewalls; and VPNs. Maybe we've gotten a little better at figuring out expert rules, maybe we've improved our user interfaces, but these are slow, gradual upgrades, not quantum leaps.

Email still seems to be the newest battlefield upon which security wars are being fought, and you could find any number of new anti-spam tools at RSA. The Bayesian filters are a new and interesting way to statistically classify spam, but at the core level they're a dynamic outgrowth of keyboard filters that have been around for as long as we've been fighting unsolicited commercial email. RSA's big release of the year, Nightingale, was simply another way to protect sensitive online information, a competitor to Microsoft's Wallet technology. We had the ubiquitous hardware tokens too, and discussion of the recently approved AES encryption standard, but nothing dramatically new and exciting.

I suppose I shouldn't have been too surprised, based on my experiences at IETF a month before. Most of the Security Area working groups were still working on the same problems that they'd been discussing five years before. S/MIME is pushing forward on yet another draft of a standard that has never been broadly deployed. IPSEC is similarly continuing to work on the same problems, now years old. TLS was widely implemented and specified, but not widely adopted -- the world still uses SSL 3.0.

In the last year since those two conferences I had lunch with various professional colleagues that I had lost track of, continued to watch as a bystander the leading edge of security and cryptography.

As I overview the industry I have begun to feel that we'd largely abandoned the most interesting and innovative security techniques that were being discussed just five years ago. What happened to alternative public key infrastructures? What happened to attribute or role certificates? What happened to "authorization" being the next step after "authentication", or separating "security" from "privacy"?

Remarkably, if any of these topics are being considered, they seem to be moving outside of the traditional security industry. Such is the case with SAML, the Security Assertion Markup Language, a branch of XML which seems to be doing some of the only work on attribute certificates.

With so many technologies abandoned utterly, or else given up to another computer fields, we must ask: why are we stagnating, moving backward rather than forward?

Fear: Outlining the Problem

I thought, could it be the result of the dot-bomb and subsequent recession? Perhaps that is part of it, but we are in denial unless we face the deeper cause. If we go on as we are the security industry will not recover with the next boom.

The decline of the security industry is based upon a basic disconnect between the business world and the security world.

Within the security industry we base our models of trust upon mathematics. We strive to continually push the envelope by codifying security and improving it. On the other hand the business industry bases its models of trust upon risk. It balances the risk of a bad outcome, the cost of that bad outcome, and the cost of reducing that risk. Even if a system is technically insecure, the business world will accept it if the risk of a security breach is low, the cost of a security breach is low, or the cost of closing that breach is high.

Where our model is mathematics, theirs is economics. These two models worked well in tandem for quite a few years; the need for a security industry was initially obvious because of the totally undefined risks and the potentially high costs that were out there, waiting to be taken advantage of.

But now, years later, we've done our job too well. We've taken all those undefined risks and codified them -- made them real and quantifiable. We've offered real demonstrations of online security through years of ecommerce, and in doing so we've proven lower rates of credit card fraud, and almost total proof from high-cost offline problems like extortion and bad reputation. We've helped fill out business' risk models and so shown when we were necessary and when weren't.

In short, we have dug ourselves into a hole. Thus it shouldn't be surprising that the newer security technologies are stagnating ... because we've carefully, cleverly, and constantly diminished our revenues by staying with a business model in which 'good enough' security will become ever cheaper. We've turned our security business into a cheaper alternative to insurance, where business only pay for security if their insurance premiums would otherwise be too high. As the bulk of the risk is now handled by old, cheap technology, what remains for new sales is not enough to keep us truly innovating.

Recent statistics underline the decreasing value of innovative, new security to businesses. According to the CSI/FBI 2003 Computer Crime and Security Survey, the annual cost of computer crime has decreased in almost every category. From 2001 to 2003, the cost for theft of proprietary information is down from $151.2M to $70.2M. System penetration by outsiders is down from $19.1M to $2.8M. Insider abuse of network access is down from $35.0M to $11.8M. The only computer crime up in dollar damage inflicted is denial-of-service attacks, a very small part of the security pie.

With costs due to computer crime plunging year after year, clearly companies are not incentivized to put money in new prevention technologies.

To simplify, as long as the risks were unknown, we were in a business feeding off of 'fear' and our security industry 'pie' was growing. But as we and our customers both understand the risks better, and as we get better at mitigating those risks cheaply, this "fear" shrinks and thus the entire 'pie' of the security industry becomes smaller. Yes, new 'threats' keep on coming: denial-of-service, worms, spam, etc., but businesses understanding of past risks make them believe that these new risks can be solved and commodified in the same way.

As the philosophy and culture of the business world is hundreds of years old, going back to at least the Italian merchants of the Renaissance, business isn't going to change its model of how business works. Thus, it is up to us to rework the basic beliefs and understanding of our security industry.

In order to get out of this hole we need to dramatically rethink how we approach, develop, and market security services. To do this requires us to reconsider our own security models, based upon a better understanding of core business models. Some possibilities:

1. Enter the Insurance Business
2. Move into Reliability Improvement
3. Move into Enabling Technologies

Solution #1: Entering the Insurance Business

Entering the insurance business is an old idea. It was once an important part of Verisign's business plan, and no doubt of others as well.

At its simplest level, we can enter the insurance business by offering a guarantee against damages with a product. The main benefit of this approach is that it lets us approach security in a more rational and realistic fashion. No longer do we have to engage in an endless quest for improved security, no matter how small the risk. Instead we can assess our risks and prepare ourselves to accept manageable losses.

There are risks implicit in this solution as well. For the most part, those of us in the security industry are unfamiliar with the insurance business model, and thus we're entering particularly uncharted waters. In addition, we need to understand that some losses will be huge and unavoidable, such as was the case with the Code Red worm. We thus need to create business models that are acceptable to our customers, but which do not leave us entirely liable for the next utterly unforeseen worm which gets set loose on the Internet.

There may also be some limitations with this particular model, if the valuations of security companies are too low to insure the losses of a large corporation, such as a GM.

Finally, we need to ask ourselves the question: "What value does insured security provide over simple insurance?" I suspect there are some real values to customers in saved productivity and time, but further market research would be required to truly assess this.

A security company could offset most of these risks by a partnership with an insurance company or another business within the insurance industry. We would need deep reserves and to work together with imaginative actuaries. Together we could offer insurance against the damages of security breaches. We would be the guardians against break-ins and the fixers if they did occur. The insurance company would help estimate risks, collect premiums and pay.

If we chose to go it alone, we could offer risk mitigation services to insurance companies. We would guard and provide disaster mitigation services for a monthly premium. For example, when offering an anti-breakin security system, we could offer a guarantee to rebuild all certified systems if an intrusion does occur. This way we would take some, but not all, of the risks. Perhaps our presence would reduce insurance premiums enough to pay for our fees.

Overall, despite potential risks, I believe that using an insurance model is a strong possibility for the security industry.

Solution #2: Improving Reliability

Some of us in the security business may feel like we are already providing reliability, because many of our products prevent catastrophic risks due to break-in, theft, and other malevolent acts. However, what we generally tend to offer is data security, not data reliability. Perhaps paradoxically, at the more personal, day-to-day level, the security industry has actually reduced data reliability in the name of improved data security.

I can personally testify to this fact because I have, recently, lost data due to security. I encrypted a directory in Windows XP, then was later forced to rebuild my system. Apparently some of the required info to decrypt the directory was stored in some unrecoverable registry entry, because I can no longer access it. The data is totally secure, but also unavailable.

This anecdote isn't unusual for the security industry. Forgotten keys can often cause cryptographic-related data loss. Likewise, VPNs and firewalls introduce single points of failure into networks.

RSA's Nightingale technology of last year is a fairly standard security-based technology. It uses "secret-splitting" technology to divide sensitive data among two different locations, thus removing what RSA calls "a single point of compromise"; you can't get access to the data unless you compromise two machines. Clearly, there is improved data security. However it raises the same old problem of data reliability, because now data can be lost if either of two servers is lost.

Improving reliability of extant security protocols is a good move forward in this expansion of the industry. For example in a classic cryptography situation we might unlock data with multiple secrets, but only require a set number of those secrets to unlock the data, not all of them.

Consider a company who is encrypting some of their most sensitive sales and marketing data. Ten company officers might each possess a secret which together can be used to decrypt all the data. However, this introduces a clear reliability problem, as the departure of any officer could leave all sales and marketing data unreadable. (Likewise, just restricting this data access to one specific secret, such as that of the VP of Sales, introduces this single-point-of-failure condition.) Instead we could offer a high reliability, but secure situation where any five (of ten) secrets together could decrypt the data. Therefore, if an individual officer disappears, leaves for a rival company, or otherwise makes his secret unavailable, not only can he himself not access the data alone, but even if he leaves with the secret the remainder of the company's access is unaffected. And, if a company didn't think that "5 of 10" executive was the right number, they could instead only require "3 of 10" to decrypt the data ... or "7" or "9".

By thinking in this new methodology, by measuring security against reliability, we can offer our customers real choices and let them each choose the level of security that works best for them.

However, the underlying bases of cryptography let us go a step further than this. Even without considering security implications, we can make use of our existing cryptographic algorithms in order to allow for more reliable access to and retrieval of all sorts of data. In other words, we can offer protection against not just hackers, but also backup errors, system crashes, and other catastrophic failures that are actually much more likely to affect the average user than an Internet security breach is.

iSCSI, a remote SCSI protocol, offers very good potential for interaction with cryptography. A redundancy caching technique, somewhat like RAID 5, could be integrated with a secret share system where, e.g., the data could be read as long as 80% of the remote drives (and thus their keys) could be accessed; this allows for a very high reliability storage system because individual storage drives could be distantly located, and at the same time uses cryptographic techniques to offset reliability problems that could potentially be caused by the uncertain and fluid nature of Internet connectivity.

Even issues like load balancing and methods to deal with machine down-time might all be improved by some of our cryptographic techniques.

Solution #3: Leaving Behind Fear

In talking about insurance and reliability I feel like I'm largely expanding upon a fairly well-known and conservative way of using cryptography. These are good first steps for companies that wish to move forward in a cryptography market that is shrinking due to our own success, but they're not necessarily enough for a major breakout into revenue sources that will make this once again an exciting industry from a business point of view.

What is required, I believe, is a major paradigm shift. We need to leave the whole business of fear behind and instead embrace a new model: using cryptography to enable business rather than to prevent harm. We need to add value by making it possible to do profitable business in ways that are impossible today. There are, fortunately, many cryptographic opportunities, if we only consider them.

Cryptography can be used to make business processes faster and more efficient. With tools derived from cryptography, executives can delegate more efficiently and introduce better checks and balances. They can implement improved decision systems. Entrepreneurs can create improved auction systems. Nick Szabo is one of the few developers who has really investigated this area, through his work on Smart Contracts. He has suggested ways to create digital bearer certificates, and has contemplated some interesting secure auctioning techniques and even digital liens. Expanding upon his possibilities we can view the ultimate Smart Contract as a sort of Smart Property. Why not form a corporation on the fly with digital stock certificates, allow it to engage in its creative work, then pay out its investors and workers and dissolve? With new security paradigms, this is all possible.

Federated identity is another area for potential expansion. Secure, federated identities could offer many benefits for consumers. Imagine being able to visit a third-party seller on the Internet, automatically charge a sale to your Amazon account, then automatically ship it to your standard address, all through a single secured identity token. Federated network identity also has real applicability in the business world, as is shown by the work being done by Liberty Alliance. Through a business system like this, an auto parts manufacturer could offer his products to General Motors as part of a larger bid, all without having to specifically arrange identity with GM itself.

However, there are notable challenges in the area of federated identity -- challenges which a new-paradigm security industry could lead the way in solving. Distinctions must be made regarding various levels of identity security, so that, e.g., your VPN couldn't be accessed if someone gained access to your Amazon password. In addition there are real concerns from users about controlling their user information, due to worries over spam and privacy; some users, for examples, might not want information about their politics, sexuality, or interests federated with information about their family or job. For instance do we really want our information on Orkut to be used by Google?. These challenges demonstrate why federated identity is still a leading edge possibility for the security industry.

Beyond business processes and federated identity there are many other areas that the security industry should be considering, as it moves beyond the business of fear. The whole idea of Public Key Infrastructures should perhaps be rethought, and maybe we should resuscitate lost technologies such as Attribute Certificates, and some of the ideas such as local name spaces as in described Rivest's SDSI. There are also some interesting possibilities for trusted peer-to-peer environments that can be dynamically expanded on the fly. The possibilities are only limited by our imagination, if we can just think beyond current possibilities.

We have already seen the first wave of security technology; now we need to initiate a second, for I believe with the next wave the best is yet to come.