 |
» |
|
|
|
You must use security certificates if you are using digital
signatures (RSA signatures) for IKE authentication. HP-UX IPSec
uses the certificates to obtain cryptography keys for digital signatures
and to verify the digital signatures. If you are not using digital
signatures for IKE authentication, you can skip this chapter. Security
Certificates and Public Key Cryptography | |
Security certificates are used for public key cryptography,
also referred to as asymmetric key cryptography.
Public key cryptography uses a pair of related, but different keys.
One key, the private key, is associated with
a specific system or entity and is kept secret; the other key is
the public key and can be distributed freely.
The public and private keys are mathematically related so that data encrypted
with the public key can only be decrypted with the private key. With asymmetric key cryptography, the public key can be freely distributed
over a non-secure communication channel. However, there must be some assurance that a particular public
key is the actual public key of the entity with which you want to
communicate. This is usually done by distributing public keys in
the form of public-key certificates, commonly
referred to as security certificates. A security certificate
associates (or binds) a public key with a particular person, device,
or other entity. The certificate is issued by an entity, in whom
users have put their trust, called a certificate authority (CA)
that guarantees or confirms the identity of the holder (person,
device, or other entity) of the corresponding private key. The CA
digitally signs the certificate with the CA’s private key,
so the certificate can be verified using the CA’s public
key. The format for security certificates (public-key certificates)
is defined by the International Organization for Standardization
(ISO) X.509 standard, Version 3. Certificates are issued with a specific lifetime, defined
by a start date/time and an expiration date/time. However, situations
can arise, such as a compromised key value, that necessitate the
revocation of the certificate. In this case, the certificate authority
can revoke the certificate. This is accomplished by including the
certificate’s serial number on a Certificate
Revocation List (CRL) updated and published on a regular
basis by the CA and made available to certificate users. Digital
Signatures | |
With digital signatures, the sender uses its private key to
create a digital signature value, and sends the digital signature
with the data. The recipient uses the sender’s public key
and the data to verify the digital signature. There are different methods to generate and verify the digital
signature. In one method, the sender generates a one-way hash value
and encrypts it with its private key to form the digital signature.
The recipient uses the sender’s public key to decrypt the
digital signature and extract the hash value; it then generates
its own hash value and compares the hash values. In another method,
the sender uses its private key and the data as input to a keyed
secure hash algorithm that outputs the digital signature. The receiver
uses the data, the sender's public key and the digital signature
as input to a verification algorithm that verifies the digital signature. One difference between a digital signature and a symmetric-key
hash value is that only the holder of the private key can generate
the digital signature, while either holder of a symmetric key can
generate a symmetric-key hash value. Since only the private key
holder can generate the digital signature, a digital signature also
provides non-repudiation which makes it difficult for the sender
to deny sending the message. IKE Public
Key Distribution | |
IKE primary authentication with digital signatures requires
that the IKE initiator and responder obtain the other entity’s
public key, using security certificates. This may be done as part
of the IKE negotiation - the two entities may exchange certificates
at the beginning of the IKE negotiation. Alternatively, this may
be done independent of the IKE negotiation and each entity may get
the other entity’s certificate from a CA or certificate
directory service. The method used varies according to the CA used
and the services provided by the CA. Requirements | |
To use security certificates, your topology must meet the
following requirements: The
systems using certificates must use IPv4 addresses for IPSec. HP-UX
IPSec does not support IKE digital signature authentication with
IPv6 addresses. The security certificates must be administered using
one of the following PKI products: Baltimore UniCERT 3.5 package
All security certificates
must be administered using a PKI product from the same vendor. When
you configure HP-UX IPSec, you must configure only one PKI vendor
for all security certificate operations.
|
Printable version
