This scenario describes a company that wants to sign vulnerable application objects on their public Web server. They want to be able to more easily determine when there are unauthorized changes to these objects. Based on the company's business needs and security goals, this scenario describes how to use Digital Certificate Manager (DCM) as the primary method for signing objects and verifying object signatures.
Situation
As an administrator for MyCo, Inc. you are responsible for managing your company's two systems. One of these systems provides a public Web site for your company. You use the company's internal production system to develop the content for this public Web site and transfer the files and program objects to the public Web server after testing them.
The company's public Web server provides a general company information Web site. The Web site also provides various forms that customers fill out to register products, and to request product information, product update notices, product distribution locations, and so forth. You are concerned about the vulnerability of the cgi-bin programs that provide these forms; you know that they might be altered. Therefore, you want to be able to check the integrity of these program objects and to detect when unauthorized changes have been made to them. Consequently, you have decided to digitally sign these objects to accomplish this security goal.
You have researched i5/OS™ object signing capabilities and have learned that there are several methods that you can use to sign objects and verify object signatures. Because you are responsible for managing a small number of systems and do not feel that you will need to sign objects often, you have decided to use Digital Certificate Manager (DCM) for performing these tasks. You have also decided to create a Local Certificate Authority (CA) and use a private certificate to sign objects. Using a private certificate issued by a Local CA for object signing limits the expense of using this security technology because you do not have to purchase a certificate from a well-known public CA.
This example serves as a useful introduction to the steps involved in setting up and using object signing when you want to sign objects on a small number of systems.
Scenario advantages
This scenario has the following advantages:
- Signing objects provides you with a means to check the integrity of vulnerable objects and more easily determine whether objects have been changed after they have been signed. This may reduce some of the troubleshooting that you do in the future to track down application and other system problems.
- Using DCM's graphical user interface (GUI) to sign objects and verify object signatures allows you and others in the company to perform these tasks quickly and easily.
- Using DCM to sign objects and verify object signatures reduces the amount of time you must spend to understand and use object signing as part of your security strategy.
- Using a certificate issued by a Local Certificate Authority (CA) to sign objects makes signing objects less expensive to implement.
Objectives
In this scenario, you want to digitally sign vulnerable objects, such as cgi-bin programs that generate forms, on your company's public server. As the system administrator at MyCo, Inc, you want to use Digital Certificate Manager (DCM) to sign these objects and to verify the signatures on the objects.
The objectives for this scenario are as follows:
- Company applications and other vulnerable objects on the public Web server (System B) must be signed with a certificate from a Local CA to limit the costs of signing applications.
- System administrators and other designated users must be able to easily verify digital signatures on systems to verify the source and authenticity of company signed objects. To accomplish this, each system must have a copy of both the company's signature verification certificate and the Local Certificate Authority (CA) certificate in each server's *SIGNATUREVERIFICATION certificate store.
- By verifying the signatures on company applications and other objects, administrators and others can detect whether the content of the objects has changed since they were signed.
- The system administrator must use DCM to sign objects; the system administrator and others must be able to use DCM to verify object signatures.
Details
The following figure illustrates the object signing and signature verification process for implementing this scenario:
The figure illustrates the following points relevant to this scenario:
System A
- System A runs i5/OS Version 5 Release 2 (V5R2).
- System A is the company's internal production server and development platform for the public iSeries™ Web server (System B).
- System A has a Cryptographic Access Provider 128-bit for iSeries (5722–AC3) installed.
- System A has Digital Certificate Manager (i5/OS option 34) and the IBM® HTTP Server (5722–DG1) installed and configured.
- System A acts as the Local Certificate Authority (CA) and the object signing certificate resides on this system.
- System A is uses DCM to sign objects and is the primary object signing system for the company's public applications and other objects.
- System A is configured to enable signature verification.
System B
- System B runs i5/OS Version 5 Release 1 (V5R1).
- System B is the company's external public Web server outside the company's firewall.
- System B has a Cryptographic Access Provider 128-bit (5722–AC3) installed.
- System B has Digital Certificate Manager (i5/OS option 34) and the IBM HTTP Server (5722–DG1) installed and configured.
- System B does not operate a Local CA, nor does System B sign objects.
- System B is configured to enable signature verification by using DCM to create the *SIGNATUREVERIFICATION certificate store and import the needed verification and Local CA certificates.
- DCM is used to verify signatures on objects.
Prerequisites and assumptions
This scenario depends on the following prerequisites and assumptions:
- All systems meet the requirements for installing and using Digital Certificate Manager (DCM).
- No one has previously configured or used DCM on any of the systems.
- All systems have the highest level of Cryptographic Access Provider 128-bit licensed program (5722-AC3) installed.
- The default setting for the verify object signatures during restore (QVFYOBJRST) system value on all scenario systems is 3 and has not been changed from this setting. The default setting ensures that the server can verify object signatures as you restore the signed objects.
- The system administrator for System A must have *ALLOBJ special authority to sign objects, or the user profile must be authorized to the object signing application.
- The system administrator or anyone else who creates a certificate store in DCM must have *SECADM and *ALLOBJ special authorities.
- The system administrator or others on all other systems must have *AUDIT special authority to verify object signatures.
Configuration task steps
There are two sets of tasks that you must complete to implement this scenario: One set of tasks allows you to configure System A as a Local Certificate Authority (CA) and to sign and verify object signatures. The second set of tasks allows you to configure System B to verify object signatures that System A creates.
See the scenarios details topic presented below to complete these steps.
System A task steps
You must complete each of these tasks on System A to create a private Local CA and to sign objects and verify the object signature as this scenario describes:
- Complete all prerequisite steps to install and configure all needed iSeries products
- Use DCM to create a Local Certificate Authority (CA) to issue an object signing certificate.
- Use DCM to create an application definition
- Use DCM to assign a certificate to the object signing application definition
- Use DCM to sign the cgi-bin program objects
- Use DCM to export the certificates that other systems must use for verifying object signatures You must export both a copy of the Local CA certificate and a copy of the object signing certificate as a signature verification certificate to a file.
- Transfer the certificate files to the company's public server (System B) so that you and others can verify the signatures that System A creates
System B task steps
If you intend to restore the signed objects that you transfer to the public Web server in this scenario (System B), you need to complete these signature verification configuration tasks on System B before you transfer the signed objects. Signature verification configuration must be completed before you can successfully verify signatures as you restore the signed objects on the public Web server.
On System B, you must complete these tasks to verify signatures on objects as this scenario describes:
- Use Digital Certificate Manager (DCM) to create the *SIGNATUREVERIFICATION certificate store
- Use DCM to import the Local CA certificate and the signature verification certificate
- Use DCM to verify the signatures on transferred objects