Nick Szabo’s Papers and Concise Tutorials
Trusted Third Parties Are Security Holes
Copyright (c) 2001, 2004, 2005 by Nick Szabo
Introduction
Commercial security is a matter of solving the practical problems
of business relationships such
as privacy, integrity, protecting property, or detecting
breach of contract. A security hole is any weakness that increases
the risk of violating these goals. In this real world view of
security, a problem does not dissapear because a designer assumes
it away. The invocation or assumption in a security protocol design of a
“trusted third party” (TTP) or a “trusted computing base” (TCB) controlled by a third party constitutes
the introduction of a security hole into that design. The security hole
will then need to be plugged by other means.
If the risks and costs of
TTP institutional alternatives were not accounted for in the protocol design,
the resulting protocol will in most cases be too costly or risky
to be practical.
If the protocol beats these odds and proves practical, it will
only succeed after extensive effort has gone into plugging the TTP
security hole(s). TTP assumptions cause most of the costs and risks
in a security protocol, and plugging TTP security holes produces
the most benefit and profit.
As a result, we propose a security protocol design methodology
whereby the most risky and expensive part(s) of a security protocol,
the trusted third partie(s), are designed in parallel with
security protocol(s) using those parties. The objectives of
cost and risk minimization are focused on the TTPs rather
than the security protocols themselves, which should be
designed to suit the cost and risk minimized TTPs.
We also briefly discuss and reference research and implementation
in security mechanisms that radically reduce trusted third party
costs and risks by distributing automated TTPs across
several parties, only a portion of which need to act
in a reliable or trustworthy matter for the protocol
to be reliable or trustworthy.
New Trusted Third Parties are Costly and Risky
This author has professional experience implementing a
TTP that was assumed by early advocates of
public key cryptography. This TTP has come to be called
a “certificate authority” (CA). It has been given the responsibility
of vouching for the “identity” of participants. (Here
I focus on the costs imposed by the TTP; alternatives such
as PGP’s Web of Trust and SPKI have been discussed amply
elsewhere).
The certificate authority has proved to be by far the most
expensive component of this centralized public key infrastructure
(PKI). This is exacerbated when the necessity for a TTP deemed
by protocol designers is translated, in PKI standards such as SSL and
S/MIME, into a requirement for a TTP. A TTP that must be
trusted by all users of a protocol becomes an arbiter
of who may and may not use the protocol. So that, for example,
to run a secure SSL web server, or to participate in S/MIME, one
must obtain a certifcate from a mutually trusted certificate authority.
The earliest and most popular of these has been Verisign. It has
been able to charge several hundred dollars for end user certificates —
far outstripping the few dollars charged (implicitly in the cost
of end user software) for the security protocol code itself.
The
bureaucratic process of applying for and renewing certificates takes
up far more time than configuring the SSL options, and the
CA’s identification process is subject to far greater exposure than
the SSL protocol itself.
Verisign
amassed a stock market valuation in the 10’s of billions of
U.S. dollars (even before it went into another TTP business, the Internet
Domain Name System(DNS) by acquiring Network Solutions). How?
By coming up with a solution — any solution, almost,
as its security is quite crude and costly
compared to the cryptographic components of a PKI — to the
seemingly innocuous assumption of a “trusted third party”
made by the designers of public key protocols for
e-mail and the Web.
Some more problems with CAs are dealt with here.
The Internet DNS is another example of the high costs and
risks imposed by a TTP.
This one tiny part of the TCP/IP protocol stack has accounted for
a majority of the disputes and handwringing involving that protocol.
Why? Because it is one of the few areas of the TCP/IP stack that
depends on a centralized hieararchy of TTPs rather than on protocol
negotiations between individual Internet nodes. The DNS is also
the single component of the Internet most likely to fail even when
its names are not being disputed or spoofed.
The high costs of implementing a TTP come about mainly because
traditional security solutions,
which must be invoked where the protocol itself leaves off,
involve
high personnel costs. For more information on the
necessity and security benefits of these traditional
security solutions, especially personnel controls, when
implementing TTP organizations,
see this author’s essay on
group
controls. The risks and costs borne by protocol users also
come to be dominated by the unreliability of the TTP — the
DNS and certificate authorities being two quite commom
sources of unreliability and frustration with the Internet
and PKIs respectively.
Existing Trusted Third Parties are Valuable
Companies like Visa,
Dun and Bradstreet, Underwriter’s Laboratories, and so
forth connect untrusting strangers into a common trust
network. Our economy depends on them.
that many developing
countries lack these trust hubs and would benefit
greatly from integrating with developed word hubs like these. While these
organizations often have many flaws and weaknesses — credit
card companies, for example, have growing problems with fraud,
identity theft, and innacurate reports, and Barings recently
went belly up because their control systems had not properly
adapted to digital securities trading — by and large
these institutions will be with us for a long time.
This doesn’t help us get TTPs for new protocols. These institutions
have a particular way of doing business that is highly evolved and
specialized. They usually cannot “hill climb” to a substantially different
way of doing business. Substantial innovations
in new areas, e.g. e-commerce and digital security, must come
from elsewhere. Any new protocol design, especially paradigmatically
different areas such as capabilities or cryptographic computations,
will be a mismatch to the existing institutions. Since building
new TTPs from scratch is so costly, it is far cheaper when introducing
protocols from these institutionally novel security technologies
to minimize their dependencies on TTPs.
New Trusted Third Parties Can Be Tempting
Many are the reasons why organizations may come to favor
costly TTP based security over more efficient and effective
security that minimizes the use of TTPs:
Limitations of imagination, effort, knowledge, or time amongst
protocol designers — it is far easier to design security protocols that
rely on TTPs than those that do not (i.e. to fob off the problem
rather than solve it). Naturally design costs are an important
factor limiting progress towards minimizing TTPs in security protocols.
A bigger factor is lack of awareness of the importance of the problem
among many security architects, especially the corporate architects
who draft Internet and wireless security standards.
The temptation to claim the “high ground” as a TTP of choice are great.
The ambition to become the next Visa or Verisign is a power trip
that’s hard to refuse. The
