Make Sense of Public Key Infrastructure

Public Key Infrastructure

Written by Adrian J. Beasley

General
Public Key Infrastructure (PKI), strictly speaking, is the infrastructure which supports the trustworthy distribution of public keys, and nothing else. Unfortunately the term has come to encompass the whole area of cryptography, which is logically quite distinct, and this, in my opinion, complicates and obfuscates the entire subject. The present document keeps them separate.

Conventional (Symmetric Key) Cryptography
Cryptography deals with the secure transmission of messages, whereby the original text of the message (plain-text) is converted by a specific method into another form (cypher-text) for transmission to the intended recipient, who has available the converse method to reconvert it back into the original plain-text. If the cypher-text is intercepted by a third party, it is meaningless unless they also have the method to reconvert it. Cryptographic methods thus come in matching pairs – encrypt and decrypt – and both parties must have available the same pair for two-way transmissions.

Cryptography has been in use for at least 2000 years (Julius Caesar used a primitive form). The cryptographic methods available have increased in power and complexity over the years, but all have in common that they rely on a key. The method defines the process to be performed on the message, and the key is the parameter supplied to the process which determines the precise form of the results. Note that it is not necessary that the method itself be secret to be secure – this is in fact generally not the case, and there are many very secure methods whose details are publicly available – but the key must be kept secret. The combination of cryptographic method-pair and key is popularly termed the ‘code’.

Until very recently, all cryptographic methods used the same key for encryption and decryption – a symmetric key. Symmetric key cryptography is very fast and efficient, and, if the key is long enough, very secure. If a different key is used for each transmission session, and the session is not too long, then the code is effectively unbreakable. Breaking the code, without knowing the method and key, requires enormous computing power, sophisticated mathematics, a lot of data to work on, and a long time. Any code could, theoretically, be broken eventually, but strong codes ensure that the time to break is so long (years) that the results would no longer be of interest.

Symmetric key cryptography suffers from one very grave weakness – it doesn’t scale. Some method has to be found of securely distributing the key, so that both (or more) parties to the transmission have the same key available for the same session. All sorts of solutions have been tried, including courier with diplomatic bag, and the one-time code books beloved of spooks. All have in common that they are administratively inconvenient, costly, and potentially insecure. They are hard enough to manage between just two parties, and wholly impracticable when many parties are involved, i.e. they don’t scale.

As well as the key, the cryptographic method to be used needs to be agreed by both parties. In practice, this is usually known in advance and doesn’t vary, but strictly speaking, to be completely general, the identity of the method needs to be distributed along with the key. (The parties to the transmission, certainly when this is computer based, generally have several standard cryptographic methods available.)

Asymmetric Key Cryptography
This is a very recent development (the last 30 years, I think, with practical applications only in the last 10). Asymmetric Key cryptographic methods use one key to encrypt the text and a different but related key to decrypt it. This is a truly astonishing concept, and relies on some very advanced mathematics. Fortunately, it is not necessary to understand the mathematics in order to be able to use the methods.

(But, as a matter of general interest, the approach relies, for its security, on the extreme computational difficulty in determining the prime factorisation of all but very small natural numbers – less than a million, say. All numbers which are not themselves prime have a unique factorisation into primes. But determining this factorisation, without any supporting information, involves, effectively, trying all possible combinations, which expand exponentially as the size of the number increases. All this stuff has been known for 2500 years, and appears in Euclid. No-one in the intervening years has been able to come up with a significant improvement on the Sieve of Eratosthenes, as the original method is called, though many of the best intellects have tried. As a further, amusing aside, the consequence is that Number Theory, which used to be the purest form of pure mathematics – of no practical application whatever – has been transformed into a very important branch of applied mathematics. Carl Friedrich Gauss would have been delighted – I think.)

What this means is that we have pairs of keys, called the public and the private key for reasons that will immediately become apparent, related mathematically such that, using an appropriate cryptographic method, text encrypted using the private key can be decrypted only using the corresponding public key (and no other), and text encrypted using the public key can be decrypted only using the corresponding private key (and no other). Hence ‘asymmetric’.

