The Microsoft Internet Security Framework: Technology for Secure Communication, Access Control, and Commerce

Microsoft Corporation

December 20, 1996

Introduction

The Microsoft® Internet Security Framework (MISF) provides a comprehensive set of public key security technologies that meet the needs of business, developers, and users for secure exchange of information across public networks, access control to resources and information, and electronic commerce.

MISF technologies support Internet standards, ensuring interoperability across platforms and browsers to meet users’ needs for security on the Internet. To this end, MISF technology is distributed to millions of users worldwide through the Windows and Windows NT operating systems and through applications such as Microsoft Internet Explorer and Microsoft Internet Information Server. Using MISF tools in the Microsoft Win32® and ActiveX SDKs, developers can leverage their existing investments by extending their applications or network security to use public-key security without having to recreate their applications. MISF is built upon a flexible architecture, allowing developers to support new standards and changes in the field of cryptography while protecting their original application investments. Additionally, Microsoft is working to make key MISF interfaces available cross-platform.

Comprehensive Security

MISF delivers a comprehensive set of technologies enabling companies to build secure business applications for securely using the Internet or their intranets.

Ensure private communications. Ensuring the confidentiality and integrity of communications is critical as businesses increasingly rely on the Internet. MISF addresses these concerns by supporting the Secure Sockets Layer (SSL) version 3.0 and Private Communications Technology (PCT) version 1.0 protocols for private point-to-point communication using Microsoft Internet Explorer and Microsoft Internet Information Server. Microsoft’s implementation of SSL and PCT is interoperable with major browsers and servers from other vendors. For secure end-to-end private e-mail over the Internet, Microsoft is supporting the S/MIME protocol in a 1997 release of Microsoft Exchange client, Microsoft Outlook, and Microsoft Internet Mail.

Verify identity on the Internet. MISF enables companies to securely identify and authenticate customers, employees, suppliers, and partners through standards-based public-key certificate technology. Both Internet Explorer version 3.0 and Internet Information Server version 3.0 can authenticate servers and clients respectively using SSL and PCT and digital certificates, such as those issued by VeriSign and other Certificate Authorities. The Microsoft Certificate Server allows companies to issue and manage certificates, and to act as their own Certificate Authority (CA). Through Microsoft’s support of hardware technology such as smart cards and Fortezza, companies can choose the level of authentication security based on business needs. Microsoft’s upcoming S/MIME support provides digitally signed e-mail for identification and authentication of e-mail messages.

Control access to information and resources. Microsoft is integrating certificate-based authentication into the Windows NT® security model. Companies will be able to control access to information and resources on the Internet or their intranet using certificates with the same Windows NT administration model and tools they use today. Administrators will be able to benefit from extending single log on to the certificates-based authentication model by mapping certificate information to existing Windows NT accounts. Additionally, certificates will be integrated with the Windows NT Directory Service.

Conduct secure transactions. Companies need to ensure that customer information received via the Internet (such as  credit card numbers) is kept safe and private. Businesses today rely on SSL and PCT to conduct secure transactions. In the future, merchants will be able to use Microsoft’s implementation of the Secure Electronic Transaction (SET) protocol for secure credit card transactions. Microsoft is also working with the industry to provide integrated payment solutions; VeriFone now provides its vPOS integrated payment processing software for merchants using Microsoft Merchant Server. With the Microsoft Wallet, users will be able to securely store and manage the private information they need, such as certificates and private keys, to shop safely on the Internet. Users will also be able to safely transfer the contents of their Wallets between computers through Microsoft’s support for PFX (Personal Information Exchange).

Ensure software accountability and integrity. The proliferation of downloadable content on the Internet presents security risks for both home and corporate Web users. Microsoft, using standards-based technology, developed Authenticode™ technology to positively identify the publisher of signed software (including ActiveX controls, Java applets, or Netscape plug-ins) and to verify the software’s integrity. The digital signature technology that Authenticode uses is also available to developers through the Windows Trust Verification services in the Win32 API.

