FIPS 140-2 in the Mobile World
FIPS 140-2 in the Mobile World
There are many questions around security for mobile devices. Within the U.S. government market one of the main questions is ‘Do you have FIPS 140-2 certification?’. Before you can answer this question it is helpful to understand what is meant by FIPS 140-2 certification.
On July 17, 1995, the National Institute of Standards and Technology (NIST) established the Cryptographic Module Validation Program (CMVP) that validates cryptographic modules to Federal Information Processing Standards (FIPS). The CMVP is a joint effort between NIST and the Communications Security Establishment Canada (CSEC). FIPS stands for Federal Information Processing Standard and the number 140-2 refers to a specific standard.
What is FIPS 140-2 certification?
FIPS 140-2 standard is entitled "Security Requirements for Cryptographic Modules". FIPS 140-2 was released on May 25, 2001 and is legally required for U.S. Federal Government agencies, including The Department of Defense (DoD). The standard specifies the security requirements that are to be satisfied by a cryptographic module utilized within a security system protecting unclassified information within computer and telecommunication systems (including voice systems).
The standard describes government requirements that hardware and software products must meet for Sensitive but Unclassified (SBU) use. The standard was published by NIST, has been adopted by the Canadian government’s Communications Security Establishment (CSE), and is being adopted by the financial community through the American National Standards Institute (ANSI).
With the passage of the Federal Information Security Management Act (FISMA) of 2002, there is no longer a statutory provision to allow for agencies to waive mandatory Federal Information Processing Standards (FIPS).
The standard provides four increasing, qualitative levels of security: Level 1, Level 2, Level 3, and Level 4. It does not specify in detail what level of security is required by any particular application.
- FIPS 140-2 Level 1 the lowest level imposes very limited requirements; loosely, all components must be "production-grade" and various egregious kinds of insecurity must be absent.
- FIPS 140-2 Level 2 adds requirements for physical tamper evidence and role-based authentication.
- FIPS 140-2 Level 3 adds requirements for physical tamper resistance (making it difficult for attackers to gain access to sensitive information contained in the module) and identity-based authentication, and for a physical or logical separation between the interfaces by which "critical security parameters" enter and leave the module, and its other interfaces.
- FIPS 140-2 Level 4 makes the physical security requirements more stringent, and requires robustness against environmental attacks.
These levels are intended to cover the wide range of potential applications and environments in which cryptographic modules may be employed. Software only solutions will never achieve certification above level 1 because the other levels all involve hardware elements for physical tamper resistance.
Vendors of cryptographic modules use independent, accredited Cryptographic and Security Testing (CST) laboratories to test their modules. The CST laboratories use the Derived Test Requirements (DTR), Implementation Guidance (IG) and applicable CMVP programmatic guidance to test cryptographic modules against the applicable standards. NIST's Computer Security Division (CSD) and CSEC jointly serve as the Validation Authorities for the program, validating the test results and issuing certificates.
FIPS 140-2 precludes the use of unvalidated cryptography for the cryptographic protection of sensitive or valuable data within Federal systems. Unvalidated cryptography is viewed by NIST as providing no protection to the information or data - in effect the data would be considered unprotected plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 is applicable. In essence, if cryptography is required, then it must be validated.
What does this mean to enterprise mobile solutions?
In the world of enterprise applications security is a critically important element of mobile applications. Initially enterprise applications were extended only within the corporate environment. These were typically warehouse management or service applications. They required purpose specific mobile devices and were protected by simple security methods. Rarely were they secured beyond this as they didn’t carry sensitive corporate data or could not function beyond the limited range of a controlled wireless network.
Today, with the proliferation of smart mobile devices, such as the iPhone, iPad and their comparable Android counterparts, we have the requirement to extend corporate and agency data beyond the controlled IT infrastructure. This makes security a mandated element of all enterprise mobile solutions and in particular the FIPS 140-2 standard a base line requirement for government market segments.
What needs to be secured?
Data exists in multiple places within the mobile world. There is the originating location, typically the enterprise system; the intermediate server (a mobile application server) which caches or replicates data before it is transmitted to the mobile device, the transport package (data transmission) to/from the mobile device and memory (storage) on the mobile device itself.
The enterprise data and the mobile application server both sit behind the corporate firewall and typically do not require encryption as they are protected by multiple other security elements. So for mobile we need to protect the other two elements which are referred to as ‘data in motion’ and ‘data at rest’. Data in motion is the data in the transport package and data at rest is the data on the mobile device itself.
There are two sets of data in motion that must be considered for a complete discussion. First is the data used for enterprise mobile applications and the second is data for email applications. These data paths differ in the route each takes. Data for enterprise mobile applications typically passes through a mobile application server while email typically passes through a corporate email server like Microsoft Exchange. This results in two different transports that can contain sensitive information that each must be protected.
To compound this situation further, mobile devices utilized within a corporate environment need to be managed. These devices can be lost or stolen and standard levels of security for functions like access or data wiping are needed. These requirements are typically met by using a Mobile Device Management (MDM) solution which interfaces with APIs provided by the device manufacturer and/or the Operating System (OS) vendor. If a MDM solution is not an integrated element of the mobile application server the communication between the MDM server and the device will be via a separate data path.
This results in four areas of a mobile infrastructure that need to be secured to provide a complete solution; 1) data at rest, 2) application data, 3) email data, and 4) MDM data.
Research In Motion (RIM) began providing smart mobile devices many years ago, extending enterprise email and contact databases to mobile devices. The RIM BlackBerry line of devices incorporates high level security and utilizes a proprietary architecture to support this security. RIM has achieved FIPS 140-2 certification for many of their devices, making them the defacto device for the markets that require this certification.
RIM provides security for all four of the mobile data areas but is currently limited to only the RIM family of devices. This security is provided by the BlackBerry Enterprise Server and via routing all device communication through the RIM Network Operating Center (NOC).
However, with the explosion of consumer smart devices RIM has been faced with multiple competitors and unfortunately has lost their position as the leading provider of these devices. Many would say that RIM missed the market and is now faced with possible exclusion, even though they still provide the most secure devices within the market.
There are other companies that provide FIPS 140-2 certified solutions in the market as well. Two of these are Good Technology and Protected Mobility.
Protected Mobility provides a patent-pending technology to protect mobile applications with end-to-end security. This is provided by their product called “Protected Mobility” which is a set of encryption libraries, key management and an Application Program Interface (API) suite that provide cross-OS platform solution. This set of libraries is used by developers to add these security capabilities to their solutions on a custom development basis.
Good Technology’s primary product, Good for Enterprise, is a secure e-mail, mobile device management, and Intranet-Internet proxy server solution. It includes three main components: Good Mobile Control, for device management and security, Good Mobile Messaging, for secure email and PIM access, and Good Mobile Access for secure mobile access to enterprise networks and applications. They add S/MIME messaging and Common Access Card support to support additional requirements for government.
Good separates work data from personal data in a secure encrypted container. Their solution leverages FIPS-certified cryptographic libraries to encrypt both data over-the-air and at rest on the device.
Good Technology provides MDM capabilities that leverage the same transports as their container but to accomplish the MDM functions the MDM data path has to extend beyond the container to interface with the OS APIs which provide the device level MDM functionality. This violates the FIPS 140-2 standard resulting in an MDM solution that does meet the security standard. As the APIs are provided by the device manufacturer or OS vendor this is a situation that cannot be overcome with a container approach as it must be addressed by securing the OS level.
An important point, regarding Good Technology’s FIPS 140-2 capabilities, is that this security is provided by installing an application on the device and routing the communication traffic through Good’s NOC. The application, typically referred to as a container, provides the needed encryption only within the container. This means that the native capabilities of the device must either be duplicated within the container or not used. While positioning this as a separation of the business space and personal space this is not a segmented OS architecture. The user experience is different between the capabilities provided by the container and those provided by the native operating system. The native integrated capabilities, which are why many users purchased their devices, are not available within the container.
In addition to the differences in user experience there is a question of the level of security a secured application can provide on a mobile device. The security keys for encryption have to be stored on the device and this makes them vulnerable to attack since the device is not secured at the same level as the container. If the device is ‘jail broken’ the keys may be accessed effectively overcoming the security on the device. While not a simple effort it is not that difficult for an experienced hacker, or agent that is after sensitive government information.
As the device manufacturers achieve FIPS 140-2 certification for their devices the competitive capabilities of this approach will become limited. Users expect the native capabilities of the phone to be integrated within mobile applications. Device manufacturers and the OS vendors are also addressing the issue of separation of business and personal data as well. It will be a matter of time before these capabilities are standard offerings within the mobile market. Many Mobile Enterprise Application Platforms (MEAPs) are supporting Hybrid Containers which leverage cross platform languages (HTLM5) and device APIs to utilize native device capabilities.
Why do we need device manufacturers to help resolve this issue?
Mobile applications can exist within a container maintained in memory on the mobile device. This container can be encrypted providing additional security above the security capabilities of the device. But this limits the ability to provide the user experience mobile device users have come to expect. To provide the native experience, many users purchased their devices for, it is necessary for applications to interface or exchange data with other applications, both native and purchased. In a container paradigm applications can only interact with other applications within the container and with device functionality controlled within the container.
Mobile application development began with applications developed on development tools that were specific to a device family or OS. As more devices and different OSes appeared on the market the conundrum of developing the same application for different devices and different OSes and OS versions became evident. To address this issue developers began looking to HTML5 as a standard that would allow them to develop a single application that would function across multiple devices and OSes. However, HTML5 does not allow the developer to leverage the native capabilities of the specific device. While effective this also proved to be limiting.
The concept of a Hybrid Container was quickly adopted. This is a HTML5 based container that leverages device APIs to integrate native device capabilities into the application. It appears that the HTML5 standard may be expanded to support the device APIs directly removing the need for the Hybrid Container and allowing developers to leverage the device capabilities without the use of a container.
What we see is that the device side of mobile application development is quickly becoming unified around HTML5 as a standard that will also allow leveraging native device capabilities. This is sure to include data exchange with other applications on the device.
With these changes it is desired to have the device certified for FIPS 140-2 rather than having an application on the device provide the security. As software level encryption can only reach a level 1 certification, devices can achieve the higher levels because hardware level tamper resistance can be included. Having the device encrypted eliminates any ability to overcome security controls outside of an encrypted container or an attack on the container itself.
With device certification developers are no longer constrained by a container’s capabilities. Instead they can take advantage of advances in mobile development tools to build complex applications, understanding that the data they leverage will be secure on the device even if they exchange the data with native applications.
As smart devices have proliferated in the consumer market employees have begun to ask why they have to carry multiple devices. Why they can’t use their preferred personal device to gain access to the corporate environment. This has presented the enterprise world with a basic problem of how do you separate personal information and data from corporate data and information.
Today, mobile devices offer a single OS and data space. Many vendors are working to develop segmented data spaces and even dual operating systems for mobile devices. Once these solutions become available enterprises will be able to define a data space, fully under their control, that is separate from the personal data. Until that happens, the devices are unable to separate the data sets, unless a container approach is utilized. We discussed the limitations of the container approach earlier. Even with the container approach, MDM functions like ‘wipe device’ become either become limited to ‘wipe container space’ or are forced to wipe personal data along with company data.
Generating separate data spaces or having dual operating systems and data spaces, have the same concerns regarding FIPS 140-2 certification as single OS devices. The resolution of this issue, beyond what a container approach can provide, falls on the device manufacturers or OS vendors. FIPS 140-2 level security needs to be built into the device at the hardware and OS levels to minimize zero day attacks against these new solutions.
SAP and FIPS 140-2
SAP provides multiple mobile solutions for our enterprise customers. These solutions include mobile enterprise analytics, mobile enterprise application platform, and mobile device management. The roadmap for these solutions bring them together into a single integrated environment, focused around delivering and maintaining enterprise level mobile solutions. SAP’s vision for enterprise mobile is to provide a fully integrated application environment that is an extension of the enterprise systems.
Security is a core component of these solutions. Until recently the main demand for secure mobile solutions was to extend enterprise email to mobile devices. With the release of the iPhone and iPad devices demand for expanded enterprise applications began. Android based devices further increased the demand and the complexity of providing secure mobile devices grew exponentially as there is no single Android OS across all devices.
SAP has responded to this demand by working with device manufacturers to insure our mobile solutions support newly released management and security capabilities. We have even worked directly with device manufacturers, like Samsung, to extend the standard security capabilities of the Android OS.
Recognizing the need for FIPS 140-2 certified solutions, SAP has been closely following the device manufacturer’s efforts to certify devices and is working with them to define requirements for an end-to-end FIPS 140-2 certified solution. These efforts depend on the release of certified devices utilizing certified transports and that provide secure paths for email communication, MDM controls and application data.