This chapter provides a general overview of the eXchange SME/KS feature, as it operates with AS2 PM, including basic information, general operation, and setup.
This chapter covers the following topics:
The SME/KS feature enables the protected transmission of messages over public domains by providing message encryption, decryption, digital signing, and signature verification. SME/KS uses Public Key Infrastructure (PKI) technology to ensure the confidentiality of message exchanges by digitally signing and encrypting messages when they are sent, and decrypting and authenticating messages when they are received.
SME/KS encrypts and decrypts messages using the Secure Multipurpose Internet Mail Extensions (S/MIME0 messaging format. For more information on the S/MIME format, see About S/MIME Cryptography
Compression reduces the physical size of string and binary file formats using Java-based mathematical equations that scan and index repetitive patterns. Most files contain repetitive patterns. For example, in a color image, the number and placement of repetitive colors are indexed. The information is indexed, which reduces the size of the file. When the file is decompressed, the index regenerates the patterns and reinflates the file to its original size.
SME/KS enables eGate to process events via S/MIME. SME/KS is interoperable with any other client application that supports S/MIME.
A SME/KS implementation adds the following security attributes to message transactions:
Encryption and decryption
Data compression and decompression
Transaction privacy
Message authentication
Sender authentication
Message nonrepudiation
A security certificate (generally called a certificate) is an electronic document that establishes credentials for performing transactions over the Internet. In addition to a certificate, you must also have both private and public keys. A private key is an encryption/decryption key known only to you. A public key is a value provided by a certificate authority (CA). When a public key is combined with a private key derived from the public key, it can be used to encrypt messages and digital signatures. For more information on acquiring a certificate, see Certificate Formats.
You must acquire your security components from a CA. A CA is a company that issues and manages security credentials and public keys for message encryption and decryption. For example, VeriSignTM is a leading CA. To acquire your certificate and keys, you order them from your designated CA.
Multipurpose Internet Mail Extension (MIME) is a specification for formatting non-ASCII message that enables the transfer and acceptance of files over the Internet. MIME-compliant messages can contain multiple data types, for example:
Messages of unlimited length
Binary files
Character sets other than US-ASCII
Multimedia: image, audio, and video objects
Multiple, nested objects in a single message
MIME is a two-part message format with a header and a body. The header metadata provides the information for message transmission and interpretation. The body contains the bulk data. MIME messages can remain in binary format when transmitted over a protocol such as HTTP or FTP.
However, if a MIME message is sent by SMTP or another text-only protocol, is must be base64 encoded (base64 encoding is a text-based representation of binary data). For more information, see the Internet Engineering Task Force Text Messages specification (RFC 822) and the MIME Message Body Format (RFC 2045), at http://www.ietf.org.
The S/MIME Version 3 specification (RFC 2623) is also found at the same URL.
The S/MIME format is the IETF RFC 2311 specification for encrypting and signing message data. This format creates one-way hash algorithms that ensure data integrity by verifying that no modifications are made to a message while in transit. The sender’s identity is validated using a digital signature. S/MIME is the encryption-supported version of the MIME protocol, based on Public Key Cryptography Standards (PKCS).
PKCS standards specify how RSA Data Security public-key cryptographic algorithms are used to implement enveloped encryption and digital signatures. The RSA public-key system uses two related keys to perform the mathematical algorithms that encrypt and decrypt data: a public key, which may be made available to any prospective correspondent, and a private key known only to the key’s owner, for example:
A public key can be published openly, allowing anyone to send secure messages that can only be decrypted by the owner of the private key. Public keys are stored as certificates that comply with the X.509 standard. In addition to the public key, a certificate also contains information about the key owner’s identity, the key’s validity, and the CA that issued the certificate.
Private key encryption can be decrypted with a corresponding public key. This encryption method creates a digital signature, which guarantees that the signed message is authentic and came from the originator.
Digital signatures provide data integrity, authentication and nonrepudiation of electronic documents. Digital signature verification ensures that:
The document received is identical to the document sent.
There is authentication of the identity of the sender.
No subsequent repudiation of the document by the originator occurs.
This section describes how v encrypts and decrypts message data, verifies digital signatures, and compresses and decompresses message files.
In key pair encryption, the sender's message is encrypted with the public key and signed by the sender. The signature is then encrypted with the sender’s private key. Upon receipt, the message is decrypted with recipient's private key. In the Keystore, the sender’s public certificate is used to validate the authenticity of the public key. The public certificate contains the sender’s name, institution, and email address, and is signed by a trusted CA. The certificate alias identifies the certificate in the Keystore. The recipient's private key alias and password is used to access the private key from the Keystore and decrypt the message. See Figure 3–1.
Input parameters labeled with an asterisk (*) show the default values.
Signature verification begins when a subscriber publishes a certificate to a CA. Published certificates contain the subscriber’s identity and public key, and are digitally signed by the CA, which safeguards access to the subscriber’s private key. When a subscriber signs and sends a message, SME/KS converts the message to S/MIME format. The message now contains the digital footprint of the subscribers private key. When the message is received, the public key validates the digital signature created by the private key. See Figure 3–2.
Input parameters labeled with an asterisk (*) show the default values.
The compression process converts byte type files into PKCS#7 format using the zlib compression library. See Figure 3–3. For more information on the zlib compression library, visit the gzip product home page at http://www.gzip.org.
Digital signatures are normally attached to the message. However, digital signatures can also be detached. A detached signature may be stored and transmitted separately from the message it signs. In an S/MIME message with a detached signature, the signature is calculated over on the entire payload data, in addition to its MIME headers. The default Content-Type for this MIME part is text plain. If signing a Content-Type other than text plain, you must generate a Content-Type header line for the payload. All other MIME headers and boundaries, including those for the detached signature part, are produced by SME/KS.
The characteristics of attached digital signatures in PKCS#7 and S/MIME formats are:
The characteristics of detached digital signatures in PKCS#7 and S/MIME formats are as follows:
PKCS#7: Includes the signature and certificate without the signed data.
RNIF1.1: Uses PKCS#7 and a detached format.
S/MIME2: May include a MIME multipart message consisting of the original data in one segment and a binary format signature or a base64-encoded signature in a second segment.
AS2 requires that private keys be in PKCS#12 format. If a key has been generated through a browser-based process and appears among your personal certificates in Microsoft Internet Explorer, and you want to use it with AS2, you must export it to a PKCS#12 file.
Remember the password you specify to encrypt the exported file. You will need it during theAS2 PM configuration process to allow decryption and use of the key.
A public key certificate is an electronic message issued by a CA that matches the value of the public key to the identity of the person, device, or service that holds the corresponding private key.AS2 only accepts certificates in PKCS#7 format and DER-encoded binary X.509.
After you pay a fee, your certificate is transmitted to you as an email or file attachment. Then, you copy the contents from the CA certificate into a text file to create your own certificate file.
Open the certificate email or file.
Select the file contents between the header and trailer text.
Make sure you exclude the header and trailer.
Copy the contents of the certificate to the buffer.
Create a new text file.
Paste the certificate file contents into the empty file.
Save the file as machine name.cert.
Where:
machine name is the name of the computer that is hosting the SME/KS files.
The .cert extension is arbitrary. Certificate and key files can have any extension, but the extension you use should imply the contents of the file.
Microsoft Internet Explorer provides a Certificate wizard tool to convert between formats. For more information, see To Convert Certificates With Internet Explorer.
Double-click the certificate file.
The Certificate Information window appears. See Figure 3–4.
Click the Details tab.
See Figure 3–5.
Click Copy to File.
The Certificate Export wizard appears. See Figure 3–6.
Click Next.
The Export File Format window appears. See Figure 3–7
Click Next.
The File to Export window appears. See Figure 3–8.
Browse to the certificate file name.
Select the certificate file and click Next.
The certificate details are displayed in the window. See Figure 3–9.
Click Finish to exit the wizard.
From the Tools menu, click Internet Options.
Click the Content tab and then click Certificates.
The Certificates dialog box appears. See Figure 3–10.
Click Import.
The Certificate Import wizard appears. See Figure 3–11.
Click Next.
The File to Import window appears. See Figure 3–12.
Browse to the certificate file you want to open.
See Figure 3–13.
Click Next.
The Certificate Store window appears. See Figure 3–14.
Browse to the location where you want to store the certificate and click Next.
Details of the completed certificate import appear. See Figure 3–15.
Click Finish to exit the wizard.
A Keystore is a special file type that holds the keys and certificates. A Keystore is a repository for sensitive cryptographic key information for self-authentication. Key entries are private keys accompanied by the certificate chain for the corresponding public key.
A Truststore holds public key certificates belonging to the message sender. Certificates held in the Truststore are trusted certificates, that is, the Keystore owner trusts that the public key in the certificate belongs to the certificate owner.
At run time, one Keystore is created for each Java CAPS Environment. Several Truststores may exist to accommodate the different relationships between TPs. Java CAPS groups both Keystores and Truststores under the common name Keystore. However, both are regarded as separate entities.
eGate Integrator provides manages Keystores in Environments. The following procedure assumes you already have an existing Environment to which you want to add a Keystore.
In Environment Explorer, right-click the Environment and chooseNew Keystore.
Provide a meaningful name for the new Keystore.
Open the Keystore's properties page and configure appropriately under Environment Configuration > Connection Settings.
For an example, see To Create and Configure the Keystore External System.