Developer.com Click here to support our advertisers
Click here to support our advertisers
SOFTWARE
FOR SALE
BOOKS
FOR SALE
SEARCH CENTRAL
* JOB BANK
* CLASSIFIED ADS
* DIRECTORIES
* REFERENCE
Online Library Reports
* TRAINING CENTER
* JOURNAL
* NEWS CENTRAL
* DOWNLOADS
* DISCUSSIONS
* CALENDAR
* ABOUT US
----- Journal:

Get the weekly email highlights from the most popular online Journal for developers!
Current issue -----
developer.com
developerdirect.com
htmlgoodies.com
javagoodies.com
jars.com
intranetjournal.com
javascripts.com

REFERENCE

All Categories : ActiveX

Chapter 8

Microsoft Internet Security Initiatives


CONTENTS

This chapter presents a convenient definition of security categorized along several important dimensions. First, we'll examine security in terms of the nature of transactions: abstract data interchange, code execution, or a flow of commercial cash and/or services. Security is also a needed element of the transaction setting, whether individual home computers or corporate systems. A third dimension stresses minimization of the risk faced by Internet participants (buyers and sellers of information and physical goods and services), which is at the heart of the various security proposals.

With these categories as a framework, this chapter presents some of Microsoft's most important security initiatives:

  • The Cryptographic API (CryptoAPI)
  • Private Communications Technology (PCT)
  • Code signing
  • The Point-to-Point Tunneling Protocol (PPTP)
  • Personal Effects Exchange (PFX)

In addition to the above technologies, we will examine Microsoft's support for the Secure Electronic Transaction (SET) protocol announced by MasterCard and VISA in February 1996.

The Microsoft protocols will be positioned in the broader scheme of Internet security initiatives. These include the Sun Microsystems security model of networked Java code, both present and planned; Netscape's Secure Sockets Layer (SSL); and others. As we shall see, Microsoft products demonstrate a fair degree of compatibility with their (mostly UNIX-based) rivals. Yet the Microsoft offerings represent a distinct and divergent vision of safety for Internet participants.

The chapter concludes with a discussion and pointers for further reading.

Defining Security in Terms of the Internet

Any discussion of security in conjunction with the Internet-or, for that matter, any generalized network used by anonymous participants-is likely to bring an emotional response. Nearly everyone has misgivings, from senior Information Technology management to fearful novices to intermediate home-computer users. Major Internet software vendors, including Microsoft and Netscape, have mounted broad efforts to allay public fears and present a coherent plan to improve Internet security. These efforts encompass features found in popular products, such as Netscape's Commerce Server, as well as proposals found on line in white papers and business overviews.

To the Internet consumer, security can be a very confusing area. The topic is riddled with acronyms, highly quantitative cryptographic techniques, and conflicting proposed specifications. So we'll start this chapter by breaking the broad term security into the following major categories:

  • Transaction security vis-à-vis executable code security. Transaction security involves specific issues in conducting electronic commerce on the Internet, such as the transfer of cash or goods across TCP/IP. Executable code security involves the more general concern of running a program.
  • Single-user security vis-à-vis corporate security. Single-user security protects an individual connecting to the Internet via an Internet Service Provider. Corporate security protects a firm that wishes to interact with the Internet while still guarding the firm's internal data (typically with the help of Internet firewall machines).
  • Logistical security. This is the practical need to transfer secure data from one architectural platform to another. The different architectures might be a computer in the workplace and a home computer, each made by different manufacturers. It might be two different operating systems or, at a higher level, two Web browsers with different feature sets.

Some of the above categories overlap; however, they share the common and reasonable goal of minimizing risk. In every category, the aim is to avoid risk whenever possible. There is also the need to educate the user, via software agents, as to the potential unavoidable risks of a planned operation.

Furthermore, Microsoft faces the design challenge of developing a set of tools that is extensible and modular. These tools need to grow and operate together, as other Internet hardware and software vendors push their own solutions forward. In many cases, the solutions to these security challenges are integrated directly with the operating system (usually NT).

Transaction Security: The Industrial-Strength CryptoAPI Toolkit

Microsoft is hard at work providing the Internet developer with a rock-solid and extensible means of creating applications that can encrypt or digitally sign documents without fuss or mess. This tool is the Cryptographic Application Program Interface (CryptoAPI), and it deploys the public-key encryption technology from RSA, Inc.

CryptoAPI is a set of functions rather than a set of cryptographic algorithms. To accomplish the mathematical tasks, a cryptographic service provider (CSP) module must be present. Microsoft supports one CSP at the operating system level, by bundling the RSA Base Provider. More CSPs can be added to the application as needed. In fact, it is possible for a CSP to access hardware devices (such as smart cards) as well as software operations. The programmer need only use the simplified CryptoAPI interface. Trying to directly access cryptographic software or hardware is unwise, and considered bad program behavior.

