346 lines
20 KiB
HTML
346 lines
20 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="Cryptography concepts" />
|
||
|
|
<meta name="abstract" content="This article provides a basic understanding of cryptographic function and an overview of the server's cryptographic services" />
|
||
|
|
<meta name="description" content="This article provides a basic understanding of cryptographic function and an overview of the server's cryptographic services" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzajcoverview.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../rzahu/rzahurazhudigitalcertmngmnt.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../apis/catcrypt.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzajcinitialstore.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../rzahu/rzahurzahu1nmcertstore.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../rzaha/rzahajce.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzajcco4758.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="concepts" />
|
||
|
|
<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>Cryptography concepts</title>
|
||
|
|
</head>
|
||
|
|
<body id="concepts"><a name="concepts"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Cryptography concepts</h1>
|
||
|
|
<div><p>This article provides a basic understanding of cryptographic function
|
||
|
|
and an overview of the server's cryptographic services</p>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Cryptography</h4><p>Cryptographic services help ensure
|
||
|
|
data privacy, maintain data integrity, authenticate communicating parties,
|
||
|
|
and prevent repudiation (when a party refutes having sent a message).</p>
|
||
|
|
<p>Basic
|
||
|
|
encryption allows you to store information or to communicate with other parties
|
||
|
|
while preventing non-involved parties from understanding the stored information
|
||
|
|
or understanding the communication. Encryption transforms understandable text
|
||
|
|
(plaintext) into an unintelligible piece of data (ciphertext). Decryption
|
||
|
|
restores the understandable text from the unintelligible data. Both functions
|
||
|
|
involve a mathematical formula (the algorithm) and secret data (the key).</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Cryptographic algorithms</h4><p>There are two types of
|
||
|
|
cryptographic algorithms:</p>
|
||
|
|
<ol><li>With a <dfn class="term">secret</dfn> or <dfn class="term">symmetric</dfn> key algorithm, the
|
||
|
|
key is a shared secret between two communicating parties. Encryption and decryption
|
||
|
|
both use the same key. The Data Encryption Standard (DES) and the Advanced
|
||
|
|
Encryption Standard (AES) are examples of symmetric key algorithms. <div class="p">There
|
||
|
|
are two types of symmetric key algorithms: <dl><dt class="dlterm">Block ciphers</dt>
|
||
|
|
<dd>In a block cipher, the actual encryption code works on a fixed-size block
|
||
|
|
of data. Normally, the user's interface to the encrypt/decrypt operation will
|
||
|
|
handle data longer than the block size by repeatedly calling the low-level
|
||
|
|
encryption function. If the length of data is not on a block size boundary,
|
||
|
|
it must be padded.</dd>
|
||
|
|
<dt class="dlterm">Stream ciphers</dt>
|
||
|
|
<dd>Stream ciphers do not work on a block basis, but convert 1 bit (or 1 byte)
|
||
|
|
of data at a time.</dd>
|
||
|
|
</dl>
|
||
|
|
</div>
|
||
|
|
</li>
|
||
|
|
<li>With a <dfn class="term">public key</dfn> (PKA) or <dfn class="term">asymmetric key</dfn> algorithm,
|
||
|
|
a pair of keys is used. One of the keys, the private key, is kept secret and
|
||
|
|
not shared with anyone. The other key, the public key, is not secret and can
|
||
|
|
be shared with anyone. When data is encrypted by one of the keys, it can only
|
||
|
|
be decrypted and recovered by using the other key. The two keys are mathematically
|
||
|
|
related, but it is virtually impossible to derive the private key from the
|
||
|
|
public key. The RSA algorithm is an example of a public key algorithm. <p>Public
|
||
|
|
key algorithms are slower than symmetric key algorithms. Applications typically
|
||
|
|
use public key algorithms to encrypt symmetric keys (for key distribution)
|
||
|
|
and to encrypt hashes (in digital signature generation).</p>
|
||
|
|
</li>
|
||
|
|
</ol>
|
||
|
|
<p>Together, the key and the cryptographic algorithm transform the data.
|
||
|
|
All of the supported algorithms are in the public domain. Therefore it is
|
||
|
|
the key that controls access to the data. You must safeguard the keys to protect
|
||
|
|
the data.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Cryptographic operations</h4><p>Different cryptographic <em>operations</em> may
|
||
|
|
use one or more <em>algorithms</em>. You choose the cryptographic operation
|
||
|
|
and algorithm(s) depending on your purpose. For example, for the purpose of
|
||
|
|
ensuring data integrity, you might want to use a MAC (message authentication
|
||
|
|
code) operation with the AES algorithm.</p>
|
||
|
|
<p>The system provides several
|
||
|
|
API sets that support cryptographic operations. See the <strong>System cryptography
|
||
|
|
overview</strong> information at the bottom of this topic for more information.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Data privacy</h4><p>Cryptographic operations for the purpose
|
||
|
|
of data privacy (confidentiality) prevent an unauthorized person from reading
|
||
|
|
a message. The following operations are included in data privacy:</p>
|
||
|
|
<dl><dt class="dlterm"><dfn class="term">Encrypt and Decrypt</dfn></dt>
|
||
|
|
<dd>The encrypt operation changes plaintext data into ciphertext through the
|
||
|
|
use of a cipher algorithm and key. To restore the plaintext data, the decrypt
|
||
|
|
operation must employ the same algorithm and key. <div class="p">Encryption and decryption
|
||
|
|
may be employed at any level of the operating system. There are three levels: <dl><dt class="dlterm">Field level encryption</dt>
|
||
|
|
<dd>With field level encryption, the user application explicitly requests
|
||
|
|
cryptographic services. The user application completely controls key generation,
|
||
|
|
selection, distribution, and what data to encrypt.</dd>
|
||
|
|
<dt class="dlterm">Session level encryption</dt>
|
||
|
|
<dd>With encryption at the session layer, the system requests cryptographic
|
||
|
|
services instead of an application. The application may or may not be aware
|
||
|
|
that encryption is happening.</dd>
|
||
|
|
<dt class="dlterm">Link level encryption</dt>
|
||
|
|
<dd>Link level encryption is performed at the lowest level of the protocol
|
||
|
|
stack, usually by specialized hardware.</dd>
|
||
|
|
</dl>
|
||
|
|
The Cryptographic Coprocessors and the 2058 Cryptographic Accelerator
|
||
|
|
may be used for both field level encryption and Secure Sockets Layer (SSL)
|
||
|
|
session establishment encryption. While VPN is supported in i5/OS™, it does
|
||
|
|
not use either coprocessor or the accelerator. Furthermore, the system does
|
||
|
|
not support SNA session level encryption at all.</div>
|
||
|
|
</dd>
|
||
|
|
<dt class="dlterm"><dfn class="term">Translate</dfn></dt>
|
||
|
|
<dd>The translate operation decrypts data from encryption under one key and
|
||
|
|
encrypts the data under another key. This is done in one step to avoid exposing
|
||
|
|
the plaintext data within the application program.</dd>
|
||
|
|
</dl>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Data integrity, authenticity, and non-repudiation</h4><p>Encrypted
|
||
|
|
data does not mean the data can not be manipulated (e.g. repeated, deleted,
|
||
|
|
or even altered). To rely on data, you need to know that it comes from an
|
||
|
|
authorized source and is unchanged. Additional cryptographic operations are
|
||
|
|
required for these purposes.</p>
|
||
|
|
<dl><dt class="dlterm"><dfn class="term">Hash (Message Digest)</dfn></dt>
|
||
|
|
<dd>A cryptographic hash operation produces a fixed-length output string (often
|
||
|
|
called a digest) from a variable-length input string. For all practical purposes,
|
||
|
|
the following statements are true of a good hash function: <ul><li>Collision resistant: If any portion of the data is modified, a different
|
||
|
|
hash will be generated.</li>
|
||
|
|
<li>One-way: The function is irreversible. That is, given a digest, it is
|
||
|
|
not possible to find the data that produces it.</li>
|
||
|
|
</ul>
|
||
|
|
These properties make hash operations useful for authentication purposes.
|
||
|
|
For example, you can keep a copy of a digest for the purpose of comparing
|
||
|
|
it with a newly generated digest at a later date. If the digests are identical,
|
||
|
|
the data has not been altered.</dd>
|
||
|
|
<dt class="dlterm"><dfn class="term">MAC (Message Authentication Code)</dfn></dt>
|
||
|
|
<dd>A MAC operation uses a secret key and cipher algorithm to produce a value
|
||
|
|
(the MAC) which later can be used to ensure the data has not been modified.
|
||
|
|
Typically, a MAC is appended to the end of a transmitted message. The receiver
|
||
|
|
of the message uses the same MAC key, and algorithm as the sender to reproduce
|
||
|
|
the MAC. If the receiver's MAC matches the MAC sent with the message, the
|
||
|
|
data has not been altered. <p>The MAC operation helps authenticate messages,
|
||
|
|
but does not prevent unauthorized reading because the transmitted data remains
|
||
|
|
as plaintext. You must use the MAC operation and then encrypt the entire message
|
||
|
|
to ensure both data privacy and integrity.</p>
|
||
|
|
</dd>
|
||
|
|
<dt class="dlterm"><dfn class="term">HMAC (Hash MAC)</dfn></dt>
|
||
|
|
<dd>An HMAC operation uses a cryptographic hash function and a secret shared
|
||
|
|
key to produce an authentication value. It is used in the same way a MAC is
|
||
|
|
used.</dd>
|
||
|
|
<dt class="dlterm"><dfn class="term">Sign/Verify</dfn></dt>
|
||
|
|
<dd>A sign operation produces an authentication value called a digital signature.
|
||
|
|
A sign operation works as follows: <ol><li>The data to be signed is hashed, to produce a digest.</li>
|
||
|
|
<li>The digest is encrypted using a PKA algorithm and a private key, to produce
|
||
|
|
the signature.</li>
|
||
|
|
</ol>
|
||
|
|
The verify operation works as follows: <ol><li>The signature is decrypted using the sender's PKA public key, to produce
|
||
|
|
digest 1. </li>
|
||
|
|
<li>The data that was signed is hashed, to produce digest 2.</li>
|
||
|
|
<li>If the two digests are equal, the signature is valid.</li>
|
||
|
|
</ol>
|
||
|
|
Theoretically, this also verifies the sender because only the sender
|
||
|
|
should posses the private key. However, how can the receiver verify that the
|
||
|
|
public key actually belongs to the sender? Certificates are used to help solve
|
||
|
|
this problem.</dd>
|
||
|
|
</dl>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Key and random number generation</h4><p>Many security-related
|
||
|
|
functions rely on random number generation, for example, salting a password
|
||
|
|
or generating an initialization vector. An important use of random numbers
|
||
|
|
is in the generation of cryptographic key material. Key generation has been
|
||
|
|
described as the most sensitive of all computer security functions. If the
|
||
|
|
random numbers are not cryptographically strong, the function will be subject
|
||
|
|
to attack.</p>
|
||
|
|
<p>The i5/OS operating system contains a pseudorandom number
|
||
|
|
generator (PRNG). The PRNG is used by many system functions and is available
|
||
|
|
for application use through the <cite>Cryptographic Services</cite> API set.</p>
|
||
|
|
<p>The
|
||
|
|
PRNG is composed of two parts: pseudorandom number generation and seed management.
|
||
|
|
Pseudorandom number generation is performed using the FIPS 186-1 algorithm.
|
||
|
|
Cryptographically strong pseudorandom numbers rely on good seed. The FIPS
|
||
|
|
186-1 key and seed values are obtained from a system seed digest. The system
|
||
|
|
automatically generates seed using data collected from system information
|
||
|
|
or by using the random number generator function on a cryptographic coprocessor
|
||
|
|
if one is available. System-generated seed can never be truly unpredictable.
|
||
|
|
If a cryptographic coprocessor is not available, you should add your own random
|
||
|
|
seed to the system seed digest. This should be done as soon as possible any
|
||
|
|
time the Licensed Internal Code is installed.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Key management</h4><p>Key management is the secure handling
|
||
|
|
and storage of cryptographic keys. This includes key storage and retrieval,
|
||
|
|
key encryption and conversions, and key distribution.</p>
|
||
|
|
<p><strong>Key storage</strong></p>
|
||
|
|
<p>Key
|
||
|
|
storage on the system includes the following:</p>
|
||
|
|
<ul><li>Cryptographic Services key store</li>
|
||
|
|
<li>Digital certificate manager certificate store </li>
|
||
|
|
<li>CCA key store (used with the Cryptographic Coprocessors) </li>
|
||
|
|
<li>JCE key store</li>
|
||
|
|
</ul>
|
||
|
|
<p>In addition, keys can also be stored on the Cryptographic Coprocessors
|
||
|
|
themselves.</p>
|
||
|
|
<p><strong>Key Encryption and Conversions</strong></p>
|
||
|
|
<div class="p">Keys must be
|
||
|
|
encrypted prior to sending or storing them outside the secured system environment.
|
||
|
|
In addition, keys should be handled in encrypted form within the system as
|
||
|
|
much as possible to reduce the risk of exposure. The management of encrypted
|
||
|
|
keys is often done via a hierarchical key system.<ul><li>At the top is a master key (or keys). The master key is the only clear
|
||
|
|
key value and must be stored in a secure fashion. </li>
|
||
|
|
<li>Key-encrypting keys (KEKs) are used to encrypt other keys. Typically,
|
||
|
|
a KEK is used to encrypt a stored key, or a key that is sent to another system.
|
||
|
|
KEKs are normally encrypted under a master key. </li>
|
||
|
|
<li>Data keys are keys used directly on user data (such as to encrypt or MAC).
|
||
|
|
A data key may be encrypted under a KEK or under a master key.</li>
|
||
|
|
</ul>
|
||
|
|
Various uses of a key will require the key to be in different forms.
|
||
|
|
For example, keys received from other sources will normally be converted to
|
||
|
|
an internal format. Likewise, keys sent out of the system are converted to
|
||
|
|
a standard external format before sending. Certain key forms are standard,
|
||
|
|
such as an ASN.1 BER-encoded form, and others are peculiar to a cryptographic
|
||
|
|
service provider, such as the Cryptographic Coprocessors.</div>
|
||
|
|
<p><strong>Key Distribution</strong></p>
|
||
|
|
<div class="p">Typically,
|
||
|
|
data encryption is performed using symmetric key algorithms. The symmetric
|
||
|
|
keys are distributed using asymmetric key algorithms. Consider these examples:<ul><li><strong>RSA</strong> - An RSA public key is used to encrypt a symmetric key which
|
||
|
|
is then distributed. The corresponding private key is used to decrypt it.</li>
|
||
|
|
<li><strong>Diffie-Hellman</strong> - The communicating parties generate and exchange
|
||
|
|
D-H parameters which are then used to generate key pairs. The public keys
|
||
|
|
are exchanged and each party is then able to compute the symmetric key independently.</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">System cryptography overview</h4><dl><dt class="dlterm">Cryptographic Service Providers</dt>
|
||
|
|
<dd>A cryptographic service provider (CSP) is the software or hardware that
|
||
|
|
implements a set of cryptographic operations. The system supports several
|
||
|
|
CSPs:<ul><li>4758 Cryptographic Coprocessor </li>
|
||
|
|
<li>4764 Cryptographic Coprocessor </li>
|
||
|
|
<li>2058 Cryptographic Accelerator </li>
|
||
|
|
<li>i5/OS LIC
|
||
|
|
</li>
|
||
|
|
<li>Java™ Cryptography
|
||
|
|
Extensions</li>
|
||
|
|
</ul>
|
||
|
|
</dd>
|
||
|
|
<dt class="dlterm">Cryptographic API sets</dt>
|
||
|
|
<dd>User applications can utilize cryptographic services indirectly via i5/OS functions
|
||
|
|
such as SSL, VPN IPSec, and LDAP. User applications can also access cryptographic
|
||
|
|
services directly via the following APIs:<ul><li>CCA<p>The Common Cryptographic Architecture (CCA) API set is provided
|
||
|
|
for running cryptographic operations on a Cryptographic Coprocessor. </p>
|
||
|
|
</li>
|
||
|
|
<li>i5/OS Cryptographic
|
||
|
|
Services<p>The i5/OS Cryptographic
|
||
|
|
Services API set is provided for running cryptographic operations within the
|
||
|
|
Licensed Internal Code or optionally on the 2058 Cryptographic Accelerator. </p>
|
||
|
|
</li>
|
||
|
|
<li>Java Cryptography<p>Java Cryptography
|
||
|
|
Extension (JCE) is a standard extension to the Java Software Development Kit.</p>
|
||
|
|
</li>
|
||
|
|
<li>Network Authentication Service<p>GSS (Generic Security Services), Java GSS,
|
||
|
|
and Kerberos APIs are part of the Network Authentication Service which provides
|
||
|
|
authentication and security services. These services include session level
|
||
|
|
encryption capability.</p>
|
||
|
|
</li>
|
||
|
|
<li>i5/OS SSL
|
||
|
|
and JSSE<p>i5/OS SSL
|
||
|
|
and JSSE support the Secure Sockets Layer Protocol. APIs provide session level
|
||
|
|
encryption capability. </p>
|
||
|
|
</li>
|
||
|
|
<li>SQL<p>Structured Query Language is used to access or modify information
|
||
|
|
in a database. SQL supports encryption/decryption of database fields.</p>
|
||
|
|
</li>
|
||
|
|
</ul>
|
||
|
|
</dd>
|
||
|
|
</dl>
|
||
|
|
This table indicates what CSPs are used under each user interface.
|
||
|
|
<div class="tablenoborder"><a name="concepts__cps"><!-- --></a><table cellpadding="4" cellspacing="0" summary="" id="concepts__cps" frame="border" border="1" rules="all"><caption>Table 1. CSPs used under each user interface</caption><thead align="left"><tr valign="bottom"><th align="center" valign="bottom" id="d0e323">CSP APIs</th>
|
||
|
|
<th align="center" valign="bottom" id="d0e325">i5/OS LIC</th>
|
||
|
|
<th align="center" valign="bottom" id="d0e329">JCE</th>
|
||
|
|
<th align="center" valign="bottom" id="d0e331">4764 and 4758</th>
|
||
|
|
<th align="center" valign="bottom" id="d0e333">2058</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
<tbody><tr><td valign="top" headers="d0e323 "><strong>CCA</strong></td>
|
||
|
|
<td align="center" valign="top" headers="d0e325 "> </td>
|
||
|
|
<td align="center" valign="top" headers="d0e329 "> </td>
|
||
|
|
<td align="center" valign="top" headers="d0e331 ">X</td>
|
||
|
|
<td align="center" valign="top" headers="d0e333 "> </td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e323 "><strong>i5/OS Cryptographic Services</strong></td>
|
||
|
|
<td align="center" valign="top" headers="d0e325 ">X</td>
|
||
|
|
<td align="center" valign="top" headers="d0e329 "> </td>
|
||
|
|
<td align="center" valign="top" headers="d0e331 "> </td>
|
||
|
|
<td align="center" valign="top" headers="d0e333 ">X</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e323 "><strong>Java Cryptography</strong></td>
|
||
|
|
<td align="center" valign="top" headers="d0e325 "> </td>
|
||
|
|
<td align="center" valign="top" headers="d0e329 ">X</td>
|
||
|
|
<td align="center" valign="top" headers="d0e331 "> </td>
|
||
|
|
<td align="center" valign="top" headers="d0e333 "> </td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e323 "><strong>Network Authentication Service</strong></td>
|
||
|
|
<td align="center" valign="top" headers="d0e325 ">X</td>
|
||
|
|
<td align="center" valign="top" headers="d0e329 ">X</td>
|
||
|
|
<td align="center" valign="top" headers="d0e331 "> </td>
|
||
|
|
<td align="center" valign="top" headers="d0e333 "> </td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e323 "><strong>i5/OS SSL and JSSE</strong></td>
|
||
|
|
<td align="center" valign="top" headers="d0e325 ">X</td>
|
||
|
|
<td align="center" valign="top" headers="d0e329 ">X</td>
|
||
|
|
<td align="center" valign="top" headers="d0e331 ">X</td>
|
||
|
|
<td align="center" valign="top" headers="d0e333 ">X</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e323 "><strong>SQL</strong></td>
|
||
|
|
<td align="center" valign="top" headers="d0e325 ">X</td>
|
||
|
|
<td align="center" valign="top" headers="d0e329 "> </td>
|
||
|
|
<td align="center" valign="top" headers="d0e331 "> </td>
|
||
|
|
<td align="center" valign="top" headers="d0e333 "> </td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzajcoverview.htm" title="IBM offers cryptography solutions for customers who require a high level of security.">Cryptography</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relconcepts"><strong>Related concepts</strong><br />
|
||
|
|
<div><a href="rzajcinitialstore.htm" title="A key store file is a database file that stores operational keys, i.e. keys encrypted under the master key. Read this information if you plan to keep records of your DES and PKA keys.">Initialize a key store file</a></div>
|
||
|
|
<div><a href="rzajcco4758.htm" title="IBM offers two Cryptographic Coprocessors, which are available on a variety of server models.">4764 and 4758 Cryptographic Coprocessors</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relinfo"><strong>Related information</strong><br />
|
||
|
|
<div><a href="../rzahu/rzahurazhudigitalcertmngmnt.htm">Digital Certificate Manager</a></div>
|
||
|
|
<div><a href="../apis/catcrypt.htm">Cryptographic Services API set</a></div>
|
||
|
|
<div><a href="../rzahu/rzahurzahu1nmcertstore.htm">Certificate Stores</a></div>
|
||
|
|
<div><a href="../rzaha/rzahajce.htm">Java Cryptography Extension</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|