This completely avoids the major limitation of symmetric keys. The private key belongs to an individual (John Doe) and is kept private – only John Doe knows it. The corresponding public key is published to the entire world. Thus anyone can send a secure message to John Doe by encrypting it with John Doe’s openly available public key, but only John Doe can decrypt it, using his own private key. Likewise John Doe can send a secure message to anyone else by encrypting it with that person’s openly available public key, and only that person can decrypt it, using their own private key.

A further important benefit is that the message can be digitally signed. John Doe, prior to encrypting the message, performs a hash (see next para.) on it and encrypts the hash value using his private key. He then appends this digital signature (the encrypted hash value) to the message and finally encrypts the whole with the public key of the recipient. Only the recipient can decrypt the message, using their private key. The digital signature is then available, and the recipient decrypts that using John Doe’s openly available public key. This has three important consequences. By performing the same hash function on the decrypted message and comparing the hash value with that in the digital signature then, if they match, the recipient can be sure that the message has not been altered in transit. They can also be certain that the message really is from John Doe and nobody else. The third consequence is that John Doe cannot subsequently deny having sent the message!

[Hashing is some appropriate one-way mathematical process (the hash function), which transforms a general message of arbitrary length into an equivalent fixed-length value (the hash). ‘One-way’ means that there is no means of getting from the hash back to the original message. The hash is unique for a given initial message. But of course, since the hash is of fixed length, it has only a finite number of possible values (2ⁿ where n is the length in bits). Accordingly, an infinite number of original messages, of varying length, yield the same hash. (And that is fundamental reason why the operation is one-way.) However, the chance of more than a very small number of these making any sort of linguistic sense is remote – the vast majority are simply garbage. Many orders of magnitude even more remote is the chance of two such messages dealing with the same topic. The possibility of two conflicting or contradictory messages having the same hash can thus be discounted.
The defining characteristic of a good hash function is that the slightest change (1 bit) to the original message results in a new hash which is totally different from and bears no discernable relationship to the previous hash. (It should also be computationally efficient.)]

Thus, using asymmetric key encryption, every individual and organisation needs to own only one public/private key pair to be able to communicate securely and provably and, optionally, privately, with anyone else, and vice versa.

In fact digital signatures have developed independent uses of their own. They certify the origin of a piece of data (which need not even be textual) and also guarantee that the contents have not been tampered with since leaving the originator, whether or not the data are confidential – i.e. data can be signed without necessarily being subsequently encrypted. They are thus used, for example, to guarantee program code integrity, so program code distributed over the Internet can be signed, and thus guaranteed not to have been infected with a virus since leaving its (certified) originator – but anybody can read it. This is an important point to stress; digital signatures originally appeared as a side benefit of asymmetric key encryption, but they have taken on a life of their own and are now far more common in situations which are not in any way confidential, and thus where encryption (of the entire communication) is not even used.

Unsurprisingly, asymmetric key encryption and decryption are heavy on computation. They are of the order of a hundred times heavier than symmetric operations, and transmissions thus take a hundred times longer. As a consequence, the way that asymmetric key encryption is used in practice, for bulk transmissions, is for the parties to agree on a symmetric key and cryptographic method, using asymmetric operations for this interaction, and then use that (much more efficient) symmetric key and method for the actual bulk transmission (possibly using digital signatures for the individual blocks of data). This combines the benefits of both approaches. (In fact, the symmetric key is often changed on a regular basis throughout the transmission, even, in the extreme case, changing after each exchange. This means that there are simply not enough data available for each key value for any practical attempt at code-breaking.)

Digital Certificates and Certification Authorities
Unfortunately, asymmetric key encryption also has a big problem (but nowhere near as crippling as that of symmetric). The public key is ‘published to the entire world’ - but how? More to the point, how can anyone be sure that a given, published public key really does belong to the individual it purports to belong to (and is not a fake, published by some miscreant who wishes to intercept secure communications intended for that individual)? As with symmetric key encryption, for complete generality, the identity of the cryptographic method also needs to be exchanged, and, additionally, the hash method used in generating the digital signature.

