Safety Net

Peter C. Berkman

As we all know, the Internet is growing rapidly. With this growth, the necessity for digital integrity and validation is all the greater. This column will serve as a means of communicating some of the basic concepts, coding examples, and technology implementations that Microsoft uses to ensure this accountability. Since this is the first column, we'll start by exploring the concepts of Public Key Technology, then review some of Microsoft's current implementations of Digital Certificates.

At the lowest level, these keys are at the core of almost every cryptographic operation. This key pair is used for encrypting/decrypting and digital signing (certificates, code signing, and so on). For encrypting/decrypting, one of the two keys is used to encrypt the message and the other is then required to decrypt it. For digital signing, the private key is used to sign the message. The private key is generated by a Cryptographic Service Provider (CSP) loaded on your system and the public key is derived from this private key. The private key can be stored in a number of forms, including hardware devices such as Smart Cards or in software such as a file or registry entry. The private key must be kept securely private. The public key is sent with the digital message. As the name implies, this portion is public and is used to encrypt messages and verify signatures.

The certificate identifies an entity and is digitally verifiable through its issuer chain. The Certificate Authority (CA) builds this chain by issuing a certificate from its "root" certificate, then uses that certificate to issue leaf certificates. A "root" certificate is identifiable because it is self-signed (meaning that its subject and issuer name are identical and it is signed with the same key that created it). This issuer chain can contain a number of certificates but must start with the entity or "leaf" certificate and end with the "root" certificate. For example, when you enroll for a personal identity certificate, the CA's "root" certificate has issued a certificate that is used exclusively for issuing personal identity certificates. This is referred to as an "intermediate certificate." This intermediate certificate then issues your personal identity certificate. In this example, there would be three certificates in the verification chain. This chain would include your personal identity certificate, issued by the CA's intermediate certificate, which in turn was issued by the CA's "root" certificate. Each certificate in the chain is signed by the issuer and contains the entity's public key. Thus, to validate the signature of each certificate, the issuer certificate is required for its public key.

Microsoft uses certificates in a number of products. These include Internet Explorer 4.0 and Internet Information Server (for client/server authentication), Outlook Express (secure e-mail), and the Authenticode technology (content signing).

The first step to content verification is to digitally sign the file by running the Signcode.Exe, which is found in the InetSDK. Signcode hashes the content and stores it along with your certificate and other signature information in a data stream. This data stream is hashed using your private key (signed) and stored in the file being signed.

The file is now digitally verifiable. The verification process is accomplished by calling the WinVerifyTrust API found in WINTRUST.DLL (Windows NT Platform SDK). WinVerifyTrust extracts and verifies the signature data, builds and verifies the certificate chain, and compares the hash stored in the signature against one that it performs during the verification process.

Microsoft's Internet Explorer and the Internet Information Server provide a connection that is authenticated and encrypted over the Internet. This is done using identity certificates installed on the server and client machines. Each of these certificates identifies the entity to the other and is validated through its verification chain.

There are two security levels in Microsoft Outlook Express. The first adds a digital signature to the outgoing message. This feature is the same as content verification above. The second level involves encrypting a message for each of the recipients. This feature signs and encrypts your message before sending it. It uses the public key of the recipient to encrypt the content of the message. When the message is received, it is decrypted using the private key. This feature prevents others from reading a message not meant for them. The sender's identity is verified by the signature on the content.

This component of BackOffice is used by Certificate Authorities and corporate data centers. It controls the issuance and maintenance of digital certificates. Each certificate that is issued has extensions added that are assertions made by the CA or corporation about the certificate's purposes, life, usage, and so on. Certificate Server runs under Windows NT Server.

We have briefly covered the Public Key and digital certificate concepts and some of Microsoft's uses of these technologies. Future columns will contain more focused, detailed information relevant to coding and implementing using the Microsoft Crypto and Trust SDK.

For More Information, visit:

http://www.microsoft.com/security/ for more information on current security issues, solutions, and SDKs.

http://msdn.microsoft.com/workshop/prog/inetsdk/ to obtain information regarding development and implementation.

http://www.verisign.com or http://www.thawte.com to obtain a digital certificate.

http://www.rsa.com for more information on Public Key Cryptography.

Send e-mail to:

safecode@microsoft.com to ask questions regarding content signing and verification.

secure@microsoft.com for potential security issues.

Join:

The CryptoAPI list server at http://www.microsoft.com/sitebuilder/resource/mail.asp

Your comments and questions regarding implementation coding issues or ideas for future content are always welcome at pberkman@microsoft.com.