Man-in-the-middle attack Network Compromises and Attacks

40 VPNs discussed in the book rely upon sophisticated techniques for combating the man-in-the- middle attack, sometimes relying upon per-packet or time-oriented authentication, or even the quick shifting of keys.

2.4.3.5 Replay attack

A replay attack is essentially what would happen if an attacker were to record a transmission from A to B, even if the attacker is unable to read the message, then replay the message at a later time. Sometimes attacks of this nature can work if used in concert with an IP spoofing assault or even a man-in-the-middle one. Some VPNs combat this threat by serializing the packets, some by encapsulating the IP header as well as the datagram, and some by using synchronized timestamping. A combination of these techniques could also be used.

2.4.3.6 Detection and cleanup

Computer break-in incidents are difficult to detect and more difficult to prosecute. According to the Computer Emergency Response Team CERT, a full 35 of all high-degree break-ins go completely undetected by the system administrators responsible for the equipment compromised; an even higher 85 of all incidents go unreported. Sometimes it is only by accident that an administrator notices the tell-tale symptoms of a break-in. Strange things found in the temporary directory, strange processes running, applications found that were not distributed with the operating system, and users reporting that they are having trouble logging in or have forgotten their passwords somehow are clues. When attackers are careful to clean up after themselves, the odds that someone will notice decrease dramatically. If they are careless or just joyriders, detection is much easier and cleanup is simpler. The biggest gut-wrenching feeling occurs when the attacker seems not to have changed anything. If only a minimal clue to their penetration is left, you can be assured that you need to sanitize—and quickly. For a whole host of security-related documents, including current advisories, check with CERT directly at http:www.cert.org . In closing, always try to be quick to respond to any threat or apparent break-in as soon as you are notified or as soon as you discover it. The faster you are at taking care of things, the less impact there is overall. Even though you are sure to have a restricted budget and inadequate resources for your security efforts, try to follow through with all measures you can take to pursue the attackers. If they think you are too busy or uncaring, they will come back, with better tricks and harsher consequences. Be attentive to what they were trying to do as well as what they did. If you can connect the dots, you may put yourself in front of them, and possibly even catch them. Dont just assume they will disappear or that they didnt really do anything anyway. Just to reiterate: keep good backups, change user accounts and passwords regularly, and develop a registry for access and authentication levels that can be deployed organization-wide.

2.5 Patents and Legal Ramifications

Cryptographic routines are complex mathematical systems, and the people who have created them are experts who have spent a great deal of resources to create and protect their systems. 41 As any good lawyer will tell you, intellectual property is just as tangible as real property, and in some cases easier to support in a court of law. Even using some technologies could constitute a legally binding agreement with the softwares creators, so you need to take care when dealing with any and all such systems. The U.S. government classifies all encryption routines as munitions, which is to say that they consider the mathematical formulas that protect data a dangerous technology. Cryptography, to the Feds, is the same as treason, illegal arms trading, smuggling, racketeering, and drug sales. The boys on the Hill do not take such matters lightly, either. You may ask yourself, How could a little code hurt the giant U.S. government or its citizens? To learn exactly why the government treats these technologies with such kid gloves, we have to look back at some historical elements. Remember the enigma box? It was a WWII German code box that scrambled military orders sent from the high command to the field. Along similar lines, the Japanese had developed a system involving a code box called Purple. In times of war, code cracking and encryption take on a very important role, best described by the saying: loose lips sink ships. The protection of even simple communication is of paramount importance to the government. If all the routines developed on U.S. soil were exported abroad with no restrictions and a war were to break out, it would be unclear to our military leaders if their communications were safe. Products and services described in this book may be prohibited from being exported outside of the United States, or crippled in such a way as to make them freely exportable. Generally a reduction in the size of the key used to encrypt the data allows for a license to ship overseas. International organizations are already working on strong world-wide encryption technologies, and we are sure that the next 10 years will paint a new landscape of the data protection universe. One typical legal protection that a cryptographic creator has is the patent. DES, contrary to popular belief, is patented, but it is distributed royalty-free, which is one of the reasons why it pops up almost everywhere. All public key two-key systems are patented as well, by either RSA Data Security Inc., or by the Public Key Partners PKP group see Table 2-1 . Obviously they make it their business to collect license fees and monitor for stray usages of their software. Table 2-1. Cryptographic Patents Encryption Routine Patent Information Hellman-Merkle Patent 4,218,582, expired August 19, 1997. Supposedly covers all public key systems. Rivest-Shamir-Adleman Patent 4,405,829, expires September 2, 2000. Covers the RSA algorithm. Hellman-Pohlig Patent 4,424,414, expires January 3, 2001. Related to Diffie-Hellman expired 1997. Schnorr Patent 4,995,082, expires February 19, 2008. The DSS Algorithm is based on this. Kravitz Patent 5,231,668, expires July 27, 2008. The actual DSS Algorithm.