The Quiet Enjoyment Infrastructure™ is a set of methods, procedures, and standards for fixing the Internet. Because, let's face it, the Internet is broken. People tend to look to security technologists for solutions to security problems. The latest effort to fix the Internet, the Clean Slate Design, presents advanced construction materials technology.
The technologists have done their job well. The set of construction materials upon which we build our solution to Internet problems is called ID-PKI, which was conceived in a flourish of new ideas that developed around what has been called public key infrastructure (PKI) when that technology was invented in the 1970's.
The Quiet Enjoyment Infrastructure is based upon a set of construction materials called PKI. Bruce Schneier illustrates why the fundamental technology behind PKI is so special:
"In real-world terms, it allows you and a friend to shout numbers at each other across a crowded coffeehouse filled with mathematicians so that when you are done, both you and your friend know the same random number, and everyone else in the coffeehouse is completely clueless. If this sounds ridiculous, it should. It sounds impossible. If you were to survey the world’s cryptographers in 1975 they would have told you it was impossible." - Bruce Schneier, Secrets and Lies: Digital Security in a Networked World. John Wiley & Sons, 2000.
-
What is PKI?
PKI is an astoundingly good set of construction materials that should solve all our security problems. When the keys used by PKI are large enough, the essential building material has never been broken. In decades of PKI history: zero intrusions.
Bruce Schneier and Carl Ellison co-authored a paper explaining why such wonderful technology has not been successful in real-world deployment. Read that paper combined with a detailed explanation of why QEI fills in the gaps and makes PKI successfully deployable by clicking PKI Detail below.
Or if you'd rather not read pages of technical details, let us sum it up for you:
PKI is a set of construction materials. PKI experts regularly lament that it seldom assembles itself into a building, in spite of the fact that they have educated potential building owners on how PKI materials work.
If you have ever been involved in a construction project, or even if you haven't, the reason why a set of construction materials fails to assemble itself into a building should not be difficult to grasp. This is particularly true if you're not too close to the technology to see where it ends and the rest of the world begins.
Read on, and learn how the Quiet Enjoyment Infrastructure provides the things that turn a set of PKI construction materials into buildings that are usable in the real world. Then judge for yourself whether QEI will fix the Internet.
-
The Difference Between Highways and Buildings
The PKI enthusiasts' belief that their new technology solved everything was quite analogous to the feelings of the nineteenth century inventors of concrete and steel, who believed that their creations would cause twenty story buildings to begin popping up in cities around the world. When the practical realities of fitting new technology with an existing construction infrastructure prevented that from happening, they got discouraged. They began to doubt the relevance of their new construction materials to the practical world of real estate.
Precisely the same thing happened with PKI.
One problem with PKI is its name. It's meaningful to people who understand cryptography, but it does nothing to help the understanding of those who must be involved in its deployment. QEI fixes this admittedly peripheral problem, as we will see later with our new interpretation of the initials PKI. QEI makes PKI Construction materials useful in the real world of real online buildings.
-
What is the Internet?
If the Internet is, as originally purported, an information highway, then what is a highway but a public, outdoor transport facility? If we were to use our physical highways as we use the information highway, we'd be keeping our files, holding our meetings, and letting our kids hang out in a busy outdoor rest area alongside the Interstate.
In the physical world, we put our vehicles onto highways to bring us to buildings. As we will see, this metaphor of physical buildings set apart from the highway has real depth. But we must be willing to really learn from the world's experiences over centuries in making buildings useful, manageable, and secure. We are not borrowing a concept here and there; we are importing the bulk of the methods and procedures of the world of physical facilities into our world of online facilities.
A set of secure building materials does not make a secure building. That requires the services of professionally licensed architects, contractors, structural engineers and building inspectors. It requires building codes and occupancy permits. Most of all, it requires duly constituted public authority - DCPA - to stand behind those certifications and behind the certification of the identities of all involved. The inventors of PKI understood the need for something called a certification authority while treating the term glibly. QEI ensures that authority means real authority, not some technology placeholder for a business opportunity. -
Identity is the Foundation of Security
Online buildings also require something that is not part of the design of physical buildings. Online, we normally don't have visual and aural cues that tell us who's in the room with us -- and so we need reliable identity credentials to make online buildings work.
In the physical world, the foundational identity credential is the birth certificate, issued by the vital records department at city hall. In the global village, where packets don't know anything about the boundaries between cities, provinces, nations and continents, city hall must be a world city hall. Packets also have no way of consulting a paper birth certificate, so QEI's foundational identity credential is naturally a key pair, issued and signed by city hall pubic officials in a proper enrollment procedure. -
PKI Detail
Q: If PKI is so good, why hasn't it solved our security and privacy problems? A: PKI is only a set of construction materials.
To make a secure building you need licensed architects and contractors, building codes and occupancy permits in addition to construction materials. You also need a source of duly constituted public authority, a city hall, to do all that licensing and certifying.
QEI provides ten solutions to ten problems.
The facts about public key cryptography are truly remarkable. As Bruce Schneier noted in his book Secrets and Lies4,
In real-world terms, it [public key cryptography] allows you and a friend to shout numbers at each other across a crowded coffeehouse filled with mathematicians so that when you are done, both you and your friend know the same random number, and everyone else in the coffeehouse is completely clueless. If this sounds ridiculous, it should. It sounds impossible. If you were to survey the world's cryptographers in 1975 they would have told you it was impossible.
No one has ever cracked any of the standard pkc algorithms when keys are of normal length. For that matter no one has ever cracked the old 1024 bit standard RSA; the most common key length these days is 2048 bits. Public key cryptography is so good, and the entire PKI set of construction materials is so good, that it seems that PKI should be able to solve all of our security and privacy problems. So why do we still have security and privacy problems?In 2000, Bruce Schneier and Carl Ellison attempted to answer that question with a paper entitled "Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure."
The Quiet Enjoyment Infrastructure, introduced at the NIST PKI Technical Working Group meeting on November 20, 2003, is a set of methods, procedures and standards that provides a comprehensive solution to the problems caused by pervasive inauthenticity in real world online spaces such as the Internet. Click here for an overview of QEI.
From the book Quiet Enjoyment by Wes Kussmaul, PKI Press, 2004:
What is public key infrastructure (PKI)? Let's start with the definition of public key infrastructure that appears in The Open Source PKI Book. PKI is:
The set of hardware, software, people, policies and procedures needed to create, manage, store, distribute,and revoke PKCs [public key certificates] based on public-key cryptography.
The Quiet Enjoyment Infrastructure is a PKI that is designed to overcome the problems that have been encountered in previous PKIs. QEI is a PKI that benefits from the hindsight gained in two decades' worth of collective experience implementing PKI in the real world.
Actually the term "public key infrastructure" reveals its own first big hole, for public keys are useless without private keys. Why then do we have an well designed public key infrastructure without a correspondingly well-thought-out private key infrastructure? The answer has to do with the assumption of liability, the multitude of options for private key containers, and other elaborate excuses for not finishing the job. Dog ate homework.
QEI is really a PKI+PKI+, a combination of public key infrastructure, private key infrastructure, and additional elements that have everything to do with authenticity and accountability and nothing to do with technology.
Ten Answers to Ten Famous "Risks" of PKI
On September 16, 2001, two distinguished cryptographers and security authors put forth1the definitive critique of the way PKI is implemented and deployed.
The authors' bios, from their document:
Bruce Schneier is the author of Applied Cryptography, the Blowfish and Twofish encryption algorithms, and dozens of research papers and articles on cryptography and computer security. He is CTO of Counterpane Internet Security, Inc., a managed security service company offering leading-edge expertise in the fields of intrusion detection and prevention, preemptive threat discovery, forensic research, and organizational IT systems analysis.
Carl M. Ellison is a Senior Security Architect for Intel Corporation, with special focus on cryptography, cryptographic access control and public key certificates. Prior to the focus on cryptography, his earlier professional computer science career focused on system design with special emphasis on distributed and networked systems.
A little further background on the paper helps illustrate what this is all about.
One of Bruce Schneier's unique talents is to be able to write about security at any level. His newsletter, Crypto-Gram, includes common-sense reflections on things like airport security, while his other works such as Applied Cryptography delve into the deepest reaches of the number theory mathematics behind asymmetric cryptography. At about the same time the paper was published, Schneier also published Secrets and Lies, a comprehensive book for general audiences about digital security.
The 400-page book ends with a three page afterword that is really a lament. He describes an epiphany, a realization in 1999 that "Beautiful cryptography was regularly compromised through bad implementations. Carefully tested implementations were being broken through human errors. We would do all this work, and systems were still insecure.
He continues, "I came to security from cryptography, and thought of the problem in a military-like fashion. Most writings about security come from this perspective, and it can be summed up pretty easily: Security threats are to be avoided using preventive countermeasures," followed by some elaboration of the point, then
"Imagine my surprise when I learned that the world doesn't work this way. I had my epiphany in April 1999: that security was about risk management, that the process of security was paramount, that detection and response was the real way to improve security, and that outsourcing was the only way to make this happen effectively..."
"I've realized that the fundamental problems in security are no longer about technology; they're about how to use the technology. There's no way to turn what we do [Counterpane's monitored security services] into a product."
The epiphany is what makes Bruce Schneier's contribution so valuable. So many of the people in the security business, including the vendors that Schneier goes on to be so critical of, are stuck in the military-countermeasures view of security: As a general secures a province, so we should secure our businesses.
Trouble is, the only thing you can do in a war zone is wage war. You can't get any real world work done in a war zone. You can secure your company's network using the military approach, just don't expect to be able to use it for anything except its own self protection.
But Schneier's epiphany does not take us all the way out of the war zone. He is still saying that the only hope is human detection, response, and monitoring. We're still seeing the network as an essentially outdoor space to be patrolled by highly trained guards with dogs.
That's still not realistic. The physical world continues to provide us with the apt metaphor. In it, businesses have guards, sure, but are they highly trained military personnel with high powered rifles patrolling an outdoor perimeter defined by a tall chain link fence topped with razor wire? Of course not, that's way over the top for businesses, health care organizations, and every other kind of organization except the small minority of highly secure operations requiring an outdoor perimeter.
Most organizations have something better, more practical than a secure outdoor perimeter. It's called... a building. A building provides the possibility of usable facilities for small organizations that could never afford that Counterpane-style trained perimeter guard. A few minimally-trained and minimally-paid security guards taking turns sitting at a reception station are quite sufficient to secure the typical office building, provided the building is properly designed and constructed.
Our response to the ten risks of PKI should be seen as the response of a businessperson to a paper entitled "Ten risks to securing spaces with building materials for people who have never seen a building." Our response is, "Hey, these PKI building materials are good solid stuff, why aren't we building buildings with them!" If I may be so presumptuous, I suggest that the real destination of Bruce Schneier's intellectual quest away from the military model of security is: real estate. This is all about providing security with bounded indoor spaces, which then make security monitoring so much easier. Not only that, it turns networks into actual usable places of business.
The QEI Real Estate Response
Following is the QEI response, point by point, to the Ellison and Schneier challenge. First, the preface to their work:
Computer security has been victim of the "year of the..." syndrome. First it was firewalls, then intrusion detection systems, then VPNs, and now certification authorities (CAs) and public-key infrastructure (PKI). "If you only buy X," the sales pitch goes, "then you will be secure." But reality is never that simple, and that is especially true with PKI.
Certificates provide an attractive business model. They cost almost nothing to make, and if you can convince someone to buy a certificate each year for $5, that times the population of the Internet is a big yearly income. If you can convince someone to purchase a private CA and pay you a fee for every certificate he issues, you're also in good shape. It's no wonder so many companies are trying to cash in on this potential market. With that much money at stake, it is also no wonder that almost all the literature and lobbying on the subject is produced by PKI vendors. And this literature leaves some pretty basic questions unanswered: What good are certificates anyway? Are they secure? For what? In this essay, we hope to explore some of those questions.
QEI Response:
Schneier and Ellison start by hitting the nail on the head. Not to beat the point to death, but if your customer doesn’t know what to ask for but has a vague pain called “lack of security” then you naturally look in your inventory of pharmaceutical products for the highest-margin drug that will lessen that pain. It’s just business. In most cases the customer is a business, engaged in its own quest for high margin drugs to treat the pains of its own customers. Business ethics calls for selling drugs that really work to treat the pain, not for questioning the customer’s pain and suggesting that it’s really an underlying ailment that should be treated. Not only is that above and beyond the call of duty for most businesses, the behavior is likely to lose a customer. “Sell the customer what he says he wants, not what you think he should want” is the first lesson in Marketing 101.
That’s why I’m selling books instead of widgets. True, we have a widget called VIVOS® to sell, but when we went to sell it we discovered that there was no market for it because it did not address anyone’s identified pain.
The vendors are stuck in a difficult place. We agree that there has been a great deal of techno-gadgetry opportunism in the PKI tools business. At the same time, those very same vendors – Baltimore2, RSA, Entrust – spend a fortune on market education, trying to impart some context to their CA server products. But it’s not as though they have options. What are they supposed to do – put their intellectual property assets, their development teams, their branding efforts on the shelf and tell their customers to listen up and get it right before they start spending money on solutions?
And what do the vendors of certificates do about their lack of the most important ingredient in any digital certificate? No matter how good their development teams, no matter how secure the protection of their root, not having duly constituted authority in a certificate is like a jewelry manufacturer gradually discovering that the material it has given its artisans to craft their fine work with is brass instead of gold. What are they supposed to do, voluntarily go out of business?
For a system to be sustainable in operation – in real life as opposed to pilot projects – it must have real demonstrable integrity. People trust the banking system to keep track of their money not because they understand the technology of banking. Rather, they trust the banking system because experience tells them that banks do not lose depositors’ money. (Hopefully Chapter 5 helps some bankers in their effort to sustain that confidence.) Depositors also benefit from a vague understanding that governmental authority is involved in banking. Without that authority, the pain of uncertainty about banks would surely keep more currency in mattresses.
As with any good business opportunity, those who go for the quick hit soon learn that you must deliver enduring value if you want to build a sustainable business. Unfortunately, it is the credibility of the industry itself that has taken the biggest hit with the security fad approach of some vendors.
There are those who are trying to paper the walls of the Internet with inexpensive – and dangerously meaningless – soft certificates. Tabelio will differentiate itself from the certificate hucksters by delivering genuine enduring value in the form of reliable identity credentials based upon genuine authority that can be used anywhere. Certificates “cost almost nothing to make” only if they are only made out of technology. In that case the cost of making a certificate is the same as the cost of making any other file on your computer.
But paper certificates also “cost almost nothing to make.” Would we say that about an FAA airworthiness certificate issued to Boeing to permit the sale of a new airliner? Sure, the paper upon which it is printed costs almost nothing. However, the cost to Boeing to demonstrate compliance, and the cost to the FAA to examine that petition, runs into the millions of dollars for each party.
Similarly, Tabelio Birth Certificates are made of materials that cost almost nothing. However, the time and expertise and assumption of risk and responsibility on the part of the Tabelio Officer and those managing the network of Tabelio Officers cost plenty. We will demonstrate that the cost is worth it. A Tabelio Birth Certificate will really mean something to all relying parties.
Tabelio is a token-based system. While a token-based system is more costly to deploy than one based upon soft certificates, it’s nevertheless our belief that two-factor or three-factor authentication is necessary in establishing identity in most environments. The Tabelio Wallet can also house single-factor identifiers like the simple serial number found in a Mobil Speedpass token, and a multitude of others.
Furthermore, the mass deployment of credentials – either soft or hard – results in a world awash with meaningless identity credentials. The only way to issue certificates that can later be relied upon to certify a person’s identity is in an old fashioned, labor intensive, time consuming face-to-face setting at the same time the person’s identity is established. Anything else is folly.
Yes, the operation of a PKI can provide profits to the enterprise which operates the CA and for its suppliers as well. But the parts of QEI that will replace the role of “PKI Vendors” include those that resemble the birth and death records department of a municipality. Once again, the ingredient that must be added is authority. Even the supplier of PKI tools and building blocks must submit to the authority of building inspectors, who ensure that their building materials are up to code. Tabelio’s challenge is to supply trust in a system that we believe will bear up under the closest scrutiny. “Closest scrutiny” starts with the scrutiny of Carl Ellison and Bruce Schneier. We invite your critical examination of QEI. The paper then goes beyond certificates to PKI:
The paper then goes beyond certificates to PKI:
Security is a chain; it's only as strong as the weakest link. The security of any CA-based system is based on many links and they're not all cryptographic. People are involved.
Does the system aid those people, confuse them or just ignore them? Does it rely inappropriately on the honesty or thoroughness of people? Computer systems are involved. Are those systems secure? These all work together in an overall process. Is the process designed to maximize security or just profit?
Each of these questions can indicate security risks that need to be addressed.
Before we start: "Do we even need a PKI for e-commerce?" Open any article on PKI in the popular or technical press and you're likely to find the statement that a PKI is desperately needed for e-commerce to flourish. This statement is patently false. E-commerce is already flourishing, and there is no such PKI. Web sites are happy to take your order, whether or not you have a certificate. Still, as with many other false statements, there is a related true statement: commercial PKI desperately needs e-commerce in order to flourish. In other words, PKI startups need the claim of being essential to e- commerce in order to get investors.
There are risks in believing this popular falsehood. The immediate risk is on the part of investors. The security risks are borne by anyone who decides to actually use the product of a commercial PKI.QEI Response:
PKI is an ideal set of materials for constructing secure environments in which all sorts of things can happen, including transactions. But if you’re looking to secure one process – a transaction for example – then yes, PKI is probably overkill. E-commerce is flourishing in the retail environment and in some industrial environments with simple SSL connections – that is, a few fragments of a PKI. There are substantial mechanisms in place to secure many transactions without a PKI.
However, Ellison and Schneier need to heed their own comments about including people in design considerations. They note that the links in any CA-based system are not all cryptographic, that people are involved. They note that such systems often do not aid people, that they often confuse them and ignore them.
The same goes for all aspects of e-commerce systems, and the same criticism can be made of the transaction view of e-commerce. While the cryptographers all talk about e-commerce as though it’s nothing but purchase and sales events, in fact the primary activity in e-commerce is communication. It starts with meetings, listening for the other party’s needs, presenting solutions, negotiating, collaborating, politicking, proposing, counter-proposing, counter-counter-proposing, abandoning, re-opening, quoting, quibbling – and finally ordering and delivering. If that process can’t take place within a space whose security is accepted and taken for granted by its occupants, then the process must resort to costly, tedious, and time-consuming air travel. Then there is communication in the context of a collaborative application. Various parties to a business relationship are sharing databases, spreadsheets, project plans, Quark and Illustrator files, all of which must be kept secure and none of which has anything to do with a transaction.
OK, I am beating the horse to death, but this is the crux of the matter, popping up before we get to the specific objections. The world is struggling to find ways to rely upon collaborative environments; it is not struggling to secure transactions. Transactions are fairly under control. The problem presents itself with the online spaces where those transactions take shape. In any fairly sizable business deal the actual transaction is almost an afterthought. It’s usually initiated in a phone call after months of negotiations. Whether the resulting purchase order or contract is XML formatted and beamed into a SOAP-based order entry system or is faxed or Fedexed is utterly insignificant.
But PKI is very much needed for the collaboration part of it. If you are in an online space discussing a major new purchase, and the details of that conversation reveal a lot about your company’s operations and plans, you need to know who is in that room with you.
Information technology wants to become media. That is just an inexorable process that seems not to get much notice. The latest form of media adds aspects of real estate. But it is real estate / media, not technology / real estate / media. There is no more technology to it than there is to your TV set, which is to say there is plenty of technology to it but it is all hidden behind the sheetrock, you never have to deal with it. Just as physical meeting rooms are not managed by the architects and contractors who built them, online meeting rooms should be managed by those who have something to accomplish in them.
Online collaboration tools are still sold as an information technology item to information technology buyers decades after they reached a remarkable level of maturity as consumer media. You can set up online realtime and standing conference facilities as a consumer, anytime, without the intervention of information technology professionals, or you can pay hundreds of thousands of dollars for a year’s development effort that may yield essentially the same thing if you’re lucky. The same should be true of PKI. You can buy all the widgets and the thousands of hours of costly consulting time to set one up for your organization, then struggle for years to get it working and usable and accepted, or you can accept the idea of realmediaestate PKI whose identity credential is the individual’s permanent property and therefore to be managed by the individual. The CA is managed by the very people whose liability was created in the enrollment process. The relying party merely has to maintain directories, access control lists and privilege assignments. I believe that the result will be a PKI that is as easy to construct as a Delphi Forum. If you have a few minutes to spare, go build one of those right now. In the future, expect the construction of a small PKI to be about as simple as that.
So far we’ve just addressed the preamble to the paper. Let’s move on to the ten risks.Risk #1: "Who do we trust, and for what?" There's a risk from an imprecise use of the word "trust." A CA is often defined as "trusted."
In the cryptographic literature, this only means that it handles its own private keys well. This doesn't mean you can necessarily trust a certificate from that CA for a particular purpose: making a micropayment or signing a million-dollar purchase order.
Who gave the CA the authority to grant such authorizations? Who made it trusted?
A CA can do a superb job of writing a detailed Certificate Practice Statement, or CPS – all the ones we've read disclaim all liability and any meaning to the certificate – and then do a great job following that CPS, but that doesn't mean you can trust a certificate for your application. Many CAs sidestep the question of having no authority to delegate authorizations by issuing ID certificates. Anyone can assign names. We each do that all the time. This leaves the risk in the hands of the verifier of the certificate, if he uses an ID certificate as if it implied some kind of authorization.
There are those who even try to induce a PKI customer to do just that. Their logic goes: (1) you have an ID certificate, (2) that gives you the keyholder's name, (3) that means you know who the keyholder is, (4) that's what you needed to know. Of course, that's not what you needed to know. In addition, the logical links from 1 to 2, 2 to 3 and 3 to 4 are individually flawed. [We leave finding those as an exercise for the reader.]QEI Response:
As with most computer security considerations, it is important to start at the beginning. Most of our security problems come from neglecting that simple ordering of steps.
If you subscribe to the motto of The Village Group, Identity Is The Foundation Of Security, then Step One must be a sound procedure for the establishment of identity.
The Authority Infrastructure provides the strongest possible authority platform upon which to build a professional practice of identity verification and credential issuance. The credential itself is a simple digital birth certificate.
A Tabelio token does not attest to employment status, character, network privileges, banking relationships, health care entitlements, or for that matter any relationships. A Tabelio Birth Certificate simply attests to the existence of a human being and a binding of that human being to certain immutable information (name at birth, place and time of birth, parents’ names at birth, parents’ address(es)) and a key pair. All else, all relationships which the token is used for, are the responsibility of someone other than the Tabelio Officer who issued the credential.
Security experts talk a lot about the problem of establishing that a person is whom he or she says she is. That problem is made enormously difficult when the establishment of identity is a byproduct of a relationship, typically an employment relationship. Tabelio removes that complexity. In the process of certificate issuance, all a Tabelio Officer cares about is the validity of a person’s assertion of identity. The use of that identity is the TBC owner’s concern.
Are we refuting the statement about the link between the key pair and the individual, that “that's not what you needed to know” is inaccurate – are we saying that’s what you did need to know? No, we are in agreement if we take the statement literally; and that does not refute the position that Identity Is The Foundation Of Security. On top of that foundation are all the access controls and relationship information and privileges that have practical use in deciding what an individual ought to be able to do while online.
What we are saying, however, is that if you don’t start with a foundation of reliable identity then any authorization structure you build on top of unreliable identity is itself unreliable – like constructing a building on an unstable foundation. So we are in agreement on literal semantics, but not on emphasis.
Identity is where it’s at.
Risk #2: "Who is using my key?"
One of the biggest risks in any CA-based system is with your own private signing key. How do you protect it? You almost certainly don't own a secure computing system with physical access controls, TEMPEST shielding, "air wall" network security, and other protections; you store your private key on a conventional computer. There, it's subject to attack by viruses and other malicious programs. Even if your private key is safe on your computer, is your computer in a locked room, with video surveillance, so that you know no one but you ever uses it? If it's protected by a password, how hard is it to guess that password? If your key is stored on a smart card, how attack-resistant is the card? [Most are very weak.] If it is stored in a truly attack-resistant device, can an infected driving computer get the trustworthy device to sign something you didn't intend to sign?
This matters mostly because of the term "non-repudiation." Like "trusted," this term is taken from the literature of academic cryptography. There it means something very specific: that the digital-signature algorithm is not breakable, so a third party cannot forge your signature. PKI vendors have latched onto the term and used it in a legal sense, lobbying for laws to the effect that if someone uses your private signing key, then you are not allowed to repudiate the signature. In other words, under some digital signature laws (e.g., Utah and Washington), if your signing key has been certified by an approved CA, then you are responsible for whatever that private key does. It does not matter who was at the computer keyboard or what virus did the signing; you are legally responsible.
Contrast this with the practice regarding credit cards. Under mail- order/telephone-order (MOTO) rules, if you object to a line item on your credit card bill, you have the right to repudiate it – to say you didn't buy that – and the merchant is required to prove that you did.QEI Response:
Digital signature legislation is actually much worse than that. It provides no significant standards for what constitutes a digital signature that can bind a signer as strongly as a wet signature.
TCPA, Palladium, Embassy Trust, cME, and LaGrande are versions of what we are calling a Local Crypto Infrastructure (LCI). Any one of them that is certified to the Osmium standard addresses this problem. Since the earliest of these efforts were just getting underway when “Ten Risks” was written, one might think that the LCI takes care of it. But it doesn’t. Schneier and Ellison point out risks that are present even in an Osmium-certified LCI-secured system. Basically, how do we know it’s really you using that LCI-secured computer?
This problem underscores the reason why the credential must be used to secure personal assets and relationships, not just company assets and relationships. It’s the bank ATM card factor. People do not share their ATM cards and therefore the cards are remarkably secure in spite of their obsolete technology. People don’t share their bank cards because those cards grant access to personal assets. It’s very simple.
Whether it is contained in a USB dongle, button jewelry, proximity device, vicinity device, smart card, or other device, a Tabelio Wallet carries multiple keys. They range from the simple serial number, giving one-factor protection to not-terribly-important resources, up to the private key that is only released for use with three factors and which never leaves the token. Because the token is carried with the person whose identity is being authenticated, it can in actual practice be more difficult to hack than the highly secure stationary computer with “physical access controls, TEMPEST shielding, ‘air wall’ network security, and other protections.” That’s because the secure computer sits still for the hacker while he or she tries to get at its contents. The token, on the other hand, has two things going for it:
Possession: in order to hack it you have to get at it.
Isolation: the private key is not surrounded by a general-purpose operating system, the kind with all sorts of exploration facilities built in and new holes always being discovered. Rather, the key is kept by an operating system – you – that only has one security job: guard the key.
The token itself is issued by a person using a piece of equipment that is designed to meet FIPS 140-2 standards. Its case can only be opened by damaging it or by its custodian and operator, a Tabelio Officer. The Tabelio Officer is trained to look for signs that the equipment’s tamper-evident cabling has been disturbed, or other signs of tampering, at the start of every authentication session. The equipment must be kept in a secure place.
Most importantly, a Tabelio Officer has something significant to lose if he or she is guilty of not doing their job properly. Every Tabelio Officer is a duly appointed notary public with an active commission; criminal penalties apply if malfeasance in office can be demonstrated. In traditional practice, notaries outside of Latin law jurisdictions seldom go to jail if they perform their job sloppily. With Tabelio, however, that laxity is no longer taken for granted. A Tabelio Officer will know that Tabelio will put its resources toward such prosecution in order to enforce its standards.Risk #3: "How secure is the verifying computer?"
"How secure is the verifying computer?"
The previous section showed that the computer holding or driving the private key needs to be secure. Long keys don't make up for an insecure system because total security is weaker than the weakest component in the system.
The same applies to the verifying computer – the one that uses the certificate.
Certificate verification does not use a secret key, only public keys.
Therefore, there are no secrets to protect. However, it does use one or more "root" public keys. If the attacker can add his own public key to that list, then he can issue his own certificates, which will be treated exactly like the legitimate certificates. They can even match legitimate certificates in every other field except that they would contain a public key of the attacker instead of the correct one.
It doesn't help to hold these root keys in "root certificates." Such a certificate is self-signed and offers no increased security. The only answer is to do all certificate verification on a computer system that is invulnerable to penetration by hostile code or to physical tampering.QEI Response:
There is no getting around it, the root private key of a PKI system must be kept in a very secure facility. Your average corporate computing center just will not do. No matter how important a company considers its secrets, no matter how thorough the policies and technologies used to secure corporate information, the fact is there’s too much going on in companies for their information facilities to be the kind of ivory tower environments that a root key requires.
By contrast, a root key that is used only to certify identity records just does one simple same thing over and over and over. That kind of activity is the opposite of typical datacenter commotion.
The physical environment of the root key of the World e-Trust unit of the International Telecommunication Union is the sort of thing that marketers like to invoke as a source of drama for presentations: it’s kept in a bunker under a mountain in the Swiss Alps. More significant are the procedural safeguards that are used to protect its use. It is protected by some of the best physical measures available. They don’t give guided tours of the root key facility to tourists.
The ITU World e-Trust root private key is accessible only when a quorum of individuals from the commission, each with his or her own identity credentials, is present at the same time at the console, after having been admitted through substantial physical security apparatus.
In its regular online use, the ITU World e-Trust unit is similarly well protected.
But since the Ten Risks paper was written, a very promising new way to do certificate verification, called Novomodo, has been launched. With Novomodo one needn’t send packets into the bunker, trusting that anything other than a simple validation request will be trapped. With Novomodo, a simple hashing procedure does the job with little demand on resources and no communication with the root. If Novomodo lives up to its early promise, QEI will use it for credential verification. Other methods that avoid the difficulties of OCSP and CRLs may also be used, as they prove themselves in practice.
Another technology that has come along since the Ten Risks were compiled is PassMark. PassMark plants an image that is unique to, and secretly chosen by, the user in the context of a certificate contents presentation window. If you see your own PassMark in the certificate contents window, you know that the certificate is not a replay of something captured by our friend Eve, the “man” in the middle.
Risk #4: "Which John Robinson is he?"
Certificates generally associate a public key with a name, but few people talk about how useful that association is. Imagine that you receive the certificate of John Robinson. You may know only one John Robinson personally, but how many does the CA know? How do you find out if the particular John Robinson certificate you received is your friend's certificate? You could have received his public key in person or verified it in person (PGP allows this), but more likely you received a certificate in email and are simply trusting that it is the correct John Robinson. The certificate's Common Name will probably be extended with some other information, in order to make it unique among names issued by that one CA.
Do you know that other information about your friend? Do you know what CA his certificate should come from?
When Diffie and Hellman introduced public-key cryptography, they proposed a modified telephone directory in which you could find public keys. Instead of name, address, and phone number, it would have name, address, and public key. If you wanted to find John Robinson's public key you would look him up in the directory, get his public key and send him a message for his eyes only using that public key. This might have worked with the Stanford Computer Science Department phone directory in 1976, but how many John Robinsons are in the New York City phone book, much less in a hypothetical phone book for the global Internet?
We grow up in small families where names work as identifiers. By the time we're 5 years old, we know that lesson. Names work. That is false in the bigger world, but things we learn as toddlers we never forget. In this case, we need to think carefully about names and not blindly accept their value by the 5-year-old's lessons locked into our memories.QEI Response:
Ah, here we have the crux of the global village. In a village one is known individually. Can this happen on a global basis? Can there truly be a global village?
It turns out that the size of the population in a system does not affect this problem all that much. The fact that there may be fifty thousand John Robinsons in a worldwide QEI system doesn’t really cause much more trouble than three John Robinsons in your company’s network.
Yes, important information will occasionally be sent to the wrong John Robinson. But then, how bad is this situation in actual practice? How often do people send really sensitive private information to someone whose identity they’ve just dug up in a directory, whether a traditional phone directory or a Tabelio directory? You get to the point where you’re exchanging that kind of information after having engaged in discussion and information transfer of a less sensitive sort.
The global village will require some innovative thinking about the problem of ambiguous identities. The Personal Intellectual Property Infrastructure with its Disclosure Practice Statement will solve the problem where too much ambiguity persists for sensitive communication or high-value transactions to proceed. At the initiative of a Tabelio Birth Certificate owner, the original enrollment recording and biometrics may be retrieved. Remember, this is a digitally signed file that cannot be altered without alerting any relying party to the fact that it has been altered. So the relying party who is still in doubt about the identity of the person to whom he is about to send ten million dollars can send a request: “Please release your enrollment recording including biometrics to me through your Disclosure Practice Statement.” The DPS, which is also digitally signed, discloses anything its owner chooses to release to a specified relying party. If after viewing the enrollment particulars, including the electronically verified image of driver’s license or passport, the signed video and audio recording of the person reciting an oath, the record of PII corroboration, and the self-supplied birth certificate information, the relying party is still not sure whether this is the correct John Robinson to send the ten million dollars to, we have one remaining question: how did you get to owe ten million dollars to this person who is obviously a complete stranger to you?
Typically, the certified identities of everyone you deal with will be in your directory, and when you encounter someone new you will probably add their identity to your directory. Only the case where your knowledge of someone goes from casual (not in your directory) to more meaningful (in your directory) will there be a possibility of confusion. If you know and deal with two John Robinsons, your directory will direct you to other information about each (address, affiliation, other) that will enable you to distinguish which one you are directing a message to. In any event, you are not likely to initiate communication with John Robinson for the first time, unannounced, by wiring money to him or sending him confidential information. It’s more likely to be “Hello, are you the John Robinson I met at the thoracic surgery conference in Atlanta in October?” If it’s still ambiguous after JR1 responds to that, then you have a very unusual, but not likely disastrous, situation on your hands.
A unified identity system with the built-in protections of the Disclosure Practice Statement will go a long way toward establishing a true village environment. But there will be occasionally be some confusion. There may even be a John Robinson who seizes an opportunity to use that confusion to his advantage when he’s approached out of the blue by someone thinking he’s someone else. Nothing new about that. But how often does that happen, now or in the future? It’s a rather marginal risk.Risk #5: "Is the CA an authority?"
The CA may be an authority on making certificates, but is it an authority on what the certificate contains? For example, an SSL server certificate contains two pieces of data of potential security interest: the name of the keyholder (usually a corporate name) and the DNS name for the server. There are authorities on DNS name assignments, but none of the SSL CAs listed in the popular browsers is such an authority. That means that the DNS name in the certificate is not an authoritative statement. There are authorities on corporate names. These names need to be registered when one gets a business license. However, none of the SSL CAs listed in the browsers is such an authority. In addition, when some server holds an SSL server certificate, it has permission to do SSL. Who granted the authority to an SSL CA to control that permission? Is the control of that permission even necessary? It serves an economic purpose (generating an income stream for CAs) but does it serve a security purpose? What harm is done if an uncertified server were allowed to use encryption? None.QEI Response:
This is where PKIs offered to the public have really come up short. Indeed, who appointed Microsoft or VeriSign to be a government? That’s the position they’ve taken, by self-certifying themselves to be root authorities to the world.
VeriSign’s Thawte unit even takes it a step further, perhaps a step beyond what’s legal. They’ve chosen to call their verification and enrollment agents “notaries” without actually requiring them to be notaries. Can you imagine what would happen if they called them “lawyers” or “police officers?” And does such a blatantly phony claim of authority actually fool anyone? A big problem with technology is its lexicography. One word may mean completely different things in different technology disciplines – or for that matter, within one technology discipline. It makes the irony of the word “discipline” amusingly obvious to anyone who cares about language. Not enough people who care about language care about technology.
Take the word server. Is it hardware, software, or some combination? Any information technology professional can recount conversations where the word was used for ten straight minutes with some participants referring to hardware and others referring to software. More amazing still is that nobody seems to care. The literature of information technology is just full of such unintentional obfuscation. It complements the intentional obfuscation in such a manner as to constitute a full employment program for consultants. That in itself should be no big deal; Jargon serves an economic role in many professions.
Sometimes, however, the misuse of a technology term conceals something meaningful to all people, not just technologists. The term certification authority or certificate authority is used by technologists in a manner that exemplifies a big source of trouble. Perhaps it’s inadvertent, but then a lot of evil is passed on inadvertently. The standard usage of “certification authority” implies a serious design flaw. In this book the term certification authority means something different from its previously accepted usage. Previous usage defines certification authority as a piece of technology. Think about this ominous usage of the term “authority.” An authority (singular noun) should be a human being or a group of human beings that brings something called authority (amorphous noun) to bear on a situation. A database or a piece of software may administer the authority granted it by a human being or a group of human beings, but it cannot itself be an authority. Yet that is what the term has meant – until now. The implication is that a piece of technology shall be the arbiter of who uses information about you.
Letting the term certificate authority slide by as a technical term used by information technologists to identify a legitimate technical process is like letting the term ethnic cleansing slide by as a technical term used by political scientists to identify a legitimate sociological process. It is precisely this semantic sleight of hand that invites Big Brother to control our lives. In this book, and I hope in general usage, a certificate authority is a person or group of human beings who serve as the authority over the usage of one or more digital certificates. A certificate authority server is a chunk of technology that implements the wishes of the certification authority. Do your part for humanity. Next time you hear someone use “certification authority” or certificate authority” to refer to a piece of technology, correct them. Tell them the proper term is “certification authority server.” Authority is a part of governance. Authority exists because those governed by authority accept the legitimacy of the authority. For example, the International Telecommunication Union has been accepted for a century and a half as the governing body of the world’s telecommunication networks. It is a part of the United Nations network of agencies. The ITU has authority because those governed by it have accepted its claim to authority.
The root certificate at the top of the pyramid, or in the Tabelio model at the center of the network, must be self-signed. Since God Himself is not signing digital certificates last I checked, the best we can do is to have all such self-signing done by an organization that possesses legitimately constituted authority. Ultimately, all authority is “self signed.” We have governments at the municipal, county, and state levels, all of which exist by the acquiescence of a people and its national government. Where did that authority come from? Why, the origin is the Declaration of Independence, a self-signed certificate of a group of people who felt they had sufficient popular backing to do such an audacious thing. Time proved them right. The whole world accepts the authority of that document.
The ITU’s root is self-signed, because the ITU’s authority is well established and is accepted by the world. Perhaps there needs to be an update to the doctrine of the Divine Right of Kings, called the Divine Right of Root Certification Authorities.Risk #6: "Is the user part of the security design?"
"Is the user part of the security design?"
Does the application using certificates take the user into account or does it concern itself only with cryptography?
For example, a normal user makes a decision of whether to shop with a given SSL-protected Web page based on what is displayed on that page. The certificate is not displayed and does not necessarily have a relation to what is displayed. SSL security does not have the ability to control or even react to the content of the Web page, only its DNS address. The corporate name is not compared to anything the user sees and there are some Web pages whose certificate is for a company that does Web hosting, not for the company whose logo appears on the displayed page. Users can't, and can't be expected to, sort this all out.QEI Response:
Even if there were a way of ensuring that every page on a website is bound to the certificate of the company making the offers and assertions on the page, that would not be enough. QEI is not just about making computers and networks more effective and secure, it is about making life better and more secure.
The problem of server certificates is a little like the problem of the Arthur Andersen signature on an audit. Exactly who is doing the attesting, Arthur Andersen or a bunch of people collectively calling themselves Arthur Andersen? Many of the business integrity problems of recent years are a direct consequence the fact that it’s been the latter. That has to change. But the problem here isn’t responsibility for attestation to reliability of financial reports, but rather attestation to reliability of active resources. A server certificate should be signed by a person, probably an officer, on behalf of an organization. It should not be “signed” by an organization. How does an organization execute a signature anyway?
But this response avoids a bigger, more important question. If you are interested in securing a connection between a client and a server, why would you do that outdoors in the first place? Servers should present secure services inside authenticated spaces, where all traffic is authenticated. Outdoor servers should do what one does outdoors: offer flashy billboards to the outdoor public. They should be designed and built with the assumption that the public includes vandals who want to destroy them, so they should be as simple as possible. Databases should never be connected to such outdoor billboards unless they are databases with nothing of any consequence in them, and the machine they run on is connected to nothing but the outdoor Internet. Tabelio does not involve itself with the manner of use of its identity certificates. As a practical manner, however, online retailers ought to sign their server certificates with one or more Tabelio certificates. That way, the assurances that are supposed to be conveyed by an SSL session are really there.
The responsibility behind SSL sessions today is as vague as Schneier and Ellison imply. Today it’s quite possible for a thief to hijack the URL of a legitimate store or bank. When the user goes to the appropriate page to enter his credit card or bank account information, the lock appears on his browser, signifying a secure SSL connection. All well and good. If the thief is diligent he will also hijack the site of some small company that has a VeriSign certificate or will get such a certificate simply by applying and paying the fee. That way the browser will show that the cert is signed by a “legitimate authority.”
GeoTrust is offering a way to trace an icon on a secure screen back to the certifying authority. A new company called SmartMarks will soon be offering an even more secure way of ensuring that the connection is genuine. That’s a step in the right direction, but as in the offline world, companies doing business in the online world can be constituted in pretty vague ways. It’s easier than ever to start a business, take money from the public, shut down, and open another business under another name.
QEI’s requirement for occupancy permits does a lot to change that. The occupancy permit for a retail facility – for any facility for that matter – requires a signature from the key of a Tabelio-authenticated human being who is ultimately accountable for what happens in that facility. That accountability may be fully indemnified by a corporation or other legal entity, and the individual’s name need not be published within the facility. But if a need for recourse arises, there is an irrefutable chain of accountability. Thieves will tend to stay away from using stuff like that because the route to jail is visible and defined. The crooks can keep their roadside stands, while most of the population changes their buying habits and abandons the outdoor spaces when making any significant purchase.Risk #7: "Was it one CA or a CA plus a Registration Authority?"
Some CAs, in response to the fact that they are not authorities on the certificate contents, have created a two-part certification structure: a Registration Authority (RA), run by the authority on the contents, in secure communication with the CA that just issues certificates. Other vendors sell CA machinery directly to the content authority.
The RA+CA model is categorically less secure than a system with a CA at the authority's desk. The RA+CA model allows some entity (the CA) that is not an authority on the contents to forge a certificate with that contents. Of course, the CA would sign a contract promising not to do so, but that does not remove the capability. Meanwhile, since security of a chain is weaker than the weakest link, the RA+CA is less secure than either the RA or the CA, no matter how strong the CA or how good the contract with the CA. Of course, the model with a CA at the authority's desk (not at the vendor's site) violates some PKI vendors' business models. It's harder to charge for certificates when you sell someone the CA code (or they get it for free, as Open Source).QEI Response:
The Tabelio Officer is both RA and CA. The certificate distribution system consists of the Tabelio Officer’s arm and hand, as she physically hands a token to the enrollee. The Tabelio Officer is responsible for his or her own entries in the CA system (others are in a backup role if the enrolling Tabelio Officer becomes incapacitated.)
The remark about “authority on the certificate contents” reveals a fundamental problem with the way PKI is conceived and deployed. Tabelio Officers are authorities on the one, and only one, thing that comprises the content of the certificate. They are authorities on the identity of the subject of the certificate, and the only thing the certificate attests to is identity. This is a fundamental difference between QEI and almost all previous PKI deployments. In the past, certificates either carried all sorts of attesting information or served as vehicles for such wide ranging attestations. For example, if the CA were to be run by an ASP on behalf of an employer, then the certificate would carry employment-related information. If the person’s employment terminated, the certificate would be revoked. If the person’s responsibilities changed, chances are they would fall under the purview of a different CA within the same company. Again, the certificate would be revoked and a new one issued. If the company got acquired, the acquirer would want to bring the new employees under its existing CA umbrella or else scrap its own to be replaced by that of the acquired company.
Can you see how impossible it is to maintain such systems? Can you imagine taking the next step, deciding that since the company has gone to the effort and expense of issuing all those certificates, that now they can use them to authenticate their dealings with health plan providers, 401k plan accounts, etc? What happens when the employee gets terminated but chooses to continue health benefits through COBRA? What happens if the company chooses a new 401k provider?
To make PKI work you must separate identity from relationships. With QEI, a person’s identity certificate may be used for anything. Hopefully we will see the day soon when it can be used to start a car or open the door to a house. (If you’re out of town and you need to let someone into your house or drive your car, you simply enter your private online office using your Tabelio ID, and link the proper authorizations to your acquaintance’s Tabelio ID for certain times.) Employers won’t have to worry about issuing or revoking certificates, they simply do what they’ve done for years, that is, maintain a roster of employees with a list of access privileges and other attributes as part of the same directory or in a separate one. The only difference is that the employee is identified by his or her Tabelio public key, which maps to traditional information such as name and employee badge number.Risk #8: "How did the CA identify the certificate holder?"
Whether a certificate holds just an identifier or some specific authorization, the CA needs to identify the applicant before issuing the certificate.
There was a credit bureau that thought they would get into the CA business. After all, they had a vast database on people, so, the thinking ran, they should be able to establish someone's identity online with ease. If you want to establish identity online, you can do that provided you have a shared secret with the subject and a secure channel over which to reveal that secret. SSL provides the secure channel.
The trouble with a credit bureau serving this role is that in their vast database there is not one secret shared with the subject. This is because credit bureaus are in the business of selling their information to people other than the subject. Worse, because credit bureaus do such a good job at collecting and selling facts about people, others who might have information about a subject are probably hard pressed to find any datum shared with the subject that is not already available through some credit bureau. This puts at risk commercial CAs that use credit bureau information to verify identity on-line; the model just doesn't work.
Meanwhile, having identified the applicant somehow, how did the CA verify that the applicant really controlled the private key corresponding to the public key being certified? Some CAs don't even consider that to be part of the application process. Others might demand that the applicant sign some challenge right there on the spot, while the CA watches.QEI Response:
QEI hits this one out of the park.
The Tabelio Birth Certificate is issued only by a Tabelio Officer in a face-to-face setting after performing a specific set of steps to establish the identity of the person to whom the credential will be issued.
The Tabelio Officer must first meet the certification requirements of an organization that is focused specifically on developing and maintaining a set of standards for the purpose that is inspired by those of the Latin notary community. Those requirements include a history of reliable performance in a profession such as magistrate, CPA, court reporter, PACE Certified paralegal, signing agent, birth and death records administration or other public records administration, immigration administration, or motor vehicle license administration.
After meeting ICCAP certification standards and receiving ICCAP certification, the candidate must undergo training and testing in identity verification, oath administration, and credential issuance. After passing tests on those subjects, and after obtaining appropriate bonding and errors and omissions insurance, the candidate may become a Tabelio Officer. The Tabelio Officer is Registration Authority, Registration Authority Operator, and Certification Authority Operator and takes legal responsibility for the consequence of his or her enrollments.
Other certificates may bind to the Tabelio Birth Certificate, which is no more than the name implies: an attestation of identity. It does not attest to the nature of any relationship or the privileges that might go with such a relationship.
This is just a brief sketch. For a more detailed view see Chapter 27, “Building the Authority Infrastructure,” and Chapter 28, “The Enrollment Infrastructure.”Risk #9: "How secure are the certificate practices?"
Certificates aren't like some magic security elixir, where you can just add a drop to your system and it will become secure. Certificates must be used properly if you want security. Are these practices designed with solid security reasons, or are they just rituals or imitations of the behavior of someone else? Many such practices and even parts of some standards are just imitations which, when carefully traced back, started out as arbitrary choices by people who didn't try to get a real answer.
How is key lifetime computed? Does the vendor use 1 year, just because that's common? A key has a cryptographic lifetime. It also has a theft lifetime, as a function of the vulnerability of the subsystem storing it, the rate of physical and network exposure, attractiveness of the key to an attacker, etc. From these, one can compute the probability of loss of key as a function of time and usage. Does the vendor do that computation? What probability threshold is used to consider a key invalid?
Does the vendor support certificate or key revocation? Certificate Revocation Lists (CRLs) are built into some certificate standards, but many implementations avoid them because they seem to be archaic remnants of the newsprint booklets of bad checking account numbers one used to find at the supermarket checkout stand. Like those booklets, CRLs are seen as too big and too outdated to be relevant. However, if CRLs are not used, how is revocation handled?
If revocation is handled, how is compromise of a key detected in order to trigger that revocation? Can revocation be retroactive? That is, can a certificate holder deny having made some signature in the past? If so, are signatures dated so that one knows good signatures from suspect ones? Is that dating done by a secure timestamp service?
How long are the generated public keys and why was that length chosen? Does the vendor support 512-bit RSA keys just because they're fast or 2048-bit keys because someone over there in the corner said he thought it was secure?
Does the proper use of these certificates require user actions? Do users perform those actions? For example, when you establish an SSL connection with your browser, there's a visual indication that the SSL protocol worked and the link is encrypted. But who are you talking securely with? Unless you take the time to read the certificate that you received, you don't know.
Even then, you may not know (cf., Risk #4, above) but if you don't even look, it's much like going into a private room with the lights off: you might know that someone else is there and your conversation is private, but until you know who that other person is, you shouldn't reveal any secret information.QEI Response:
This is really two sets of questions about two different topics.
The first set of questions is about the management of identity credentials.
The various key pairs issued by a Tabelio Officer are valid for a period of four years, after which the holder must have them renewed by any Tabelio Officer. Theoretically the Tabelio credential could be good for the lifetime of the holder, but a limited key lifetime was chosen for a number of reasons. Among other things it allows for the opportunity for quality assurance on the whole network of Tabelio Officers.
The notion of “theft lifetimes” is problematic. If the key is kept on the disk drive of a computer, then it is too susceptible to theft – its lifetime should be ten minutes. If it’s kept on a token, that is, in a chip in a card, key fob, or piece of jewelry, its owner will probably know if it is stolen. Even if it isn’t missed for a day or two, it’s useless without at least its password and possibly without its owner’s finger as well.
There is one credential that is the benchmark for the way identity credentials should be treated: the bank ATM card. The ones that get misplaced tend to be the ones that give access to accounts with not much money in them. People treat their bank ATM cards with a certain respect.
There is no reason why a Tabelio credential could not be issued on behalf of a bank, and include in its uses those of an ATM card.
Tabelio not only supports key revocation, but it also supports technologies such as Novomodo. That means Certificate Revocation Lists are actually part of the same database system with all certificate information. If someone attempts to use an expired or revoked certificate, the relying party may check its status at any time and act accordingly.
Since the Tabelio credential is designed to be used in any way its owner or its owner’s relying parties see fit, Tabelio can only make recommendations about how it should be used in creating digital signatures and how should be relied upon. Date stamps should come from secure network sources for transactions, especially important ones. Whether or not transactions should be voidable retroactive to the time when a token was reported stolen is up to the relying party. For non-transactional authentication, the question is moot.
The Tabelio Birth Certificate is actually secured by two key pairs for each authenticated party. The standard lengths of its keys are 1024 bits and 2048 bits. Most current processes will use the 1024 bit key; however, the other is available depending upon the needs of the relying party, and will become more usable and necessary as computing power increases. And of course the Tabelio Wallet that physically carries the keys can have as many keys as you might fit on a physical key ring.Risk #10: "Why are we using the CA process, anyway?"
"Why are we using the CA process, anyway?"
One PKI vendor employee confided in us a few years ago that they had great success selling their PKI solution, but that customers were still unhappy.
After the CA was installed and all employees had been issued certificates, the customer turned to the PKI vendor and asked, "OK, how do we do single sign-on?" The answer was, "You don't. That requires a massive change in the underlying system software."
Single Sign-On (SSO) might be the killer app of PKI. Under SSO, you come into work in the morning, plug in your smart-card, enter the PIN that activates it, and for the rest of the day, you don't have to do any more logins. All of that is handled for you by the SSO mechanism.
======= Attractive isn't it? Of course, it's attractive. Authentication is a pain.
Anything we can do to avoid it, we'll jump at.
Unfortunately, the security value of authentication is all but completely defeated by SSO. Authentication is supposed to prove that the user is present at the controlling computer, at the time of the test. Under SSO, when the user has to rush to the washroom, any passing person can walk up to that user's computer and sign on someplace via the SSO mechanism.
So, why are so many jumping at the CA process with such fervor? Do they use certificates out of empty ritual, just because the other guy does and it's the thing to do this year? Do they do it in order to pass the liability buck: to be able to blame the PKI experts if any insecurity sneaks through?
We are not that cynical. Our assessment is that security is very difficult, both to understand and to implement. Busy system administrators and IT managers don't have the time to really understand security. They read the trade press. The trade press, influenced by PKI vendors, sings the praises of PKIs. And PKI vendors know what busy people need: a minimal-impact solution. "Here, buy this one thing and it will make you secure." So that's what they offer. Reality falls far short of this promise, but then, this is a business and the prominent voices are those with something to sell. Caveat emptor.QEI Response:
Single Sign-On isn’t an app, it’s the way life needs to be. One problem with SSO as it’s being sold is that it is not ambitious enough. SSO should be assumed, and the infrastructure needs to support the appropriate identity tokens. In the case of physical offices (there will always be a few of those) the proximity or vicinity token and reader is part of the occupancy permit requirements, for exactly the reasons cited by Schneier and Ellison.
Wearable vicinity tokens help with the problem of presence at a workstation. A personal computer equipped with a vicinity token reader will lock itself so that it cannot be used until the person wearing the proximity token comes back into range. Some proximity systems can be set to prompt for a password after the token is back in range but before unlocking. The vicinity token is more secure than the proximity token, because it can reasonably be expected to be worn. The proximity token, good for a few centimeters, in practice is detached from the body and left near the reader, which is probably an IrDA port.
When the employee wearing a vicinity token gets up to go to the washroom, the workstation goes blank. Nothing revives it except the appropriate vicinity token in the appropriate vicinity, or in case of emergencies (when the batteries in the vicinity token wear out or some such eventuality) the system administrator’s fingerprint USB token.
The assumption here is that access within an office setting needs to be governed by vicinity tokens, while in the home the standard may call for authentication using a once-per-session token. That raises the question of such things as access to a client machine using GoToMyPC and the various other means of bypassing the screen and keyboard. The occupancy permit requires any online office facility whose physical access infrastructure includes workstations requiring vicinity tokens to require vicinity tokens of all users.
Let us repeat here the other necessary component of the QEI-compliant identity credential. Traditional SSO requires employees to always carry an identity device, and never share access credentials with anyone – for what purpose? It’s only for an on-the-job purpose, to protect only company assets.
This will come as a shock, but employees quite often are more careful about protecting their own assets than they are about protecting the company’s assets. When a new team member or advisor needs to get at a file for which she does not have the proper credentials, what happens? Everyone knows the answer: she borrows someone else’s access credential, of course. It’s just too much trouble to follow the rules; and, after, all the transgression is for the company’s benefit. The real problem is that the practice begets a culture in the organization where the assumption is that the credential means nothing. The identity credential becomes untrusted, and for good reason.
What if that access credential also provided access to its owner’s bank account, medical records, family intranet, retirement accounts, credit card accounts, religious congregation’s intranet (which of course we really know is a building) and half a dozen other places of personal importance? In other words, what if it protected both company assets and personal assets? We know the result from the answer to the question, what would happen if an employee asked to borrow another’s bank card and PIN? The first employee would of course not even bother to ask. So the result of using the credential to protect personal assets would be: an end to sharing of credentials. And the result of that would be a culture where the identity credential actually means something. Single sign-on should mean one credential to sign you on anywhere, to any application for which you have access privileges, and for that matter let you in your home and office door and start your car and let you into your retirement accounts and health records.
Mobile phones and PDAs can be used as vicinity tokens. However, the private key should not be kept in the device’s memory but rather should be kept in a separate chip that cannot be accessed by a general-purpose operating system.
Carl Ellison’s Update to the Ten Risks
When I got in touch with Bruce Schneier and Carl Ellison to get their permission to reprint their Ten Risks paper, both were accommodating. But Carl noted that a more recent paper of his offered a new treatment of the solution to PKI problems and suggested that I comment on that paper as well.
Presented at the first annual PKI Research Workshop3 in April 2002, Improvements on Conventional PKI Wisdom refines some of the points made in the “Ten Risks” paper, and took the question of the reliability of the certification authority a step further.
Most significantly, Improvements addresses the very problem addressed by QEI – the widespread difficulty that’s a consequence of the lack of reliable identities of individuals in online environments. But its author starts out with very different assumptions: since there is no reliable source of a universal ID, a reliable PKI must be a work-around of that fact.
The paper’s abstract:Abstract: This paper contrasts the use of an ID PKI (Public Key Infrastructure) with the use of delegatable, direct authorization. It first addresses some commonly held beliefs about an ID PKI – that you need a good ID certificate to use digital signatures, that the ID certificate should come from a CA that has especially good private key security, that use of the ID certificate allows you to know with whom you’re transacting and that the combination gives you non-repudiation. It then identifies flaws in those assumptions and addresses, instead, the process of achieving access control – either through an ACL plus ID, or directly. It then applies each method of achieving access control to two examples – one within a large company and one between companies.
The “flaws in the assumptions” are largely a restatement of the flaws enumerated in the “Ten Risks” paper.
Carl Ellison has been in the PKI business at least as long as I’ve been in the authenticated online environments business. His response is a loud and clear: Well, that Idea – PKI based upon individual identities – didn’t work, now how can we get PKI to work without reliable identities? And he comes up with a very good, thoroughly reasoned answer to the question. The problem is with the presumption.
My answer to Carl is this: I know that authenticated identities work in an online environment because I built a business around authenticated identities. One important reason why the identities on Delphi were reliable is that they were secured with personal assets: accounts were tied to a credit card number. Carl’s work during that same time focused on corporate networks, where the identity credential was a form of employee ID: issued to protect corporate assets but having nothing to do with the employee’s own personal assets. As we have pointed out, when a new member of or consultant to a team needs access to network resources, typically credentials are lent by another team member rather than going through the hassle of getting new credentials issued.
But QEI is not built upon one person’s subjective experience with a credit card based identity anchor. For one thing, that anchor – while strong enough for the kind of exposures in a traditional online service – is not strong enough to anchor common exposures when the world’s most common workplace becomes the personal information appliance. A more important point is that if we pour some real code-compliant authority into those empty jars whimsically labeled “Registration Authority” and “Certification Authority” then we can have genuinely reliable identities. In essence, Ellison concludes that the original goal of PKI – the control of access and privileges in a particular network facility – is the goal on which we should refocus. The original vision that followed the exhilarating revelation of public key cryptography – that is, the vision of a worldwide, universal identity-based PKI – just presented too many practical problems.1 "Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure"C. Ellison and B. SchneierComputer Security Journal, v 16, n 1, 2000
2Baltimore's UniCert platform is now owned by Cybertrust.
3Improvements on Conventional PKI Wisdom by Carl Ellison, Intel Labs, Proceedings of the 1st Annual PKI Research Workshop, www.cs.dartmouth.edu/~pki02/Ellison/index.shtml4Secrets and Liesby Bruce Schneier