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.
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).
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.
|
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.
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.
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.
- The message sender generates a random session key using
the function CryptGenKey.
- The sender uses the function CryptExportKey to encrypt the
session key, using the recipient's public key.
- 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.
- The message recipient generates a second random session key
using the function CryptGenKey, and encrypts this second key using
CryptExportKey.
- 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.
- 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.
- 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".
- 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.
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.
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).
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.
|
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.
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 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.
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.
|
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.
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.
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 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.
|
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 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.
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.
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