r corporations are actively developing the tools that will allow people to apply digital signatures and to ensure that those signatures will hold up in a court of law.
Banks and money lenders aren't the only ones interested in signatures. Many companies are experimenting with signing everything from e-mail to Word documents. Signatures can provide a level of integrity and nonrepudiation that appeals to anybody worried about data forgery and tampering.
So how does it work? What are the big projects? Who's going to use it? How do you get a signature? And how do you implement signatures for your company?
What's My Sign?
There are many digital signature algorithms described in academic litera
ture. In practice, three major ones stand out: the hash-based signature, the U.S. government's Digital Signature Standard (DSS), and the RSA signature created using the classic algorithm developed by Ron Rivest, Adi Shamir, and Len Adleman. All three algorithms have different uses and different requirements.
Hash signatures.
Hash functions are similar to encryption functions; in fact, some hash functions are just slightly modified encryption functions. Most operate by grabbing a block of data at a time and repeatedly using a simple scrambling function to modify the bits. If this scrambling is done repeatedly, then there is no known practical way to predict the outcome. It is not practical for someone to modify a document in any way and make sure that the same output will emerge from the hash function.
A hash-based signature uses a cryptographically secure hash function like Message Digest 5 (MD-5) or Secure Hash Algorithm (SHA) to produce a hash value from a file. The hashing proce
dure concatenates your secret key (which you get through a third party) to the file, then hashes the file and key combination. The result, the
hash value
, is shipped with the file as a signature, but the secret key is withheld. The receiving end also has a copy of the secret key and uses it to evaluate the signature.
In the case of CyberCash's CyberCoin, users get secret keys when they sign up. Those keys are known only to their computer and the central computer. When a transaction is ready, a file containing the amount and the details is put together and then signed with the secret key. (The client assembles the file, concatenates the secret key, computes the hash function, and then ships the file and the result of the hash function without the secret key.) The central bank can check this transaction by repeating the computation because it knows the secret value as well.
The hash-based signature may be the least known of the signature algorithms. It's becoming more popular lately becaus
e it's less computationally intensive than the other algorithms. Many of the microcash payment systems like DEC's Millicent or CyberCoin use hash-based signatures to reduce the processing costs and make smaller transactions feasible. Each of these systems requires a central server to check every transaction; using faster algorithms means using less computer server power and reducing the central server load.
The major limitation of these hash-based signatures is that the receiver must also have a copy of your secret key to check the signature. This could allow the receiver to forge a signature. Maintaining these secret keys is also bothersome, and many use a shared secret infrastructure.
DSS and RSA signatures.
The other two signature algorithms, DSS and RSA, don't have this limitation. They are
public-key
algorithms -- in other words, there are two keys for each person (see the sidebar "How Public-Key Crypto Works"). One key creates a signature and is kept secret. The other
key -- the public one -- verifies the signature.
DSS was developed by the U.S. National Institute of Standards and Technology (NIST) with the National Security Agency. Only those companies that do business with the U.S. government are required to use it, and many prefer not to because it's a signature-only system. NIST chose this crippled solution because the United States government is working to discourage the use of any encryption software that will curtail the government's ability to eavesdrop. Software that provides authentication only, like DSS, is openly exportable in products, while software that uses RSA for general encryption is heavily restricted.
RSA signatures are clearly the most popular, thanks in part to the aggressive marketing, patenting, and long-term development done by RSA Data Security. The company controls many of the most important patents in the field, and although there has been substantial litigation in the area, RSA has used its position to successfully establish itsel
f as the leader. Its software and libraries can be found in the core of many products, and the company continues to employ some of the best cryptographers.
RSA Data Security was responsible, for instance, for integrating digital signature software with the Macintosh OS long before the Web took off. The company added drag-and-drop signature applets to PowerTalk (Apple's collaboration software) that would allow someone to embed a digital signature in an electronic form by merely dragging it to the icon. The firm has licensing agreements with all the major OS companies including Microsoft, IBM, Sun, and Digital, and each of these companies has added similar features to its product line, but without the same level of integration. Unlike DSS, RSA can also be used to encrypt data and provide security as well as authenticity.
Both hash-based and public-key algorithms can be adjusted to be secure by making sure that the secrets and the keys use a sufficient number of bits to resist all known attacks. Hash
-based signatures are inherently easier to attack because the secret used to create the signature is known to both sides. A break-in at either the central computer or the user's house could compromise a hash-based signature. The signature-generating key used in public-key systems, on the other hand, is stored only in the owner's computer, significantly reducing the security risk.
Whom Do You Trust?
After withstanding scrutiny for almost 20 years, the public-key digital signature algorithms themselves are quite solid. That said, they require a great deal of support and
infrastructure
. The problem is that it's impossible to be sure that a particular person's public key is really that person's public key and not a forgery. After all, the key is just a number -- it bears no resemblance to a person, nor does it carry personal data about its owner.
The popular solution to this problem is to wrap the key in a digital
certificate
, a small block of data (ma
ybe several thousand bytes long) that contains the public key and an endorsement made by someone else's digital signature. That "someone else" is called a
certificate authority
, or CA. The certificate shifts the burden of trust to this new signature. If it checks out correctly, then you have more reason to trust the public key.
Unless you don't trust the certificate authority. Then you have to check the certificate on
its
digital signature, and so on and so on. All the certificate does is shift the trust up the chain. The biggest challenge right now is to develop this
hierarchy of trust
for digital certificates.
At this point, most users' computers will investigate only one level into a certificate hierarchy. If your Web browser connects to a server that's enabled with Secure Sockets Layer (SSL),
the server will establish its identity by shipping a copy of its public key encased in a certificate. That certificate was probably produced by VeriSign, one o
f the major certificate providers for Web servers that use SSL to encrypt the data traveling between the server and the browser. The browser validates the VeriSign certificate by checking VeriSign's signature.
But again, how does the browser know that
VeriSign's
signature is valid? Does it keep going up some hierarchy? No. In this case, it stops at VeriSign because VeriSign's is a
root
certificate. In the future, we could have a
deeper hierarchy
. For instance, governments might choose to sign certificates for each other. Or the United Nations might sign the certificate of the United States, which might sign the certificates of the 50 states. And these hierarchies could coexist. The credit card companies' Secure Electronic Transactions (SET) protocol, for instance, makes provisions for both corporate certificate authorities and geopolitical certificate authorities.
But hierarchies are not the only solution. Pretty Good Privacy (PGP), the popular free encrypti
on solution, uses a network of signatures to guarantee each public key. This is called a
web of trust
. Your key might be signed by your parents, spouse, boss, and a few good friends. People who will want to verify your signature might know someone from this group and have a copy of his or her public key. If not, they might know someone who knows someone else who is once removed from the group. And so on and so on.
Existing webs of trust are too small to offer a practical solution to Internet commerce. Many credit card companies or banks are going to set up their own hierarchical networks because they need specific guarantees of identity that satisfy their models of risk. They may decide, for instance, that they'll be satisfied if a certificate is mailed to a new customer's house on a floppy disk. Banks understand the problems involved in distributing credit cards and can use their experience to ensure that certificates are safely placed in the right hands.
But while simple certificates fr
om bank-run hierarchies may be good short-term solutions, a strong web-like approach might serve the most people. Pindar Wang, chairman of the Hong Kong-based certificate authority VeriFi, says simple hierarchical structures won't work in Asia. "They are not practical," he stresses, "because the trust relationships which CAs attempt to represent are by no means static or clearly delineated outside of well-defined power structures. There is no clearly defined hierarchy -- not even a static web of trust! Instead, we find a highly dynamic gray area where spheres of influence and lines of power are constantly forming and dissolving."
U.S. certificate authorities may come to discover the same fact about the market. Cross-company alliances are already becoming more common. Corporate restructuring often takes people from project to project, making it difficult to rely on simple hierarchical certificates to provide more than just an identity (see the sidebar "Extending Certificates").
As if the hierarchy
problems aren't enough, CAs must maintain two databases: a complete list of certificates and a list of revoked certificates. After all, if when a certificate becomes compromised (e.g., an employee leaves the company or someone's computer is stolen), there must be a way to call up the CA and request that the certificate be disavowed. As you can imagine, this mechanism could be somewhat unwieldy. As time goes by, revoked certificates would pile up, demand more space, and slow down verification. Certificates based on the X.509 standard (the standard virtually everyone uses) come with an expiration date to ensure that old, retired certificates can be removed from on-line. Similarly, Nortel's Entrust system uses two types of certificates with different expiration limits (see the sidebar "Certificate Systems"). The certificates for encrypting the message data often last a much shorter time than the certificates for signing documents. Either one can be revoked independently of the other.
Shadow of a Doub
t
One of the biggest questions about certificates is how much assurance they really provide. Some, such as VeriSign's Class 1 certificates, are passed out to anyone who can fill in a form on a Web page. They are good only for establishing a consistent presence, not for guaranteeing that someone is a real person.
VeriSign's Class 2 certificates, on the other hand, are issued after a check of some consumer databases. If you have a credit rating, then you can have a certificate. It's unclear, however, whether VeriSign or anyone else has the tools available to prevent identity theft by someone who knows enough information about you. Nor is it clear what it means to have an entry in these databases. (One person received a credit card application for his dog, filled it out, and got the card. The dog pays his bill each month.)
VeriSign also offers a Class 3 license that requires someone to personally take their application to a notary, who will check identification before endorsing it. This
adds an additional layer of credibility to the certificate.
Thawte, a South Africa-based certificate authority, plans to offer an even higher grade of certificate. Thawte's plan requires that the certificate holder meet personally with a representative of the company. At this time, the company has only one U.S. representative (in North Carolina). Clearly the company will need to expand its operations if it intends to enter this high-grade business seriously.
Defining the limits of certainty is also a difficult legal problem. The various certificate authorities are trying to draw limits that are both attractive to customers and financially feasible. The
Guidelines on Digital Signatures
issued by the American Bar Association states that "a certification authority must have sufficient financial resources to (1) maintain its operations in conformity with its duties, and (2) to be reasonably able to bear its risk of liability to subscribers and persons relying on certificates issued by the cer
tification authority."
Satisfying the first requirement is straightforward. Database servers, network connections, and adequate security are well-defined problems. The second requirement, however, is very open-ended. Understanding the risks of a server failure is one thing, but defining the risks of a certificate causing grief is another.
In time, the certificate authorities may adopt a structure similar to the bonding used by locksmiths or couriers. If a certificate is misused and someone ends up with a loss, some insurance fund will actually offer compensation. The CAs will need to investigate peoples' backgrounds before offering these higher-grade certificates.
Personal Responsibility
Of course it's not just up to the certificate authorities. VeriSign requires that you keep your certificate on a "trustworthy" system. What's trustworthy? According to VeriSign, it's "computer hardware, software, and procedures that are reasonably secure from intrusion and misuse; provide
a reasonable level of availability, reliability, and correct operation; are reasonably suited to performing their intended functions; and enforce the applicable security policy."
The word "reasonable" is not precise, and its definition may change over time. It could, for instance, mean a Windows 95 client today and something completely different tomorrow if a gross insecurity appeared in Windows 95. For instance, if malicious ActiveX components proliferate, then it might be considered reasonable for security-conscious owners not to run ActiveX modules on their machines.
Users will have a responsibility to maintain their certificates on a system and pay attention to ensure that they take all "reasonable" measures to keep it secure. This responsibility will be the most onerous and difficult one for average users because the majority of people are not that conscious of computer security.
It may be impossible to determine exactly what would happen if someone lost a fair amount of money because a
certificate was compromised. In most cases, the certificate holder would probably be responsible. Only the holder's computer holds the private key necessary for signing files, so that computer would be the only likely source for the key. But the authority could also be liable if someone were able to register a different key in that person's name. VeriSign takes some precautions to ensure that the certificates are revoked only by the rightful owner. Only time and some test cases will determine whether VeriSign, Thawte, or any of the other certificate authorities are charging enough to discharge their responsibilities when things go wrong.
What's Going to Happen?
Most of the tools for creating and checking digital signatures are still in the lab. At this point, Web browsers using SSL to set up secure links are the only ones that use digital signatures very often. Others, however, have bigger dreams.
The leaders are the banks. They recognize that Internet commerce demands a way fo
r people to check the authenticity of documents like checks or credit card authorizations. The SET protocol endorsed by Visa and MasterCard is one of the most sophisticated uses of digital signatures, and these companies intend to make it a standard part of electronic commerce. According to Visa and MasterCard, the date for the finalization of SET was just moved from April 14 to May 31, so details were not available by the time this issue went to press.
Many corporations recognize that they have very little power to corral their employees and regulate what they do over the Net. It's not hard to imagine a low-level clerk committing a company to expensive contracts. Many companies like IBM, Apple, Xcert, GTE, and VeriSign are actively trying to find ways to build a corporation-wide structure for supporting digital signatures.
The lawyers are also closing in. Utah was the first to draft legislation recognizing digital signatures, and many other states are following. Unfortunately, the laws do vary s
lightly from state to state. Eventually, the U.S. government will issue its own laws that will smooth out the differences between the states. The American Bar Association has an active committee drafting recommendations for the use of digital signatures in commerce.
These forces see that the infrastructure to support digital signatures is the next necessary step for the Web. Although it's impossible to predict what the final shape will be, it's easy to see that the final environment will be largely defined by the two forces with major amounts of cash on the line: banks and lawyers.
The overall effect will be a widening network of trust. At the beginning, people may hold only certificates that are good for one organization at a time. Your hard disk will begin to look like your wallet as it becomes filled with certificates for work, health club, drivers license, scout troop, or practically any other part of life. In time, the organizations will begin to cross-link their databases and countersign cer
tificates as people grow more and more used to the structure.
"People believed that the certificate world would just be a big pyramid," says Scott Dueweke, IBM's marketing manager for electronic payment and certification. "I don't think many people who are involved in this in a deep way believe that anymore. I think you're going to see islands of trust that are corporations, associations, or governments. As the islands grow, gradually we'll have a complete network of trust."
Where to Find
Entrust Technologies Ltd.
Nepean, Ontario, Canada
Phone: 613-765-5607
Internet:
http://www.entrust.com
Who Goes There?
