Determining Secure Application Requirements

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Before you begin to design your public key infrastructure and configure certificate services, you need to define the security needs of your organization. For example, does your organization require electronic purchasing, secure e-mail, secure connections for roaming users, or digital signing of files? If so, you need to configure CAs to issue and manage certificates for each of these business solutions.

A Windows Server 2003 PKI can support the following security applications:

  • Digital signatures

  • Secure e-mail

  • Software code signing

  • Internet authentication

  • IP security

  • Smart card logon

  • Encrypting file system user and recovery certificates

  • 802.1x authentication

Digital Signatures

A digital signature is a means for originators of a message, file, or other digitally encoded information to bind their identities to the data. This can be extremely useful for important documents such as legal opinions and contracts. The process of digitally signing information involves transforming the information, together with some secret information held by the sender, into a tag called a signature. Digital signatures are used in public key environments to help secure electronic commerce transactions by providing verification that the individual sending the message is who he or she claims to be, and by confirming that the message received is identical to the message sent.

You can use digital signatures even when data is distributed in plaintext, such as with e-mail. In this case, while the sensitivity of the message itself does not warrant encryption, it can be important as a means to ensure that the data is in its original form and has not been sent by an impostor.

One way that your organization can capitalize on the use of digital signatures is by using CAPICOM. CAPICOM is an ActiveX control that provides a COM interface to Microsoft CryptoAPI. It exposes a select set of CryptoAPI functions to enable application developers to incorporate digital signing and encryption functionality into their applications. Because CAPICOM uses COM, application developers can access this functionality in a number of programming environments, such as Microsoft® Visual Basic®, Microsoft® Visual Basic® Scripting Edition, Active Server Pages, Microsoft® JScript®, C++, and others. CAPICOM is packaged as an ActiveX control, allowing Web developers to use it in Web-based applications as well.

You can use CAPICOM for:

  • Digitally signing data with a smart card or software key.

  • Verifying digitally signed data.

  • Displaying certificate information.

  • Inspecting certificate properties such as subject name or expiration date.

  • Adding and removing certificates from the certificate stores.

  • Encrypting and decrypting data with a password.

  • Encrypting and decrypting data by means of public keys and certificates.

Secure E-mail

Standard Internet mail is sent as plaintext over open networks with no security. In the increasingly interconnected network environments of today, intruders can monitor mail servers and network traffic to obtain proprietary or sensitive information. You also risk exposure of proprietary and confidential business information when you send mail over the Internet from within your organization.

Another form of intrusion is impersonation. On IP networks, anyone can impersonate mail senders by using readily available tools to counterfeit the originating IP address and mail headers. When you use standard Internet mail, you can never be sure who really sent a message or whether the contents of the message are valid. Moreover, malicious attackers can use mail to cause harm to the recipient computers and networks (for example, by sending attachments that contain viruses).

For these reasons, many organizations have placed a high priority on implementing secure mail services that provide confidential communication, data integrity, and non-repudiation. A Windows Server 2003 public key infrastructure allows you to enhance e-mail security by using certificates to prove the identity of the sender, the point of origin of the mail, and the authenticity of the message. It also makes it possible to encrypt mail. To provide message authentication, data integrity, and non-repudiation, secure mail clients can sign messages with the private key of the sender before sending the messages. The recipients then use the public key of the sender to verify the message by checking the digital signature.

S/MIME clients that run on any platform or operating system can exchange secure mail because all cryptographic functions are performed on the clients, not on the servers.

Software Code Signing

A growing number of applications, ActiveX® controls, and Java applets are being downloaded and installed on computers with little or no user notification.

In response to this problem, Microsoft introduced Authenticode™ digital signature technology in 1996, and in 1997 added significant enhancements to this technology. Authenticode technology allows software publishers to digitally sign any form of active content, including multiple-file archives. These signatures can be used to verify both the publishers of the content and the content integrity at time of download. Many software vendors already sign their applications and you can use these signatures to manage the software applications used on your network.

Authenticode relies on a certification authority structure in which a small number of commercial CAs issue software-publishing certificates. If you want to expand the use of software-publishing certificates in your own organization, the Windows 2000 and Windows Server 2003 PKI allows you to issue your own Authenticode certificates to internal developers or contractors and allows any employee to verify the origin and integrity of downloaded applications.

Internet Authentication