Provide a solid security foundation. MISF technologies are built on CryptoAPI, a Win32 API available today worldwide in Internet Explorer, Windows 95, and Windows NT. CryptoAPI allows developers to easily incorporate cryptography into their applications, by insulating developers from the intricacies of cryptography. The CryptoAPI architecture, built on top of the Cryptographic Service Provider (CSP) model, makes security upgradable to meet evolving business and customer needs. As export policies change, developers can take advantage of the highest strength cryptography allowed by upgrading the CSP without having to modify their applications.

Working with the Industry

Microsoft is actively working with the industry to help build the public-key infrastructure necessary for secure commerce and business applications:

• Microsoft is working closely with RSA to ensure that industry-leading cryptography is delivered worldwide to Windows and Windows NT customers. Microsoft has also licensed CryptoAPI to RSA for inclusion in RSA’s cryptography toolkits across the platforms they support.
  
  
• Microsoft fully supports VeriSign’s Digital IDs in Internet Explorer and Internet Information Server. Additionally, Microsoft and VeriSign delivered the first implementation of code signing to the industry through Authenticode.
  
  
• Hewlett Packard is using CryptoAPI as the interface that developers will use to write to its International Cryptographic Framework technology.
  
  
• Microsoft and VeriFone have delivered an integrated payment solution for Windows NT and Merchant Server using VeriFone’s vPOS payment solution.
  
  
• Microsoft is working with Groupe Bull, Hewlett-Packard, Schlumberger, and Siemens Nixdorf via the PC/SC Workgroup to integrate smart cards with personal computers.
  
  
• Microsoft hosted a Security Design Review in September 1996, where over 150 of the major Internet security vendors and software developers participated in an open, technical forum covering Internet Security technology.
  
  
• Microsoft is a founding and current member of the Public-Key Cryptography Standards (PKCS) group, along with Apple, IBM, Lotus, Nortel, Silicon Graphics, Sun and others.

Open

Microsoft is committed to supporting Internet standards, and is also very active in the Internet standards body process, ensuring that our customers will continue to benefit from the latest innovative standards-based security technology:

• All MISF technologies are based on fundamental standards such as the X.509v3 certificate format, the PKCS #7 digital signature format, PKCS #10 certificate encapsulation, and protocols such as SSL and PCT.
  
  
• Microsoft is working with the IETF on a secure communications protocol unifying SSL and PCT. This protocol, being defined through the IETF transport-layer security working group, provides improved security, scalability, performance, and features.
  
  
• Microsoft has submitted the PFX protocol and the digital signature technology used by Authenticode to the W3C as discussion drafts for consideration as an industry submission to the Internet standards bodies.

MISF Architecture

As illustrated in the architecture below, CryptoAPI is the foundation for MISF. Higher-level protocols and services are built upon the base-level cryptographic and certificate management functionality provided by CryptoAPI and its associated Cryptographic Service Providers (CSPs). Applications can then add security functionality by building on top of MISF. This section takes a more in-depth look at the technologies that are included in MISF, and provides links to detailed information. Appendix A summarizes MISF technologies and their availability.

MISF Technologies

Microsoft CryptoAPI

CryptoAPI, the foundation technology for MISF, provides developers access to standards-based, core cryptographic functionality. CryptoAPI version 1.0 supports public-key and symmetric-key operations such as key generation, key management, key exchange, encryption, decryption, hashing, digital signatures, and verification of signatures. CryptoAPI 2.0 includes the core cryptographic functionality as well as certificate-based functionality so that developers can use certificates with these public-key operations and perform the necessary encapsulations and encoding to apply certificates within their applications.

CryptoAPI uses a service provider model in which cryptography is provided by Cryptographic Service Providers (CSPs). This model allows developers to easily adapt their applications to evolving cryptographic technologies and government export policies (see "Microsoft Policy on Export Controls on Encryption"). Through different CSPs, developers can use higher strength exportable cryptography, new cryptographic algorithms, or a range of hardware-based devices—without having to change their application code.