This is where we move from the clear atmosphere of technology, as detailed in previous sections, into the murky atmosphere of administrative process, where it all becomes really boring.

You know that a public key is kosher if it was given to you personally by the owner, whom you know personally and whom you trust. This is the approach of Pretty Good Privacy, and it works, but it doesn’t scale. But if you already have the public key of someone you trust, and that person sends you the public key of a third party that they, the sender, (whom you trust,) attest is genuine, and the communication is digitally signed by the sender, so that you can decrypt the signature using the sender’s public key, which you already have, and thus be sure that it really did come from the sender and has not been altered since, (and may, but need not, be encrypted with your public key so that only you can decrypt it, with your private key,) then you might reasonably decide to accept the public key of that third party. You have just accepted a Digital Certificate – the public key of a third party, guaranteed as genuine and digitally signed by someone (more usually some organisation) that you trust. That trusted person or organisation is the Certification Authority by whom the Digital Certificate is issued. The Digital Certificate contains further information, including but not limited to the identity of the cryptographic method to which the key applies, and the hash method used in that third party’s digital signature (which information you need, actually to be able to use the key).

It all relies on trust. You must trust a Certification Authority, and hold the Digital Certificate of that Certification Authority. Then you are able to accept other Digital Certificates issued by that Certification Authority. These may be sent to you by the owner of the Digital Certificate, who wishes to be able communicate securely with you. The fact that the Digital Certificate is signed by the Certification Authority (and thus you can also guarantee that it hasn’t been altered since the Certification Authority issued it) means that you can safely accept the public key contained in it. Alternatively, if you wish to communicate securely with someone whose Digital Certificate you do not already hold, you can simply ask them for it, or obtain it from the issuing Certification Authority (if you know which it is).

All Microsoft Operating Systems since NT4 have contained the Digital Certificates of a range of public Certification Authorities – all the well-known ones and many you’ll never have heard of. You may be sure that these are the goods (assuming that your OS is not a bootleg copy!). Digital Certificates are stored in a particular location in filestore, the Certificate Store. Initially this contains just the standard Certification Authority Digital Certificates, but you can add to it at will. If you receive a secure communication from an individual or organisation whose Digital Certificate you already have (and therefore trust) it is processed automatically. If you receive a secure communication from an individual or organisation whose Digital Certificate you do not already have, it may be flagged as unprocessable. However, many organisations often include their Digital Certificate with the communication (especially if the communication is just digitally signed, rather than encrypted also, such as software downloads), and then you are presented with the option to accept or reject it, and also you may accept the Digital Certificate and add it to the certificate store. (If you already accept the issuing Certification Authority, there’s no a priori reason to reject the communication or the Digital Certificate.) All these operations are the province of Cryptographic Services, which has been an integral part of all M/S OSs for many years (and an optional add-on before that.)

In an e-commerce transaction, when it comes to payment time, the website automatically supplies you with a Digital Certificate issued by a public Certification Authority (which your computer will already trust). This serves two purposes, it guarantees the identity of the vendor (and thus that you are not dealing with a rogue website) and it is used to encrypt your message – credit card details and so on – for transmission back to the website where it is decrypted using the vendor’s private key. The authentication and encryption are each one-way only, because that’s all that is needed - there is normally no requirement to authenticate the client to the vendor, and communications from the vendor to the client are not confidential.

A Digital Certificate, since it contains both the public key itself and the associated information which must be known in order actually to be able to use the key, is the unit by which public keys are distributed, stored and used. You will never in practice encounter a public key (except your own) other than in the context of a Digital Certificate.

There’s a lot more to be said about Digital Certificates – the subject is horribly complicated and convoluted – but that, in essence, is what it’s about, to the best of my understanding. It is worth stressing again that Digital Certificates are fundamentally nothing more than a means of distributing public keys (and associated information) in a trustworthy fashion. Public keys do not depend on Digital Certificates in any way for their functionality (except insofar as the associated information also contained in the Digital Certificate is required in order actually to be able to use the key). Note that Digital Certificates have nothing whatever to do with private keys; private key processing and administration are entirely the responsibility of the key’s owner.

