ion technology because the branch office was staffed exclusively by U.S. citizens. The request was denied.
Today, U.S. law still prohibits such a request. In fact, export restrictions put many software developers in the frustrating position of not having access to the security technology they need to run applications in a global marketplace.
More than ever, today's applications, including on-line commerce, require data confidentiality, authentication, and repudiation capabilities, all of which are available from existing cryptography technologies. Unfortunately, the governments of the U.S. and other countries are firmly opposed to the use of strong cryptography in products designed for the international market.
These restrictions are the subject of intense debate in political and computer communities alike. But if you develop software that can run on desktops worldwide, you can't wait for the debate to end. You have to find a way of dealing with export restrictions now.
Modern Cryptography
The Internet is partly to blame for this cryptography confusion. As the Net metamorpho
sed from an academic test-bed to a global information infrastructure, digital cryptography emerged from the intelligence-community closet into mainstream computing, especially as businesses embraced on-line commerce.
Public-key encryption -- where every user has a private key, which he or she never reveals, and a public key, which he or she can freely reveal -- is often the best answer for secure on-line commerce. In the public-key model, outsiders cannot decrypt any data that's been encrypted using only a private key, unless they break the encryption or the private key is compromised. To enable select recipients to decrypt data, the author encrypts the data using his or her private key and the recipients' public keys. Those parties whose public keys were used to encrypt the data can then use their respective private keys to decrypt it; they use the author's public key to establish its authenticity.
One factor that makes public-key technology attractive is
digital signatures
, where an author
uses a private key to produce a signature block based on a checksum of the document's original contents. Another factor is reliable authentication of authorship: Since the author must use a private key to create an encrypted document, no one else could have written it. Third, you can disavow forged documents: No one can forge a digital signature with a user's public key. Likewise, public-key users can "countersign" each other's public keys, thus vouching for each other. All these factors help make on-line transactions more secure.
Alternatives to public-key encryption include the aforementioned DES, a 56-bit-key-length method that uses a symmetric, or
shared-secret
, encryption scheme where trusted parties have access to a given set of encrypted data and an identical key. A shared-secret scheme permits faster decryption than is possible with public-key technologies, but if any shared-secret key is compromised, all the keys are compromised. In addition, there's no way to determine who created any g
iven data item, since any of the common keyholders could have encrypted it.
The reverse is also true. Any particular keyholder cannot conclusively disavow authorship of data encrypted with a shared key, so a third party can forge data using the shared key. This is especially true if that key is compromised without the knowledge of the authorized keyholders.
Token Security
Despite its strengths, public-key encryption isn't foolproof. It works best when the users all know each other or when they countersign each other's public keys, which effectively authenticates the keys. But in most global transactions, the principals don't know each other personally. Therefore, in a global public-key environment, a less cumbersome (and more secure) mechanism is necessary.
This has led to the appearance of commercial middle-layer companies, such as VeriSign, which are known as
certificate authorities
and act as trusted third parties. Their role is much like that of a bank that effect
ively turns your personal checks into currency. A certificate authority countersigns public keys with its own private key and makes both the user's countersigned public key and its own public key available to the general public through a well-known and secured HTTP or FTP server. Other users can download the certificate authority's public key to verify countersigned keys belonging to persons or organizations they do not personally know.
This isn't the only situation where third parties get into the global-transaction act. Another way to deal with password problems is through the use of tokens, which are generated automatically by either the encryption hardware or software or, in the key-recovery model discussed earlier, issued by a trusted third party. Tokens usually reside on a local disk and can, therefore, be portable. Tokenized encryption schemes simply substitute the contents of a token for the password that a more interactive encryption system requires. You can use tokens in either public- or symmet
ric-key encryption.
Developer Dilemmas
Since the encryption strength for any given algorithm is roughly 2 to the power of the key length, encryption using 56-bit keys is about 65,536 times stronger than the same algorithm using 40-bit keys.
But there are
several burdens
on developers seeking a simple solution to developing products for the global market. First, there's no provision for permitting the export of existing 56-bit cryptography products after December 31, 1998. Given the often-chaotic nature of product-release cycles, this could easily leave software developers unable to offer support, patches, or in-line upgrades for foreign clients who purchase 56-bit products and are unwilling or unable to upgrade to a version that supports key recovery.
Second, software developers must present a plan and a time line for implementing key recovery. That can be a tough task. A developer's customers might not be willing to sign up for key recovery as a conditio
n of purchase for future products. Besides, foreign governments are unlikely to permit the U.S. government to access the keys of foreign companies or individuals.
Third, with the addition of the Justice Department to the Export Administration Review Board membership, two-thirds of its members represent defense, intelligence, or law-enforcement constituencies, all of which have an interest in limiting the spread of strong encryption. This potentially hampers developers wishing to market products with strong encryption.
Loopholes and Strategies
U.S. software vendors have taken a number of approaches to the export dilemma. Some have simply created versions of their products that employ strong encryption for the domestic market and weak, 40-bit versions for their foreign customers. Netscape is perhaps the best-known company to adopt this strategy.
Is 40 bits good enough? Since Netscape's Navigator and Commerce Server are widely deployed in Internet-based commerce, their products w
ere among the first targets of public code-breaking efforts. On August 16, 1995, French graduate student Damien Doligez announced that he had broken Navigator's 40-bit SSL (Secure Sockets Layer) encryption in only eight
days
by using 120 networked Unix machines to test possible keys one by one (see the table
"More Bits, More Security"
). If he had had to try every key, the process would have taken a maximum of 15 days.
Lotus Notes employs a different workaround. Charlie Kaufman, the security architect for Notes 4.0, explains that the software uses a technique called Differential Workfactor Cryptography to permit its international version to comply with U.S. export restrictions. "When a bulk data key is created, a 64-bit random number is generated," he explains. "In the international version of Notes, 24 of the bits are encrypted under a public RSA key provided to us by the U.S. government. The result -- called a Workfactor Reduction Field -- is bound into the encrypt
ed data. There's no Workfactor Reduction Field in the North American edition of Notes."
Kaufman cautions that although 64-bit encryption can protect us from students like Doligez for quite some time to come, "there's no question that people who are willing to build custom hardware for cracking engines could break 64-bit encryption today, at a reasonable cost."
Sun Microsystems takes yet another route. It exports its Solaris OS with support for secure remote procedure calls (RPCs); this requires both DES encryption and the Diffie-Hellman key-exchange mechanism. (The latter is a method for two entities to interactively create their own encryption key for one-time use.) Sun avoids conflict with export laws by leaving the DES and Diffie-Hellman libraries out of the shipping product and requiring users wishing to use secure RPCs to buy a separate kit that includes these libraries.
Qualcomm uses a different strategy in the current version of Eudora, its ubiquitous freeware and commercial e-mail client.
The company has adopted a plug-in architecture to permit third parties to add modular functionality to Eudora 3.0; it has also published an open API to which third parties can write their plug-in.
Phil Zimmerman's new company, PGP, Inc., has chosen to publish its own API to allow third parties to integrate PGP encryption into their own products. In the meantime, PGP is producing 40-bit exportable and 128-bit domestic versions of its Viacrypt commercial PGP product line. PGP is also producing a PGP plug-in for Qualcomm's Eudora.
Meanwhile,
Hewlett-Packard
has announced what it calls the International Cryptography Framework. The ICF complies with the terms of the Clinton administration's executive order by proposing that an HP-made hardware-based encryption engine be incorporated into every PC, network computer, workstation, minicomputer, and mainframe.
The encryption capabilities of such a tamper-resistant chip would be activated by a software- or hardware-generated Policy Ac
tivation Token, which a network-security server controlled by a third-party "accredited agency" would issue. The chip, which HP has not yet made, would support Trusted Information Systems' RecoverKey technology, enabling government agencies, including foreign ones, to "recover" a Policy Activation Token without alerting the chip's user to that fact.
HP has announced that Intel will manufacture the ICF encryption chip for HP server, workstation, and midrange computers beginning this year. However, the proposed chip will support only 56-bit DES encryption, which may be too weak to offer reliable data integrity after 1998, when the current statutes expire. Also, the tamper-resistant design of the sealed unit can be an opportunity for the U.S. government to arrange for a "back door" into the chip, without any user being able to close that door. Developers might be reluctant to use a so-called spy on the motherboard.
Jim Bidzos says that RSA Japan, a subsidiary of RSA Data Security, has agreed to permit Ni
ppon Telephone and Telegraph (NTT) to develop and market an encryption chip that will use 1024-bit RSA public-key technology for authentication and digital signatures, as well as 128-bit conventional cryptography for bulk encryption. But U.S. companies that incorporate the RSA/NTT chip into their products still cannot reexport those products.
Alternatives for Developers
At present, there are no easy answers to the encryption conundrum. Software developers who wish to incorporate cryptographic technology into their products have only three choices. They can continue to produce 40-bit exportable versions and watch their foreign market share diminish; they can produce 56-bit export versions and sign up for a problematic key-recovery scheme; or they can simply wait for further developments to occur and, in the meantime, concentrate on lobbying Congress and the Clinton administration to further loosen current export controls.
None of these alternatives is attractive. Moreover, the race
to dominate an emerging global on-line marketplace adds increasing urgency to the need to find a solution that protects everyone's interests.
But there is good news -- as the Computer Science and Telecommunications Board (CSTB) of the National Research Council (NRC) concluded in its report on cryptography's role in securing the information society. "Widespread commercial and private use of cryptography in the U.S. and abroad is inevitable in the long run," the report says. "Its advantages, on balance, outweigh its disadvantages."
Where to Find
Hewlett-Packard Co.
Palo Alto, CA
Phone: (408) 447-4587
Internet:
http://www.hp.com
Encryption for a Small Planet
