 |
|
| Towards 2000
Part 14:�
Introduction Everyone has heard of cryptography and has a pretty good idea of how it can be used to protect privacy in today’s networking environments.� Whether it is for securing communications in e-commerce transactions, creating virtual private networks, maintaining confidentiality and integrity of e-mail messages, or simply securing private files on a local hard drive, cryptography is required in one form or another. Crypto for Beginners There are basically two types of cryptography – secret key (or symmetric key) and public key (or asymmetric key). With secret key cryptography, Bob encrypts some plain text using a standard algorithm and a key chosen by him before sending the encoded text to Alice. In order to read the message, Alice requires the same key and algorithm combination used by Bob during the encryption process.� This naturally introduces a potential problem – how do we ensure that the key is distributed in a secure manner? Bob has to ensure that Alice is provided with a copy of his secret key whilst being sure that no one else is able to obtain a copy. If Bob and Alice have regular contact in person then the key can be transferred face to face – you cannot get much more secure than that. In business terms, secret keys (such as bank PIN numbers) are often distributed by mail in special tamper-proof envelopes, or can be encapsulated in hardware devices such as smart cards, where the issuing authority never gives the customer access to the key information at all. With public key cryptography, however, each person gets a pair of keys, known as the public key and the private key. The public key is generated from the private key using a complex algorithm, following which the public key can be published, whilst the private key remains secret. Unique mathematical properties ensure that it is impossible to derive the private key form the public key, and any message encrypted with a given public key can only be decrypted using the corresponding private key. Digital Signatures Once we have our data encrypted to prevent snoopers discovering its content, we still have to prove who we are to the other party involved in the transaction – an electronic equivalent of our physical signature. To ensure that no one can forge your electronic signature, digital signatures make use of public key techniques, using algorithms such as DSA and RSA (the latter being the most common implementation). Suppose Alice now wishes to send a signed message to Bob using RSA. She uses a “hash function” to create a uniquely concise version of the original text - known as a “message digest” - which serves as a very much smaller "digital fingerprint" of the message. Next, Alice encrypts the message digest with her RSA private key and this becomes the digital signature, which she sends to Bob along with the message itself (which may or may not be encrypted). Bob, upon receiving the message and signature, decrypts the signature with Alice's public key to recover the message digest. He then hashes the message with the same hash function Alice used and compares the result to the message digest decrypted from the signature. If they are exactly equal, the signature has been successfully verified and he can be confident that the message did indeed come from Alice. If, however, they are not equal, then the message either originated elsewhere or was altered after it was signed, and he rejects the message. Note that for authentication, the roles of the public and private keys are converse to their roles in encryption, where the public key is used to encrypt and the private key to decrypt. Digital Certificates Since public keys are designed to be readily available, it is difficult to ensure that a particular public key does indeed belong to the person you are expecting, and is not a forgery. A digital certificate is a small block of data which contains the user’s public key together with the a confirmation of authenticity from a third party in the form of that party’s digital signature. The third party is the “Certification Authority” (CA) in our PKI, and it is important that the CA is trusted in order that the certificate can be considered genuine. Certification Authority In terms of electronic commerce, a potential customer�– Alice - will first obtain a certificate from a trusted CA by providing proof of identity. This can range from a valid e-mail address to being required to appear in person with a birth certificate and passport, depending on the level of digital ID required. At the time of registration, a request for a digital ID is generated and her signing and/or encryption public keys will be bound to their respective digital certificates and stored at the CA. The resulting public key certificate will also be published in some form of readily-accessible directory. This can be queried by anyone wishing to find the digital identity of a given user, and in particular, a good certificate publisher will allow clients to automatically fetch certificates, including all certificates between the root and the desired certificate. Publishers can use any kind of directory service, including X.500, the Lightweight Directory Access Protocol (LDAP), or operating system specific directories (such as Active Directory) to publish certificates and CRL’s.� Once she has registered with her CA, Alice is ready for her e-commerce experience. When she wishes to purchase her new PC from Acme Computers over the Internet, she digitally signs the order (she may or may not encrypt it, depending on its sensitivity) and provides a copy of the certificate (this is done automatically in S/MIME applications). If she wishes, to encrypt the order, she must first obtain a copy of Acme’s public key, the authenticity of which she will be able to verify by virtue of the fact that the digital certificate has been signed by a trusted CA (providing the CA’s root certificate is held in Alice’s browser software). Certificate Validation Acme Computers checks Alice’s certificate on receipt, and because it has been signed by a trusted CA (either directly, or further up the hierarchy), the company knows it has a valid copy of Alice’s public key. It can then use this to verify the digital signature on the order, which was, of course, signed by Alice using the corresponding private key. At the same time, the expiry date on the certificate will be checked to make sure it is still valid. As a separate operation (or automatically if it is supported by the client software) Acme will check to see that the certificate has not been revoked (the equivalent of a credit card company cutting up your card). Certificates based on the X.509 standard (the most commonly used type) incorporate an expiry date to ensure that certificates and their associated key pairs are renewed automatically after a given period of time. There also needs to be a system in place to allow certificates to be revoked immediately in certain cases – say where an employee has left the company or the user’s private key has been compromised. This is done via a mechanism called the Certificate Revocation List (CRL). The issuing CA can revoke a certificate, thus preventing further use, by adding the serial number of the certificate to a CRL which is published at regular intervals. A CA can vary dramatically in scope. At the large end are commercial CA's like Thawte, Verisign, GlobalSign, GTE Cybertrust or others. These commercial CA’s issue certificates to millions of users. At the smaller end are CA’s operated by departments within a company; these CA’s issue certificates to a small number of users. These smaller CA’s may be intermediate CA’s whose certificates are signed by higher-level CA’s inside the organisation; those CA’s may in turn have certificates signed by other CA’s, all the way up to the root level (the hierarchy we mentioned earlier). Windows 2000 PKI Windows 2000 arrives with basic PKI capabilities built in to the operating system, necessary to support network-wide authentication and VPN’s amongst other things. It is perfectly capable of providing PKI functionality from a departmental to an enterprise level, however, and since the Windows 2000 PKI doesn't require any particular CA model, the administrator is free to mix and match from the standard models as needed. For example, some organisations prefer the idea of outsourcing all of their certificate management and issuance, while others prefer to keep everything in house. Windows 2000 accommodates both of these extremes, and everything in between, functioning either as a standalone Root or as part of a hierarchy. Because it is built into the operating system, the Windows 2000 PKI provides ease of use for both end users and administrators. Requesting a certificate requires a single mouse click, for instance, either through Internet Explorer or the Windows 2000 Certificate Manager.
In either case, the Certificate Request Wizard is simple to use - users fill out a short series of wizard pages and the request is automatically forwarded to the responsible CA. Once their certificates are processed (usually in real time), the private key material can be delivered straight to the client, and the public portion is automatically stored in Active Directory for later use. The fact the Active Directory forms the core of a Windows 2000 network provides a convenient repository for certificates and CRL’s which is accessible to everyone. As far as the administrator is concerned, the few management tasks required to maintain the Windows 2000 PKI occur as part of the normal system housekeeping Windows NT administrators already know how to do. In Windows 2000, the MMC is the administrator's standard workspace for all administrative tasks, including those related to PKI management. From the Certificate Services MMC snap-in, administrators can easily perform all the everyday tasks required for normal PKI maintenance:
These tasks are all integrated with the existing MMC, and they're performed using the same familiar tools and commands. For example, the figure above shows that to revoke a certificate, all an administrator has to do is right-click the certificate and choose the "Revoke Certificate . . . " command. Next month we will look in more detail at how Windows 2000 implements its PKI.
|
|
Send mail to [email protected] with
|
