Techforum

Make your own digital certificates

Article summary: Although security is an area of concern for everyone, there are many myths and ambiguities surrounding it. One of the most common misconceptions in the minds of most IT professionals is that you need a third-party authority to issue and consume digital certificates. This is true for Internet-based transactions with unknown persons. However, for intranet and extranet applications, as well as internal mail, you can implement your own PKI (Public Key Infrastructure) using Certificate Server that is built into Windows 2000.

This is a great opportunity for organisations to upgrade and tighten security without spending for third-party certificates.

This article highlights the need for PKI and details how this could be implemented in a very cost-effective manner.

What is PKI?

PKI means Public Key Infrastructure. When we perform transactions on the Web, or when we send mail to each other, we need a method of identifying whether the source of information is the person who it claims to be. In addition we need to know whether the message was tampered with after it was sent by the originator.

PKI provides this assurance. First of all it creates a pair of numbers. One number is available for everyone to see and the other is kept private and secure for each user. Now the public key is used to encrypt messages, which can be decrypted only using the private key. This ensures that only the authorised person can read the message.

In addition, the private key is used to create a digital certificate, which is then used to authenticate users for messaging validation, Web client transactions, Web server application authentication and so on.

How do you get the keys?

* From third-party providers

The public and private keys need to be generated by some specialised software. Further the public key should be made available online for validation by any user. This means the authentication server containing the public keys must be always accessible to all possible applications using the PKI.

The private keys need to be issued in a secure manner to maintain safety of the key. Valid users may lose the key or want additional keys (one for desktop computer, another for laptop, etc). All this requires some administration overhead.

Most importantly, you need to be sure that a particular private key really belongs to the specified person.

All these tasks are typically managed by the Certifying Authority (CA). CAs are generally third-party organisations that offer identity validation as well as PKI administration services.

For each digital certificate issued, a yearly fee needs to be paid to the CA.

* From local (in-house) provider

It is also possible to set up a Certifying Authority in-house. The purpose, functionality and tasks performed by the local CA would be similar to the third-party one. Windows 2000 (and above) contains a full-featured tool called Certificate Server to manage PKI infrastructure.

As this is an in-house infrastructure, there is no extra cost attached to this method of issuing digital certificates.

Now that you have two choices, which one do you choose?

Which type of Certifying Authority to use?

* Do you perform high-value commercial transactions, with a large number of end customers?

The main reason third-party certifying authorities are utilised for is identity verification. In a mass market eCommerce website, it is impossible for the company to verify the actual identity of every online customer. Therefore, every potential customer has to first obtain a digital certificate (which is created from the private key) from the third-party certifying authority.

Many sites simply have a registration process, which generates a username and password for the logged-on user. However this is sufficient only for non-serious websites. For serious commercial transactions, we need assurance that the information entered by the user is correct and the identity of the person is correct. Therefore, PKI with a third-party provider becomes necessary for such transactions.

* Do you sell ‘digitally signed’ software commercially?

The reverse is true in this case. This is so for Macro software, ActiveX controls, .NET components and so on, which are commercially available. Here the software vendor obtains a digital certificate from the CA and publishes it along with the software.

Users then have a choice of viewing the certificate, checking its validity and then deciding to load the software. This is known as ‘authenticode’.

* Do you need secure transactions with internal employees and known associates (dealers, distributors, C&F agents)? Or do you need secure internal mail flow?

In both these cases, there’s good news. You do not have to opt for a third-party CA.

Do you know why? Simply because you do not need a third-party to tell you to trust your own employees, dealers and distributors. You already trust them!

All that you need is a mechanism for generating, issuing and administering key pairs and certificates. This is provided by the Certificate Server of Windows 2000.

Uses of PKI

PKI is a generic infrastructure. You can use it primarily for the following purposes:

1. To authenticate the owner of the digital certificate.
2. To ensure that content sent has been sent from the specified originator.
3. To ensure that the content has not been tampered after it was sent by the valid originator.
4. To create and sign code for internal use (macros, controls, reusable components, websites).

The practical uses are:

1. Secure e-mail.
2. Secure Web communication.
3. Secure websites and Web applications.
4. In-house distribution of software files.
5. IP security.
6. Encrypted File System for secure storage of data.

* Secure e-mail

The CA needs to be configured along with your messaging system. For Exchange 5.5 there is a built-in key management server. For Exchange 2000 there is active directory integration for direct support of digital certificates.