Digital Certificate Life Cycle
Digital Certificates are issued by a Certification Authority, by whom (i.e. with whose private key) they are digitally signed. A Digital Certificate has a unique (for that Certification Authority) identifier, and a start date and an end date, outside which validity period the certificate is unusable, i.e. all the operations which involve Digital Certificates check that the current system date falls between these dates, and will not operate outside the validity period. (Occasionally, processing is historic – relating to some date in the past – in which case any relevant Digital Certificate must have been valid at that date, even though it may have expired subsequently.) It may be possible, as the Digital Certificate approaches its end date, to extend the period of validity. This should not be done repeatedly, since nothing can be guaranteed secure for ever.

In addition, a Digital Certificate may be revoked at any time by its issuing Certification Authority. Each Certification Authority maintains a Certificate Revocation List (CRL), containing the identifiers of all revoked certificates and possibly the reason for revocation (though this is not greatly important; it is the fact of revocation that matters rather than the cause). Every system which uses Digital Certificates must either maintain a local copy of the CRL of every Certification Authority it uses (and keep it up to date!) or know the location of the Certification Authority’s own CRL. Either way, all operations which involve Digital Certificates check whether the Digital Certificate is on the CRL of the issuing Certification Authority, and, if so, will not use it. (See also next section on Digital Certificate purpose.) In fact, the location of the CRL is another item of information in the Certification Authority’s Digital Certificate.

Certification Authorities may be public, i.e. organisations whose primary business is the issuing of Digital Certificates, or private. Public Certification Authorities are widely known and trusted bodies, most of whose own Digital Certificates are contained as standard in the OS. Individuals or organisations purchase a Digital Certificate from a public Certification Authority. They must supply the Certification Authority with a copy of their public key, and a lot of background information, and the Certification Authority will also carry out a prescribed (and published) series of checks. (The public key is just a long string of seemingly garbage text, and is supplied to the Certification Authority simply by cutting and pasting the text string into the application document, which may of course be electronic.) When the Certification Authority has satisfied itself (according to its proclaimed standards) that the applicant is who they say they are and does what they say they do, and that they are generally reputable and also the rightful owner of that public key, in other words when the Certification Authority is satisfied and prepared to guarantee the applicant’s and public key’s integrity, the Certification Authority issues a Digital Certificate to the applicant containing the public key and associated information, digitally signed with the Certification Authority’s own private key. The Certification Authority also itself makes the Digital Certificate publicly accessible. The individual or organisation is now the client of the Certification Authority. Note that the Certification Authority does not create the public key, and never even sees the corresponding private key. The client is responsible for generating the key pair, using appropriate cryptographic software, and supplying the public key (together with the associated information on cryptographic and hash methods) along with the application. The client alone is responsible for administering the private key. The Certification Authority publishes details of its procedures, especially of the checks it performs on applicants. All this is crucial in maintaining public trust in the Certification Authority (since trust is, ultimately, all that the Certification Authority has to sell).

The above is generally true, but the amount and rigour of the checking varies between Certification Authorities. By and large you get what you pay for.

Reputable Certification authorities publish (at least) two documents. The Certificate Policy defines the measures taken to validate an applicant prior to issuing a certificate. It includes, inter alia, how the applicant’s identity is validated, the certificate’s intended purpose, the type of device on which the corresponding private key is to be stored, the applicant’s responsibilities concerning the private key, and the revocation policy procedures and responsibilities. The Certificate Policy thus deals largely with the applicant/user’s responsibilities. The Certificate Practice Statement, on the other hand, details the responsibilities of the Certification Authority. It defines the measures which are taken to secure the Authority’s operations and management of issued certificates. It also defines how the Authority will enforce the applicant validation procedures, the liability accepted in the event of security breaches suffered by the user, where these can be tied to the certificate, and the circumstances under which the certificate can be revoked prior to its expiry

