WebDeveloper.com �: Where Web Developers and Designers Learn How to Build Web Sites, Program in Java and JavaScript, and More!   
Web Developer Resource Directory WebDev Jobs
Animated GIFs
CSS
CSS Properties
Database
Design
Flash
HTML
HTML 4.01 Tags
JavaScript
.NET
PHP
Reference
Security
Site Management
Video
XML/RSS
WD Forums
 Client-Side
  Development

    HTML
    XML
    CSS
    Graphics
    JavaScript
    ASP
    Multimedia
    Web Video
    Accessibility
    Dreamweaver
    General
    Accessibility
    Dreamweaver
    Expression Web

    General

 Server-Side
  Development

    PHP
    Perl
    .NET
    Forum, Blog, Wiki & CMS
    SQL
    Java
    Others

 Site Management
    Domain Names
    Search Engines
    Website Reviews

 Web Development
  Business Issues

    Business Matters

 Etc.
    The Coffee Lounge
    Computer Issues
    Feedback




The Race to Secure Cyberspace

by Don Larson

For a community that measures its periods of history in days or months rather than years, Internet users' wait for secure Internet commerce has seemed to take eons. It appeared the wait might be over in 1995 when several new security systems hit the market, but a number of well-publicized cracks in each of them quickly deflated expectations of a boom in online trade. Now, less than a year later, a new generation of protocols and software that promise improved security has created a fresh buzz. Forecasters such as Forrester Research predict that online spending will skyrocket in the coming years, growing from $518 million in 1996 to $6.6 billion by the year 2000. Hoping to cash in, many businesses are lining up to get a piece of these new security systems.

The impending boom in the secure client-server arena has set off a stampede of companies, each trying to be first to market with products designed to meet the growing demands of hungry consumers and the servers that must feed them. For administrators and developers who want to sell from their sites, the onslaught of products is a mixed blessing. While it means plenty of software to choose from, deciding which payment mechanisms and security protocols to support--then facing the complex task of integrating multiple components for each protocol--may make for some long hours and headaches. Other variables, such as expandability for future standards and budget caps, won't make these decisions any easier.

To help you make the right decisions, Web Developer® offers an overview of secure technologies, with a look at the major players, their respective protocols, and how they have attempted to address the inherent problems in creating commerce products for the real world.

The Protocol Pace
One of the easiest methods of enabling secure commercial transactions on your site is to install a secure Web server. That way, potential customers will need nothing more than a browser (that supports the same security scheme as your server) and a credit card to conduct secure business transactions via the Internet.