The CryptoAPI interface permits simple calls to encrypt data, exchange public keys, hash a message to create a digest, and create a digital signature. It also supplies high-level administrative functions such as selecting a CSP from a group of possible CSPs. The story gets better, because the CryptoAPI interface provides the basis for many useful higher-level security services. We'll discuss these later in the chapter; they include Secure Electronic Transaction (SET) for electronic commerce, Private Communication Technology (PCT) for securing client/server messaging, Personal Information Exchange (PFX) for shuttling confidential data and keys among various platforms, code signing, and more.

Public-key methods, which are considered cryptographically very secure, meet the goal of implementing secure messages on an insecure Internet. Each network participant has a pair of keys-a private and a public key-which were created simultaneously. In public-key technology, the private key is needed to perform the inverse operation of the public key. Conversely, the public key is needed to perform the inverse operation of the private key.

Figure 8.1 illustrates the components of the CryptoAPI. The cryptographic primitives handle generation of keys (both public and private), and the ability to select a specific CSP. In the upcoming sections we'll see two examples of the primitives at work in practice. The higher-level functions, which Microsoft indicates will be released in the second version of the API, will encapsulate several primitives into single function calls. For example, code signing and digital signature verification might be combined. Other Microsoft security initiatives such as PCT, PFX, and SET (which we discuss in this chapter) are higher-level protocols that are designed to communicate effectively with the CryptoAPI.

Figure 8.1 : CryptoAPI architecture.


NOTE
In the coming months, look for Microsoft and its strategic partners to move ahead rapidly with implementations of the CryptoAPI protocol as an add-on or version upgrade of many popular desktop software packages, particularly in the field of electronic commerce. (See the later section on the SET protocol.) Microsoft will thus leverage its immense desktop operating system and application software installed base to gain supremacy in the new battleground of Internet security.

Why Use Cryptography?

There are two fundamental types of user actions for which cryptography is either a good idea or a requirement. In both cases, the user is publishing some sort of data. The data may be placed in the public domain via a Web site or an FTP site or perhaps posted as an article to Usenet; or the user may be publishing data by transmitting it directly to another party, such as in a private e-mail message, a financial transaction via a Web site, or the like.

Public Transmissions with Digital Signatures

When publishing or transmitting data that is publicly available, the publisher wants to ensure that the data is not tampered with before it reaches the end consumer. In the real world, people traditionally sign paper documents to prove the validity of a transaction, because an individual's handwriting is considered unique. In the computer world, a digital signature is attached to the data being published.

Let's look at a hypothetical publisher named Joe, who wants to post a digitally-signed message to a Usenet newsgroup. With the digital signature technique, Joe creates and holds two keys: one public and the other private (which must always be kept secure and never transmitted on TCP/IP). Joe should make sure his public keys are distributed widely; he does not want to keep public keys secret. In this case, Joe will include his public key in the message he is posting to Usenet.

To digitally sign his posting, first Joe runs a hash function to algorithmically create a small digest document, typically a few hundred characters, out of the message he is posting. This digest is merely a short summary of the content of Joe's message. Then he uses his private key to encrypt the digest, which will be the digital signature. Joe then appends this digital signature, along with his public key, to the message he is posting to Usenet.

A reader can now verify that Joe in fact did post this message to Usenet. To do this, the reader uses Joe's public key to decrypt the digital signature, in this case the digest of the message. If the digest matches the message content, then the message is valid. Otherwise, the user will be able to clearly see that the message content has been tampered with by someone other than Joe, because the only key that could create a proper digest is Joe's private key.

In one sense, digitally signing a document is almost more secure than its real-world counterpart of handwritten signatures: The average human is not a handwriting expert, and a good forgery can easily escape detection. With a digital signature, forgery is realistically impossible.

Private Transmissions with Data Encryption

The second fundamental type of action calling for cryptography is when one party wants to send private data to another party. For data to be private, it must be encrypted before it is transmitted, and only the intended recipient will be able to decrypt it. Most of us are familiar with data encryption from childhood; we may have used "decoder rings" or other play methods to encrypt and decrypt messages. However, the means to decryption must only be available to the recipient. Obviously, if everyone has the same decoder ring, nothing will be private.

The same public/private key pair that is used for public transmissions can also be used for private transmissions. The difference is that the sender of the data uses the recipient's public key to encrypt the data. Suppose Jane is a member of the Internet community and wishes to send Joe a secured message. She has received Joe's public key through a convenient third party, a Certificate Authority (CA). She uses Joe's public key to encrypt her message and sends it off to Joe.

Encryption is a one-way function that is, essentially, the factoring of a very large number whose only two factors are large prime numbers. Jane's encryption is a good example of a one-way function. The encryption is very difficult to invert computationally; a corollary is that it is computationally unfeasible to generate a bogus message that would result in the same encrypted message. Although the encrypted message might be copied by attackers before it gets to Joe, only Joe can perform the inverse operation (decryption) using his secure private key.