Private Certification Authorities are local to the owning organisation, and wholly under its control. The Digital Certificates they issue are used only within the organisation (or perhaps also by business partners on an extranet). Public trust is not an issue since the public is not involved, and thus all the administrative apparatus described above can be dispensed with. Otherwise, Digital Certificates issued by a private Certification Authority are identical in all respects to those issued by a public Certification Authority. Administering Digital Certificates in a private Certification Authority can be very much simpler than public Digital Certificates, and a lot of it can be automated. Given the large number of uses for which Digital Certificates are now appropriate (see Uses section), a private Certification Authority is usually a very sensible investment.

Microsoft Windows Server 2003 makes available a Certificate Server, as standard (albeit its capabilities are different in the standard and enterprise editions of the OS), as does Windows 2000 Server. This is included in the OS at no extra charge. (Note that this is entirely distinct from Cryptographic Services, which allow Digital Certificates to be used, and which are always running, unless explicitly disabled.)

Types of Digital Certificate
Digital Certificates are standards based (the relevant standard is X.509) and come in two versions. Digital Certificates are intended for specific purposes (as detailed in the next section), and any operation involving Digital Certificates will check that the Digital Certificate supplied is appropriate for the intended use, and reject it if not. Version 1 Digital Certificates are for a fixed use only; the purpose for which the Digital Certificate is valid is hard coded into the Digital Certificate itself. Consequently, version 1 Digital Certificates tend to multiply, as a different certificate is required for each relevant application. Version 2 Digital Certificates, on the other hand, are programmable, in that they contain extension clauses, which specify (amongst other things) the use for which the Digital Certificate is appropriate, and there may be multiple such clauses. How this works in practice is that the Certification Authority administrator defines a number of version 2 certificate multi-use templates, including the appropriate extension clauses to determine the uses. A Digital Certificate is then generated against a template, and is good for the multiple uses defined in that template. Version 2 Digital Certificates are obviously much more convenient than version 1, since fewer are required; ideally one Digital Certificate serves all of a user’s needs. (Version 2 Digital Certificates actually correspond to version 3 of the X.509 standard. There was also a version 2, but this never won wide acceptance, and all its enhancements are also available in version 3, together with much more. The usage is confusing, but established)
 
Note again that this is all purely administrative stuff, i.e. process, not technology. There is no technical reason why a single Digital Certificate should not be used for any purpose for which asymmetric key cryptography is relevant. But there are good security grounds for restricting Digital Certificate use, on the principle of least privilege.

Digital Certificates are also categorised as computer or user, since certain applications are appropriate at computer level (for the computer’s own operations and for all users who use that computer) whereas others are appropriate only to the individual user. Again, this distinction is process, not technology.

Uses of Digital Certificates
Digital Certificate applications of primary interest to users include authentication (especially using smart-cards), remote access VPNs, secure e-mail and file encryption. Those of primary use at the computer level include IP Security, Wireless security and network-to-network VPNs. For several of these applications, the use of Digital Certificates is mandatory.

Certification Authority Hierarchies
Every Digital Certificate is guaranteed by the Certification Authority which issued it, but who guarantees the Certification Authority? In fact, the Certification Authority guarantees itself. A single private Certification Authority within a small business may be sufficient by itself, but normally Certification Authorities come in hierarchies. (We are talking here of Certification Authorities as logical units. A Certification Authority organisation, public or private, would consist of a hierarchy of logical Certification Authority units.) At the top of the hierarchy is the Root Certification Authority. When this is created, it generates its own Digital Certificate – i.e. it guarantees itself. The root Certification Authority is used only to issue Digital Certificates to a further set of Certification Authorities, one level below it in the hierarchy; it guarantees these Certification Authorities. These are either Issuing Certification Authorities, which actually issue Digital Certificates to clients or, for the larger Certification Authority organisation, public or private, Intermediate Certification Authorities, whose function again is merely to issue Digital Certificates to other Certification Authorities at a lower level, who actually are the Issuing Certification Authorities. (The 3-level root/intermediate/issuing Certification Authorities structure would seem adequate for the largest organisations.)

