The mantra of any good security engineer is: ‘Security is a not a product, but a process.’ It’s more than designing strong cryptography into a system; it’s designing the entire system such that all security measures, including cryptography, work together. — Bruce Schneier
FIPS 140-2 is the Federal Information Processing Standard titled “Security Requirements for Cryptographic Modules”. It “specifies the security requirements that will be satisfied by a cryptographic module, providing four increasing, qualitative levels intended to cover a wide range of potential applications and environments.” In other words, it is the U.S. Federal Government’s standard for how data encryption – at rest and in motion – is to be done. It requires extensive testing and certification of specific encryption algorithms and the specific hardware and software modules that implement them.
It is also a source of some confusion when it comes to the Oracle database and DISA Secure Technical Implementation Guide (STIG) compliance, which I will attempt to sort out to the best of my ability in this post. For people who design and configure systems for the Department of Defense, the STIGs are the mandatory security hardening guidelines and evaluation checklists for just about everything. Almost every conceivable aspect of an information system, network, application, or physical facility has an associated STIG. If you would like to know more about STIGs in general, check out this earlier post called “The Rules of the Road“.
What do the STIGs say about FIPS?
STIG control V-61747, from the DISA Oracle 12c Database STIG, is titled “The DBMS must use NIST-validated FIPS 140-2-compliant cryptography for authentication mechanisms.” It reads as follows (emphasis added):
Encryption is only as good as the encryption modules utilized. Unapproved cryptographic module algorithms cannot be verified and cannot be relied upon to provide confidentiality or integrity, and DoD data may be compromised due to weak algorithms. Applications utilizing encryption are required to use approved encryption modules that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. FIPS 140-2 is the current standard for validating cryptographic modules, and NSA Type-X (where X=1, 2, 3, 4) products are NSA-certified hardware-based encryption modules. Authentication modules with weak encryption could allow an attacker to gain access to data stored in the database and to the administration settings of the DBMS.
In the instructions for checking if FIPS is properly enabled, it goes on to say:
If encryption is required but not configured, check with the DBA and system administrator to see if other mechanisms or third-party cryptography products are deployed for authentication.
Further, we have STIG Control V-61759, with the lengthy title “The DBMS must implement required cryptographic protections using cryptographic modules complying with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance“, which says:
Detailed information on the NIST Cryptographic Module Validation Program (CMVP) is available at http://csrc.nist.gov/groups/STM/cmvp/index.html Note: this does not require that all databases be encrypted. It specifies that if encryption is required, then the implementation of the encryption must satisfy the prevailing standards…
If the DBMS has not implemented federally required cryptographic protections for the level of classification of the data it contains, this is a finding.
The keys to understanding these STIG controls are:
- From the title and the description, it is apparent that V-61747 is talking specifically about encryption that takes place during the user authentication process and subsequent data in motion. The phrase “If encryption is required but not configured” carries the implication that there may be cases where encrypted user authentication may actually not be required.
- V-61759 appears to be talking about data at rest (confirmed later in the verification text, which talks about the DBFIPS_140 initialization parameter and the DBMS_CRYPTO package). It states explicitly that encryption for data at rest is only required for specific use cases.
All these really say is that if I use encryption, I have to use FIPS-compliant encryption. These controls don’t really give me a specific use case or requirement that says I must encrypt anything. Enter STIG Control V-61447. It says:
Connections by mid-tier web and application systems to the Oracle DBMS from a DMZ or external network must be encrypted…
In cases where either or both systems are located in the DMZ (or on networks external to DoD), network communications between the systems must be encrypted.
So here is at least one STIG-mandated use case for encrypting data in motion. I would even go so far as to generalize this control and recommend requiring FIPS-compliant encrypted communication from any client – whether a remote server or a laptop on the VPN – if they are even potentially crossing the network enclave boundary, where firewalls and other monitors perform stateful packet inspection and might be able to read un-encrypted data transmissions.
There are a lot of other reasons within DoD that you may have to deploy FIPS encryption for your database, particularly if you store Controlled Unclassified Information (CUI) data, Personally Identifiable Information (PII) or any other form of “For Official Use Only” (FOUO) data. Your local Information Assurance office should be able to help you sort out your specific requirements.
I Have a Requirement for Encryption – Now What?
Even if you have a requirement just turning it on in the way specified in the STIG controls doesn’t do anything unless your database and application are engineered to use FIPS-related features where it matters.
For example, V-61759 specifies that the DBFIPS_140 initialization parameter must be set to “TRUE”.
To see if Oracle is configured for FIPS 140-2 Transparent Data Encryption and/or DBMS_CRYPTO, enter the following SQL*Plus command:SHOW PARAMETER DBFIPS_140
or the following SQL query:SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'DBFIPS_140';
If Oracle returns the value ‘FALSE’, or returns no rows, this is a finding.
This parameter enables FIPS compliance for your data-at-rest encryption provided through the Transparent Database Encryption feature (TDE) of the Advanced Security Option, and through use of the DBMS_CRYPTO package. The STIG doesn’t mention that if you haven’t configured any tablespaces, tables, or columns using TDE or any stored procedures to use DBMS_CRYPTO, then turning it on won’t have any effect for you. Whether you should use TDE is a whole other discussion, depending on what type of storage you’re using and whether it provides its own encryption (double-encryption is generally considered to be a bad thing, for several reasons).
Similarly, V-61747 speaks of parameters in the fips.ora file that affect encryption of data in motion:
Open the fips.ora file in a browser or editor. (The default location for fips.ora is $ORACLE_HOME/ldap/admin/ but alternate locations are possible. An alternate location, if it is in use, is specified in the FIPS_HOME environment variable.)
If the line “SSLFIPS_140=TRUE” is not found in fips.ora, or the file does not exist, this is a finding.
The control doesn’t mention that setting “SSLFIPS_140=TRUE” in fips.ora won’t do anything for you if you aren’t using SSL/TLS communications (aka. TCPS) over the network. This is not the default network protocol used by OracleNet – even natively encrypted OracleNet. SSL/TLS requires Public Key Infrastructure (PKI) certificates and wallets on both the client and the server. If you must also support the standard OracleNet for unencrypted or natively (non-SSL/TLS) encrypted communication, it will require a non-standard port number (i.e. not 1521) as well.
The paper “Configuring SSL for Oracle Client Authentication and Encryption with DoD Common Access Cards Using Microsoft Certificate Store” describes how to implement basic PKI authentication in a DOD environment – essentially CAC authentication for the database. As you work through implementation, also reference these Oracle Doc links on how to configure and confirm of each setting in the database and various “.ora” files for your particular version: Oracle 12.2; Oracle 18c; Oracle 19c
What Else Do I Need to Know about Enabling FIPS?
You should also be aware of the following in regards to enabling FIPS-compliant encryption:
- FIPS-compliant encryption of data in motion using TCPS is included in the basic Oracle database license, but FIPS-compliant encryption for data at rest is not. Encryption of data at rest requires the purchase of the Oracle Advanced Security Option, which includes Transparent Data Encryption. If you are required to encrypt your data at rest, this is an extra cost – or in the case of the USAF and their enterprise agreement with Oracle, an extra registration requirement.
- The fips.ora file can be elusive. If you have just a basic DB install, then the $ORACLE_HOME/ldap/admin/fips.ora file is easy to find. If you are running Oracle Grid Infrastructure, things get slightly more complicated. Network listener operations are handled by the GI home, so for inbound connections to the listener $ORACLE_HOME/ldap/admin/fips.ora is in the Grid Infrastructure home directory. Outbound connections, like database links to other servers, are all handled from the Database home directory.
- Firewalls are not your friends. If your connection crosses through a firewall be aware that many (perhaps most?) firewalls now perform stateful packet inspection – confirming that your OracleNet traffic really looks like OracleNet traffic and not like someone trying to sneak something else through an open port. With SSL/TLS encryption enabled, the firewall is unable to perform the packet inspection and may reject the connection out of hand, even though it allows a “tnsping” packet through without issue. This requires modification of the firewall exception/rule to turn off the packet inspection, which you would have to coordinate with the owners of the firewall.
- Enabling SSL/TLS with FIPS will affect your system performance, per MOS Doc ID 2279002.1.
- Over the years there have been a number of bugs regarding FIPS enforcement in both TDE and SSL/TLS. Everything from auto-open wallets not opening to authentication failing to memory leaks in the listener has been reported. Keep up with all patches, not just security patches.
Finally, pay attention to the valid cipher suites used by Oracle for FIPS compliance. The FIPS standard and DoD requirements change over time as new cipher suites are added or deprecated, and Oracle doesn’t necessarily keep up within a particular database version the way that Red Hat does for the OS; they use a third-party crypto module, RSA BSAFE® Crypto-C Micro Edition, with its own FIPS-compliant certification. It may happen from time to time that the only way to stay FIPS compliant is to upgrade to a newer database version.
Case in point: note that certain minimum encryption and hashing algorithms are required by both V-61747 and V-61759.
The strength requirements are dependent upon data classification.
For unclassified data, where cryptography is required:
AES 128 for encryption
SHA 256 for hashing
NSA has established the suite B encryption requirements for protecting National Security Systems (NSS) as follows:
AES 128 for Secret
AES 256 for Top Secret
SHA 256 for Secret
SHA 384 for Top Secret
According to the documentation links above however, only the following algorithms are actually enabled within Oracle’s FIPS cryptographic module for versions 12.2, 18c, and 19c:
Only the following cipher suites are approved for FIPS validation:
All but one of these algorithms fails the minimum standard required by the STIG controls, for even unclassified systems. The minimum required hashing algorithm is SHA256, and most of these only provide SHA (i.e. SHA-1), which DoD disallowed back in 2016. The Application Security and Development STIG explicitly prohibits its use in STIG Control V-70193, which says:
While SHA1 is currently FIPS-140-2 approved, due to known vulnerabilities with this algorithm, DoD PKI policy prohibits the use of SHA1 as of December 2016. See DoD CIO Memo Subject: Revised Schedule to Update DoD Public Key Infrastructure Certificates to Secure Hash Algorithm-256.
This means that just enabling FIPS-compliant encryption, setting up PKI authentication, and letting Oracle choose an algorithm automatically still isn’t enough. You must also configure Oracle to use the one encryption and hashing algorithm that actually meets the STIG requirements.
To do this for data in motion, set the following parameters in fips.ora:
For data at rest, you will need to explicitly set the encryption and integrity (hashing) algorithms in your SQL commands. Be careful to check your syntax as there are many ways to encrypt or rekey columns, tables, and tablespaces. Be sure to specify the minimum required options for your system’s classification level and not to rely on defaults – the default level of encryption for columns is AES192, which is fine, but the integrity algorithm default is still SHA-1, which is not. The default level of encryption for tablespaces and databases is AES128, which will work for some classification levels but not others. There does not appear to be any way to set an integrity algorithm for tablespaces or databases, so this type of encryption may not even be fully compliant.
Hopefully this makes the requirements for and implementation of FIPS-compliant encryption at least a little clearer than mud, and the rather incomplete descriptions available in the DISA Oracle Database STIGs. Remember that there are many factors, moving parts, and requirements involved in any system configuration which means that the information I have put forward here is always subject to change. Everything I have suggested in this post should be validated through Oracle Documentation, Government Employees, and the Contracted System Integrators before making software and hardware acquisitions or doing anything in your Production environment. In addition, I recommended that all changes should be tried and fully vetted in Development or Test environments for your specific system architecture before doing anything in Production.