The other important detail to consider is Jane's source for Joe's public key. This must obviously be a trusted source, such as the aforementioned Certificate Authority. A section later in this chapter gives information on obtaining a digital ID from a CA.

Real-Time Encryption

The methods used above, in which the sender and recipient exchange data by encrypting with the other's public key, form the basis for conducting real-time secure data exchange. In this situation both parties are assured of the other's identity, and the data exchanged is encrypted before transmittal.

Microsoft's CryptoAPI Application Programmer's Guide contains sample pseudocode for initiating a secure transaction that will be conducted in real time. To do that, the parties implement a standard three-phase key exchange, which can be implemented as follows.

Phase 1

In Phase 1, the sender initiates the transaction, by sending a randomly generated session key.

  1. The message sender generates a random session key using the function CryptGenKey.
  2. The sender uses the function CryptExportKey to encrypt the session key, using the recipient's public key.
  3. The recipient accepts the encrypted session key and passes it to a selected Cryptographic Service Provider (CSP), using the CryptImportKey function. This function returns a handle to the sender's session key.

Phase 2

In Phase 2, the recipient responds to the sender, sending a new, randomly generated session key. The sender uses this key to verify the recipient's identity.

  1. The message recipient generates a second random session key using the function CryptGenKey, and encrypts this second key using CryptExportKey.
  2. The recipient calculates a complex hash value on the data structure. This value is composed of the sender's session key, the receiver's name, the sender's name, and the literal string "phase 2". The complex hash is transmitted to the sender.
  3. The sender accepts the second session key from the recipient and hands that off to the sender's CSP. The sender accepts the recipient's complex hash. The complex hash is validated by the sender; if the validation fails, the Microsoft specifications recommend that the "protocol should be terminated and the communication link severed." If the hashes match, the sender knows the recipient is on line and engaged in real-time transactions, because only an on-line user could have decrypted the first session key and built the correct complex hash.

NOTE
It was a conscious choice by the designers to include clear text names in the complex data structure, states Microsoft in its Internet Security Framework white paper, to "involve the users in the process as an additional check."

Phase 3

In Phase 3, the sender, having verified the recipient's identity, creates a fresh session key.

  1. Similar to Phase 2, the sender now builds a complex hash value based on the second session key, the users' names, and the literal string "phase 3".
  2. The recipient validates the hash exactly as described for the sender in step 3 of Phase 2. If the hashes match, the recipient knows the sender is on line and engaged in real-time transactions, because only an on-line user could have decrypted the second session key and built the correct complex hash.

After Phase 3 is complete, the key-exchange protocol is finished. Hopefully, the parties have validated each other's hash values and exchanged session keys.

Next, the CryptoAPI is used to create the shared session key, using the functions CryptCreateHash (to create the hash object), CryptHashSessionKey (to add the first two session keys to this hash object), and CryptDeriveKey (to derive the shared session key from the newly defined hash).

Microsoft's Implementation

Microsoft provides code in its CryptoAPI Application Programming Guide that implements, from the sender's point of view, the three-phase key exchange as described above. (This Programming Guide is available as a WinZipped Word document from the Web site

http://www.microsoft.com/intdev/security/cryptapi.htm#section3