The entire point of this hierarchy is security. (It shares the load of issuing Digital Certificates, of course, but in very few cases can that load be so great as to justify the cost of sharing it. It does also provide redundancy.) If a Certification Authority is compromised, i.e. if an attacker manages to get hold of the Certification Authority’s own private key, then all the Digital Certificates issued by that Certification Authority can no longer be trusted, since the attacker could build a rogue Certification Authority, indistinguishable from the original, and issue rogue certificates. It takes little imagination to appreciate what a disaster this would be; it would certainly destroy a public Certification Authority by the inevitable deluge of lawsuits, and by dissipating all public trust; the effects on an private Certification Authority could also be fatal, since all business processes and data would no longer be secure. The root Certification Authority and any intermediate level Certification Authorities are therefore never externally accessible. Real security paranoiacs (i.e. security professionals) insist that these servers be kept in locked rooms and not even connected to the organisation’s internal network, but that all operations – there aren’t many; just certifying new Certification Authorities – are performed offline and any data transferred by floppy disk. (Indeed, except when such operations are required, the machines can be kept switched off!) So only a particular issuing Certification Authority could be compromised – bad enough but of limited scope. (That’s the theory, anyway. Personally, I can’t see that it makes much difference. Compromise of a Certification Authority is a major disaster whether it takes out the entire business or only a part. The effect on public confidence is much the same.)

The Digital Certificates which are contained as standard in the OS are those of the root Certification Authorities of the various public Certification Authority organisations. When a new Certification Authority Digital Certificate is issued, it contains the identifier of the parent Certification Authority immediately above it in the hierarchy, so the client can download this also into the certificate store. There is thus a chain of Digital Certificates, and thus of trust, starting at the leaf Digital Certificate and extending back to the root Digital Certificate. (The previous sections have implicitly assumed that each Digital Certificate is linked directly to the root Digital Certificate originally issued with the OS. In practice, for all cases except single-level private Certification Authorities, this is never the case – there is always a chain.)

The Microsoft Certificate Server
Microsoft’s offering is a fully featured certificate server. If installed on Windows Server 2003 Enterprise Edition (or Data-Center edition) it supports version 1 and version 2 Digital Certificates (and thus templates, and hence Digital Certificates, can be customised to support multiple functions). On Windows Server 2003 Standard Edition or Windows Server 2000, only version 1 Digital Certificates are supported. The software supports a hierarchy of Certification Authorities (i.e. individual servers) as described in the previous section.

A hierarchy of Certification Authorities may be established, as described in the previous section, each supported by its own certificate server. The Certification Authorities can be of two types, Stand-Alone and Enterprise. Stand-Alone Certification Authorities are like all Certification Authorities as described so far. Enterprise Certification Authorities, on the other hand, are integrated with Active Directory, which provides many benefits, in particular that all Digital Certificates that they issue are published in AD, and thus replicated throughout the organisation and available anywhere. Stand-Alone and Enterprise Certification Authorities may be mixed in the hierarchy, in that both may have a stand-alone parent Certification Authority, but only enterprise Certification Authorities may have an enterprise parent Certification Authority. The recommended use is to have stand-alone Certification Authorities for the root and any intermediates, and use enterprise as the issuing Certification Authorities. The stand-alone Certification Authorities are not part of AD, and can be switched off when not in use. Note that the Digital Certificates of the Certification Authorities themselves can (and should) be published in AD (even though the certificate servers are not in AD). This is a manual process, but then all Digital Certificates are available in AD and the chains of trust are readily accessible. Even CRLs are published to AD!