The problem with this otherwise convenient scenario has been the continual emergence of new protocols. From S-HTTP and SSL to PCT and SET, the race to provide the next industry standard--and the shifting alliances this has produced--has made it difficult for vendor and customer alike to decide which security protocols to support. And while the finish line is far from being in sight, it is clear at this juncture that some heavy favorites are destined to dominate the field.

  • EIT/S-HTTP: Secure-HTTP was one of the first security protocols out of the gate. Developed by Enterprise Integration Technologies (EIT) Inc., which formed Terisa Systems in conjunction with RSA Data, S-HTTP is exactly what its name suggests: a security-enhanced extension of the Hypertext Transfer Protocol. S-HTTP works at the application level, encrypting the contents of messages relayed between a browser and a server using RSA's system of public/private key algorithm pairs (see "Cracking the Secrets of Encryption"). S-HTTP is designed for flexibility, allowing client and server to negotiate the strength and type of encryption to be used. S-HTTP also authenticates the identity of both client and server by using digital signatures, and verifies the integrity of the data by using Message Authentication Code (MAC). MAC ensures that a message has arrived unmodified by assigning a specific numeric value based on the contents of the message. This value is recalculated upon receipt and compared with the original. If the two values match, the message has not been tampered with in transit.

  • Netscape and SSL: With others in the field focused on application-level protocols like Secure-HTTP, Netscape Communications Corporation broke away from the pack in 1995 with the introduction of their Secure Socket Layer protocol initiative. Unlike S-HTTP, the SSL protocol operates "lower down" between the application level and the transport (TCP/IP) layer (see Protocol Layer diagram).

    This strategy represents both a strength and a weakness of SSL. On one hand, it allows SSL to encrypt the data stream itself, thereby establishing a secure transmission channel for any Internet application, independent of protocol. On the other hand, because SSL offers no method to encrypt the contents of the application, any intercepted message is fair game.

    SSL and S-HTTP are not, however, mutually exclusive. Because they operate on different levels, the protocols could be layered to "double-encrypt" the data.

    In addition to a secure data pipe, SSL includes provisions to authenticate the identity of a session's server (and optionally the client) using RSA's system of digital signatures. SSL also attaches an encrypted ID to each secure session. This ID, which is cached by both parties, allows a client and server that have previously established an SSL connection to reestablish a secure channel without repeating the entire handshaking process. In order to implement a fully functional SSL server, server administrators must first register with a certificate authority such as RSA, which verifies applicants' authenticity and distributes the public/private key certificates. Most SSL server software packages include some way of obtaining these certificates.

  • Microsoft/PCT: With Microsoft's introduction of Private Communication Technology (PCT), the self-titled "dogfight" between the industry giant and Netscape moved into new territory. Designed to support secure and spontaneous commercial transactions, PCT is similar to SSL in many ways. Like SSL, PCT operates on the transport level, making it independent of application protocols. PCT also incorporates RSA's asymmetric public/private key algorithm to authenticate both server and client, and PCT is even backward-compatible with SSL.

    However, according to Microsoft PCT "enhances" SSL's authentication scheme and protocol efficiency by incorporating lessons learned in the development of yet another security protocol, STT (Secure Transaction Technology; see below). PCT separates authentication from encryption, for instance, thereby allowing authentication keys to exceed the 40-bit export limit. In addition, NetManage, creators of WinPCT, one of the earliest implementations of the protocol, claims that PCT corrects a security hole in the design of SSL's handshake phase, a flaw through which potential attackers could gain access to session keys, which they could then use to authenticate a bogus client in a high-security environment and gain access to sensitive functions.

  • Visa and MasterCard/SET: As Netscape and Microsoft competed for dominance on the secure-channel front, a second battle was brewing. In order to fulfill credit-card payments on the Web, both Visa and MasterCard needed a protocol that could safely link the Internet to existing bank-card processing networks, and the two went head-to-head with competing solutions. In keeping with the spirit of competition, Visa formed an alliance with Microsoft and quickly released a proposal called Secure Transaction Technology (STT). Soon after, MasterCard and Netscape together offered the Secure Electronic Payment Process (SEPP), an SSL-based product. After much posturing, including a claim by Netscape that Microsoft had demanded a seat on the board of Netscape and a 20 percent stake in the company, in return for advance technical info on an upcoming Microsoft operating system (The Wall Street Journal, 9/28/95), all four parties finally agreed that a unified standard would be beneficial.

    The converged protocol that the ensuing collaboration produced is known as Secure Electronic Transactions, or SET. Like the secure-channel protocols, SET provides public/private key authentication and message integrity. SET, however, is specifically designed for credit-card transactions, in that sensitive information is encrypted throughout the card-processing network. Whereas SSL and PCT transactions expose the customer's vital information to the merchant, SET's configuration allows merchants to access only the data they require to fulfill the order. Meanwhile, the customer's credit-card data remains encrypted until it reaches the appropriate financial institutions. All of the major companies involved hope that SET is the protocol that will finally instill confidence in the Internet as a safe space in which to conduct business.

Gaining Ground
In an effort to gain acceptance of their security solutions as industry standards, all the companies involved are seeking wide implementation of their protocols in both the server and browser markets. The first to emerge, S-HTTP, provided the key ingredients for a successful security standard: client-server authentication, secure encryption, and data integrity. However, it lacked widespread support--and still does. Server-side endorsement remains slim, with the exception of Open Market Inc., which includes support for the protocol in its Secure WebServer, and more recently IBM with its Internet Connection Secure Server. Support in the client arena is almost nonexistent, outside of the Secure NCSA Mosaic, which was developed as a reference implementation by EIT, RSA, and the NCSA.

With the introduction of SSL, Netscape had apparently solved the Internet's security problem. Bolstered by Navigator's dominant position in the browser arena and a free 60-day trial, Netscape's SSL-supporting Commerce Server quickly found widespread deployment in the secure Web server market. But a series of successful attacks on the protocol's encryption scheme temporarily stalled what was shaping up to be another runaway success for the company. One of the most severe breaches even uncovered the method SSL used to generate random keys for encryption, effectively making it possible to guess the keys and break the encryption scheme in less than a minute. Although Netscape quickly responded with patches and included an improved random key generator in the upgrade, intense media coverage of SSL's stumble may have given S-HTTP and PCT the break they were looking for.

Netscape's share of the secure market remains enviable, however. Beyond Navigator, browsers such as Internet Explorer and Oracle also support SSL. And support in the server market is even more widespread, with Apache, Open Market, IBM, Spry, and even Microsoft introducing SSL-secure software. In addition, Netscape recently released a Commerce Platform, which includes its new Enterprise and FastTrack Servers with support for SSL V.3.

