Part-I and II of this article discussed the basics of cryptography and its applications in real world enterprise solutions. Part-I discussed the nitty-gritty of encryption and its implementation in Microsoft .NET Framework Class Library (FCL). Part-II discussed the hashing and signature algorithms and their implementation in FCL. It also discussed the two common cryptography applications namely digital envelope & digital signature.
Any application of cryptography in building a secured infrastructure uses many of encryption, hashing and signature ciphers. In fact all the cryptographic solutions that are available today include a comprehensive infrastructure with many ciphers, extensive security policies, rich tools for creating, deploying and managing secure applications and other integrated set of cryptographic services. One such infrastructure that comes with Windows 2000 is Public Key Infrastructure (PKI).
The challenge for any such PKI is relating the public-key with the entity that owns it, and also the publication and management of public-keys. The standard mechanism to achieve this is digital certification. This part of the article discusses digital certificates and their implementation in FCL and Web Service Enhancements (WSE 1.0) for Microsoft .NET. It also digresses into Windows 2000 PKI.
Digital Certification
Digital certification is an application in which a certification authority signs a special message m, containing the name of user and the users public-key in such a way that any one can verify that the message was signed by no one other than the centralized certification authority. This message m along with its signature is called digital certificate or digital id. A typical digital certificate contains the subjects name, subjects public-key, subjects public-key algorithm and parameters, unique id of the certificate, validity period of the certificate, certificate issuer name and the issuers signature.
To understand the need for digital certification, revisit the scenario explained in Digital Signing section of Cryptographic Applications in Part-II of this article where our fictitious personalities Alice and Bob exchange digitally signed messages between them. In this Alice sends a digitally signed message to Bob; Bob ensures that the message was not altered in transit by verifying the mathematical validity of the signature using the public-key of Alice (PBa).
Alice signs the message with her private-key (PKa) of signature key-pair and sends the signature along with the message to Bob.
Bob verifies the validity of the signature using Alices public-key (PBa).
The big challenge in this solution is publicizing the Alices public-key.
- How Bob gets Alices public-key?
- How can Bob be sure that the key he received is Alices public-key and not someone elses?
An apparent quick solution for this problem is Alice handing over her public-key to Bob in a secured manner. But this presupposes that Alice and Bob have had some form of secured communication prior. Even If Alice publicizes her public-key in this way, it is not scalable. If she needs to have similar secured communication with say 100 more users then this process becomes a nightmare. Also for Bob getting public-key in this way and managing them is a nightmare.
If both Bob and Alice can trust some intermediary who in a secured way can bind a public-key to the owner of it, the problem will be solved. Alice can simply ask this intermediary to certify her public key. Bob needs to trust only this intermediary. He can verify that trusted intermediary certified the public-key. Since both Alice and Bob need to trust the public-key with one person, this scales for any number of users. For anyone with whom Alice needs to communicate she can send the same certificate. Also Bob can verify the public-key for all the users who are certified by the intermediary.
Alice signs the message with her private-key and sends her certificate along with the message and signature to Bob. Bob verifies the validity of the signature using Alices public-key that he extracts from the Alice certificate issued by certifying authority
X 509 Certification
There are three certification methods that are commonly used now
- Directory Methods (X 509 Certificates and CAs)
- Referal Methods (PGP)
- Collabrative Methods (SKIP)
Of these X 509 devised by ITU-T is the de facto standard. X 509 digital certificates associates the public-key with the distinguished name, defined by X 500, of the user.
Certificate Chain
X 509 digital certificates are signed messages by themselves, wherein the certifying authority (hereafter referred as CA) is the signer of the message. CA uses public-key of its signature key pair to sign users digital certificate. However this does not solve the Bobs problem of binding the public-key to owner of it. How do Bob bind the public-key of CA to CA? Chicken and Egg Problem? Bob now needs to find a certificate issued by a superior CA attesting the identity of this CA. By doing this Bob starts constructing a chain of certificates, each attesting the subordinate CAs identity, terminating in a certificate issued by someone that Bob implicitly trusts. Such a certificate is called a trusted root certificate. Trusted root certificate forms the root of a hierarchy of public-keys/identity bindings that Bob accepts as authentic. The CA that issued the trusted root certificate is called Root-CA, and the one that issued certificate to Alice is called Issuing-CA. All the other CAs between the root and the issuing CAs are called Intermediate-CA. When Bob chooses to explicitly trust a particular trusted root certificate, he is also implicitly trusting all the certificates issued by that trusted root CA, as well as all certificates issued by any subordinate CA certified by the trusted root.
Certificate Contents
In addition to the users distinguished name and public-key, digital certificate also contain other information. Following Picture shows the content of Version 1 X 509 digital certificates.
Version 2 X 509 digital certificates introduced two more fields,
Issuer Unique ID: Makes the issuer name unambiguous if it is used by more than one entity.
Subject Unique ID: Makes the subject name unambiguous if it is used by more than one entity.
Version 3 X 509 digital certificates allowed adding any number of custom fields, called Extensions, to the certificate.
Following pictures shows a Version 3 X 509 digital certificate issued by the Certification Server in Windows 2000 Advanced Server.
Following are the details of the certificate
Version 1 Fields
Version: V3
Serial Number: 6106 C4F8 0000 0000 0002
Valid From: Friday, December 20, 2002 7:55:34 PM
Valid To: Monday, December 20, 2004 7:48:02 PM
Subject: CN = w2k-as-1224.PGVIJAY.com
Public Key: RSA (1024 bits) 3081 8902 8181 00A5 4F71 CE5C B897 BBB5 DE85 790A E590 DCD5 6720 8B65 A98F 0A56 652E BC60 DF7B 783C 9DF0 373C AFD0 B447 4BAD BF56 C940 164B 534C 4CD9 A602 87B4 EF02 C8CB F9FA 89E2 53CB 350D 6096 416B EB16 E9F8 8DA2 5769 112F 3DE4 28FE 6CF5 9673 8093 A65A 3BB7 C420 9A7E 718E CF64 2725 3E71 F6A7 4E00 9A00 38B8 7F9F FC39 DD0E 9255 437B 5F02 0301 0001
Issuer: CN = Pgvijay, OU = pgvijay home, O = pgvijay Inc, L = Stamford, S = ct, C = US, E = pgvijay@msn.com
Signature Algorithm: sha1RSA
Version 2 Fields
Subject Key Identifier: 2377 9A5E EA96 93A3 7409 021E FCDA B713 A368 0C34
Authority Key Identifier: KeyID=BF9A 4988 5536 A242 7512 9AE2 FC68 CF27 6CA6 C283 Certificate Issuer: Directory Address: CN=Pgvijay, OU=pgvijay home, O=pgvijay inc, L=Stamford, S=ct, C=US, E=pgvijay@msn.com Certificate Serial Number=6D81 BF9C E657 C88B 42FD A72C 44D3 39E6
Version 3 Fields
Key usage: Digital Signature, Key Encipherment (A0) See the side bar 2.
Enhanced Key Usage: Client Authentication (1.3.6.1.5.5.7.3.2), Server Authentication (1.3.6.1.5.5.7.3.1)
Certificate Template: Domain Controller
Subject: Alternative Name: Other Name: 1.3.6.1.4.1.311.25.1=0410 9BF6 C540 6777 CD4C 965F 82D4 ADE4 7440 DNS Name=w2k-as-1224.PGVIJAY.com
CRL Distribution Point:
- CRL Distribution Point
Distribution Point Name:
Full Name:
URL=ldap:///CN=Pgvijay,CN=w2k-as-1224,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=
Configuration,DC=PGVIJAY,DC=com?certificateRevocationList?base?objectclass=cRLDistributionPoint
- CRL Distribution Point
Distribution Point Name:
Full Name:
URL=http://w2k-as-1224.pgvijay.com/CertEnroll/Pgvijay.crl
Authority Information Access:
- Authority Info Access
Access Method=Certification Authority Issuer(1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=ldap:///CN=Pgvijay,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=PGVIJAY,DC=com?cACertificate?base?objectclass=certificationAuthority
- Authority Info Access
Access Method=Certification Authority Issuer(1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://w2k-as-1224.pgvijay.com/CertEnroll/w2k-as-1224.PGVIJAY.com_Pgvijay.crt
Thumbprint Algorithm: sha1
Thumbprint: 8C14 83A7 CAAE ED61 DCBE A15E 7E9A B2A0 7713 F138
Certificate Revocation Lists
A certificate revocation list (CRL) is the list of certificates that were revoked by the CA for some reason like the subjects private key being compromised. CA publishes the CRL at well-known places. Certificate issued by the Certificate Server of Windows 2000 PKI has the pointer to CRL also in it as a version 3 extension.
The above certificate states that the CRL will be published in
- Web server (http://w2k-as-1224.pgvijay.com/CertEnroll/Pgvijay.crl)
- Active directory server (ldap:///CN=Pgvijay,CN=w2k-as-1224,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=PGVIJAY,DC=com?certificateRevocationList?base?objectclass=cRLDistributionPoint)
Certificate Trust Lists
A certificate trust list (CTL) enables controlling the trust of the purpose and of the validity period of certificates that are issued by any external certification authorities (Windows 2000 PKI comes with Certificate Server and this becomes Internal certificate authority in the domain. Any CA that is not part of Windows 2000 domain, like Verisign etc, becomes external certificate authority). Typically, a certification authority issue certificates for a wide variety of purposes, such as secure e-mail or client authentication. But in situations when the trust of these certificates is to be limited, a certificate trust list is created. Suppose, for example, a certification authority named Abc CA is capable of issuing certificates for server authentication, client authentication, code signing, and secure e-mail. However, the certificates issued by Abc CA needs to be trusted only for the purpose of client authentication, a certificate trust list that limit the purpose for which certificates issued by Abc CA to client authentication is created. Any certificates issued for another purpose by Abc CA are not accepted for use by any computer to which this certificate trust list is applied.
Digital Certificate Support in CryptoAPI
Physical Store
Physical certificate store provides a grouping of certificates, certificate revocation lists (CRLs), and certificate trust lists (CTLs). Certificate store has only the pointers to the certificates and not the certificate themselves; instead certificates are persisted in permanent storages like file, registry (local or remote machine), active directory server, and smart card etc. Physical stores in turn are also located in different physical storages as the certificates. They can also be created on memory for temporary purposes.
Certificate Store Providers
CryptoAPI has predefined store provider types for different locations where a physical store can be persisted.
Logical Stores
Sometime a certificate might need to be member of several different logical groups. For this a logical collection of physical stores, called logical stores, is used. Any operation performed on the logical store is performed on the underlying physical stores. For instance, opening the logical store opens all the underlying physical stores, enumerating the certificates in the logical store enumerates all the certificates in all the underlying physical stores etc., An individual physical store can be a member of more than one logical store.
System Stores
Microsoft Windows 2000 comes with five predefined logical collection stores, namely MY, CA, TRUST, ROOT and USERDS. These stores are called system stores. Each of the following system store location has some or all of these system stores; and in addition they can also have other user created logical stores.
As said before every logical store in each of above locations have associated physical stores. For instance system stores at Current User has the following physical store association
Following picture shows a sample association between MY system store and the physical stores.
For more details on the store location please refer MSDN.
Key Databases in Cryptographic Service Providers (CSP)
Cryptography Service Providers in CrytpAPI persists the asymmetric key pairs across multiple sessions in a key database. These key databases have multiple key containers, which are identified by unique names. Windows creates a key container for each user of the machine. The key container is named after the user name. All the keys that belong to the user are kept in this container.
There are usually two key pairs in each container: key-exchange key pair and signature key pair. While the former is used to encrypt session keys, the later is used to create digital signatures. (For more details refer previous parts of this article).
Microsoft CSPs stores their key database in two different locations based on the type of the application, interactive standalone applications or non-interactive service applications. While Windows NT keeps the key containers in registry, Windows 2000 keeps them in file. Windows NT keeps key-database under the registry keys HKEY_CURRENT_USER\Software\Microsoft\Cryptography\UserKeys and HKEY_LOCAL_MACHINE\Software \Microsoft\Cryprography\MachineKeys for stand-alone applications and for non-interactive service applications respectively. Windows NT keeps key-database in a file under directories \Documents and settings\<username>\Application Data\Microsoft\Crypto\RSA\<user SID> and \Documents and settings\All Users\Application Data\Microsoft \Crypto\RSA\Machinekeys for stand-alone applications and for non-interactive service applications respectively.
Cryptography Support in Microsoft.Net
System.Security.Cryptography.X509Certificates namespace provides classes to work with X509v3 Digital Certificates.
However the namespace does not have full support to work with digital certificates, for instance there is no support for very important tasks such as
- Loading certificates from a certificate store.
- Finding the private-key associated with the public-key of digital certificate, from the key database.
- Reading X509 Version 2 Fields (Loads a v2 certificate but does not have methods to get the fields).
- Reading X509 Version 3 Fields (Loads a v3 certificate but does not have methods to get the fields).
- Working with CRL and CTL.
However X509Certificate class provides static methods to load a certificate from a file.
public
static X509Certificate CreateFromCertFile(string filename);
Following snippet shows how to load a certificate from file msn.cer/.
Following is the output generated by the above snippet. Output is edited for brevity.
1.2.840.113549.1.1.1 is the OID for RSA. For more details refer MSDN
Following picture shows the msn.cer certificate used by MSN. The certificate is available as a part of the attached sample.
Web Service Extensions for Microsoft.Net
Microsoft.Web.Services.Security.X509 namespace of Web Service Extensions (WSE 1.0) attempts to bridge the gap between the extensive X509 support in CrytpoAPIs and the limited X509 support in FCL. It has an X509Certificate class, which derives from the X509Certificate in the FCL. It also has a class to work with Certificate store X509CertificateStore. To use WSE a reference to Microsoft.Web.Services.dll should be added to the project.
Microsoft.Web.Services.Security.X509.X509Certificate class has a property to find the associated private key.
Microsoft.Web.Services.Security.X509.X509Certificate first finds the public-key, the asymmetric algorithm of the public-key and the subject name from the certificate. Then it attempts to load the default CSP that can work with the asymmetric key cipher in the certificate. In this sample the public-key cipher is RSA and the key size of 1024 bits (certificate file is attached with the sample). So it attempts to load "Microsoft Enhanced Cryptographic Provider v1.0" CSP using System.Security.Cryptography.RSACryptoServiceProvider. Then it attempts to load the corresponding private-key from the key container named after the subject-name (in this sample pgvijay) from the CSPs key database.
Following snippet shows how to use it.
Certificate Store in WSE 1.0
Microsoft.Web.Services.Security.X509.X509CertificateStore class provides partial CryptoAPI certificate store support. The X509CertificateStore class constructor takes the store provider, store location and store name.
public X509CertificateStore(X509CertificateStore.StoreProvider provider, X509CertificateStore.StoreLocation location, string storeName);
It only supports four store providers, namely system, file, collection and memory; but all the store locations defined by the CryptoAPI.
X509CertificateStore class provides methods to search for certificates based on subject name, key identifier and the hash value. Following snippet shows one such code
Following snippet shows how to find the asymmetric key pair when given the subject name of the certificate.
Certificate Services in Windows 2000
Windows 2000 Public Key Infrastructure comes with a Certificate Server. To generate a certificate for a user using the certificate server navigate to the CertServ Web Application installed in the CA Server (http://w2k-as-1224/CertSrv/).
Select Request a certificate in this page and say Next.
Select Advanced request in this page and say Next
Select Submit a certificate request to this CA using a form. In this page and say Next
Fill up the page as shown above. This creates a 1024 bits RSA key-pair and stores the key set in the key container BobKeys of the CSP Microsoft Base Cryptographic Provider v1.0. The key set can be user as both signature key pair and key exchange key pair.
Selecting Install this certificate will install the certificate in the default store of the local machine.