Securing credentials when stored locally with an application or device is absolutely critical to ensuring integrity and confidentiality of data. The CA API Gateway appliance stores most configuration data in a database object within the MySQL server or within flat configuration files located on the file system of the appliance. It is critical that the product is engineered to safeguard this data from unauthorized disclosure. There are two primary pieces of configuration data that are encrypted on the Gateway that must be protected:
- The database user password. Authenticates the Gateway application to provide unprivileged access to the Gateway database
- The cluster passphrase. Encrypts sensitive policy components such as private keys and additional stored passwords
These two values are not set by CA Technologies and must by the operator. These are pieces of information that should only be known to administrative and supervisory staff in order to ensure the confidentiality of data stored on the API Gateway. These values are stored in a configuration file located on the file system of the Gateway appliance located at /opt/SecureSpan/Gateway/node/default/etc/conf/node.properties. These two values are respectively specified in two configuration directives:
- node.db.config.main.pass
- node.cluster.pass
The crucial point of security configuration data comes in to play: Passwords are stored in a flat file that can be accessed by someone who has obtained root access to the appliance. How does the API Gateway secure these credentials from unauthorized disclosure if the root account is compromised? The credentials set by the operator are encrypted by the master passphrase.
This is a second shared key that encrypts the first two items. This passphrase is set at the factory to a secure phrase but can—and should—be changed by an administrator upon initial deployment of the API Gateway. It is also imperative that this master passphrase be changed on each node in the cluster. The master passphrase is not shared amongst individual nodes in order to further supplement the security posture of the Gateway. Compromising one node's master passphrase does not put the other nodes at risk. The procedure for changing this passphrase is documented within the API Gateway documentation. The appropriate section of the documentation can be found here.
The master passphrase is also stored within the Gateway appliance via a flat file on the API Gateway. It is stored within a file located in /opt/SecureSpan/Gateway/node/default/etc/conf/omp.dat. Again, how does CA Technologies allow this sensitive credential to be secured?This passphrase is encrypted using a private key contained within the API Gateway application code. It is generated by the API Gateway engineering team and resides natively in the application to decrypt the aforementioned configuration data on initialization. This key is only available to the API Gateway application and cannot be accessed or leveraged by an outside attacker. This is attained through security measures in the API Gateway code base that are outside the scope of this post.The following chain of encryption is executed for an API Gateway using a software keystore:
- Private key maintained by CA
- Master passphrase
- Cluster passphrase
- Private keys
- Stored passwords
- Database password
The configuration data is secured because the API Gateway application is the only component in the mix that possesses the private key to decrypt these items in serial. They are also encrypted repeatedly and sufficiently to make brute-force decryption extremely difficult.This paradigm is changed somewhat by the use of a hardware security module.
The API Gateway supports hardware security modules in two form-factors: PCI-e expansion cards for hardware appliances (such as the Thales nShield Solo) and network-based devices (such as the Thales nShield Connect or SafeNet Luna). These devices allow our customers to operate Gateway appliances that do not have key material possessed by CA Technologies. This minimizes the risk of a third-party's keys being disclosed and used for decryption.The HSMs generate a local security world that secures all of the material that needs to be encrypted. This security world is initialized with a key that is built in to the device itself via a ROM chip. Most PCI-e and network-based HSMs have security features that prevent this ROM chip from being modified or re-written. They may also contain material to make them either tamper-evident should certain environmental thresholds (such as impact, pressure, or temperature) be exceeded. If an HSM is in use then the following chain of encryption is executed:
- Key stored in the HSM ROM
- Security world
- Private Keys
- Stored passwords
- Cluster passphrase
- Database password
I hope that this post can give our customers and integrators confidence in the security of the data maintained within the API Gateway as well as elucidate how we execute this process. Please feel free to add questions or comments in the discussion below!