The Internet has become a key element in the growth of electronic commerce. However, for many users, security considerations impact how much and what kind of information they are willing to share across the Internet. The major concerns are:

  • Confidentiality. Data that is transferred between clients and servers needs to be encrypted to prevent its exposure over public Internet links.

  • Server authentication. Clients need a way to verify the identity of the servers they are communicating with.

  • Client authentication. Servers need a way to verify the identity of clients.

Client authentication of the server takes place when the client verifies the cryptographic signatures on the certificate of the server, and any intermediate CA certificates, to a root CA certificate located in the trusted root store on the client. Server authentication of the client is accomplished when the server verifies the cryptographic signatures on the certificate of the client, and any intermediate CA certificates, to a root CA installed in the trusted root store on the server. When the identity of the client is verified, the server can establish a security context to determine what resources the client is allowed or not allowed to use on the server.

IP Security

Windows 2000 and Windows Server 2003 incorporate Internet Protocol security (IPSec) to protect data moving across the network. IPSec is a suite of protocols that allows encrypted and digitally signed communication between two computers or between a computer and a router over an insecure network. The encryption is applied at the IP network layer, which means that it is transparent to most applications that use specific protocols for network communication. IPSec provides end-to-end security, meaning that the IP packets are encrypted or signed by the sending entity, are unreadable en route, and can be decrypted only by the recipient entity. Due to a special algorithm for generating the same shared encryption key at both ends of the connection, the key does not need to be passed over the network.

You do not need to use public key technology to use IPSec; instead you can use the Kerberos version 5 authentication protocol or shared secret keys that are communicated securely by means of an out-of-band mechanism at the network end points for encryption. However, if you use public key technology in conjunction with IPSec, you can create a scalable distributed trust architecture in which IPSec devices can mutually authenticate each other and agree upon encryption keys without relying on prearranged shared secrets, either out-of-band or in-band. This, in turn, yields a higher level of security than IPSec without a PKI.

For more information about deploying IPSec solutions, see "Deploying IPSec" in Deploying Network Services of this kit.

Smart Card Logon

Smart card logon is integrated with the Kerberos version 5 authentication protocol implemented in Windows Server 2003. When smart card logon is enabled, the system recognizes a smart-card insertion event as an alternative to the standard Ctrl + Alt + Del secure attention sequence to initiate a logon. The user is then prompted for the smart card PIN code, which controls access to operations performed by using the private key stored on the smart card. In this system, the smart card also contains a copy of the certificate of the user (issued by an enterprise CA). This allows the user to roam within the domain.

Smart cards enhance the security of your organization by allowing you to store extremely strong credentials in an easy-to-use form. Requiring a physical smart card for authentication virtually eliminates the potential for spoofing the identities of your users across a network. In addition, you can also use smart card applications in conjunction with virtual private networks and certificate mapping, and in e-commerce. For many organizations, the potential to use smart cards for logon is one of the most compelling reasons for implementing a public key infrastructure.

For more information about deploying smart cards, see "Planning a Smart Card Deployment" in this book.

Encrypting File System Use and Recovery

The Windows Server 2003 Encrypting File System (EFS) allows users and services to encrypt their data to prevent others who authenticate to the system from viewing the information. However, EFS also provides for data recovery if another means is needed to access this data — for example, if the user who encrypted the data leaves the organization, or if the original encryption key is lost. To support this requirement, EFS allows recovery agents to configure public keys that are used to enable file recovery. The recovery key only makes available the randomly generated file encryption key, not a private key of the user. This ensures that no other private information is accidentally revealed to the recovery agent.

Note

  • You do not need to have a public key infrastructure to use Windows Server 2003 Encrypting File System. However, the use of public keys improves the manageability of EFS. In a Windows domain environment, it is recommended that EFS be used in conjunction with a PKI.

For more information about EFS, see the Windows Security Collection of the Windows Server 2003 Technical Reference (or see the Windows Security Collection on the Web at https://www.microsoft.com/reskit).

Wireless (802.1x) Authentication

A growing number of organizations and facilities such as airports and hotels are implementing wireless network access. This creates the challenge of ensuring that:

  • Only authenticated users can access the wireless network.

  • Data transmitted across the wireless network cannot be intercepted.

Public key infrastructures, in conjunction with the IEEE 802.1x standard for port-based network access control, support both of these goals by providing centralized user identification, authentication, dynamic key management, and accounting to provide authenticated network access to 802.11 wireless networks and to wired Ethernet networks.

For more information about deploying a wireless network, see "Deploying a Wireless LAN" in this book.