Xem mẫu

Securing Windows NT/2000 Servers for the Internet 11.3.2.2 RC2, RC4, and trade secret law RC2 and RC4 were developed in the 1980s by Ronald Rivest for use by RSA Data Security. The algorithms were designed to be extremely fast and tunable: the algorithms support variable-length encryption keys, allowing keys as small as 1 bit or as long as 2048. Other than this fact and the fact that both are symmetric encryption algorithms, the two algorithms have no similarity: RC2 is a block cipher, while RC4 is a stream cipher. Both names are trademarked by RSA Data Security. Unlike the RSA algorithm, RC2 and RC4 were never patented. Instead, the algorithms were kept as trade secrets, protected by nondisclosure agreements and license agreements. Companies that had access to the RC2 and RC4 source code had to protect their trade secret measures and ensure that the code would not be revealed. Likewise, any program in which the algorithm was embedded was accompanied by a license agreement forbidding disassembly of the program. Why keep an algorithm secret? One reason that was given at the time was that the U.S. Government thought that the RC2 and RC4 algorithms were too good to be put in general circulation: perhaps the government had threatened RSA Data Security with some sort of retaliatory action in the event that the algorithms were publicly disclosed. Another reason suggested was that it was easier and cheaper to attempt to maintain the algorithms as a trade secret than to go through the exercise of patenting the algorithms in dozens of countries around the world and then attempting to police the technology. But regardless of what RSA Data Security`s rationale was for keeping the algorithms as a trade secret, the effort failed. A few years after the algorithms were put into widespread circulation, they were both publicly revealed: • In 1994, the source code for a function claiming to implement the RC4 algorithm was anonymously published on the Internet. Although RSA Data Security at first denied that the function was in fact RC4, subsequent analysis by experts proved that it was 100 percent compatible with RC4. Privately, individuals close to RSA Data Security said that the function had apparently been "leaked" by an engineer at one of the many firms that had licensed the source code. • In 1996, the source code for a function claiming to implement the RC2 algorithm was published anonymously on the Internet. This source code appeared to be based on a disassembled computer program that contained the RC2 algorithm. Many people presumed that the program disassembled was Lotus Notes, because that was the only mass-market computer program at the time that was actually using the RC2 algorithm. Under trade secret law, once a trade secret is revealed, that`s it - it`s no longer secret. Most attorneys we have spoken with believe that, while RSA Data Security maintains trademarks on the names RC2 and RC4, nothing prevents other companies from building the posted algorithms into their products and adverting "RC2 and RC4 compatibility." RSA Data Security feels otherwise. According to a statement issued by the company: It is true that RC2 and RC4 are our registered trademarks. However, our rights extend beyond the mere trademarks. We maintain that their appearance in the public domain was a misappropriation of our trade secrets. We have made a public statement to this effect. Accordingly, the public is on notice, and has been, that future or continued use is considered a continuation of this misappropriation. Moreover, the algorithms are also covered as copyrighted code and any use directly or derivatively of our code constitutes an infringement of our copyright. Essentially, RSADSI is attempting to extend patent-like protections to its trade secret intellectual property using some sort of legal theory that the fruits of a criminal activity are themselves poisoned - and, in any event, the programs that were posted were copyrighted source code. The company implies that it might take legal action against anyone who uses the algorithms without a license. Of course, threats of a lawsuit are one thing, whereas winning a lawsuit is something else entirely. On the other hand, in the past RSADSI has always made it cheaper to license its software than to fight the company in court. Furthermore, the license for the RSADSI toolkit contains not only the RC2 and RC4 algorithms, but working implementations of DES, DESX, RSA, Diffie-Hellman, and many other useful functions. Therefore, it is likely that most companies that wish to use RC2 or RC4 will license the algorithms from RSADSI, rather than try to build their cryptographic engines from anonymous postings to Usenet. page 161 Securing Windows NT/2000 Servers for the Internet 11.3.3 Cryptography and U.S. Export Control Law Under current U.S. law, cryptography is a munition, and the export of cryptographic machines (including computer programs that implement cryptography) is covered by the Defense Trade Regulations (formerly known as the International Traffic in Arms Regulation - ITAR). As of late December 1996, to export a program that includes cryptography, you need a license from the U.S. Commerce Department (prior to that date the U.S. State Department issued the licenses). In 1992, the Software Publishers Association and the State Department reached an agreement that allows the export of programs containing RSA Data Security`s RC2 and RC4 algorithms, but only when the key size is set to 40 bits or less. These key sizes are not secure. Under the 1992 agreement, the 40-bit size was supposed to be periodically reviewed and extended as technology improved. No review ever took place. In early 1996, the Clinton Administration proposed a new system called " software key escrow." Under this new system, companies would be allowed to export software that used keys up to 64 bits in size, but only under the condition that a copy of the key used by every program had been filed with an appropriate "escrow agent" within the United States, so that if law enforcement so wanted, any files or transmission encrypted with the system could be easily decrypted. In late 1996, the Clinton administration replaced the software key escrow with a new proposal entitled " key recovery." Reasoning that the main objection to the previous "key escrow" proposals was the fact that businesses did not wish to have their secret keys escrowed, the new proposal was based on a new idea. Under the key recovery system, every encrypted document or communication is prefaced by a special key recovery data block (see Figure 11.1). The key recovery data block contains the session key used to encrypt the message, but the session key is itself encrypted with the public key of a federally registered key recovery service. In this way, the key recovery service can recover the session key by decrypting that key with the service`s private key. Corporations that were extra-paranoid might have their session keys split into two parts and encrypted with the public keys of two recovery services: both of these services would have to be served with court-ordered wiretap orders to have the message content decrypted. As an added incentive to adopt key recovery systems, the Clinton Administration announced that software publishers could immediately begin exporting mass-market software based on the popular DES algorithm (with 56 bits of security) if they committed to developing a system that included key recovery with a 64-bit encryption key. Figure 11.1. A message encrypted according to the key recovery proposal The key recovery proposal is different from the key escrow proposal in two important ways: • Because the key recovery service does not hold any user`s private key, that key cannot be leaked to compromise all of the user`s messages. • On the other hand, if the key recovery service`s private key is leaked, then many, many users will have all of their messages compromised. In late 1996, some businesses seemed to be interested in the key recovery approach. In part, businesses were attracted to the idea that they could make use of the key recovery services themselves, so that in the event that they lost the key to a particular message, they could go to the key recovery service and get back the message contents. page 162 Securing Windows NT/2000 Servers for the Internet Nevertheless, the key recovery proposal did not address the really hard problems created by any key escrow or key recovery regime. Some of those questions include: • What happens when a foreign government asks for the keys for a U.S. corporation that is in strong competition with a company that just happens to be based in the foreign country? (That is, what happens when France asks for Boeing`s keys? What keeps the information learned from decrypting Boeing`s communications from being transmitted to Airbus, Boeing`s chief rival?) • What happens when a rogue government asks for an escrowed key? • What happens when foreign governments ask for the escrowed copies of signature keys. (What purpose could there be to requesting a signature key except to create fraudulent evidence?) 11.4 Foreign Restrictions on Cryptography The primary way that cryptography is restricted within the United States is through the use of export controls. There are many reasons for this peculiar state of controls: • It is widely believed that any direct restrictions on the use of encryption within the United States would be an unconstitutional violation of the First Amendment, which forbids Congress from making laws restricting the freedom of speech or the freedom of association. • The United States has a history of both openness and governmental abuse of investigative power. Nevertheless, the current policy has allowed the federal government to claim that it has no interest in restricting cryptography used within the United States. • Nevertheless, restricting the cryptography technology that can be placed in software for export effectively limits the cryptography technology that can be placed in software that is used domestically, because most companies are loath to have two different, and incompatible, versions of their software. • Fortunately for the federal government, the argument of how restrictions on foreign software impact domestic software are so complicated that they go over the heads of most sound bite-oriented Americans. But other countries do not have a First Amendment, and many have already passed laws to regulate or prohibit the use of strong cryptography within their borders. Some are also pressing for world nongovernmental organizations, such as the OECD, to adopt policy statements on the regulation of cryptography. Not surprisingly, the strongest advocates for such worldwide regulation of cryptography are within the U.S. Government itself. There are many surveys that attempt to compare the laws with respect to cryptography in different countries. Unfortunately, many of the surveys currently have contradictory findings for many countries. A rather comprehensive document comparing the various surveys on cryptography laws was completed by Bert-Jaap Koops in October 1996 and updated in March 1997. The survey can be found on the World Wide Web at the location http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm. Between October 1996 and March 1997, many more countries had imposed export, import, and domestic restrictions on cryptography. This trend is likely to continue. The survey`s findings, in brief, are reprinted in Table 11.2 and Table 11.3. page 163 Securing Windows NT/2000 Servers for the Internet Table 11.2, International Agreements on Cryptography Agreement COCOM (Coordinating Committees for Multilateral Export Controls) Wassenaar Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and Technologies European Union Impact International munitions control organization. Restricted the export of cryptography as a dual-use technology. In 1991, COCOM decided to allow the export of mass-market cryptography software (including public domain software). Dissolved in March 1994. Member countries included Australia, Belgium, Canada, Denmark, France, Germany, Greece, Italy, Japan, Luxemburg, The Netherlands, Norway, Portugal, Spain, Turkey, United Kingdom, and the United States. Cooperating members included Austria, Finland, Hungary, Ireland, New Zealand, Poland, Singapore, Slovakia, South Korea, Sweden, Switzerland, and Taiwan. Treaty negotiated in July 1996 and signed by 31 countries to restrict the export of dual-use goods. Countries including COCOM members, Russia, Hungary, Slovakia, and Poland. No formal regulations, although a September 11, 1995, recommendation states that "measures should be considered to minimize the negative effects of the use of cryptography on investigations of criminal offenses, without affecting its legitimate use more than necessary." Table 11.3, National Restrictions on Cryptography Country/Agreement Australia Austria Bangladesh Belgium Brazil Byelorussia Canada People`s Republic of China Denmark Finland France Import/Export Restrictions Written permission may be required for exporting cryptographic equipment or software Follows EU regulations None apparent Requires license for exporting None None Follows COCOM. No restriction on import or export to United States Restricts importation and exportation of voice-encryption devices Export controls August 96 law enforces EU export recommendations Equipment that implements authentication-only or integrity-only must be declared. License needed for other cryptography uses. Domestic Restrictions None Laws forbid encrypting international radio transmissions of corporations and organizations None apparent Legal status unclear as the result of the passage of an unnoticed December 1994 law None License from State Security Committee is needed for manufacture, repair, or operation of cryptography None Exact status unknown None None Cryptography may be used for confidentiality only if keys are escrowed with trusted third parties. Other uses of cryptography (authentication, nonrepudiation, and identification) may be used without restriction. page 164 Securing Windows NT/2000 Servers for the Internet Germany Greece Hungary Iceland India Indonesia Ireland Israel Italy Japan Latvia Mexico Netherlands New Zealand Norway Pakistan Poland Portugal Russia Saudi Arabia Singapore South Africa South Korea Spain Sweden Switzerland Turkey United Kingdom United States of America Follows EU regulations ... - slideshare.vn
nguon tai.lieu . vn