Signed Packages and Patches (System Administration Guide: Basic Administration)

System Administration Guide: Basic Administration

Signed Packages and Patches

Packages can include a digital signature. A package with a valid digital signature ensures that the package has not been modified since the signature was applied to the package. Using signed packages is a secure method of downloading or adding packages because the digital signature can be verified before the package is added to your system.

The same holds true for signed patches. A patch with a valid digital signature ensures that the patch has not been modified since the signature was applied to the patch. Using signed patches is a secure method of downloading or adding patches because the digital signature can be verified before the patch is added to your system.

For more information about adding signed patches to your system, see Adding Signed Patches With patchadd Command (Task Map).

For information about creating signed packages, see Application Packaging Developer's Guide.

A signed package is identical to an unsigned package, except for the digital signature. The package can be installed, queried, or removed with existing Solaris packaging tools. A signed package is also binary-compatible with an unsigned package.

Before you can add a package or patch with a digital signature to your system, you must set up a package keystore with trusted certificates. These certificates are used to identify that the digital signature on the package or patch is valid.

The following table describes the general terms associated with signed packages and patches.

Term	Definition
Keystore	A repository of certificates and keys that is queried when needed. Java keystore – A repository of certificates that is installed by default with the Solaris release. The Java keystore is usually stored in the `/usr/j2se/jre/lib/security` directory. Package keystore – A repository of certificates that you import when adding signed packages and patches to your system. The package keystore is stored in the `/var/sadm/security` directory by default.
Trusted certificate	A certificate that holds a public key that belongs to another entity. The trusted certificate is named as such because the keystore owner trusts that the public key in the certificate indeed belongs to the identity identified by the subject or owner of the certificate. The issuer of the certificate vouches for this trust by signing the certificate. Trusted certificates are used when verifying signatures, and when initiating a connection to a secure (SSL) server.
User key	Holds sensitive cryptographic key information. This information is stored in a protected format to prevent unauthorized access. A user key consists of both the user's private key and the public key certificate that corresponds to the private key.

Term

Definition

Keystore

A repository of certificates and keys that is queried when needed.

Java keystore – A repository of certificates that is installed by default with the Solaris release.

The Java keystore is usually stored in the /usr/j2se/jre/lib/security directory.
Package keystore – A repository of certificates that you import when adding signed packages and patches to your system.

The package keystore is stored in the /var/sadm/security directory by default.

Trusted certificate

A certificate that holds a public key that belongs to another entity. The trusted certificate is named as such because the keystore owner trusts that the public key in the certificate indeed belongs to the identity identified by the subject or owner of the certificate. The issuer of the certificate vouches for this trust by signing the certificate.

Trusted certificates are used when verifying signatures, and when initiating a connection to a secure (SSL) server.

User key

Holds sensitive cryptographic key information. This information is stored in a protected format to prevent unauthorized access. A user key consists of both the user's private key and the public key certificate that corresponds to the private key.

The process of adding a signed package or patch to your system involves three basic steps:

Adding the certificates to your system's package keystore with the pkgadm command
(Optional) Listing the certificates with the pkgadm command
Adding the package with the pkgadd command or adding the patch with the patchadd command

For step-by-step instructions on adding signed packages to your system, see Adding and Removing Signed Packages (Task Map). For step-by-step instructions on adding signed patches to your system, see Adding Signed Patches With patchadd Command (Task Map).

Using Sun's Certificates to Verify Signed Packages and Patches

A stream-formatted SVR4–signed package or patch contains an embedded PEM-encoded PKCS7 signature. This signature contains at a minimum the encrypted digest of the package or patch, along with the signer's X.509 public key certificate. The package or patch can also contain a certificate chain that is used to form a chain of trust from the signer's certificate to a locally stored trusted certificate.

The PEM-encoded PKCS7 signature is used to verify the following:

The package came from the entity that signed it.
The entity indeed signed it.
The package hasn't been modified since the entity signed it.
The entity that signed it is a trusted entity.

The following table describes the encryption terminology associated with signed packages and patches.

Term	Definition
ASN.1	Abstract Syntax Notation 1 (ASN.1) is a way to express a set of abstract objects. For example, ASN.1 defines a public key certificate, all of the objects that make up the certificate, and the order in which the objects are collected. However, ASN.1 does not specify how the objects are serialized for storage or transmission.
base64	base64 is a method of encoding arbitrary binary data as ASCII text.
DER	Distinguished Encoding Rules (DER) is a binary representation of an ASN.1 object. DER defines how an ASN.1 object is serialized for storage or transmission in computing environments.
PEM	The Privacy Enhanced Message (PEM) is a way to encode a file (in DER or other binary format) using base64 encoding and some optional headers. Initially used for encoding MIME-type email messages. PEM is also used extensively for encoding certificates and private keys into a file that exists on a file system or in an email message.
PKCS7	The Public Key Cryptography Standard #7 (PKCS7) describes a general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes.
X.509	The International Telecommunication Union-Telcom (ITU-T) recommendation X.509 specifies the widely adopted X.509 public key certificate syntax. This recommendation defines a framework for the provision of authentication services. X.509 describes two levels of authentication: Simple authentication – using a password as a verification of claimed identity. Strong authentication – involving credentials formed using cryptographic techniques. While simple authentication offers some limited protection against unauthorized access, use only strong authentication as the basis for providing secure services.

