232 lines
15 KiB
HTML
232 lines
15 KiB
HTML
<?xml version="1.0" encoding="UTF-8"?>
|
||
<!DOCTYPE html
|
||
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
<html lang="en-us" xml:lang="en-us">
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
<meta name="security" content="public" />
|
||
<meta name="Robots" content="index,follow" />
|
||
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
<meta name="DC.Type" content="concept" />
|
||
<meta name="DC.Title" content="Scenario: Use APIs to sign objects and verify object signatures" />
|
||
<meta name="abstract" content="This scenario describes an application development company that wants to programmatically sign the applications that it sells. They want to be able to assure their customers that the applications came from their company and provide them with a means of detecting unauthorized changes to the applications when installing them. Based on the company's business needs and security goals, this scenario describes how to use the Sign Object API and Add Verifier API to sign objects and enable signature verification." />
|
||
<meta name="description" content="This scenario describes an application development company that wants to programmatically sign the applications that it sells. They want to be able to assure their customers that the applications came from their company and provide them with a means of detecting unauthorized changes to the applications when installing them. Based on the company's business needs and security goals, this scenario describes how to use the Sign Object API and Add Verifier API to sign objects and enable signature verification." />
|
||
<meta name="DC.Relation" scheme="URI" content="rzalzscenariosoverview.htm" />
|
||
<meta name="DC.Relation" scheme="URI" content="rzalzapisigndetails.htm" />
|
||
<meta name="DC.Relation" scheme="URI" content="../rzahu/rzahurazhudigitalcertmngmnt.htm" />
|
||
<meta name="copyright" content="(C) Copyright IBM Corporation 2004, 2006" />
|
||
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2004, 2006" />
|
||
<meta name="DC.Format" content="XHTML" />
|
||
<meta name="DC.Identifier" content="apisignsc" />
|
||
<meta name="DC.Language" content="en-us" />
|
||
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
<!-- US Government Users Restricted Rights -->
|
||
<!-- Use, duplication or disclosure restricted by -->
|
||
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
<title>Scenario: Use APIs to sign objects and verify object signatures</title>
|
||
</head>
|
||
<body id="apisignsc"><a name="apisignsc"><!-- --></a>
|
||
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
<h1 class="topictitle1">Scenario: Use APIs to sign objects and verify object signatures</h1>
|
||
<div><p>This scenario describes an application development company that
|
||
wants to programmatically sign the applications that it sells. They want to
|
||
be able to assure their customers that the applications came from their company
|
||
and provide them with a means of detecting unauthorized changes to the applications
|
||
when installing them. Based on the company's business needs and security goals,
|
||
this scenario describes how to use the Sign Object API and Add Verifier API
|
||
to sign objects and enable signature verification.</p>
|
||
<div class="section"><h4 class="sectionscenariobar">Situation</h4><p>Your
|
||
company (MyCo, Inc.) is a business partner that develops applications for
|
||
customers. As a software developer for the company, you are responsible for
|
||
packaging these applications for customer distribution. You currently use
|
||
programs to package an application. Customers can order a compact disc (CD-ROM)
|
||
or they can visit your Web site and download the application. </p>
|
||
<p>You keep
|
||
current with industry news, especially security news. Consequently, you know
|
||
that customers are justifiably concerned about the source and content of the
|
||
programs that they receive or download. There are times when customers think
|
||
that they are receiving or downloading a product from a trusted source that
|
||
turns out not to be the true product source. Sometimes this confusion results
|
||
in customers who install a different product than the one they expected. Sometimes
|
||
the installed product turns out to be a malicious program or has been altered
|
||
and damages the system. </p>
|
||
<p>Although these types of problems are not common
|
||
for customers, you want to assure customers that the applications that they
|
||
obtain from you are really from your company. You also want to provide customers
|
||
with a method of checking the integrity of these applications so that they
|
||
can determine whether they have been altered before they install them. </p>
|
||
<p>Based
|
||
on your research, you have decided that you can use i5/OS™ object signing capabilities to accomplish
|
||
your security goals. Digitally signing your applications allows your customers
|
||
to verify that your company is the legitimate source of the application they
|
||
receive or download. Because you currently package applications programmatically,
|
||
you have decided that you can use APIs to easily add object signing to your
|
||
existing packaging process. You also decide to use a public certificate to
|
||
sign objects so that you can make the signature verification process transparent
|
||
to your customers when they install your product. </p>
|
||
<p>As part of the application
|
||
package you include a copy of the digital certificate that you used to sign
|
||
the object. When a customer obtains the application package, the customer
|
||
can use the certificate's public key to verify the signature on the application.
|
||
This process allows the customer to identify and verify the source of the
|
||
application, as well as ensure that the contents of the application objects
|
||
have not been altered since they were signed.</p>
|
||
<p>This example serves as
|
||
a useful introduction to the steps involved in programmatically signing objects
|
||
for applications that you develop and package for others to use.</p>
|
||
</div>
|
||
<div class="section"><h4 class="sectionscenariobar">Scenario advantages</h4><p>This
|
||
scenario has the following advantages:</p>
|
||
<ul><li>Using APIs to package and sign objects programmatically reduces the amount
|
||
of time that you must spend to implement this security.</li>
|
||
<li>Using APIs to sign objects as you package them decreases the number of
|
||
steps that you must perform to sign objects because the signing process is
|
||
part of the packaging process. </li>
|
||
<li>Signing a package of objects allows you to 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
|
||
problems for customers.</li>
|
||
<li>Using a certificate from a public well-known Certificate Authority (CA)
|
||
to sign objects allows you to use the Add Verifier API as part of an exit
|
||
program in your product installation program. Using this API allows you to
|
||
add the public certificate that you used to sign the application to your customer's
|
||
system automatically. This ensures that signature verification is transparent
|
||
to your customer.</li>
|
||
</ul>
|
||
</div>
|
||
<div class="section"><h4 class="sectionscenariobar">Objectives</h4><p>In this
|
||
scenario, MyCo, Inc. wants to programmatically sign applications that it packages
|
||
and distributes to their customers. As the application production developer
|
||
at MyCo, Inc, you currently package your company's applications programmatically
|
||
for distribution to customers. Consequently, you want to use system APIs to
|
||
sign your applications and have the customer's system programmatically verify
|
||
the signature during product installation. </p>
|
||
<p>The objectives for this
|
||
scenario are as follows:</p>
|
||
<ul><li>Company production developer must be able to sign objects by using the
|
||
Sign Object API as part of an existing programmatic application packaging
|
||
process.</li>
|
||
<li>Company applications must be signed with a public certificate to ensure
|
||
that the signature verification process is transparent to the customer during
|
||
the application product installation process. </li>
|
||
<li>The company must be able to use system APIs to programmatically add the
|
||
required signature verification certificate to the customer's system *SIGNATUREVERIFICATION
|
||
certificate store. The company must be able to programmatically create this
|
||
certificate store on the customer's system as part of the product installation
|
||
process if it does not already exist. </li>
|
||
<li>Customers must be able to easily verify digital signatures on the company's
|
||
application after product installation. Customers must be able to verify the
|
||
signature so that they can ascertain the source and authenticity of the signed
|
||
application as well as determine whether changes have been made to the application
|
||
since it was signed. </li>
|
||
</ul>
|
||
</div>
|
||
<div class="section"><h4 class="sectionscenariobar">Details</h4><p>The following
|
||
figure illustrates the object signing and signature verification process for
|
||
implementing this scenario:</p>
|
||
<br /><img src="rzalz002.gif" alt="Fig. 2 API object signing process illustration (text description follows figure)" /><br /><p>The figure illustrates the
|
||
following points relevant to this scenario:</p>
|
||
<p><strong>Central system A)</strong></p>
|
||
<ul><li>System A runs i5/OS Version 5 Release 2 (V5R2). </li>
|
||
<li>System A runs the application developer's product packaging program.</li>
|
||
<li>System A has a Cryptographic Access Provider 128-bit for iSeries™ (5722–AC3)
|
||
installed.</li>
|
||
<li>System A has Digital Certificate Manager (i5/OS option 34) and the IBM<sup>®</sup> HTTP Server
|
||
(5722–DG1) installed and configured.</li>
|
||
<li>System A is the primary object signing system for company application
|
||
products. Product object signing for customer distribution is accomplished
|
||
on System A by performing these tasks: <ol><li>Using APIs to sign company application product.</li>
|
||
<li>Using DCM to export the signature verification certificate to a file so
|
||
that customers can verify signed objects.</li>
|
||
<li>Writing a program to add the verification certificate to the signed application
|
||
product.</li>
|
||
<li>Writing a pre-installation exit program for the product that uses the
|
||
Add Verifier API. This API allows the product installation process to programmatically
|
||
add the verification certificate to the *SIGNATUREVERIFICATION certificate
|
||
store on the customer's system (Systems B and C).</li>
|
||
</ol>
|
||
</li>
|
||
</ul>
|
||
<p><strong>Customer systems B and C</strong></p>
|
||
<ul><li>System B runs OS/400<sup>®</sup> Version 5 Release 2 (V5R2) or a subsequent
|
||
release of i5/OS. </li>
|
||
<li>System C runs OS/400 Version 5 Release 2 (V5R2) or a subsequent
|
||
release of i5/OS.</li>
|
||
<li>Systems B and C have Digital Certificate Manager (option 34) and IBM HTTP Server
|
||
(5722–DG1) installed and configured.</li>
|
||
<li>System B and C purchase and download an application from the Web site
|
||
of the application development company (which owns System A).</li>
|
||
<li>Systems B and C obtain a copy of the MyCo's signature verification certificate
|
||
when MyCo's application installation process creates the *SIGNATUREVERIFICATION
|
||
certificate store on each of these customer's systems.</li>
|
||
</ul>
|
||
</div>
|
||
<div class="section"><h4 class="sectionscenariobar">Prerequisites and assumptions</h4><p>This
|
||
scenario depends on the following prerequisites and assumptions: </p>
|
||
<ol><li>All systems meet the <a href="../rzahu/rzahurzahureqdcmrequirements.htm">requirements</a> for installing and using Digital Certificate
|
||
Manager (DCM). <div class="note"><span class="notetitle">Note:</span> Meeting the prerequisites for installing and using DCM
|
||
is an optional requirement for customers (Systems B and C in this scenario).
|
||
Although the Add Verifier API creates the *SIGNATUREVERIFICATION certificate
|
||
store as part of the product install process, if needed, it creates it with
|
||
a default password. Customers need to use DCM to change the default password
|
||
to protect this certificate store from unauthorized access.</div>
|
||
</li>
|
||
<li>No one has previously configured or used DCM on any of the systems.</li>
|
||
<li>All systems have the highest level of Cryptographic Access Provider 128-bit
|
||
licensed program (5722-AC3) installed. </li>
|
||
<li>The default setting for the verify object signatures during restore (<a href="../rzakz/rzakzqvfyobjrst.htm ">QVFYOBJRST</a>)
|
||
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. </li>
|
||
<li>The network administrator for System A must have *ALLOBJ user profile
|
||
special authority to sign objects, or the user profile must be authorized
|
||
to the object signing application. </li>
|
||
<li>The system administrator or anyone else (including a program) who creates
|
||
a certificate store in DCM must have *SECADM and *ALLOBJ user profile special
|
||
authorities.</li>
|
||
<li>System administrators or others on all other systems must have *AUDIT
|
||
user profile special authority to verify object signatures.</li>
|
||
</ol>
|
||
</div>
|
||
<div class="section"><h4 class="sectionscenariobar">Configuration task steps</h4><p>To
|
||
sign objects as described in this scenario, refer to the scenario details
|
||
topic below for steps to complete each of the following tasks on System A
|
||
:</p>
|
||
<ol><li>Complete all prerequisite steps to install and configure all needed iSeries products</li>
|
||
<li>Use DCM to create a certificate request for obtaining an object signing
|
||
certificate from a well-known public Certificate Authority (CA) </li>
|
||
<li>Use DCM to create an object signing application definition</li>
|
||
<li>Use DCM to import the signed object signing certificate and assign it
|
||
to your object signing application definition</li>
|
||
<li>Use DCM to export your object signing certificate as a signature verification
|
||
certificate so that your customers can use it for verifying the signature
|
||
on your application objects </li>
|
||
<li>Update your application packaging program to use the Sign Object API to
|
||
sign your application</li>
|
||
<li>Create a pre-installation exit program that uses the Add Verifier API
|
||
as part of your application packaging processThis exit program allows you
|
||
to create the *SIGNATUREVERIFICATION certificate store and add the required
|
||
signature verification certificate to a customer's system during product installation.</li>
|
||
<li>Have customers use DCM to reset the default password for the *SIGNATUREVERIFICATION
|
||
certificate store on their system</li>
|
||
</ol>
|
||
</div>
|
||
</div>
|
||
<div>
|
||
<ul class="ullinks">
|
||
<li class="ulchildlink"><strong><a href="rzalzapisigndetails.htm">Scenario details: Use APIs to sign objects and verify object signatures</a></strong><br />
|
||
Complete the following task steps to use i5/OS APIs to sign objects as this scenario
|
||
describes.</li>
|
||
</ul>
|
||
|
||
<div class="familylinks">
|
||
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzalzscenariosoverview.htm" title="Use this information to review scenarios that illustrate some typical situations for using object signing and signature verification capabilities. Each scenario also provides the configuration tasks you must perform to implement the scenario as described.">Object signing scenarios</a></div>
|
||
</div>
|
||
<div class="relinfo"><strong>Related information</strong><br />
|
||
<div><a href="../rzahu/rzahurazhudigitalcertmngmnt.htm">Digital Certificate Manager (DCM)</a></div>
|
||
</div>
|
||
</div>
|
||
</body>
|
||
</html> |