This chapter concerns procedures to provide cryptographic security to NetWare services. The objectives important to this chapter are found on page 5-1:
Concepts:Describe Public Key CryptographyPublic key cryptography is an encoding scheme that assigns every user two keys. These keys are used to prove the identity of the sender of a message. This is called authentication. Keys are also used to encrypt and decrypt messages. Messages sent across IP networks can easily be intercepted, and are subject to eavesdropping. It is a good idea to use encryption for any transmission of a financial or sensitive nature. The public key method uses two different keys. Either of the keys can be used to encrypt a message. Whichever key is used to encrypt the message, the other key must be used to decrypt it. One of the two keys is called a user's public key. This key is delivered to anyone who needs it, and is used to decrypt messages that were encrypted with the user's other key, the private key. This method proves to message recipients that the message originated from the owner of the private key. Likewise, messages meant for the user can be encrypted with the public key, and can only be decrypted with the user's private key, ensuring security. The process of delivering public keys to people who need them is a problem. How do you know that the proof you are accepting is reliable? Public keys need to be verified by a Certificate Authority (CA). Novell provides a CA in its Certificate Server. Now the terminology changes a bit. A message may be sent to a server/provider with a digital signature. A user will create a digital signature with their private key, and register that digital signature with a Certificate Authority. The signature may also be created by the CA, since the CA may be the source of both of the user's keys. Example: A user sends a message to an online vendor, including a digital signature, created with the user's private key. That signature may be verified with the CA that the user is registered with. The CA receives a request for verification from the vendor and checks out the signature. If the signature is valid, the CA then sends an encrypted message to the vendor including the public key of the original user, allowing the vendor to read the digital signature. In this way, the vendor does not get the user's information until it has been established that the message is really from the user. Encryption can also be done strictly with public and private keys. The book gives an example of buying something online, using a web browser. The buyer is sent the public key of the store through the browser. The browser encrypts the buyer's credit card data, and sends to the store's server. The server decrypts the data using the store's private key. (A problem exists here: the store has no way to send encrypted data back to the buyer, unless the buyer has a public and private key of his/her own.) More terminology: a public key certificate is a digital message signed with a private key. A public key certificate is generated by a trusted entity, as described above, called a certificate authority (CA). Public key certificates can also be called digital public key certificates, digital IDs, digital passports, or certificates. Three lists are provided, describing what information must be, may be, or might be in a certificate. They must have a public key, a subject name, and a CA-generated signature. Usually, they contain an expiration date, the name of the CA that issued the public key certificate, and the serial number of the public key certificate. All of this information must be included if the certificate follows a standard called X.509 v3. If so, the following information is expected to be in them:
Optional information in the X.509 v3 standard:
You may have received verification services from commercial providers and not known it. Often, when downloading a file from the web, it is common to encounter a screen like the one below:
This screen states that VeriSign, a CA, has verified that the file about to be downloaded comes from the source I requested it from, Trend Micro. Other CAs listed in the text are GTECyberTrust and Australian Post. Alternatively, a company may provide its own Certificate Authority. In either case, the job of the CA is to verify identities and to issue public keys certificates. Other functions may be assigned to the CA as well:
Describe Novell Certificate ServerNovell Certificate Server protects the transmissions in your network by creating, issuing, and managing user and server certificates. A list of features is provided in the chapter:
The text remarks that the world edition of NICI supports 512-bit encryption, but the U.S. and Canadian version supports 2048-bit encryption. Certificate Server will support whatever is installed on your network. Novell Certificate Server is contained in PKI.NLM and a snap-in that allows it to be managed from ConsoleOne, which is run on a workstation. It cannot be managed from ConsoleOne running on a server. Using ConsoleOne, you can:
Novell International Cryptographic Infrastructure (NICI) must be installed for Novell Certificate Server to work. NICI comes with Certificate Server, but must be installed manually. Users can use ConsoleOne or Novell Certificate Console to export a certificate and private key. The Certificate Console is an alternative, if you do not want your users to use ConsoleOne. Configuring and Maintaining Novell Certificate ServerAs stated above, one server in your Tree will run the CA service. From it, you can create the Server Certificate objects to be used by servers that will host secure applications.
Applications must be configured to use the Server Certificates. Public key certificates expire in specific periods of time. The default period is two years for certificates signed by the Novell CA. Those signed by External CAs typically expire in one year. The certificate life span can be set to expire in 6 months, 1 year, 2 years, 5 years, or in the year 2036. Life cycle of a key pair:
A definition of a key is given in the text: "a numeric value used by an algorithm to alter information, making that information secure and visible only to individuals who have the corresponding key to recover the information". Remember that when using key pairs, either key can be used for encrypting, but the other must be used for decrypting. Secure Sockets Layer (SSL)This is a protocol that uses public and private keys on both ends of a session. For example, if you were to make a purchase from Amazon.com, you would begin an SSL session with their server by sending it your public key (keeping your private key to yourself), and receiving their public key (while they keep their private key hidden). In this way, transmissions from either end can only be decrypted by the intended receiver. Perform Novell Certificate Server TasksYou may use either an Organizational CA, an external CA, or both. Be aware that you must use an Organizational CA to sign user certificates in this version of NetWare. Benefits of using the NetWare Organizational CA:
Benefits of using an External CA:
If you do not create a CA when installing NetWare, you may do so later. To create the Organizational CA object:
You must choose a server in the Tree to run the CA service. You are advised to choose one that is reliable and available, that runs the necessary protocols to communicate with all your other servers, and that only runs software you trust. Server Certificate objects are created in the same container as the server they are associated with. Server Certificate objects are also called Key Material objects. The schema name of the NDS object is NDSPKI:Key Material. To create additional Server Certificate objects:
When creating this kind of object, you are asked to name the key pair for the certificate. The name of the object is based on the key pair name. If using the Organizational CA to create the key pair, the CA and the server the certificate is for must run the same protocol suite. Note: when creating the key material, you should specify 2048 bits if you are in the United States or Canada, 512 bits elsewhere. Detailed procedures are given in the text for creating user certificates, a trusted root container (in the Security container), and a Trusted Root object (in the trusted root container). You should practice all three procedures. The process for configuring individual application to use your CA varies from one product to another. You should check the documentation of the product. ConsoleOne will let you view the properties of the Organizational CA object (just like it lets you view the properties of other objects).
The two certificates above have similar properties. The Self-Signed Certificate is used for authentication. It is exported to entities that require verification of certificates signed by your CA. This is similar to the trusted root certificate that is exported by servers. You can begin the process of exporting a Self-Signed Certificate by clicking the Export button on its page (see bullet above). When an external CA responds to your request (CSR) for a Server Certificate, it sends two certificates. One is a signed public key certificate, which verifies your identity. It is like an ID card to show applications and secure users. The other is a trusted root certificate, which verifies the CA’s identity. This certificate proves the identity of the issuer of your public key certificate. When received, you must import the certificates above before they can be used. This can be done from either the General or Certificate tab of your Server Certificate object. You will be presented with a window in which you should paste text from the Server certificate you received. (The Server certificate from the CA is a text file.) Paste all lines between and including the lines that say “-----BEGIN CERTIFICATE-----” and “-----END CERTIFICATE-----”. To import the Trusted Root certificate, you will only have to browse to it at the appropriate time. A Trusted Root Certificate may be exported to as a reference for applications that need to verify your ID. It can be exported in two file formats: DER encoded and Base64 encoded. .DER and .CRT extensions can be used for DER-encoded certificates. Base64 encoded certificates should use .B64 as their file extension. As noted above, you may have to delete a Server Certificate object if it becomes compromised. The method is simple: just delete it from the Tree in ConsoleOne. Note that you cannot restore it. As with the CA object, you can use ConsoleOne to view the properties of the Server Certificate's Public Key Certificate and its Trusted Root Certificate. Use the Certificates tab in the Server Certificate object. User objects can store certificates in them. Open a user object in ConsoleOne, click its Security tab, and click a certificate to view properties. Multiple certificates can be stored in a user object. People with sufficient rights may export user certificates, but only the user may export their certificate and their private key, together. Use the Export button on the Security tab of the user object. User certificates may also be exported with Novell Certificate Console. Set up Novell Certificate Console by running SYS:\PUBLIC\MGMT\CERTCONSOLE\SETUP.EXE. As you can do for all objects discussed, you can view the properties of a Trusted Root object by opening it in ConsoleOne. It is stored in the Trusted Root container. The Trusted Root object has a Trusted Root tab in it. Click this tab and click the Replace button to activate a wizard to replace the Trusted Root object. This should be done when the Trusted Root certificate expires. |
