Exchanging and storing electronic information is a normal part of everyday business. Tax authorities process and store data about a person’s address, revenue, and social security contributions. Government departments exchange strategic information, such as defense requirements, and consumer products companies store their customers’ credit card payment information.
With the frequency at which data is stored and exchanged, the necessity of securing that data has become even more important. In each of the above examples, stolen or manipulated data could have disastrous consequences.
Using a security product to encrypt sensitive data before storing or sending it makes it much harder for an attacker to manipulate or make use of stolen data. But if the encryption software you are using doesn’t work the way it’s supposed to, you might as well not be using it at all.
Ensuring Data Security Is Not Optional
Security products use algorithms within cryptographic modules to provide communication encryption, secure data storage, and digital signatures for authentication. To ensure these algorithms are correctly designed and implemented, and that the cryptographic module has been thoroughly tested to avoid security flaws, the National Institute of Standards and Technology (NIST) developed the Federal Information Processing Standard (FIPS) 140 — a standard that defines a set of security requirements for products that implement cryptography. Together with the Communications Security Establishment of Canada (CSEC), NIST also founded the Cryptographic Module Validation Program (CMVP) to validate compliance with the standard.1
It is particularly important for public sector and defense agencies to ensure the reliability of data security products, and FIPS 140-2 — the currently active version of the standard — is mandatory for all cryptography-based security systems acquired by federal US and Canadian agencies. But the benefits of FIPS 140-2 compliance don’t end at the government’s door. While businesses in the private sector are not legally required to use FIPS 140-2-compliant security products, it is still recommended that they do, because the consequences of unsecured data can be just as damaging for them.
A Peek Inside the FIPS 140-2 Standard
The FIPS 140-2 standard comprises four security levels, each of which contains incremental increases in security requirements:
- Security level 1 covers the basic security requirements.
- Security level 2 adds physical security requirements, such as tamper-evident coatings and pick-resistant locks.
- Security level 3 adds further physical security requirements, such as strong enclosures and circuitry that responds to tampering.
- Security level 4 is the highest level of security; it includes protection against environmental conditions, fluctuations in voltage and temperature, and tampering.
The varying levels of requirements for data sensitivity and application environments enable vendors to choose the level that best matches the nature and storage location of the data they are looking to protect. For example, basic administrative data may require a lower security level than electronic health records, and data residing in a highly protected environment — with strong physical protection such as fences and security staff, for instance — may need a lower security level than data that is stored in publicly accessible locations. By choosing the appropriate security level, companies can reduce costs associated with purchasing and maintaining the security tool.
All levels of the FIPS 140-2 standard have the same objectives: to ensure that a product’s security functions are implemented correctly; to protect the cryptographic module and sensitive data from unauthorized access, modification, and disclosure of contents (including cryptographic keys and parameters); and to detect errors in the operation of the module. Evaluations taken during this certification’s first six years show that it is leading to improved software security — 50% of the cryptographic modules submitted for testing contained security flaws and more than 25% of the tested algorithms had been incorrectly implemented.2
How the FIPS 140-2 Certification Process Works
Three parties are involved in a FIPS 140-2 certification process (see Figure 1 for a look at the overall process flow for FIPS 140-2 testing and validation):
- The vendor, who supplies the necessary materials for testing
- A Cryptographic and Security Testing (CST) lab accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) at NIST, which performs the testing of the cryptographic module
- NIST/CSEC, which validates the testing via the CMVP and grants the certificate
When a vendor is ready to certify one of its products, it must first contract with an accredited CST lab.3 Similar to other certification processes, the vendor needs to provide the lab with a number of items, including the software to be tested and the results from a suite of tests — such as power-up, conditional, and functional tests — which it must perform on its cryptographic module and algorithms using specifications developed by NIST and provided by the CST lab.
The vendor must also deliver a specific set of documents, including those that describe the specification, design, and implementation of the cryptographic module; operational guides for the administrator; and a security policy document that describes the type and purpose of the software being certified, supported platforms, the targeted security level of the certification, and an overview of all of the required documents.
The software, test results, and documents are then validated by the accredited CST lab. When all items pass the tests, the test reports are sent to NIST/CSEC for validation and granting of the certificate. Once a certificate is granted, the security policy is published on the official NIST/CSEC website at http://csrc.nist.gov/groups/STM/cmvp/validation.html.
FIPS 140-2 and SAP
Initially, SAP did not deliver its own cryptographic modules. To secure communication channels between servers, SAP adapted a licensed product from Swiss-based IT security company Secude AG, which SAP customers could implement without additional cost. However, for end-to-end encryption, which also covers communication channels between the front-end and the back-end server, customers needed to buy a third-party product. In response to increasing customer demand for an integrated end-to-end SAP solution, in 2011 SAP acquired the cryptographic module from Secude — the secure login library.
To ensure easy maintenance and maximum benefit for its customers, SAP first modularized the software, encapsulating the secure login library’s cryptographic algorithms in a cryptographic kernel that is accessible to processes and applications via defined interfaces. By separating the cryptographic kernel from the software that uses it, the kernel can easily be maintained and made available to SAP products such as SAP NetWeaver Single Sign-On (see Figure 2).
To meet the requirements and needs of its customers, and to continue to provide solutions of the highest quality and reliability, SAP is currently undergoing the process to certify the secure login library as compliant with FIPS 140-2, security level 1, which covers basic security requirements for production-grade components. The certification process is well under way, and the algorithms of SAP’s cryptographic kernel and their implementation have already been validated (see Figure 3).
SAP aims to complete FIPS 140-2 certification in 2013. The certified cryptographic kernel will then likely be available as part of the new release of SAP NetWeaver Single Sign-On in mid-2013. SAP also plans to implement the certified cryptographic kernel in a number of other SAP NetWeaver security products and functionalities (see sidebar). Over the long term, SAP plans to make its certified cryptographic kernel available for SAP security products not based on SAP NetWeaver. Meeting each of these goals will be a renewal of SAP’s commitment to provide customers with security they can rely on, wherever they need it, based on independent, internationally applied standards.
Learn more about the FIPS 140-2 standard at http://csrc.nist.gov/publications/PubsFIPS.html, and about the validation program at http://csrc.nist.gov/groups/STM/cmvp/index.html.
Annette Fuchs (firstname.lastname@example.org) is a Senior Product Manager in security product management with a focus on security quality and processes. She has been leading several product security certification projects within SAP NetWeaver development, including the Common Criteria certifications for SAP NetWeaver Application Server for ABAP and Java. Working with FIPS 140-2 is her most recent project. Annette has been with SAP for many years, specializing in the field of security since 2002.
1 Released in 1994, the first version of the standard, FIPS 140-1, was developed in cooperation with vendors and operators of cryptographic modules. The currently active version, FIPS 140-2, was released in 2001. As of the publication of this article, FIPS 140-3 is under development. [back]
2 NIST, “Frequently Asked Questions for the Cryptographic Module Validation Program” (December 2007). [back]
3 A list of accredited labs is available at http://csrc.nist.gov/groups/STM/testing_labs/index.html. [back]