All commonly used messaging products support digital certificates. Outlook allows users to specify whether they would like to use a digital certificate for specific messages. However, for internal mail, you can configure Exchange to use digital certificates so that the security and non-repudiation aspects are automatically available for internal correspondence.

* Secure web communication

Using internally issued digital certificates you can implement Secure Sockets Layer based applications so that the data is encrypted across the Web channel. This is useful when the data is highly sensitive. However, this will have a processing overhead. Therefore the performance of an SSL-enabled application is likely to be slightly lower.

* Web application authentication

Typical Web applications make use of a userid and password, which is stored in a database. This is a grossly inadequate and potentially risky mechanism of authentication. IIS can be configured to check the identity of the logging user by using the PKI. This makes site access much more secure and people are accountable for the actions they take.

* Getting rid of Enable/Disable macro dialogs

Office macro warning is designed to prevent viruses from running. However, for serious applications that are developed on Office, this warning is a nuisance. If you sign the macro code with digital certificates and if the users choose the option of trusting in-house code, then the dialog will never appear for internal code. This is a great use of PKI for creating and distributing applications and components in-house in a fully trusted manner.

Prerequisites for PKI implementation

PKI requires the following:

• There are some features like EFS and IpSec that provide specific certificates out of the box. No planning and configuration is required for this.
• All other purposes require planning.
• Typically there are three levels of hierarchy in PKI — Root CA, Policy Implementing CA and the Issuing CA. The Issuing CA needs to be online.
• You need to decide whether the Cryptography provider available with Windows is sufficient or you require an add-on Cryptographic Service Provider (like smart cards). For most intra/extranet scenarios, the built-in provider is a good starting point as it can be used out of the box and does not require additional expenses in procuring an add on.

Case study

We recently deployed PKI for a large financial services provider. Multiple Web applications now use internally issued digital certificates. Further, user authentication is also based upon the digital certificates.

In order to reduce the administrative overheads of managing the issuing, renewal or revoke cycle of digital certificates, the Certificate Server itself is programmed using its object model. This way the administrative tasks are fully automated. Users themselves can connect to the self-service site (with adequate security, of course) for common tasks.

This was probably the first large-scale implementation of PKI using an in-house certifying authority.

The customer is very satisfied with the results of the implementation.

Planning and implementation

The details of planning and implementation are beyond the scope of this article. However I will cover some key points.

1. The base tool is not loaded along with Windows 2000 by default. You have to choose Control Panel – Add/Remove Programs – Add/Remove Windows Components and choose Certificate Services.

2. You can view the existing certificates as well as request for additional certificates using the Certificates snap-in in MMC.

3. There is a Web-based mechanism also available for managing the certificate server functionality. The default web site is:

http://<computername>/certsrv

4. The MMC snap in works in two modes: Logical and Certificate Purpose mode. Logical mode is used for browsing existing certificates. Certificate Purpose mode is used to request certificates for a specific purpose.

5. The client side software (like messaging) needs to be enabled to utilise the digital certificates infrastructure.

6. Structured planning is the most critical part of PKI implementation.

Various purposes for which a certificate can be requested are given below.

1. Server authentication.
2. Client authentication.
3. Code signing.
4. Secure e-mail
5. Time stamping.
6. IP security.
7. Windows hardware driver / system component verification.
8. Encrypted file system.
9. Digital rights management.
10. File recovery (from EFS).

Implement it in your organisation

Through TechForum I have always provided readers with information that is difficult to find but highly useful. I would say a PKI implementation is something every organization needs because it increases the protection level. Traditionally, only those companies which consider themselves to be conducting mission critical businesses (finance industry, for example) have opted for Digital Certificates for authentication and secure Web communication.

I have always strived to unearth and extract more and more value from the software you already have. This is a classic example of utilising the mundane OS to perform tasks traditionally thought to be beyond its scope!

I feel each organisation has information that is vital to its business. Therefore, PKI-based security should be looked at as a necessary part of base infrastructure–not as a special need for special businesses.

I know security is still a grey area. I have just shown the need and the feasibility of an idea that is highly appealing. I am sure many of you will have lots of questions in this regard. Feel free to send your queries to me at the address mentioned below.

About the Author:Dr Nitin Paranjape is the Chairman and MD of Maestros (Mediline). He is a consultant with many organisations, covering appropriate technology utilisation, business application of relevant technology, application architecture and audit as well as knowledge transfer. He has authored more than 650 articles on various technology-related subjects. He can be contacted at nitin@mediline.co.in