Recently, I blogged about public/private key cryptography in plain(ish) English. That post was based on a session which I saw Microsoft UK’s Steve Lamb present. A couple of weeks back, I saw the follow-up session, where Steve put some of this into practice, securing websites, e-mail and files.

Before looking at my notes from Steve’s demos, it’s worth picking up on a few items that were either not covered in the previous post, or which could be useful in understanding what follows:

• In the previous post, I described encryption using symmetric and asymmetric keys; however many real-world scenarios involve a hybrid approach. In such an approach, a random number generator is used to seed a symmetric session key which contains a shared secret. That key is then encrypted asymmetrically for distribution to one or more recipients. Once distributed, the (fast) symmetrical encrypted session key can be used.
• If using the certificate authority (CA) built into Windows, it’s useful to note that this can be installed in standalone or enterprise mode. The difference is that enterprise mode is integrated with Active Directory, allowing the automatic publishing of certificates. In a real-world environment, multiple-tiers of CA would be used and standalone or enterprise CAs can both be used as either root or issuing CAs. It’s also worth noting that whilst the supplied certificate templates cannot be edited, they can be copied and the copies amended.
• Whilst it is technically possible to have one public/private key pair and an associated certificate for multiple circumstances, there are often administrative purposes for separating them. For example, in life one would not have common keys for their house and their car, in case they needed to change one without giving access to the other away. Another analogy is to compare with single sign on, where it is convenient to have access to all systems, but may be more secure to have one set of access permissions per computer system.

The rest of this post describes the practical demonstrations which Steve gave for using PKI in the real world.

Securing a web site using HTTPS is relatively simple:

1. Create the site.
2. Enrol for a web server certificate (this authenticates the server to the client and it is important that the common name in the certificate matches the fully qualified server name, in order to prevent warnings on the client).
3. Configure the web server to use secure sockets layer (SSL) for the site – either forced or allowed.

Sometimes web sites will be published via a firewall (such as ISA Server), which to the outside world would appear to be the web server. Using such an approach for an SSL-secured site, the certificate would be installed on the firewall (along with the corresponding private key). This has the advantage of letting intelligent application layer firewalls inspect inbound HTTPS traffic before passing it on to the web server (either as HTTP or HTTPS, possibly over IPSec). Each site is published by creating a listener – i.e. telling the firewall to listen on a particular port for traffic destined for a particular site. Sites cannot share a listener, so if one site is already listening on port 443, other sites will need to be allocated different port numbers.

Another common scenario is load-balancing. In such circumstances, the certificate would need to be installed on each server which appears to be the website. It’s important to note that some CAs may prohibit such actions in the licensing for a server certificate, in which case a certificate would need to be purchased for each server.

Interestingly, it is possible to publish a site using 0-bit SSL encryption – i.e. unencrypted but still appearing as secure (i.e. URL includes https:// and a padlock is displayed in the browser). Such a scenario is rare (at least among reputable websites), but is something to watch out for.

Configuring secure e-mail is also straightforward:

1. Enrol for a user certificate (if using a Windows CA, this can either be achieved via a browser connection to http://servername/certsrv or by using the appropriate MMC snap-ins).
2. Configure the e-mail client to use the certificate (which can be viewed within the web browser configuration, or using the appropriate MMC snap-in).
3. When sending a message, opt to sign or encrypt e-mail (show icons).

Signed e-mail requires that the recipient trusts the issuer, but they do not necessarily need to have access to the issuing CA; however, this may be a reason to use an external CA to issue the certificate. Encrypted e-mail requires access to the user’s public key (in a certificate).

To demonstrate access to a tampered e-mail, Steve turned off Outlook’s cached mode and directly edited a message on the server (using the Exchange Server M: drive to edit a .EML file)

Another possible use for a PKI is in securing files. There are a number of levels of file access security, from BIOS passwords (problematic to manage); syskey mode 3 (useful for protecting access to notebook PCs – a system restore disk will be required for forgotten syskey passwords/lost key storage); good passwords/passphrases to mitigate known hash attacks; and finally the Windows encrypting file system (EFS).

EFS is transparent to both applications and users except that encrypted files are displayed as green in Windows Explorer (cf. blue compressed files). EFS is also unfeasible to break so recovery agents should be implemented. There are however some EFS “gotchas” to watch out for:

• EFS is expensive in terms of CPU time, so may be best offloaded to hardware.
• When using EFS with groups, if the group membership changes after the file is encrypted, new users are still denied access. Consequently using EFS with groups is not recommended.
• EFS certificates should be backed up – with the keys! If there is no PKI or data recovery agent (DRA) then access to the files will be lost (UK readers should consider the consequences of the regulation of investigatory powers act 2000 if encrypted data cannot be recovered). Windows users can use the cipher /x command to store certificates and keys in a file (e.g. on a USB drive). Private keys can also be exported (in Windows) using the certificate export wizard.

Best practice indicates:

• The DRA should be exported and removed from the computer.
• Plain text shreds should be eliminated (e.g. using cipher /w to write 00 and FF to the disk at random).
• Use an enterprise CA with automatic enrollment and a DRA configured via group policy.

More information can be found in Steve’s article on improving web security with encryption and firewall technologies in Microsoft’s November 2005 issue of TechNet magazine.