Digital certificates, issued and authenticated by Sun Microsystems, are used to verify that the downloaded package or patch with the digital signature has not been compromised. These certificates are imported into your system's keystore.

All Sun certificates are issued by Baltimore Technologies, which recently bought GTE CyberTrust.

Access to a keystore is protected by a special password that you specify when you import the Sun certificates into your system's keystore.

If you use the pkgadm listcert command, you can view information about your locally stored certificates in the package keystore. For example:

# pkgadm listcert -P pass:store-pass
    Keystore Alias: GTE CyberTrust Root
       Common Name: GTE CyberTrust Root
  Certificate Type: Trusted Certificate
Issuer Common Name: GTE CyberTrust Root
    Validity Dates: <Feb 23 23:01:00 1996 GMT> - <Feb 23 23:59:00 2006 GMT>
   MD5 Fingerprint: C4:D7:F0:B2:A3:C5:7D:61:67:F0:04:CD:43:D3:BA:58
  SHA1 Fingerprint: 90:DE:DE:9E:4C:4E:9F:6F:D8:86:17:57:9D:D3:91:BC:65:A6...

The following table describes the output of the pkgadm listcert command.

Field	Description
Keystore Alias	When you retrieve certificates for printing, signing, or removing, this name must be used to reference the certificate.
Common Name	The common name of the certificate. For trusted certificates, this name is the same as the keystore alias.
Certificate Type	Can be one of two types: Trusted Certificate - A certificate that can be used as a trust anchor when verifying other certificates. No private key is associated with a trusted certificate. Signing Certificate - A certificate that can be used when signing a package or patch. A private key is associated with a signing certificate.
Issuer Common Name	The name of the entity that issued, and therefore signed, this certificate. For trusted certificate authority (CA) certificates, the issuer common name and common name are the same.
Validity Dates	A date range that identifies when the certificate is valid.
MD5 Fingerprint	An MD5 digest of the certificate. This digest can be used to verify that the certificate has not been altered during transmission from the source of the certificate.
SHA1 Fingerprint	Similar to an MD5 Fingerprint, except that it is calculated using a different algorithm.

Each certificate is authenticated by comparing its MD5 and SHA1 hashes, also called fingerprints, against the known correct fingerprints published by the issuer.

SunSolve Online's Trusted Certificates

SunSolve Online uses the following certificates to verify the digital signatures on signed patches with the previous Solaris patch management tools (smpatch command), including PatchPro:

Top-level certificate, called the Root Certificate Authority (CA)
A subordinate CA, which is the Sun Microsystems Inc., CA Class B certificate.
An additional certificate issued by Sun Enterprise^TM Services, called the patch management certificate

A certificate authority certifies the relationship between public keys that are used to decrypt the digital signature with the patch and the owner of the public keys.

The Sun Root CA, Sun Class B CA, and the patch signing certificate are included with the Solaris patch management tools, including PatchPro. These three certificates provide a certificate chain of trust in the patch verification process whereby the Sun Root CA trusts the Class B CA, and the Class B CA trusts the patch management certificate. And, ultimately, the GTE CyberTrust CA trusts the Sun Root CA.

Importing Sun's Trusted Certificates

You can obtain Sun's trusted certificates for adding signed packages and patches in the following ways:

Java keystore – Import Sun's Root CA certificate that is included by default in the Java keystore when you install the Solaris release.
Sun's Public Key Infrastructure (PKI) site – If you do not have a Java keystore available on your system, you can import the certificates from this site.

https://ra.sun.com:11005/
PatchPro's keystore – If you have installed PatchPro for adding signed patches with the smpatch command, you can import Sun's Root CA certificate from the Java keystore.

Setting Up a Package Keystore

In previous Solaris releases, you could download the patch management tools and create a Java keystore, for use by PatchPro, by importing the certificates with the keytool command.

If your system already has a populated Java keystore, you can now export the Sun Microsystems root CA certificate from the Java keystore with the keytool command. Then, use the pkgadm command to import this certificate into the package keystore.

After the Root CA certificate is imported into the package keystore, you can use the pkgadd and patchadd commands to add signed packages and patches to your system.

Note –

The Sun Microsystems root-level certificates are only required when adding Sun-signed patches and packages.

For step-by-step instructions on importing certificates into the package keystore, see How to Import a Trusted Certificate into the Package Keystore (pkgadm addcert).

For complete instructions on adding signed packages with the pkgadd command, see Adding and Removing Signed Packages (Task Map).