Enterprise Certification Authorities have many benefits. Their backup requirements are automatically handled as part of AD backup. Their behaviour can be controlled by group policy, in particular relevant Digital Certificates (of certain types) can be issued automatically to users and computers. (There are several ways of issuing Digital Certificates from enterprise Certification Authorities, but only one for stand-alone Certification Authorities – the user/computer must request a Digital Certificate through a web interface to the server, and an administrator must then manually approve the request.) Note that, unlike obtaining a Digital Certificate from a public Certification Authority, where the applicant must generate the key pair independently, M/S certificate servers appear to generate the key pair and the Digital Certificate as part of the same operation. (This is in fact misleading. The key pair is still generated by cryptographic software on the client, and only the public key passed across to the Certification Authority, which generates the Digital Certificate and passes it back to the client. As far as the onlooker is concerned, it all takes place as a single, client-server process.)

For a small organisation, a single enterprise Certification Authority is adequate. For larger organisations, as noted above, the recommended structure is a stand-alone root Certification Authority (and stand-alone intermediate Certification Authorities, if appropriate) and enterprise issuing Certification Authorities in the various major divisions. All Digital Certificates are valid throughout the organisation, since they all chain back to the root Certification Authority. In a multi-domain forest, the root Certification Authority should be in the root domain. The others could be anywhere, but would reasonably be distributed across the non-root domains

In my opinion, the certificate server is the great unrealised benefit of the Windows OS; it remains unrealised for the same reason that PKI in general remains unrealised, because of the quite exceptional turgidity of the entire topic (as the reader will now appreciate.)

Private Key Administration and Use
Whereas the public key, in the form of a digital certificate, is published and multiplied indefinitely, the private key is the responsibility of the owner. It must be secured – a copy exported to some medium, such as a floppy disk, where it can be stored offline in a secure location. If the private key were compromised, the consequences would be severe – everything secured by the key would no longer be secure. If the private key were lost, the consequences would be equally severe – everything secured by the key would no longer be accessible, it would likewise be lost.

How the private key is administered is determined by what type it is. If it is a computer key, then it is generally stored on the owning computer. All the standard security recommendations apply, network and physical; there is nothing really new here. But for user keys, different considerations apply. The user may need to log on to more than one machine. Ideally, the user’s private key should not be stored on the owner’s computer(s), particularly not laptops, but on some other medium, which is stored separately, and only introduced to the computer when it is in use. A floppy disk is a possibility, but far better is a smart-card, which is additionally protected by a password or PIN. This implements two-factor authentication, whereby authentication depends on something you have – the card – and something you know – the password or PIN – both of which are necessary. It is still essential that a copy/copies of the private key are held in secure, offline locations, in case the card is lost.

There have been various proposals for storing private keys is some database, where some trusted third party has responsibility for them, and access is controlled by extremely stringent procedures (of course!). This is termed key escrow. It is greatly favoured by authoritarian regimes and bureaucracies, who are affronted at the idea of the citizen having secrets inaccessible to the state or the police. It needs to be strongly opposed. The individual user must accept the responsibility; there is no safe alternative.

There is, however, one area where key escrow or an equivalent method is appropriate. If files on a user’s computer are encrypted, using the Encrypted File System, it is desirable that the contents be accessible in the event of the private key becoming lost or inaccessible (if the user leaves the employment, say, possibly in unfriendly circumstances). One or more users, generally administrators, can be nominated as File Recovery Agents, and they also have the ability to decrypt the files. Similarly, it could simply be the case that several users need to be able to access files, which are kept encrypted, as part of their normal duties. How this is implemented is that the file is encrypted using a symmetric algorithm and key. The symmetric key used is itself encrypted, using the public keys of the owner and any other relevant users/recovery agents, and these encrypted forms are stored as part of the file’s header. Any of these users could, using their own private key, decrypt that copy of the asymmetrically-encrypted symmetric key that applies to them, and thus decrypt the file’s contents. File Recovery Agents are usually nominated by group policy, and are thus not under the user’s control.

True key escrow is also available with the Microsoft Certificate Server. The private keys can also be stored in the Certification Authority’s database (AD, in the case of enterprise Certification Authorities), where they are accessible by nominated Key Recovery Agent users. Within the context of a private Certification Authority, the objections to key escrow have less force, but I still prefer the File Recovery Agent approach.