Microsoft has two important caveats regarding the referenced code example. First, the programs do not perform error checking (as they should). Second, fixed-length buffers are used to store encrypted keys and hash values (which they shouldn't; dynamic buffers are preferable because of potential differences among CSPs).

Microsoft presents similar code to show the same three-phase key exchange on the recipient's side. The company states that the communications details between the parties are not given, because these are specific to the implementation.

CryptoAPI Programming Examples

Programming with the CryptoAPI is a straightforward process compared to other APIs and extensions in the ActiveX domain. Moreover, the Microsoft examples are easy to follow. You'll find these programs at the following URL:

http://www.microsoft.com/intdev/security/cryptapi.htm.

and they include C source code, Makefiles, and readme documentation files.

  • INITUSER. This program generates a container to hold a user's public key and private keys, and instantiates two sets of public/private keys: one for digitally signing a message, and the other for exchanging keys. This package is 1.69K zipped.
  • ENUMALGS. This sample application lists the algorithms at the user's disposal that are acting as CSP providers. ENUMALGS is useful when the user has a number of CSPs with widely differing functions (for example, one might be primarily hardware based). This package is 2.08K zipped.
  • SIGN. The SIGN.c program is actually two console applications that digitally sign a message; they can also be used to verify files. The SIGN sample pack is 4.36K zipped.
  • CFILER. This is a Windows-based program to encrypt and sign files. It is 76K zipped.

Commercial Transaction Security: The SET Protocol

The Internet has traditionally been a difficult environment in which to provide secure channels for network participants who wish to exchange assets (cash, software, or physical goods). The chief technical problem on the World Wide Web specifically is the nature of the HTTP protocol: It is lightweight and stateless; it drops the connection every time a Web server responds to a client. HTTP was not meant to maintain a persistent connection between parties to a transaction; nor was it meant to conduct authentication of the parties' identity. The new Secure Electronic Transactions (SET) protocol will fill these needs.

Developed by VISA and MasterCard and announced in February 1996 with assistance from Microsoft, IBM, Netscape, and others, SET will offer both consumers and merchants an efficient and secure means of doing business on the Web. SET combines two earlier notions. First, it integrates with bankcard payment services. This concept has been demonstrated on the Web by First Virtual Holdings. (First Virtual merchants and consumers pay transaction fees to have credits and debits flow via dedicated cable to the credit card company's back office, rather than over the Internet.)

SET also accomplishes public-key cryptography known as strong cryptography. This forms the basis of the Microsoft CryptoAPI, which we examined earlier in this chapter. In fact, the strong cryptographic methods come from an earlier Microsoft proposal, Secure Transaction Technology (STT), which comprises a competing proposal, Secure Electronic Payment Process (SEPP).

The Goals of SET

All concerned parties to commercial transactions realized early on the importance of agreement on a single, de facto standard, and SET is the result. What must it accomplish? The discussion that follows is based on the published SET draft (for details, see "For Further Reading" at the end of this chapter).

Here are the goals of the SET protocol:

  • To ensure that data transferred between transaction parties is kept confidential, away from the prying eyes of intruders.
  • To authenticate the transaction parties, using strong methods, leaving as little risk as possible of impostors' obtaining goods fraudulently.
  • To verify the validity of payment instructions after a trade is initiated.

Cryptographic methods are necessary to meet these criteria. However, it's important to keep the implementation free of architectural dependency to allow a wide choice of consumer platforms. Furthermore, the implementation must be efficient, to accommodate wide ranges in processing power.

Let's see how SET will meet these important goals.

Confidentiality of Transmission

All messages will be encrypted bidirectionally between the trade counterparts. This encryption uses both public keys (asymmetric) and randomly generated symmetric keys. It is somewhat complex; let's look at an example.

Suppose a merchant wants to send a message to a buyer confirming an order. Under SET, the encryption is done initially using a symmetric key (that is, the same key is used to both encrypt and decrypt the message). Then this key is encrypted, using the buyer's public key. The merchant has previously acquired the buyer's public key; public knowledge of participants' public keys does not compromise the algorithm. The encrypted key is sent to the buyer, attached to the symmetrically encrypted message.

Upon receipt of the package, called a digital envelope, the buyer uses a private key to decrypt it and obtain the symmetric key. This private key is never transmitted on the Internet; if the private key is compromised, the entire scheme collapses. The symmetric key will unlock the body of the message and transform it into readable text. Note that any symmetric key implementation must have a robust (hard to guess) method of generating symmetric keys to guard against a brute-force generation of test keys.

Message Authentication

Every party has a private key which, as mentioned above, must be kept absolutely private. To send a message, the sending party runs a SET hash function against the text message, which produces a 160-bit message digest. Then the sender uses the private key to encrypt the message digest, and the encrypted digest (a digital signature) is appended to the message and passed to the recipient. Note that, theoretically, authentication via digital signature does not presume that the message itself is encrypted; that is completely up to the implementation. SET can choose to force all messages to be encrypted as described above, or make it optional.

When the message/signature combination arrives, the same SET hash function is used on the message to compute a digest at the receiver's end. The receiver, who has the sender's public key, can decrypt the digital signature; a match means the sender is authentic.

You'll note in this example that the private key is used to sign the document, and the public key is used to decrypt it. This is in contrast to the method described earlier for transaction security, in which the sender uses the recipient's public key to encrypt the symmetric key. Though the SET concept can be confusing, its details can be abstracted away from the commercial participants once they are convinced of SET's worth in protecting them from fraud.

General (Before-Message) Party Authentication

The SET protocol is meant to contravene the possibility of fraudulent attempts to initiate commerce under someone else's identity. The genuine parties to the transaction don't want to waste processing time or risk fraud by receiving a public-key encrypted message until they are reasonably certain that an impostor did not start the transmission. This guarantee is accomplished with an abstract entity, the Certificate of Authority (CA).

The CA accepts new participants on the commerce network after they show credentials such as a notarized birth certificate or passport. Then the CA issues a message with the new person's name and public key, which contains the CA's digital signature. Assuming that the CA is trusted and the CA's public key has been widely distributed, the new players thereby gain the trust of the existing participants.

The CA does not have to be a monolithic data-processing entity (with one point of entry into a software system) but can exist in distributed form (with replicated key data on multiple network nodes) for increased efficiency during the general authentication phase.

Revoking a CA certificate is just as critical as issuing one. When a participant loses an important credential (for example, a passport is revoked) then the CA must have a mechanism to report immediately to merchants that a former participant is no longer eligible to start a transaction. A practical example of credential revocation will be presented in the section on code signing in this chapter.

NOTE
Until SET becomes available, Microsoft is pushing its own PCT ideas forward and supporting Netscape's Secure Sockets Layer.

General Client/Server Transmission Security: The PCT Protocol

The Private Communications Technology (PCT) protocol furnishes the following elements of transmission security for client/server relationships over the Internet:

  • Provides symmetric session-encryption keys between servers and clients.
  • Accommodates authentication of server to client via Certificate of Authority (CA) trusted public keys; optionally, it also authenticates client to server.
  • Verifies message integrity with hash function message digests, as explained earlier for the SET protocol.

PCT assumes the existence of a network transport layer (most commonly TCP/IP), but not a particular application protocol. Thus PCT can be implemented to coexist equally with HTTP, FTP, and so on.

The PCT protocol is similar in record format to Netscape's Secure Sockets Layer (SSL) scheme of securing transmission between a Web server and a Web client. In addition, however (as pointed out by the October 1995 Microsoft discussion draft), PCT offers some advantages.

First, PCT permits stronger authentication because it separates the authentication and encryption functions. In SSL these two functions are bound, making SSL subject to the current 40-bit encryption key limit that the U.S. government places on export. The public/private key pairs used to authenticate messages are specified to be different from the encryption keys. Indeed, as we saw with SET, there is no built-in requirement to encrypt a message at all (but authentication can still take place).

Secondly, PCT has a more streamlined handshake phase than SSL, resulting in faster server authentication.

Although PCT can be used to conduct electronic commerce, it was not specifically designed for this purpose as SET was. Therefore, with PCT, the merchant obtains the customer's credit card number. With SET the consumer is protected by a higher degree of anonymity: The merchant need only have the bank's voucher that the consumer has enough money to pay for the goods.

Microsoft has announced that PCT 1.0, which is backward compatible with SSL, will be present in Internet Explorer 3.0 (a Web client) and Internet Information Server (IIS) 2.0, a Web server.

Executable Code Security: Code Signing

Two camps, equally important, have a vested interest in minimizing the risks associated with running a downloaded executable program on a client machine. One group is end users, who do not want the program to behave erratically or maliciously. The other group is developers, who want to establish trust and good faith with end users by providing a tamperproof code authorship seal: code signing.With a mechanism in place to provide this guarantee, end users will have a way of verifying that code developed by a trusted vendor has not been altered between its creation and its download. An authorship-checking module can intercept altered or corrupted code before handing control to the software-launching module.

In this section we will define Microsoft's notion of code signing within their ActiveX framework, and review the fundamental cryptographic principles underlying code signing. We will also examine Microsoft's partnership with Verisign as a Certificate Authority providing digital IDs as a specific implementation of code signing.

Microsoft's Code Signing Initiative

Microsoft points out that ActiveX controls, Java applets, and other network executables currently suffer from a deficiency in end-user trust.

Of course, Java proponents would argue that their language offers "soft" (algorithmic) security because the bytecode compiler removes dangerous operations. Java proponents say it is perfectly feasible to layer "hard" (cryptographic) techniques on top of the algorithms, if desired, to answer safety concerns at the expense of efficiency. (There is a performance hit associated with the encryption at the server side and decryption at the client side.)

Nevertheless, Microsoft's new code-signing initiative, which the company places under the technology umbrella "Authenticode," is important, because it provides an easy-to-use procedure for Internet code signing and verification. This solution will be heartily welcomed by software developers.

Let's consider the general flow of events to sign code: The developer follows the same steps as discussed for the SET message-encryption protocol-that is, a digital signature is appended to the code. It is assumed that a Certificate Authority (CA) has already awarded the developer a public key, which is freely available on the Internet. The developer uses a hash function on the program to compute a digest, the length of which is determined by the code-signing implementation. The digest is then encrypted with the developer's private key.

The package containing the encrypted key and the developer's Digital Certificate (awarded by the CA) is encapsulated into a special structure, the signature block. The code signing standard specifies the signature block structure and its relationship to the executable code. When the code plus the signature block are distributed, the recipient (say, a Web client) can use a Win32 function, WinVerifyTrust. This function scans the signature block, makes sure the digital certificate is a valid one awarded by a trusted CA, and runs the same hash function (obtained by the signature block) on the executable code to produce a client-side code digest. If the client-side digest matches the distribution digest, the protocol has determined the software was not tampered with after it was signed-which is quite different from promising the code won't do anything bad on the client side!

Now that we have a good grasp on the underlying principles of Microsoft's vision of safe code, let's see the specifics play out in practice.

How Does the Developer Acquire a Certificate?

Without a certificate from a trusted Certificate Authority (CA), signed code wouldn't mean much. Fortunately, it has become easy for a software firm or an individual developer to collect the necessary credentials. The steps necessary to acquire a Certificate and sign code are spelled out at the Microsoft Web site

http://www.microsoft.com/intdev/sdk/

in the Authenticode section.

The developer will need Internet Explorer 3.0 to apply for the certificate and to view signed code. Assuming this prerequisite is met, the application for Software Publisher's Certificate is submitted by following the links at the URL

http://www.microsoft.com/intdev/signcode/

The Certificate is issued from a participating Certificate Authority (CA) that supports the Authenticode technology.

The CA needs to see the developer's key pair, which is generated during the Certificate application phase, and other relevant details to prove that the developer is a legitimate entity. As Microsoft states, the CA may well hire external contractors, such as Dun & Bradstreet, to examine the developer's credentials.

Microsoft's Agreement with Verisign

In August 1996, Microsoft and Verisign issued a joint press release, which is available at

http://www.microsoft.com/corpinfo/press/1996/aug96/CODSIGPR.htm

For the first time, the implementation details of the general CA/Authenticode scheme with Verisign, formalizing the notion of a CA, were available to the public. Pricing details were also revealed: Class 2 Digital IDs, issued to individual software developers, were set at $20; Class 3 Digital IDs, meant for commercial software houses, were priced at $400.

The announcement has received rapid support from large and small third-party software vendors, including RealAudio, Microcom, and Ncompass Labs. Figure 8.2 shows the Verisign Web page, which is the first stop for individuals or firms to get, find, or revoke a digital ID.

Figure 8.2 : Verisign's Digital ID Center.


NOTE
NOTE. The stakes are enormous in the multi-billion-dollar Certificate Authority industry arena. Verisign has a big advantage as the first practical CA to step forward. Although Microsoft distributes its code signing technology for free, look to the Microsoft operating systems to be one step ahead in any Microsoft-based initiative such as Authenticode. It will be interesting to see how market forces shape the CA battlefield as competitors emerge. This will also be affected by other operating system developers, in particular UNIX-centric ones, responding with their own ideas on how code security should look and feel over a TCP/IP network.

A Code Signing How-To

In August 1996, Microsoft released a more specific step-by-step instruction guide for developers who wish to sign 32-bit code. The guide is available at the Web site

http://www.microsoft.com/intdev/signcode/

This straightforward process is likely to catch on in a big way with developers and end users alike who have built relationships with one another in the past. It will assist them in arranging an explicit mechanism, the Digital Certificate, which stands as a symbol of quality.

Following is a paraphrased version of the instructions at the Microsoft Web site mentioned above.

Summary of Code Signing Procedure from Microsoft

First, download the most recent version of the ActiveX SDK from the Web site

http://www.microsoft.com/intdev/sdk/

which contains the code signing software.

If a .cab (Cabinet) file is to be signed, the following entry is needed in the .ddf file:

.Set ReservePerCabinetSize=6144

Cabinet files are discussed a little further on in this section.

To sign an .exe, .cab, .ocx, or .dll file, Microsoft provides this syntax:

signcode -prog myfilename -name displayname -info <a href="">http://www.mycompany.com</a> 
-spc mycredentials.spc -pvk myprivatekey.pvk

where myfilename is the file to be signed; displayname is information about the executable that will appear in the certificate; <a href="">http://www.mycompany.com</a> is a hyperlink that should direct the end user to useful information about the person or company developing the code; mycredentials is the credentials file awarded by the CA; and myprivatekey is the private key that was generated during the application process with the CA.

Running signcode without any parameters will launch a Wizard to guide the developer through the signing process.

To test the newly created code signature, use

chktrust filename

and to test a signed .cab file, use

chktrust -c cabfilename.cab

If you are providing an ActiveX control in a Web page, you can add the Codebase attribute to the <OBJECT> tag, which will indicate to the client Web browser where to find the control. For example:

<OBJECT classid="clsid:AE2E4103-DBEE-11CF-8712-444553540000"
	codebase="http://127.0.0.1/ONotes.ocx#Version=4,70,0,1161"
	id=ONotes1
	width=350
	height=250
	vspace=0
	align=left>
   </OBJECT>

If the client user does not have this particular OCX installed and registered, they will receive a screen prompting them before the control is installed, as shown in Figure 8.3.

Figure 8.3 : A sample Control installation prompt screen.

About Cabinet Files

Some readers might be unfamiliar with Cabinet files: the new Microsoft compression technology. The CAB (Cabinet) technology is a way for developers to compress files that will be sent across the network to optimize bandwidth (for example, Java class files or ActiveX OCXs). Internet Explorer 3.0 is able to download compressed CAB files, expand them into their original components, check their authenticity with Authenticode, and run them safely.

Cabinet technology is described in the August 9, 1996, developer's announcement at the Web site

http://www.microsoft.com/devnews/cab.htm

Typical of new technology initiatives from Microsoft, the company made no attempts to port the technology widely before the announcement. They have mentioned plans to port Cabinet technology to the Macintosh platform in the future, and UNIX lovers hope they, as well, will benefit soon after.

For Java folks, the Web site

http://www.microsoft.com/workshop/java/cab.htm

contains information that is useful to developers with links to the Cabinet compression and decompression APIs. This site also has sample applications making use of these APIs.

How Code Signing Impacts the End User

In terms of cryptographic theory and development, the subject of code signing is somewhat complex. In terms of how this new technology will play out with the end user, things get a lot simpler. Industry analysts predict that end-user cyptographic integration with common desktop applications will become commonplace in the first and second quarters of 1997, and the changes in usage patterns are likely to be quite minor.

A typical scenario has the client selecting preferences to direct the scanning software agent to warn or not warn when no signature block at all is found. A mismatched digest, of course, is much more severe a breach, and the scanning agent takes suitable actions to warn the user. When all goes well, a matched digest is indicated in a friendly, information-style dialog box, or the user can dispense with that and simply run the code.

Microsoft summarizes its vision of Authenticode's appearance from the end-user perspective at the Web site

http://www.microsoft.com/ie/most/howto/trusted.htm

As stated above, you'll need Internet Explorer 3.0 at a minimum to support signed code. From the Web page at

http://www.microsoft.com/IE/trustsoft/default.htm

"you can safely download," announces Microsoft, "software programs and components with Microsoft Internet Explorer through its support for code signing. Code signing enables you to identify who published the software before you download it and verify that no one tampered with it." Microsoft compares this with the physical shrink-wrapping of software purchased in a retail outlet or by mail order. They maintain that the shrink-wrap gives the consumer peace of mind that a trusted vendor has written the code to magnetic media (disk or CD-ROM) and presumably placed the product in the shrink-wrap-with virtually no possibility of tampering.

This virtual shrink-wrapping appeals to consumers, who believe in paying for quality and avoiding risk. Equally important, however, is the disapproval of the Gnu crowd-those following the Gnu Public License (GPL) tenets of freely distributed source code in the spirit of worldwide scientific research. They are adamant that their compilers (for example, the Gnu C and C++ compilers) are quite good; the customer pays nothing and receives worldwide support in the form of the Gnu Usenet community and other hardy volunteers. Microsoft takes the practical tack of targeting the average consumer, not the scientific researcher; the company wants to give the former some peace of mind.

Figure 8.4 shows the first portion of the Trusted Code screen. (Note the ominous bug graphic, representing what the consumer presumably avoids by adopting software that can scan signed code.)

Figure 8.4 : The Trusted Code screen.

The Point-to-Point Tunneling Protocol, or PPTP, addresses an important security problem on today's Internet: the awkward necessity of authenticating a remote dial-up user at the point of the remote-access hardware (for instance, a PPP modem pool) rather than more conveniently at the existing corporate NT security domain.

The PPTP shifts security administration to fall under the aegis of NT, thus offering well-established schemes of accessing NT databases and other resources, and full integration with the NT Remote Access Services (RAS). The PPTP specification, developed by network hardware provider US Robotics along with Microsoft and other remote-access hardware vendors, accommodates the powerful effect of a private NT network's extending its reach throughout the Internet. A specialized remote-access server such as US Robotics's NETServer can tunnel PPP packets on a TCP/IP network directly to a specific corporate NT server, eliminating the need for intermediary machines and authentication protocols. With the PPP connection terminating at the NT machine, Microsoft can make use of existing access technologies built into RAS, such as DHCP and WINS.

Logistical Security: PFX

As cryptographic techniques grow more prevalent in the marketplace, the network participant will have more need to ensure a safe environment- to create and sign code, to accrue sensitive data files, and to transmit these objects securely across TCP/IP from the workplace or from home.

Consider the scenario when the platforms at home and at work are quite different-for example, the combination of an IBM-compatible PC and a Macintosh. It is quite possible that the Web browsers on the two machines might be quite different, as well. How, then, can the commuter arrange the logistics of transporting private data between the two sites? Unfortunately, current hardware solutions for secure transport, such as smart cards, are not mature. Other, less convenient methods must be used.

Microsoft's Personal Effects Exchange (PFX) provides two possible techniques: The user can elect to use either the strong public-key method, or a symmetric-key password encryption scheme that is less secure but more convenient.

The Public-Key Method

The PFX standard assumes an installed PFX desktop software product to generate the user's public and private keys (which are RSA-compliant).

Let's say a user at home is working with a computer that has the PFX package installed. He or she can take a diskette with the public key to another location such as the workplace and use a machine there, also with PFX software installed, to encrypt workplace data. (Note that it is unnecessary and dangerous to transport the work or home private key via diskette from one location to the other, and should be avoided.) The public-key encrypted data from work can be transported home again on a diskette or e-mailed to the home PFX computer. The only awkward part of this public-key mode is the requirement of transporting the diskette containing the public key between locations. On-line transmission is not an acceptable alternative; if it were intercepted, the entire scheme would be compromised.

NOTE
Interestingly, as suggested in the PFX discussion draft, the PFX software receipt of e-mailed public-key encrypted data can be implemented by a new and experimental MIME type, PFX Importation.

Symmetric-Password Mode

The less-secure alternative put forth in the PFX discussion draft has the user typing in a name and password at, say, the office, to generate a symmetric encryption key. This key is used to encrypt the work data, and the user can then save the file to disk and transport it home. The same key will be used later to decrypt the data at home. (It is too dangerous to attempt an e-mail of the encrypted data in this mode, because the user could pick a trivially simple user/password pair that might be easily guessed by an attacker.)

This considerably riskier symmetric-password mode might be considered a fallback in the event the user is not in current possession of the public key.

The PFX Safe

The PFX software must allow for secure transport of sensitive private keys from machine to machine; it must also secure CA-bestowed user certificates. Private keys, certificates, and other data the user deems confidential are stored in the PFX Safe.

Like its physical counterpart, the PFX Safe has "compartments." Each compartment can be assigned an OSI Object Identifier (OID) stemming from the a universal name space. The software implementation will protect the private keys as the most tightly guarded items in the safe; that is, they will never be accessible by any application software. The remaining items (certificates and confidential data) are encrypted; the user can decrypt them and view them in plain text if desired.

Concluding Remarks

Microsoft is making its philosophy known on a variety of security issues, publishing white papers and discussion drafts for the benefit of the Internet Engineering Task Force (IETF) as well as casual readers. You'll find these publications under the Web site directory

http://www.microsoft.com/intdev/security

Obviously, Microsoft recognizes the financial importance of standards in the multi-billion-dollar arena of electronic commerce. Naturally, they want to provide tools that support a high level of trust between developers and end users, even as traditional software distribution channels disappear. The next few years will see interesting battles between Microsoft and the more UNIX-oriented Netscape Communications Corporation, in terms of both product features and standards evolution.

Equally interesting will be Microsoft's extension of its ActiveX software initiatives to accelerate the security notions and fledgling security software described in this chapter.

For Further Reading

General Interest: An overview of the Microsoft Security Framework is available on line at

http://198.105.232.5/intdev/security/

This resource includes links to press releases, white papers, and the major Microsoft initiatives, including the CryptoAPI, PCT, PFX, and more.

Jim Flynn has written an interesting review piece, "Battle for the Internet Infrastructure," on line at

http://www.datamation.com/PlugIn/issues/1996/may1/05asoft2.html

which speculates on the competition between Netscape and Microsoft to win the favor of Internet developers. Though security is not the central focus, it is a recurring theme throughout the article.

General Cryptography and Internet Cryptography: The RSA Data Security, Inc., home page at

http://www.rsa.com

has discussions of public-key cryptography as it applies to securing e-mail, firewalls, the SET standard, and more.

An interesting discussion of the social issues behind the rights of private citizens to encrypt data, both domestically and abroad, as well as useful links to personalities and technologies in the field of cryptography, is available at

http://www.virtualschool.edu/mon/Crypto.html

Bruce Schneier's book, Applied Cryptography, 2d ed. (New York, Wiley & Sons, 1996) is considered an excellent and thorough treatise on this subject.

The Usenet newsgroups sci.crypt and sci.crypt.research are also worth following.

Secure Electronic Transaction (SET) Protocol: MasterCard and Visa both maintain on-line information on the Secure Electronic Transaction (SET) protocol. VISA's is at

http://www.visa.com/cgi-bin/vee/sf/set/intro.html

and includes links to technical details of the protocol, as well as a business overview.

Point-to-Point Tunneling Protocol (PPTP): A brief history of the PPTP protocol, as well as statements about its raison d'être and feature set can be found at the US Robotics site:

http://www.usr.com/aboutusr/103_18.html

The Microsoft CryptoAPI: Everything you need to know about the Microsoft CryptoAPI, including an overview, an application programming guide, sample code, availability information, a list of FAQs, and more, is on line at

http://www.microsoft.com/intdev/security/cryptapi.htm

Code Signing: Microsoft advances reasons for code signing, describes the process step by step, and has links to the underlying specifications and a list of FAQs at

http://www.microsoft.com/intdev/signcode/

Internet Explorer, which supports code signing, is described at

http://www.microsoft.com/IE/trustsoft/default.htm

Personal Effects Exchange (PFX): Microsoft's proposed standard for transporting confidential data (both cryptographic keys and the more typical notion of user-defined secrets) is described at

http://www.microsoft.com/intdev/security/brink009.htm

Private Communication Technology (PCT): The PCT protocol and a useful comparison and contrast with the better-known Netscape Secure Sockets Layer (SSL) technology can be found at

http://www.microsoft.com/intdev/security/pct.htm


HomeAbout UsSearchSubscribeAdvertising InfoContact UsFAQs
Use of this site is subject to certain Terms & Conditions.
Copyright (c) 1996-1998 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited.
Please read the Acceptable Usage Statement.
Contact reference@developer.com with questions or comments.
Copyright 1998 Macmillan Computer Publishing. All rights reserved.

Click here for more info

Click here for more info