Lee Goldberg

The explosive growth of networking technology continues to redefine the rules for maintaining the privacy and integrity of electronic data. There is a staggering amount of personal, commercial, governmental, and military information in the various networking infrastructures worldwide. Almost anyone can reach out to the network, which often means almost anyone can reach in. In short, network security is an issue that can no longer be postponed. Fortunately, security measures do not have to be expensive or complicated—a reality the networking community has only recently taken to heart. Network security itself, however, must be better understood and embraced, preferably before a compromise occurs. The articles in this issue are intended to alert you to the risks and some solutions and to encourage you to develop and implement security methodologies and strategies before—rather than after—an incident. Strong cryptography is very powerful when it is done right, but it is not a panacea. Building a secure cryptographic system is easy to do badly and very difficult to do well. Unfortunately, most people can't tell the difference. In this article, the author conveys some of the lessons learned in designing, analyzing, and breaking cryptographic systems. Patrick W. Dowd John T. McHenry

Popular magazines often describe cryptography products in terms of algorithms and key lengths. These security techniques make good headlines ("Triple DES is much stronger than single DES."). Unfortunately, cryptography isn't so simple: Longer keys do not guarantee more security. Compare a cryptographic algorithm to the lock on your front door. Improving the lock probably won't make your house more secure. Burglars don't try every possible key (the equivalent of a brute-force attack); most aren't clever enough to pick the lock (the equivalent of a cryptographic attack). No, burglars smash windows, kick in doors, disguise themselves as police, and rob key-holders at gunpoint. Strong cryptography is very powerful when it is done right, but it is not a panacea. Building a secure cryptographic system is easy to do badly and very difficult to do well. Unfortunately, most people can't tell the difference. In this article, the author conveys some of the lessons learned in designing, analyzing, and breaking cryptographic systems. Bruce Schneier

With no insult intended to the early Web designers, security was an afterthought. At the outset, the Web's highest goal was seamless availability. Vendors engaged in retrofitting security must contend with the Web environment's peculiarities, which include statelessness, location irrelevance, code and user mobility, and stranger-to-stranger communication. This article presents a survey of Web-specific security issues. The focus is on security in the server and host environments, mobile code, data transport, and anonymity and privacy. The server is the central system and the repository of information resources. The server is thus the locus of threats, whereas the client is largely out of sight. The authors conclude that, although the state of Web security is abysmal, the use of the Web for business will result in a more serious approach to security. They suggest that public-key technology will be the skeleton on which Web security will hang. A trust management paradigm for securing Web commerce will give way to a risk management paradigm, in proportion to the value of the transactions moving on the Web. Aviel D. Rubin Daniel E. Geer Jr.

Internet Protocol, version 6, was conceived with two main goals: increase address space and improve security, relative to IPv4. The community achieved the first goal by increasing the IP address length from 32 bits to 128 bits. To meet the second goal, the Internet Engineering Task Force chartered the IP Security Working Group to design a security architecture and corresponding protocols that would provide cryptographically based security for IPv6. As work progressed, however, the IP community realized that the security architecture proposed for IPv6 could also be used for IPv4. Consequently, it extended this charter to retrofitting the security protocols, or IPsec protocols, into IPv4 implementations. Many IPv4 software vendors have announced they will support the IPsec protocols in future releases. This retrofitting is an important part of the working group's charter because IPv6 deployment is turning out to be slow. This article overviews the proposed security architecture and the two main protocols—the IP Security Protocol and the Internet Key Management Protocol—describes the risks they address, and touches on some implementation requirements. Rolf Oppliger

The economies and conveniences of telecommuting have made the technologically sophisticated home office a growing phenomenon. Businesses, however, are facing a major challenge in extending the office network environment to employees' homes. Many companies have developed highly integrated enterprise networking solutions, which through a standardized desktop allow users on a LAN or secured intranet to easily communicate and share data. When this connectivity is done properly which is not easy both employee and employer benefit. But it also carries a risk because the enterprise does not control the home environment. How to transparently establish the trustworthiness of home machines so that their interconnection to the enterprise can be extended via an internetwork? This article describes a proposed solution, secure identity-based loading. SIBL uses smart cards, operating system modifications, and network authentication to provide secure, economical, and transparent home office environments. William A. Arbaugh James R. Davin David J. Farber Jonathan M. Smith

As more users subscribe to ATM data services to support their broadband applications, ATM security devices must be employed to ensure protection against eavesdropping, impersonation, unauthorized data modification, and denial-of- service threats. Because security policies can vary according to site preference or import/export regulations, the ATM Forum's ATM Security Specification, Version 1.0, provides for the negotiation of security parameters. To increase the likelihood for successful negotiation of encryption parameters, the ATM encryptor must implement multiple algorithms. Such encryptors are called algorithm-agile encryptors. This article describes a prototype ATM encryptor that implements mechanisms for requesting an encryption algorithm, performing end-user and encryptor authentication, and exchanging encryption keys, using the ATM Forum's Security Message Exchange protocol. When used together, these mechanisms provide protection against eavesdropping and impersonation threats. Thomas D. Tarman Robert L. Hutchinson Lyndon G. Pierson Peter E. Sholander Edward L. Witzke

Using the Dining Philosophers problem, the author shows how Synchronous C++ can improve the development of concurrent applications. sC++ introduces the concept of an active object. The syntax of the definition, instantiation, reference, call, inheritance, and deletion of an active object is identical to the syntax of the same operations on a standard or passive object. An active object, however, contains an internal activity that runs in parallel with the activities of the other active objects. This activity can delay the executions of its methods-when called from outside-until it is ready to accept them. sC++ has strong connections to the domains of concurrency, behavior analysis, and OO programming. Namely, sC++ contains a real-time kernel, lends itself to analysis by modern modeling and analysis theories, and uses the same syntax for active objects as for passive ones. This article focuses on examples in which the dynamic and functional models dominate and the object model is secondary. In doing so, the author proposes a mapping between the elements of all three models and sC++ statements. Claude Petitpierre

Diana J. Bendz

Mark Resmer

Patricia Cravener

Ted Lewis