Given that CryptoAPI has been approved for export, developers can be assured of having to write only one application for worldwide distribution. Today, CryptoAPI is available worldwide with the Microsoft RSA default CSP, which supports the following algorithms: 40-bit RC2 and RC4; 512-bit RSA; MD2 and MD5; and 160-bit SHA-1.

Microsoft is currently working with six additional companies besides RSA to provide CSPs: Atalla (a Tandem company), BBN Corp., Cylink, Northern Telecom Inc. (Nortel Secure Networks), Spyrus, and Trusted Information Systems. Additionally, Hewlett Packard recently announced that its International Cryptography Framework will use CryptoAPI interfaces to access ICF.

CryptoAPI supports X.509 v3 certificate formats and ASN.1 encoding, as well as PKCS #7 and #10 for encapsulation. This will allow applications that use CryptoAPI to interoperate with other certificate-based systems that adhere to these standards. Microsoft is also working to make CryptoAPI a cross-platform API. Given that CryptoAPI has been licensed to RSA, RSA will be able to deliver CryptoAPI through its BSAFE® and other security toolkit products on the platforms that they support.

CryptoAPI 1.0 is currently available to millions of users through Windows NT 4.0, Microsoft Internet Explorer 3.0, and Windows 95 OSR2. In September, Microsoft shipped a developer’s beta version of CryptoAPI 2.0, which is scheduled to be released with the next version of Internet Explorer and with updates to Windows and Windows NT.

Developer Information

