CA DLP Release Notes for Advanced Encryption r12.0
This documentation and any related computer software help programs (hereinafter referred to as the "Documentation") are for your informational purposes only and are subject to change or withdrawal by CA at any time. This Documentation may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior written consent of CA. This Documentation is confidential and proprietary information of CA and may not be used or disclosed by you except as may be permitted in a separate confidentiality agreement between you and CA. Notwithstanding the foregoing, if you are a licensed user of the software product(s) addressed in the Documentation, you may print a reasonable number of copies of the Documentation for internal use by you and your employees in connection with that software, provided that all CA copyright notices and legends are affixed to each reproduced copy. The right to print copies of the Documentation is limited to the period during which the applicable license for such software remains in full force and effect. Should the license terminate for any reason, it is your responsibility to certify in writing to CA that all copies and partial copies of the Documentation have been returned to CA or destroyed. TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION "AS IS" WITHOUT WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO THE END USER OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS, LOST INVESTMENT, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED IN ADVANCE OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE. The use of any software product referenced in the Documentation is governed by the applicable license agreement and is not modified in any way by the terms of this notice. The manufacturer of this Documentation is CA. Provided with "Restricted Rights." Use, duplication or disclosure by the United States Government is subject to the restrictions set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS Section 252.227-7014(b)(3), as applicable, or their successors. Copyright 2010 CA. All rights reserved. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.
CA Product References This document references the following CA products: CA DLP Contact CA Contact Technical Support For your convenience, CA provides one site where you can access the information you need for your Home Office, Small Business, and Enterprise CA products. At http://ca.com/support, you can access the following: Online and telephone contact information for technical assistance and customer services Information about user communities and forums Product and documentation downloads CA Support policies and guidelines Other helpful resources appropriate for your product Provide Feedback If you have comments or questions about CA product documentation, you can send a message to techpubs@ca.com. If you would like to provide feedback about CA product documentation, complete our short customer survey, which is also available on the CA Support website, found at http://ca.com/docs.
Contents Chapter 1: New Features 7 Support for FIPS 140-2... 7 Which Files Are Included In This Release?... 8 Chapter 2: FAQS about Advanced Encryption Mode 9 What Is FIPS 140-2?... 9 Which FIPS Certified Cryptographic Module Is Used?... 10 Which Encryption Algorithms Are Used?... 10 What Data Is Encrypted?... 11 Can I Convert My Existing CA DLP Deployment To Be FIPS Compatible?... 11 Key Points... 11 Key Points... 11 Certificates and Key Store... 12 Deployment... 12 Known Issue... 12 Chapter 3: Understanding Advanced Encryption Certificates 13 Overview... 13 Deployment Architecture... 14 Root and Enterprise Certificates... 15 Certificate Security... 15 Revocation List... 15 Folders Used By Certificate Scripts... 16 Chapter 4: Deploying In Advanced Encryption Mode 17 How Do I Deploy CA DLP In Advanced Encryption Mode?... 17 Designate a Secure Server... 18 Generate the Root Certificate... 18 Generate the Key Store and Revocation List... 19 Deploy CA DLP Machines... 20 Ensure Machine Policy Is Correctly Configured... 22 Secure the Critical Advanced Encryption Files... 23 How Do I Replace Enterprise Certificates?... 23 Create Custom Machine Searches... 24 Update the Key Store and Revocation List... 25 Deploy the New Key Store and Revocation List... 26 Contents 5
Chapter 5: Acknowledgments 27 OpenSSL... 28 Glossary 31 6 Release Notes for Advanced Encryption
Chapter 1: New Features This section contains the following topics: Support for FIPS 140-2 (see page 7) Which Files Are Included In This Release? (see page 8) Support for FIPS 140-2 This release introduces CA DLP support for FIPS 140-2. You can now deploy CA DLP in Advanced Encryption mode. When deployed in this mode, CA DLP uses Transport Layer Security (TLS) and certificates to enable FIPS 140-2 compliant data transfers between CA DLP machines. CA DLP machines use a single enterprise certificate across the CA DLP enterprise. There is no authentication of individual machines. Any machine possessing the enterprise certificate and its associated private key can communicate with any CA DLP machine that uses the same certificate. Note: These Release Notes contain instructions for deploying CA DLP in Advanced Encryption Mode. The full set of CA DLP documentation, including the Deployment Guide and Database Guide, are available to download from CA Technical Support: http://ca.com/support Chapter 1: New Features 7
Which Files Are Included In This Release? Which Files Are Included In This Release? All the files and utilties that you need to deploy CA DLP in Advanced Encryption mode are included in the WIN- ADVANCED ENCRYPTION MODE ENHANCEMENT solution package (RO16355). Find this on the CA DLP Solutions & Patches page of the CA Technical Support site: http://ca.com/support, This solution package contains the contains the following files: CertificateSearches.txt Contains SQL snippet for the machine searches that you must run in the Administration console when replacing the enterprise certificate. Client_12.0_Advanced_Encryption.msp Windows Installer patch package that you must use to patch the administrative installation source image for CA DLP client machines. EnableAdvancedEncryption.vbs Customizes the administrative installation source images to allow deployment in Advanced Encryption mode. GenerateRootCert.bat Generates the root certificate and a key pair that is subsequently used to generate and sign the enterprise certificate. GenerateKeyStore.bat Generates the enterprise certificate, Key Store, and Revocation List. OpenSSL.exe Command line utility used by the certificate generation batch files, GenerateRootCert.bat and GenerateKeyStore.bat. RootCert.ini Contains configuration parameters for the root certificate. You do not need to edit this file. Server_12.0_Advanced_Encryption.msp Windows Installer patch package that you must use to patch the administrative installation source image for CA DLP servers. ServerCert.ini Contains configuration parameters for the enterprise certificate. You do not need to edit this file. 8 Release Notes for Advanced Encryption
Chapter 2: FAQS about Advanced Encryption Mode The U.S. Federal Government mandates that all Federal software purchased from commercial sources protect sensitive information using encryption binaries that have passed FIPS 140-2 certification. Because CA DLP processes corporate e-mails, which constitute sensitive information, it must be deployed in Advanced Encryption Mode to achieve compatibility with FIPS 140-2. This section contains the following topics: What Is FIPS 140-2? (see page 9) Which FIPS Certified Cryptographic Module Is Used? (see page 10) Which Encryption Algorithms Are Used? (see page 10) What Data Is Encrypted? (see page 11) Can I Convert My Existing CA DLP Deployment To Be FIPS Compatible? (see page 11) Key Points (see page 11) What Is FIPS 140-2? The Federal Information Processing Standards (FIPS) 140-2 publication is a security standard for the cryptographic libraries and algorithms that a product should use for encryption. On Federal networks, FIPS 140-2 encryption affects the communication of all sensitive data between components of CA products and between CA products and third-party products. FIPS 140-2 specifies the requirements for using cryptographic algorithms within a security system protecting sensitive, unclassified data. Chapter 2: FAQS about Advanced Encryption Mode 9
Which FIPS Certified Cryptographic Module Is Used? Which FIPS Certified Cryptographic Module Is Used? When deployed in Advanced Encryption Mode, CA DLP uses the Advanced Encryption Standard (AES) adopted by the US government. Specifically, it uses the TLS protocol to transfer sensitive data between machines. To allow this, CA has licensed the RSA BSAFE Crypto-J 4.0 cryptographic library. This library has been validated as meeting the FIPS 140-2 Security Requirements for Cryptographic Modules. CA DLP uses this library to encrypt sensitive data being transferred between machines. Note: The term FIPS 140-2 compliant and the FIPS 140-2 standard relate to the requirements of a cryptographic module (that is, one actually implementing cryptographic algorithms) and not to an application's use of cryptography. An application's use of cryptography is guided by what a FIPS 140-2 compliant cryptographic module will provide. CA DLP will not be a FIPS 140-2 compliant product. Instead, it will use a FIPS 140-2 compliant cryptographic module (RSA BSAFE Crypto-J 4.0) and will only use cryptographic algorithms, for purposes such as symmetric encryption, that are approved by FIPS 140-2. We therefore use the term FIPS compatible to describe the CA DLP support for FIPS 140-2. Note: Due to a limitation in the RSA BSAFE Crypto-J library, it is necessary to use the JAVA JCE libraries to extract keys from certificates. We are actively working with RSA to address this issue and hope to have it resolved in a future release. Which Encryption Algorithms Are Used? In Advanced Encryption Mode, CA DLP uses these encryption algorithms: Data Transfers: Sensitive data sent across the network between CA DLP machines is encrypted with TLS, using AES 128-bit as the symmetric cipher algorithm. Captured data: Blob files (binary large objects) containing captured data are encrypted using AES 128-bit as the symmetric cipher algorithm. They are saved in the CMS data store. Local encryption keys: These keys, used to encrypt captured data and policy data, are themselves encrypted with a master key using the 3DES (Triple Data Encryption Standard) algorithm. 10 Release Notes for Advanced Encryption
What Data Is Encrypted? What Data Is Encrypted? When two CA DLP machines transfer data, the preliminary handshaking between them is not encrypted. It is only the communication of the instance of the Java RMI service that is encrypted. In practical terms, this means that any potentially sensitive data is encrypted. In terms of its cryptographic boundary, CA DLP is self-contained. It has no dependency on an external Public Key Infrastructure (PKI). Can I Convert My Existing CA DLP Deployment To Be FIPS Compatible? No. Such migrations are not supported. Note: In theory, it is possible to convert your existing CA DLP machines to run in Advanced Encryption Mode. But in practice, this requires you to take all CA DLP machines offline and reconfigure them before restarting CA DLP. Any machines not changed at this point would cease to communicate with other machines in the CA DLP enterprise. For a typical CA DLP enterprise, with hundreds or thousands of protected machines, this is unlikely to be practicable. Key Points Key Points CA DLP uses TLS and certificates to enable FIPS 140-2 compliant data transfers between machines. CA DLP machines use a single enterprise certificate and private key across the CA DLP enterprise. There is no authentication of individual machines. Any machine possessing the enterprise certificate and its associated private key can communicate with any CA DLP machine that uses the same certificate. Chapter 2: FAQS about Advanced Encryption Mode 11
Key Points Certificates and Key Store A self-signed root certificate and a single enterprise certificate, and associated key pairs, are generated before installing CA DLP. A Key Store containing the root certificate, the enterprise certificate, and the private key for the enterprise certificate key pair is deployed throughout the CA DLP enterprise. Possession of the Key Store is enough to permit any CA DLP machine to communicate with other CA DLP machines. The critical files (keystore.dat, revocation.properties, and wigan.java.security) are stored in the CA DLP \data and \system folders. You must secure these file locations as part of the general machine hardening process after deployment. Deployment Advanced Encryption Mode must be enabled at install time, and if enabled must be enabled on every CA DLP machine. There is no backward compatibility with existing CA DLP installations. There is no automatic integration with third-party Public Key Infrastructures (PKIs). Mechanisms to replace the enterprise certificate and its key-pair are not built into CA DLP. Instead, you must use a manual process, or a third-party software distribution mechanism, in conjunction with the OpenSSL.exe utility (provided by CA). Known Issue When running in Advanced Encryption mode, there may be occasional slowdowns when connections are made between CA DLP machines, possibly accompanied by a brief period of high CPU usage. This is due to the mathematical nature of the encryption setup process. We expect to address this known issue in a future release. 12 Release Notes for Advanced Encryption
Chapter 3: Understanding Advanced Encryption Certificates This section contains the following topics: Overview (see page 13) Deployment Architecture (see page 14) Root and Enterprise Certificates (see page 15) Folders Used By Certificate Scripts (see page 16) Overview In Advanced Encryption Mode, each CA DLP machine holds a copy of the Key Store. This contains the root certificate, the enterprise certificate, plus the private key for the enterprise certificate key pair. All network communications with the potential to transmit sensitive data are protected by TLS, using AES 128 Bit Chapter 3: Understanding Advanced Encryption Certificates 13
Deployment Architecture Deployment Architecture The following diagram summarizes the FIPS 140-2 implementation for CA DLP. CA DLP Deployment Architecture: Advanced Encryption Mode 1. KeyStore.dat. This is the Key Store file. It contains the root certificate, the enterprise certificate, and the private key for the enterprise certificate key pair. A copy is held on each machine in your CA DLP enterprise. 2. Revocation.properties. This is the Revocation List file. It contains a list of all revoked enterprise certificates. A copy is held on each machine in your CA DLP enterprise. 3. Root certificate private key. This private key must be kept separate from your CA DLP enterprise on a secure server. It is used when you create replacement enterprise certificates. 4. Encrypted sensitive data. This includes infrastructure changes such as policy edits or user account updates (4a) replicated from the CMS to gateway servers and endpoint machines. It also includes captured data, such as e-mails, files or Web activity (4b) replicated from endpoint machines and gateway serves to the CMS. 14 Release Notes for Advanced Encryption
Root and Enterprise Certificates Root and Enterprise Certificates CA DLP uses certificates with a two-level hierarchy: Root certificate: This serves as the trusted root certificate. It is used to sign the Enterprise certificate. The root certificate enables CA DLP machines to authenticate each other before transferring sensitive data. You must create a self-signed root certificate on a secure server. Enterprise certificate: This certificate is signed by the trusted root certificate. CA DLP machines use this certificate to encrypt data transfers between machines. When you update the enterprise certificate, its serial number is incremented by 1 and the previous serial number is added to the Revocation List (see below). The root certificate, plus the enterprise certificate and the private key from its associated key pair, are then added to the Key Store and distributed to all CA DLP machines. This enables any machine in the CA DLP enterprise to use TLS to communicate with any other CA DLP machine. Certificate Security Because every CA DLP machine has a copy of the same enterprise certificate, the security of any data transfer is at risk if the enterprise private key is compromised. If this happens, you will need to distribute a new enterprise certificate and private key to all CA DLP machines. As with any PKI, we recommend that you regularly replace the enterprise certificate (that is, revoke the existing certificate and issue a new one). The CA DLP scheme has been designed to make this as simple as possible. Revocation List The Revocation List identifies certificates that have been marked as revoked. It holds the serial numbers of revoked certificates. The Revocation List is a Java properties file named revocation.properties. It is stored in the CA DLP \data folder. You must protect this file with the same level of operating system protection as the Key Store file. Chapter 3: Understanding Advanced Encryption Certificates 15
Folders Used By Certificate Scripts Folders Used By Certificate Scripts When you run the certificate generation scripts, GenerateRootCert.bat and GenerateKeyStore.bat, three subfolders are created: \tmp, \persist, and \output. For example, if the scripts are stored in an \AdvancedEncryption folder, they will subfolders such as \AdvnacedEncryption\persist. \tmp subfolder This holds temporary files while the script is running. When the script completes, this subfolder should be empty. If it is not, you can safely delete its contents. \persist subfolder This subfolder is critical. It contains files needed to update the certificates and Key Store at a later date. It contains: a script log file; a text file with the serial number of the most recent enterprise certificate; the self-signed root certificate containing its public key; the root key pair, encrypted; and the enterprise certificate. The file containing the encrypted root key pair must be kept secure because it is needed to sign every enterprise certificate generated. If this critical file is lost, the Key Store will need to be regenerated and redeployed to every machine in the CA DLP enterprise. Important! Never delete any files in this folder! \output subfolder This subfolder contains keystore.dat and revocation.properties. Whenever you update your enterprise certificate after the initial CA DLP deployment, you will need to deploy these files to the \data folder on each CA DLP server and client machine using a secure software delivery mechanism. Note: The \data folder holds all the configuration data and captured data used by your CA DLP enterprise. By default, when you install a CA DLP server or client machine this folder is added as a subfolder in the CA DLP installation folder. But you can rename it and locate it anywhere suitable on your network. 16 Release Notes for Advanced Encryption
Chapter 4: Deploying In Advanced Encryption Mode This section contains the following topics: How Do I Deploy CA DLP In Advanced Encryption Mode? (see page 17) How Do I Replace Enterprise Certificates? (see page 23) How Do I Deploy CA DLP In Advanced Encryption Mode? For CA DLP to be compatible with FIPS 140-2, you deploy it in Advanced Encryption Mode. This section describes the deployment procedure. The main steps are: 1. Designate a secure server that is separate from your intended CA DLP enterprise. 2. Generate the self-signed root certificate. 3. Generate the Key Store and Revocation List. 4. Deploy your CA DLP servers and client machines. a. Create new administrative installation source images. b. Patch the new source images. c. Customize the new source images. d. Install the servers and client machines from the appropriate source image. 5. Confirm that encryption is correctly configured in the machine policy for all your CA DLP servers and client machines. 6. Secure the critical Advanced Encryption files on your CA DLP servers and client machines so that they can only be accessed by the CA DLP infrastructure. These steps are fully described in the following sections. Chapter 4: Deploying In Advanced Encryption Mode 17
How Do I Deploy CA DLP In Advanced Encryption Mode? Designate a Secure Server Important: It is essential that the root certificate's private key is kept secure. The CA DLP Advanced Encryption Mode Enhancement solution package contains the files and utilities that you will need to deploy CA DLP in Advanced Encryption mode. We recommend that you create an \AdvancedEncryption folder on a secure server that is separate from your intended CA DLP enterprise and then copy the required files and utilities to this folder. This ensures that, when you generate the root certificate and Key Store, these files are saved to a location that is secure. Generate the Root Certificate To generate the root certificate, run the batch file supplied with the CA DLP distribution media. To generate the root certificate 1. From a command prompt on your designated secure server, change to the \AdvancedEncryption folder. 2. From a command prompt, run GenerateRootCert.bat. 3. When prompted, enter and confirm a strong passphrase to secure the root key pair. You will need to supply this passphrase later, when you self-sign the root certificate, and when you sign the enterprise-wide certificate. Important! This passphrase will not be stored anywhere. If you forget or lose it, you will need to regenerate all certificates and key stores! 4. GenerateRootCert.bat generates the root certificate and a key pair (root.crt and root.key respectively). These files are saved in the \AdvancedEncryption\Persist subfolder on your secure server. They will be used to generate the enterprise-wide certificate, the Key Store file, and the Revocation List file. Important! You must retain the contents of the \Persist subfolder for the lifetime of the CA DLP deployment. These contents are needed each time you update the enterprise wide certificate. More information: Folders Used By Certificate Scripts (see page 16) 18 Release Notes for Advanced Encryption
How Do I Deploy CA DLP In Advanced Encryption Mode? Generate the Key Store and Revocation List To generate the Key Store and Revocation List files, you run a batch file supplied with the CA DLP distribution media. To generate the Key Store and Revocation List files 1. On your designated secure server, browse to the \AdvancedEncryption folder. 2. Run GenerateKeyStore.bat. 3. When prompted, enter the root certificate passphrase. The batch file now generates keystore.dat and revocation.properties. These files are saved in the \AdvancedEncryption\output subfolder on your secure server. The enterprise-wide certificate is stored in keystore.dat and has a serial number of 1. The certificate itself is saved as server1.crt. It is saved in the \AdvancedEncryption\persist subfolder on your secure server. More information: Folders Used By Certificate Scripts (see page 16) Chapter 4: Deploying In Advanced Encryption Mode 19
How Do I Deploy CA DLP In Advanced Encryption Mode? Deploy CA DLP Machines To deploy CA DLP in Advanced Encryption Mode, you must first perform an administrative installation to your network. In fact, you must do this twice for servers and client machines. The administrative installation extracts the contents of the original CA DLP Windows Installer packages to a network folder specified by you, and in a format that can be patched to support Advanced Encryption mode. By performing the administrative installation, you will create the basic source images that you will use to install CA DLP servers and client machines. After creating your CA DLP source images, you must then patch and customize them. This enables you to deploy CA DLP in Advanced Encryption mode. Finally, you can install CA DLP servers and client machines directly from the patched and customized source images. 1. Create new administrative installation source images. To create the source images for your CA DLP servers and client machines, you must perform an administrative installation. Run the following commands to create administrative installation source images for CA DLP servers and client machines. These commands will launch the installation wizard, which will prompt for a target folder for the source images: msiexec /a <Path_source>\server.msi msiexec /a <Path_source>\client.msi <Path_source>\server.msi Identifies the Windows Installer package for servers on your CA DLP distribution media. <Path_source>\client.msi Identifies the Windows Installer package for client machines on your CA DLP distribution media. 2. Patch the administrative installation source images. Run the following commands to patch the administrative installation source images for CA DLP servers and client machines: msiexec /a <Path_admin>\server.msi /p <Path_patch>\Server_12.0_Advanced_Encryption.msp msiexec /a <Path_admin>\client.msi /p <Path_patch>\Client_12.0_Advanced_Encryption.msp <Path_admin>\server.msi and <Path_admin>\client.msi Identify the server and client machine source images that you created in step 1. 20 Release Notes for Advanced Encryption
How Do I Deploy CA DLP In Advanced Encryption Mode? <Path_patch>\Server_12.0_Advanced_Encryption.msp Identifies the patch package that will customize the server source image. <Path_patch>\Client_12.0_Advanced_Encryption.msp Identifies the patch package that will customize the client machine source image. 3. Customize the administrative installation source images. You now need to customize the administrative installation source images so that they install the Key Store (and associated components) on all CA DLP servers and client machines. To do this, you must run a script supplied with the CA DLP Advanced Encryption Mode Enhancement solution pacakge. From a command prompt on your designated secure server, change to the \AdvancedEncryption folder and run the following commands: EnableAdvancedEncryption.vbs /package:<path_admin>\server.msi /files:<path_keystore> EnableAdvancedEncryption.vbs /package:<path_admin>\client.msi /files:<path_keystore> /package:<path_admin>\server.msi Identifies the server source images that you created in step 1. /package:<path_admin>\client.msi Identifies the client machine source images that you created in step 1. /files:<path_keystore> Identifies the path to the folder containing the Key Store and Revocation List files, keystore.dat and revocation.properties. When you generated these files (see the previous section), they were saved in the \AdvancedEncryption\output subfolder on your secure server. 4. Deploy your CA DLP servers and client machines. Important: You must deploy your CMS before deploying the other servers and client machines! After customizing the administrative installation source images, you can deploy CA DLP servers and client machines using your preferred deployment methods. For example, use the following command syntax to deploy client machines as part of a managed deployment: msiexec /i <Path_admin>\client.msi WGNPARENTSERVERNAME=<Server> <Path_admin>\client.msi Identifies the client machine source image that you patched in step 2 and customized in step 3. <WGNPARENTSERVERNAME>=<Server> Chapter 4: Deploying In Advanced Encryption Mode 21
How Do I Deploy CA DLP In Advanced Encryption Mode? Identifies the parent gateway or the CMS. During the installation, the following critical files are installed: keystore.dat, revocation.properties and wigan.java.security. As the final step in overall deployment, you will need to restrict access to these files. Note: Full server and client machine installation instructions are available in the Deployment Guide. Ensure Machine Policy Is Correctly Configured The two settings in CA DLP machine policy that control data encryption are Communications Encryption and Encrypt Stored Data?. Find these settings in the Security folder of the machine policy. When CA DLP runs in Advanced Encryption Mode, Encrypt Stored Data? must be set to True (this is its default value), while Communications Encryption is not used. Consequently, you do not normally need to change these settings after deploying CA DLP. Machine Policy Setting 'Communications Encryption' This setting covers encryption for network communications. It specifies the level of network encryption (none, low, medium, or high) for data sent between CA DLP machines. However, CA DLP ignores this setting when it runs in Advanced Encryption Mode. This is because network encryption using TLS is an integral part of Advanced Encryption Mode and cannot be disabled. Instead, the infrastructure logs an entry in the CA DLP Activity Log file indicating that it is running in this mode. Machine Policy Setting 'Encrypt Stored Data?' This setting covers stored data encryption. The machine policy setting specifies whether to encrypt Binary Large Object files (blobs) containing captured data. This setting remains active and must be set to True (the default) when CA DLP runs in Advanced Encryption Mode. This is because FIPS 140-2 states that all sensitive data must be encrypted with an approved algorithm. Important: CA DLP administrators must therefore ensure that this setting is never set to False! Note: If Encrypt Stored Data is inadvertently set to False, you will need to reset it to True across all machines in your CA DLP enterprise. To do this, you will need to edit this setting in the CMS machine policy, the common gateway policy and the common client policy. All gateway servers inherit the common gateway policy, and all client machines inherit the common client policy. For details about editing machine policies, see the online help for the CA DLP Administration console. 22 Release Notes for Advanced Encryption
How Do I Replace Enterprise Certificates? Secure the Critical Advanced Encryption Files When you deploy your CA DLP servers and client machines in Advanced Encryption Mode, three critical files are installed. These are keystore.dat and revocation.properties, stored in the CA DLP \data folder, and wigan.java.security, stored in the CA DLP \system folder. You must secure these files to prevent unauthorized access to these files. To secure the critical Advanced Encryption files On each CA DLP server and client machine, you must configure Windows security for each of these critical files so that: Each file can be accessed only by the Windows logon account used by the CA DLP infrastructure service. The infrastructure service only requires Read access to these files. No other process on the system is permitted to access these files. How Do I Replace Enterprise Certificates? Because every CA DLP machine has copies of the same enterprise certificate, if the enterprise private key is compromised then the security of any data transfer is at risk. As a security precaution, and as with any PKI, we therefore recommend that you periodically replace the enterprise certificate. The CA DLP scheme has been designed to make this as simple as possible. The main steps are: 1. Create three machine searches for use in the CA DLP Administration console. You will use these searches to monitor progress across your CA DLP enterprise when you update your enterprise certificate. 2. Update the Key Store and Revocation List. You will do this on your secure server using the CA-supplied script, GenerateKeyStore.bat. 3. Deploy the new Key Store and Revocation List. This is a multi-step procedure designed to minimize disruption to your CA DLP enterprise. Chapter 4: Deploying In Advanced Encryption Mode 23
How Do I Replace Enterprise Certificates? Create Custom Machine Searches Before you generate the replacement certificate, you need to create three machine searches that you run in the CA DLP Administration console. When you replace the enterprise certificate on your CA DLP servers and client machines, you will use these searches to monitor progress across your CA DLP enterprise. To create these machine searches, you will copy SQL snippets (database search queries) from a CA-supplied file and save them as the following three custom searches in the Administration: All servers with an out-of-date Key Store All client machines with an out-of-date Key Store All machines with out-of-date Revocation List To create custom machine searches 1. Create an Administration console search for any servers with an out-of-date Key Store. a. In the CA DLP Advanced Encryption Mode Enhancement solution package, open the CertificateSearches.txt file and copy the All servers with an out-of-date Key Store SQL snippet. b. In the CA DLP Administration console, create a new administrative search. c. In the Administration Search dialog, go to the SQL tab and paste in the 'All servers with an out-of-date Key Store SQL snippet. d. Save the new search as All servers with an out-of-date Key Store. e. The new search is added to the Custom Searches folder in the Administration console. The new search is saved on the machine hosting the Administration console and is only available to you when you run the console on that machine. Note: For assistance with making the search available when colleagues run the Administration console on other machines, please contact CA Technical Support: http://ca.com/support 2. Create an Administration console search any for client machines with an out-of-date Key Store. Repeat step 1, but using the All client machines with an out-of-date Key Store SQL snippet and saving the search as All client machines with an out-of-date Key Store. 3. Create an Administration console search for any servers and client machines with an out-of-date Revocation List. Repeat step 1, but using the All machines with out-of-date Revocation List SQL snippet and saving the search as All machines with an out-of-date Revocation List. 24 Release Notes for Advanced Encryption
How Do I Replace Enterprise Certificates? Update the Key Store and Revocation List Generate the replacement Key Store and Revocation List. 1. From a command prompt on your designated secure server, change to the \AdvancedEncryption folder. 2. Run GenerateKeyStore.bat. 3. When prompted, enter the root certificate passphrase. The batch file now generates keystore.dat and revocation.properties and saves these files in the \AdvancedEncryption\output subfolder on your secure server. The serial number for the enterprise certificate is incremented by 1. The certificate is saved in the new Key Store file, keystore.dat. The old serial number for the enterprise certificate is appended to the Revocation List in revocation.properties. The new enterprise certificate is saved as server<n+1>.crt, where <n> is the number used by the most recent certificate file. It is saved in the \AdvancedEncryption\persist subfolder on your secure server. For example, if the \perist folder already contains server1.crt and server2.crt, the newest replacement certificate will be saved as server3.crt. More information: Folders Used By Certificate Scripts (see page 16) Chapter 4: Deploying In Advanced Encryption Mode 25
How Do I Replace Enterprise Certificates? Deploy the New Key Store and Revocation List Deploy the updated Key Store and Revocation List. You must follow the steps below to enable your CA DLP enterprise to continue with minimal disruption during the certificate deployment. Important! Do not try to optimize the following procedure. For example, do not try to combine steps 2 and 6. The procedure below is explicitly designed to minimize the steps needed to replace certificates on your client machines while retaining a functioning CA DLP enterprise. 1. Distribute keystore.dat to the CA DLP \data folder on the CMS only. Then restart the CA DLP infrastructure service on the CMS, or reboot the server. 2. Distribute keystore.dat to the CA DLP \data folder on all gateway servers. Then restart the CA DLP infrastructure service on each server, or reboot them. 3. In the Administration console, run the 'All servers with out-of-date Key Store' custom search. When you can confirm that the CMS and all gateway servers have the new Key Store (that is, when this search returns zero results), continue to the next step. 4. Distribute keystore.dat and revocation.properties to the CA DLP \data folder on all client machines. Then restart the CA DLP infrastructure service on each machine, or reboot them. 5. In the Administration console, run 'All client machines with out-of-date Key Store' custom search. When you can confirm that all client machines have the new Key Store, continue to the next step. 6. Distribute revocation.properties to the CA DLP \data folder on the CMS and all gateway servers. Then restart the CA DLP infrastructure service. 7. Finally, in the Administration console run the 'All machines with out-of-date Revocation List' custom search to confirm that the CMS and all CA DLP gateway servers and client machines have the new list. 26 Release Notes for Advanced Encryption
Chapter 5: Acknowledgments This section contains the following topics: OpenSSL (see page 28) Chapter 5: Acknowledgments 27
OpenSSL OpenSSL This product includes OpenSSL 0.9.8k, the use of which is governed by the following terms: LICENSE ISSUES The OpenSSL toolkit stays under a dual license, i.e. both the conditions of the OpenSSL License and the original SSLeay license apply to the toolkit. See below for the actual license texts. Actually both licenses are BSD-style Open Source licenses. In case of any license issues related to OpenSSL please contact openssl-core@openssl.org. OpenSSL License Copyright (c) 1998-2008 The OpenSSL Project. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgment: "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)" 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact openssl-core@openssl.org. 5. Products derived from this software may not be called "OpenSSL" nor may "OpenSSL" appear in their names without prior written permission of the OpenSSL Project. 6. Redistributions of any form whatsoever must retain the following acknowledgment: "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/)" 28 Release Notes for Advanced Encryption
OpenSSL THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT "AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This product includes cryptographic software written by Eric Young (eay@cryptsoft.com). This product includes software written by Tim Hudson (tjh@cryptsoft.com). Original SSLeay License Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com) All rights reserved. This package is an SSL implementation written by Eric Young (eay@cryptsoft.com). The implementation was written so as to conform with Netscapes SSL. This library is free for commercial and non-commercial use as long as the following conditions are aheared to. The following conditions apply to all code found in this distribution, be it the RC4, RSA, lhash, DES, etc., code; not just the SSL code. The SSL documentation included with this distribution is covered by the same copyright terms except that the holder is Tim Hudson (tjh@cryptsoft.com). Copyright remains Eric Young's, and as such any Copyright notices in the code are not to be removed. If this package is used in a product, Eric Young should be given attribution as the author of the parts of the library used. This can be in the form of a textual message at program startup or in documentation (online or textual) provided with the package. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Chapter 5: Acknowledgments 29
OpenSSL 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: "This product includes cryptographic software written by Eric Young (eay@cryptsoft.com)". The word 'cryptographic' can be left out if the routines from the library being used are not cryptographic related :-). 4. If you include any Windows specific code (or a derivative thereof) from the apps directory (application code) you must include an acknowledgement: "This product includes software written by Tim Hudson (tjh@cryptsoft.com)" THIS SOFTWARE IS PROVIDED BY ERIC YOUNG "AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The licence and distribution terms for any publicly available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied and put under another distribution licence [including the GNU Public Licence.] 30 Release Notes for Advanced Encryption
Glossary 3DES 3DES (Triple Data Encryption Standard) is an encryption algorithm using a 128-bit key or a 192-bit key. Triple refers to using the DES algorithm three times to encrypt the data for added security. certificate FIPS FIPS 140-2 PKI In the context of public key infrastructure cryptography, a digital certificate is an electronic document that states that the name (subject) on the certificate is bound to the public key in the certificate. A certificate is signed with a digital signature from a Certificate Authority or from the certificate subject itself (a self-signed certificate). Federal Information Processing Standards (FIPS) are standards and guidelines intended to improve security and interoperability of computer systems in the US Federal government. These standards and guidelines are issued the National Institute of Standards and Technology (NIST). FIPS 140-2 is a FIPS publication that specifies the security requirements of a cryptographic module utilized within a security system protecting sensitive but unclassified information. See Public Key Infrastructure. Public Key Infrastructure (PKI) Public Key Infrastructure (PKI) is the technology and set of procedures that uses public keys and certificates issued by trusted certificate authorities to provide secure authentication between computers. TLS Transport Layer Security (TLS) is a protocol designed to provide authentication, confidentiality and data integrity between two communicating applications. It is based on SSL 3.0, but different enough that the two cannot interoperate. Glossary 31