Newer to the market, PCT has so far seen limited distribution. To date, only Open Market has implemented the protocol in its line of servers, although companies such as Spyglass, Cylink, and FTP Software have all promised support. SET, also a relative newcomer, is still in the Request for Comments stage. However, Terisa Systems--in which America Online, CompuServe, IBM/Prodigy, Netscape, RSA, and VeriFone/EIT all have a stake--announced in late April that it plans to incorporate SET into its SecureWeb™ Client Toolkit and Server Toolkit. These products, which already include support for SSL and S-HTTP, will enable client-server developers to integrate support for multiple protocols in the same session. Planned to be available in early June, the toolkits will allow for rapid deployment of the SET protocol once it is ready for implementation.

Clues of Convergence?
Ideally, all three of the competing protocols will one day coalesce into a single, interoperable, platform-independent standard, but few people are holding their breath. However, in what appears to be a major move toward that standard, Microsoft announced in May that it had submitted specifications for a converged version of SSL and PCT. Called Secure Transport Layer Protocol (STLP), the unified specification will feature a "simpler and more robust implementation...with improved security and the additional functionality needed for wider application." Given the track record of those involved, however, it will probably be some time before such a standard is in place.

And, as always, new protocols are on the horizon. One of the most important of these emerging standards is the next generation of Internet Protocol, IPsec. Currently pending approval by the IETF, IPsec--whose aliases include IPv6 (IP version 6) and IPng (IP Next Generation)--is an extension of the current IP protocol (IPv4) that includes security measures for authentication and encryption. Unlike protocols such as S-HTTP, SSL and PCT, however, IPsec supports encryption at the Internet (IP) level, providing a more fundamental level of security than its higher-level counterparts.

IPv6 remedies IPv4's shortcomings by integrating two separate security mechanisms. Known respectively as the "Authentication Header" and the "Encapsulating Security Header (ESP)," these extensions may be used either individually or together to supply different levels of security to different users. The authentication header's primary role lies in the prevention of host masquerading attacks through the authentication of a host's origin. The main goal of the ESP mechanism is to insure message integrity and confidentiality by using a standard DES (Data Encryption Standard) algorithm to actually encrypt IP datagrams, the basic units of TCP/IP.

Although the IETF plans to introduce IPsec sometime this summer, it will probably be several years before networks can make a complete migration to the new protocol. However, RSA and TimeStep Corporation have already announced support for IPsec in their S/WAN API toolkit. As part of the companies' S/WAN initiative, several leading vendors have been performing live interoperability testing of their IPsec implementations over the Internet. As with Terisa Systems and the SET protocol, RSA and TimeStep's early introduction of IPsec for implementation will likely aid in rapid and widespread deployment of the protocol.

Merchants who wish to forge ahead in the meantime will simply have to support multiple protocols in order to avoid losing potential customers. Foreseeing this eventuality, vendors such as Open Market have already begun to offer turnkey server solutions that support all of the major protocols. Newly emerging protocols should require nothing more than easily integrated upgrades, then, as the upcoming implementation of SET will hopefully prove.

Regardless of which protocol comes out on top, customers will become increasingly confident in the Web as a safe place to shop, with names like Visa and MasterCard now on board. Expect 1996 to be the year secure commerce finally allows the Web to live up to its promise as "the new medium of the '90s."


Cracking the Secrets of Encryption
Encryption literally holds the keys to securing online commerce on the Internet. But how does it work? The RSA algorithm, named for its inventors Rivest, Shamir, and Adleman, takes advantage of the unique properties of very large prime numbers and some tricky arithmetic to generate a pair of algorithms, or "keys." While one key is distributed publicly, the other is held privately by its owner. Data can be encrypted with either key. But a message encrypted with one of the keys can only be unlocked by the other.

Using large numbers thwarts attempts by attackers to decipher the keys. The U.S. version of SSL (Secure Sockets Layer), for instance, utilizes a high-grade, 128-bit key, while export versions are limited to 40-bit keys due to U.S. government restrictions. In contrast, an RSA private key is usually 1,024 bits or larger. But because the size of public/private key pairs requires a lot of processing power, they are not commonly used to encrypt entire transmissions. Instead, these keys are used to encrypt a smaller key, which is then used to secure the contents of the message.

In addition to their role in data encryption, key pairs also provide other functions vital to secure transactions. Most notably, public/private keys can be used to authenticate a server, reducing the possibility of fraud. Server verification is accomplished in the handshaking phase of a secure session, when the server transmits its public key to the client. After a few intermediate steps, the server sends another message to the client, encrypted this time with the server's private key. Because this private key can only be decrypted by the server's public key, the client should then be able to unlock the message, establishing the authenticity of the server in the process. The same process can be used to verify a client's identity. In this way, both parties can digitally sign a transaction or document. Termed "non-repudiation," this method ensures that neither client nor server can later claim not to have made the deal. Finally, key encryption guarantees a message's integrity as well, as any modification will fail to produce a verified signature.



HTML5 Development Center


Recent Articles