For more information on CryptoAPI 1.0, consult the CryptoAPI 1.0 Application Programmer’s Guide. Extensive sample code written in C is also available on the MISF Web site (http://www.microsoft.com/intdev/security/). Visual Basic developers can also access CryptoAPI 1.0 functionality through the CryptoAPI 1.0 typelib and OLE Automation server, which includes a Visual Basic sample application illustrating encryption/decryption and signature functions.

The developer’s beta release version of CryptoAPI 2.0 (libraries, header files, and DLLs), including COM interfaces (cryptcom.dll), buildable sample applications written in C, and example HTML pages created using VBScript and Java, is currently available on the Security Web site. The CryptoAPI 2.0 Beta Programmer’s Guide and Beta Reference can be browsed on the Web site as well.

(Cryptography developers in the U.S. and Canada that are interested in creating their own CSPs can request the CSP Developer’s Kit from the MISF Web site at http://www.microsoft.com/intdev/security/.)

Developers wanting to learn more about programming with CryptoAPI are invited to join Microsoft’s CryptoAPI mailing list, CryptoAPI@LISTSERV.MSN.COM. To find out how to join, go to the Mailing List section on the Site Builder Web site (http://www.microsoft.com/sitebuilder/resource/mail.asp).

Secure Channel Services (SSL and PCT)

SSL and PCT are public-key-based security protocols implemented by MISF’s Secure Channel (schannel) security provider. SSL and PCT are used today by Internet browsers and servers, including Internet Explorer and Internet Information Server, for integrity and confidentiality of communications, and optionally for mutual authentication. With SSL and PCT, parties using the Internet can be confident that their communications are private and have not been tampered with or altered.

Residing between Transmission Control Protocol/Internet Protocol (TCP/IP) and application protocols (for example, Hypertext Transfer Protocol [HTTP], File Transfer Protocol [FTP], or Telnet), SSL and PCT negotiate an encryption algorithm and symmetric session keys. During this initial negotiation, a client and server may authenticate each other. Once the handshake is complete and transmission of application data begins, all data is encrypted using the negotiated session key.

Microsoft Internet Explorer 3.0 and Internet Information Server (IIS) 3.0 support both SSL 3.0 and PCT 1.0. Microsoft’s implementation of SSL is fully interoperable with browsers and servers from other vendors running across different platforms. Webmasters apply Secure Channel services to their Web site by simply selecting a check-box item in the IIS Internet Service Manager. SSL and PCT take it from there, negotiating a secure connection with any browser connecting to the site.

While Secure Channel services are especially applicable for web-based applications, these services are also potentially valuable to non-HTTP client/server programs running on the Internet or on intranets. Microsoft has made these Secure Channel services available to all developers through the Win32 WinInet APIs and through a WinSock 2.0 provider; no additional licensing fees for using SSL or PCT are required.

Developer Information

Developers can use the Win32 WinInet APIs, which are part of the ActiveX SDK, to add secure channel support to their client-side applications quickly and easily. The WinInet APIs are multithreaded and handle caching, and the client credentials are handled automatically.

Developers who currently use Winsock can also easily add Secure Channel services to their Winsock application by writing directly to the Winsock2 layer. This is more involved and requires detailed knowledge of the protocols. Winsock 2 can be used for both client-side and server-side applications. For more information, read the SSL/Winsock 2 Layered Service Provider Specification on the MISF Web site.

Client and Server Authentication

Client and server authentication using SSL and PCT makes it possible for Web sites and users to positively identify each other. Clients such as Microsoft Internet Explorer 3.0, and servers such as Microsoft Internet Information Server 3.0 use digital certificates to identify themselves on the Internet so that they can communicate securely or gain access to a particular area of a Web site.

This provides a more straightforward means of identification and access control than current methods, which rely on the use of user IDs and passwords. With digital certificates, end users are required to log on to the Internet only once and do not have to remember passwords for numerous Web sites. For Web sites, digital certificates offer a new method to control access to the site, perform site customization, or apply specific business rules to customers (for example, strategic vendors get access to corporate servers).

Web sites enroll for and receive server certificates that are signed by a trusted Certificate Authority (CA). Similarly end users request and receive client certificates from a CA. (Information on how to install certificates in Internet Explorer and Internet Information Server is provided on the MISF Web site.) Before issuing certificates, the CA does background verification to ensure that the Web site and the end user are legitimate.

Client and server authentication is done in the context of SSL 3.0 and is supported in Internet Explorer 3.0 and Internet Information Server (IIS) 3.0. Both IE 3 and IIS 3 work with industry-standard X.509 v3 certificates and interoperate with any Web browser or server that supports SSL 3 protocol and industry-standard certificates.

Client authentication in IIS 3 goes beyond pure authentication and access control. Developers can use the Active Server Page scripting feature of IIS 3 to easily access all the information in the client certificates to serve personalized content, control access, or query backend databases.

SSL-Based Client Authentication into Windows NT Integration

Microsoft is taking advantage of the Windows NT flexible security architecture to integrate certificate-based authentication into the Windows NT security model. The next release of Windows NT will use the Windows NT Directory Service to map certificate information to existing Windows NT accounts, thereby extending single log on to certificates and integrating the administration of certificate-based authentication into a single model using the excellent administration tools provided by Windows NT. Client authentication by the server using SSL is accomplished by the same process used for server authentication. The server verifies the cryptographic signatures on the client’s certificate and any intermediate CA certificates in a chain to a known or trusted root CA. However, once the identity of the client is verified through certificate verification (client authentication), the application server needs to establish a security context with appropriate access rights defined for the client. The access control information determines what resources the client is allowed to use on this server. In the Windows NT security architecture, access control is defined by the group memberships and privileges in the security access token.

Public-key client authentication uses the information in the client’s certificate to map to local access control information. This mapping determines what authorization the client has to access resources on the server system. Initial support for client authentication by Microsoft Internet Information Server (IIS) will be available by managing an authorization database to map certificate subject or issuer information to existing Windows NT accounts. The authorization database can be as simple or complicated as needed to meet the application requirements.

The next release of Windows NT will provide broader support for client authentication by implementing a security service that uses the Windows NT Directory Service to map certificate information to existing Windows NT accounts. The mapping can be performed using a lookup of the certificate subject name in the Windows NT Directory, or searching for directory properties that identify the client certificate.

Windows NT support for client authentication integrates public-key certificates with the Windows NT security architecture. No separate database is required to define the access rights associated with public-key certificates. The access control information is maintained by the group membership stored in the Windows NT Directory. Common Windows NT Directory Service administration tools are used for granting access rights by adding Windows NT users to groups.

Support for public-key certificate authentication in Windows NT allows client applications to connect to secure services on behalf of users who do not have a Windows NT domain account. Users who can be authenticated based on a public-key certificate issued by a trusted CA can be granted access to Windows NT resources. The Directory Service administration tools allow administrators, or delegated authorities, to associate one or more external users to an existing Windows NT account for access control. The subject name in the X.509 version 3 certificate is used to identify the external user that is associated with the account.

Businesses can share information in a secure manner with selected individuals from other organizations without having to create many individual Windows NT accounts. Many-to-one mapping of certificates to Windows NT user objects provides for strong authentication based on public-key certificates and common access-control permissions. Client authentication of external users still requires the system administrator to configure the Certificate Authority for the external user’s certificates as a trusted CA. This prevents someone with a certificate issued by an unknown authority from being authenticated by the system as someone else.

Microsoft Certificate Server

Microsoft Certificate Server will be a general-purpose, highly customizable, Windows NT–based server product for managing the issuance, revocation, and renewal of digital certificates. The Microsoft Certificate Server will be released in the first half of 1997.

The Certificate Server is intended for Web-based applications that require identification and secure communications based on the SSL protocol. However, it is also applicable to other certificate-based applications such as secure e-mail (for example, S/MIME), secure payment (for example, SET), and digital signatures (for example, Authenticode.) In the case of SSL, an organization can use the Certificate Server to issue both server and client certificates in a standard X.509 v3 format. The organization may elect to issue all of their certificates from a single Certificate Server or use multiple Certificate Servers that are chained together in a CA hierarchy.

At the most basic level, the role of the Certificate Server is to receive a PKCS #10 certificate request, verify the information in the request, and issue a corresponding X.509 certificate (or, possibly, certificate chain) in a PKCS #7 format. In the case of an end user who wants to obtain a certificate for a Web browser, a certificate request is typically generated by visiting a Web site and enrolling for a certificate. To enroll, the user enters identifying information (for example, name, address, e-mail, and so on) into an HTML form, a key pair is generated, and the public key is sent in a PKCS #10 to the CA. If all of the identifying information meets the CA’s criteria for granting a request, the Certificate Server generates the certificate and it is downloaded to the user’s browser.

Features

The following are key features of the Microsoft Certificate Server.

Customizable Policy. The Certificate Server will have a customizable policy module for issuance, management and revocation of certificates. For example, one organization may wish to grant certificates only if identification is presented in person and another may choose to automatically grant credentials to e-mail requests.

Key Management. The Microsoft Certificate Server will use CryptoAPI 2.0 for key management. As such, the Certificate Server’s private key can be stored in software, as well as low-end to industrial-grade hardware devices (smart cards). In addition, Certificate Server will allow organizations to establish a CA hierarchy that can be used to decentralize CA management and ensure that a compromise of a single CA key does not affect other CAs in the hierarchy.

Transport Independence. The organization will be able to distribute and request certificates in many ways, including writing custom transports. The server will be able to post certificates back to the user via HTTP, e-mail, an Light Directory Access Protocol (LDAP) based directory service, or any other mechanism.

Ease of Use and Administration. The Certificate Server will leverage the administration, monitoring, and reliability features of NT Server to allow easy administration with familiar tools and interface.

Based on Industry Standards. The Microsoft Certificate server will issue industry-standard X509 v3 certificates, and adhere to PKCS #10 standard for certificate requests and PKCS #7 for certificate issuance. It will be able to receive and issue certificates over standard HTTP, e-mail, and RPC, as well as write to any LDAP-compliant directory or an ODBC database.

Integrated and Extensible. The Microsoft Certificate Server will be tightly integrated with Windows NT and use CryptoAPI. As such, the Certificate Server will be able to use different cryptographic service providers ranging from the RSA base provider to smart cards and hardware devices. In addition, the Certificate Server will expose APIs and COM interfaces that can be used for customization; developers will be able to customize the certificates that are issued as well as the entry, exit, and policy modules.

Microsoft Wallet

Targeted for a future release of Internet Explorer, Microsoft Wallet will be a digital version of a physical wallet. A physical wallet contains a set of credentials for identification (ID cards), authorization (driver’s license), access control (employee ID card), and payment (credit cards, debit cards, and cash). A digital wallet serves the same functions for personal computers.

Microsoft Wallet will provide secure storage of private information including digital certificates used for identification and payment, keys, passwords, and credit-card numbers. In addition, the Wallet enables users to manage this private information. This information will be available to applications through a set of published APIs; availability will be based on an access-control policy defined and managed by the user. To prevent the compromise of information such as keys and passwords, this private information will not be available to applications directly; the applications can use the information to perform only specific user-allowed operations.

Moreover, this secure Wallet should be available to users through any number of applications in addition to their browser. For example, users will be able to easily provide their credit-card information to complete a purchase from within an Internet shopping application.

The Wallet will be portable so that the user can take it to a different machine or location in a secure manner. For example, a broker working in the office with one machine and at home with a different machine would need a method for "carrying" the wallet between work and home. Microsoft has taken the lead in this area by developing a cross-platform protocol to enable users to safely and easily move the information in their Wallet from machine to machine. The Personal Information Exchange (PFX) protocol will allow applications to transfer certificates and other personal information from one computer to another computer, floppy disk, or smart card. Microsoft has submitted the PFX protocol for review to the W3C and the specification is currently available for download.

Smart Cards

Smart cards provide corporations and users alike with a highly secure and cost-effective means of carrying out electronic commerce and secure communication. However, before smart cards can be widely deployed for use by computers, standard interfaces need to be developed to integrate smart cards and smart card readers with computers.

As a founding member of the PC/SC Workgroup, Microsoft is leading the industry in solving this fundamental problem. The Workgroup, announced in September 1996, consists of leading PC and smart card companies including Bull CP8, Hewlett-Packard, Schlumberger Electronic Transactions, and Siemens Nixdorf Informationssysteme AG.

The PC/SC Workgroup will facilitate the development of smart card–based applications for the PC by developing an open specification defining an architecture that ensures interoperability among smart cards, smart card readers, and computers made by different manufacturers. Built on existing industry standards, these specifications will be open, platform independent, and application neutral, providing a comprehensive solution to OEMs, software developers, and end users. The specifications are currently available on the PC/SC Workgroup’s Web site at http://www.smartcardsys.com/, and they will be submitted to an appropriate standard body for consideration as an industry standard.

Working together, members of the PC/SC Workgroup will develop the hardware and software technology necessary to implement the group’s specification. Microsoft plans to incorporate smart card and smart card reader support into Windows and Windows NT through CryptoAPI and a smart card Cryptographic Service Provider. That will allow developers, creating secure applications today using CryptoAPI, to easily extend them to take advantage of standards-based smart card technology as well. The ability of Microsoft Internet products, such as IE 3.0, to support smart card–based user authentication has already been demonstrated. Microsoft expects to provide preliminary releases of key Windows-based components and tools to developers in early 1997.

Secure Payment

Microsoft’s goal is to provide scalable and extensible support for secure payment in Microsoft Windows and Windows NT.

Today, customers can use Internet Information Server 3.0 and Internet Explorer 3.0 to set up secure transactions using the SSL and PCT secure communications protocols. On the server side, companies can automate the payment process using Microsoft Merchant Server and the Verifone vPOS module to interface with their payment processor gateway or bank.

Microsoft is also working closely with Visa and MasterCard to provide a higher level of security for online credit card transactions. Visa and MasterCard, with contributions from Microsoft, IBM, GTE, Netscape, and others developed the SET protocol. SET is designed to handle secure payment with bankcards over the Internet using cryptography and digital certificates. The SET protocol will ensure a standard way of securing a payment transaction over the Internet.

The major advantage of SET over existing systems is the addition of digital certificates that associate the cardholder and merchant with a financial institution and the Visa or MasterCard payment system. The certificates prevent a level of fraud that today’s systems do not address, and will also provide cardholders and merchants with a higher level of confidence in transaction processing.

SET was designed with requirements for export and import approval in mind. Visa and MasterCard are meeting with government representatives to discuss any concerns they may have regarding SET’s use of cryptography. The goal is to have all SET-compliant software able to easily obtain export and import approval.

The specification for SET is available on the Visa and MasterCard Web sites.

Authenticode

Microsoft Authenticode technology, a security feature in Microsoft Internet Explorer 3.0, ensures accountability and authenticity for software components on the Internet. Authenticode alerts users before Web sites download executable files to their computers. Authenticode then verifies that the code hasn’t been tampered with and identifies the publisher of the code. Based on a user’s experience with and trust in the software publisher, the user can decide what code to download on a case-by-case basis.

By signing their code, developers build a trusted relationship with users, who can learn to confidently download software from that publisher or Web site. With Microsoft Authenticode, developers can create exciting Web pages using signed ActiveX controls, signed Java applets, or other signed executable files. And users can make educated decisions about what software to download, knowing who published the software and that it hasn’t been tampered with.

Microsoft Authenticode is based on Microsoft’s widely supported code-signing proposal to the W3C (World Wide Web Consortium). Authenticode relies on industry-standard cryptography techniques such as X.509 v3 certificates and PKCS #7 and #10 signature standards. These are well-proven cryptography technologies, which ensure a robust implementation of code signing technology. In addition, Microsoft’s code-signing specifications are readily available on the MISF Web site.

Developer Information

To sign their code, developers need to acquire a certificate from a CA such as VeriSign and use the code signing tools in the ActiveX SDK.

Detailed documentation for signing code can be found in Six Steps to Signing Your Code. Developers wanting to learn more about signing their code are invited to join Microsoft’s Authenticode mailing list, Authenticode@LISTSERV.MSN.COM.

Windows Trust Verification Services

Microsoft Authenticode is built on Microsoft’s WinVerifyTrust API, which consists of Trust Providers that determine whether a specific entity can be trusted. Specifically, Authenticode uses WinVerifyTrust's Software Trust Provider to check the validity of a software component’s digital signature, and thus whether users can trust the authenticity and integrity of the component.

This API is available on Windows NT 4.0 and Windows 95 OSR2. As a result, any application can use WinVerifyTrust's Software Trust Provider to verify a software component’s digital signature, and thus its authenticity and integrity. For example, the TIS Gauntlet firewall relies on WinVerifyTrust to ensure that only corporate approved vendors’ software components are downloaded to the corporate network.

Currently, WinVerifyTrust supports 32-bit .exe, .cab, .ocx, and class file types. Additional file type support can be added to WinVerifyTrust through a Subject Interface Packet (SIP), such that documents, macros, or compressed files can be digitally signed and verified.

Developer Information

The Platform SDK contains detailed information about how developers can use WinVerifyTrust. Additional information is available under our Windows Trust Verification Services specification. Updated documentation addressing SIPs is expected to be available in early 1997.

Appendix A: MISF Summary

Solid, Flexible Security Foundation

Private Communication

Identity, Authentication

Access Control to Information and Resources

Secure Transactions

Software Accountability and Integrity

Appendix B: Suggested Reading

For information about the Microsoft Internet Security Framework, please visit our Web site at http://www.microsoft.com/intdev/security/.

The RSA FAQ at http://www.rsa.com/ is a widely used resource for learning about public-key cryptography.

CCITT, Recommendation X.509, "The Directory-Authentication Framework." Consultation Committee, International Telephone and Telegraph, International Telecommunications Union, Geneva, 1989.

RSA Laboratories. "PKCS #7: Cryptographic Message Syntax Standard. version 1.5." November, 1993.

Schneier, Bruce. Applied Cryptography, 2d ed. New York: John Wiley & Sons, 1996.