Tuesday Jan 13, 2015

Oracle Acme Packet 3820 and 4500 Session Border Controllers Achieve FIPS 140-2 Level 2 Validations

Oracle is pleased to announce that the Acme Packet 3820 and Acme Packet 4500 Session Border Controllers (Firmware version:  c6.3 and Hardware Part Number: A1) have each achieved a FIPS 140-2 validation with overall compliance at Level 2 of the FIPS standard. Conformance with the FIPS 140-2 standard provides assurance to government and industry purchasers that products are correctly implementing cryptographic functions as the FIPS 140-2 standard specifies.

FIPS 140-2 is a mandatory public sector procurement requirement in both the United States and Canada for any product claiming or providing encryption.

The FIPS 140-2 program is jointly administered by the US and Canada. In the US, the program is administered by NIST (National Institute of Standards and Technology) through the CMVP (Cryptographic Module Validation Program). In Canada, the program is administered by the Communications Security Establishment of the Government of Canada (CSEC).

The Acme Packet 3820 and Acme Packet 4500 are one rack unit (1U) platforms that feature Oracle’s purpose-built hardware design tightly integrated with Acme Packet OS, to provide the critical controls for delivering trusted, real-time communications—voice, video, and application data sessions—across Internet Protocol (IP) network borders.

These platforms support a full range of product configurations including Network Interface Units (NIUs) and Secure Services Modules (SSMs) that accelerate compute-intensive tasks, such as encryption and transcoding. They also feature carrier-class high availability (HA) and Network Equipment Building Systems (NEBS) certification to ensure nonstop operation and survivability in the most business-critical services and applications.

The Acme Packet 3820 and Acme Packet 4500 support the Oracle Communications Session Border Controller software that integrates controls for real-time communications signaling and media.

The Acme Packet 3820 (Firmware Version: c6.3 and Hardware Part Number: A1) was awarded certificate #2312, while the Acme Packet 4500 (Firmware Version: c6.3 and Hardware Part Number: A1) was awarded certificate #2313. Both certificates and their accompanying public Security Policies can be viewed on the CMVP website .

For more information on Oracle’s participation in the FIPS 140-2 validation program, please visit the main FIPS 140-2 information page . For a complete list of Oracle products with FIPS 140-2 validations and Common Criteria certifications, please see the Security Evaluations website .

Thursday Oct 23, 2014

Oracle StorageTek T10000D Tape Drive achieves FIPS 140-2 Validation

Oracle is pleased to announce that the Oracle StorageTek T10000D Tape Drive (Firmware version:  4.07.107 and Hardware Part Number: 7042136) has achieved a FIPS 140-2 validation with overall compliance at Level 1 of the FIPS standard. Conformance with the FIPS 140-2 standard provides assurance to government and industry purchasers that products are correctly implementing cryptographic functions as the FIPS 140-2 standard specifies.

FIPS 140-2 is a public sector procurement requirement in both the United States and Canada for any product claiming or providing encryption.

The FIPS 140-2 program is jointly administered by the US and Canada. In the US, the program is administered by NIST (National Institute of Standards and Technology) through the CMVP (Cryptographic Module Validation Program). In Canada, the program is administered by the Communications Security Establishment of the Government of Canada (CSEC).

The Oracle StorageTek T10000D Tape Drive blends the highest capacity, performance, reliability, and data security to support demanding 24/7 data center operations. Designed for maximum performance, the drive allows the use of multiple keys per tape with a cache memory to minimize the overhead of key transmission

The StorageTek T10000D Tape Drive (Firmware Version: 4.07.107 and Hardware Part Number: 7042136) was awarded certificate #2254. The certificate and accompanying public Security Policy can be viewed on the CMVP website .

For more information on Oracle’s participation in the FIPS 140-2 validation program, please visit the main FIPS 140-2 information page . For a complete list of Oracle products with FIPS 140-2 validations and Common Criteria certifications, please see the Security Evaluations website .

Wednesday May 28, 2014

Oracle Sun Solaris 11.1 Completes EAL4+ Common Criteria Evaluation

Oracle is pleased to announce that the Oracle Solaris 11.1 operating system has achieved a Common Criteria certification at Evaluation Assurance Level (EAL) 4 augmented by Flaw Remediation under the Canadian Communications Security Establishment’s (CSEC) Canadian Common Criteria  Scheme (CCCS).  EAL4 is the highest level achievable for commercial software, and is the highest level mutually recognized by 26 countries under the current Common Criteria Recognition Arrangement (CCRA). 

Oracle Solaris 11.1 is conformant to the BSI Operating System Protection Profile v2.0 with the following four extended packages. (1) Advanced Management, (2) Extended Identification and Authentication, (3) Labeled Security, and (4) Virtualization.

Common Criteria is an international framework (ISO/IEC 15408) which defines a common approach for evaluating security features and capabilities of Information Technology security products.

A certified product is one that a recognized Certification Body asserts as having been evaluated by a qualified, accredited, and independent evaluation laboratory competent in the field of IT security evaluation to the requirements of the Common Criteria and Common Methodology for Information Technology Security Evaluation.

Oracle Solaris is the industry’s most widely deployed UNIXtm operating system, delivers mission critical cloud infrastructure with built-in virtualization, simplified software lifecycle management, cloud scale data management, and advanced protection for public, private, and hybrid cloud environments. It provides a suite of technologies and applications that create an operating system with optimal performance. Oracle Solaris 11.1 includes key technologies such as Trusted Extensions, the Oracle Solaris Cryptographic Framework, Zones, the ZFS File System, Image Packaging System (IPS), and multiple boot environments.

The Oracle Solaris 11.1 Certification Report and Security Target can be viewed on the Communications Security Establishment Canada (CSEC) site and on the Common Criteria Portal.

For more information on Oracle’s participation in the Common Criteria program, please visit the main Common Criteria information page here:

(http://www.oracle.com/technetwork/topics/security/oracle-common-criteria-095703.html)

For a complete list of Oracle products with Common Criteria certifications and FIPS 140-2 validations, please see the Security Evaluations website here:

(http://www.oracle.com/technetwork/topics/security/security-evaluations-099357.html).

Monday Apr 07, 2014

Oracle StorageTek Tape Drive Achieves FIPS 140-2 Validation

Oracle is pleased to announce that the Oracle StorageTek T10000C Tape Drive (Firmware version:  1.57.308 and Hardware Part Number: 7054185) has achieved a FIPS 140-2 validation with overall compliance at Level 1 of the standard. Conformance with the FIPS 140-2 standard provides assurance to government and industry purchasers that products are correctly implementing cryptographic functions as the FIPS 140-2 standard specifies.

FIPS 140-2 is a public sector procurement requirement in both the United States and Canada for any product claiming or providing encryption.

The FIPS 140-2 program is jointly administered by the US and Canada.  In the US, the program is administered by NIST (National Institute of Standards and Technology) through the CMVP (Cryptographic Module Validation Program). In Canada, the program is administered by the Communications Security Establishment of the Government of Canada (CSEC).

The Oracle StorageTek T10000C Tape Drive (Firmware Version:  1.57.308 and Hardware Part Number: 7054185) delivers the world’s fastest write speeds to a native 5 TB of magnetic tape storage making it ideal for data center operations with growing volumes. The Tape Drive blends the highest capacity, performance, reliability, and data security to support demanding 24/7 data center operations. The StorageTek T10000C Tape Drive (Firmware Version: 1.57.308 and Hardware Part Number: 7054185) was awarded certificate #2086. The certificate and accompanying public Security Policy can be viewed on the CMVP website here: (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm).

For more information on Oracle’s participation in the FIPS 140-2 validation program, please visit the main FIPS 140-2 information page here (http://www.oracle.com/technetwork/topics/security/oracle-fips140-validations-100923.html). For a complete list of Oracle products with FIPS 140-2 validations and Common Criteria certifications, please see the Security Evaluations website here: (http://www.oracle.com/technetwork/topics/security/security-evaluations-099357.html).

Friday Mar 07, 2014

Oracle announces FIPS 140-2 Validations for Solaris Cryptographic Framework

Oracle is pleased to announce that the Oracle Solaris Cryptographic Framework has achieved a FIPS 140-2 validation with overall compliance at Level 1 of the standard.   Conformance with the FIPS 140-2 standard provides assurance to government and industry purchasers that products are correctly implementing cryptographic functions as the FIPS 140-2 standard specifies.

FIPS 140-2 is a public sector procurement requirement in both the United States and Canada for any products claiming or providing encryption.

The FIPS 140-2 program is jointly administered by the US and Canada. In the US, the program is administered by NIST (National Institute of Standards and Technology) through the CMVP (Cryptographic Module Validation Program). In Canada, the program is administered by the Communications Security Establishment of the Government of Canada (CSEC).

The Oracle Solaris Cryptographic Framework provides basic cryptographic algorithms and services to the Solaris Operating System and application consumers. The framework is available for both kernel and user-level consumers. The Kernel Cryptographic Framework was awarded certificate #2061 for Intel and SPARC64 processors and certificate #2060 for SPARC T4 and T5 processors. The Userland Cryptographic Framework was awarded certificate #2077 for Intel and SPARC64 processors and certificate #2076 for SPARC T4 and T5 processors. The certificates, and accompanying public Security Policy, can be viewed on the CMVP website here.

For more information on Oracle’s participation in the FIPS 140-2 validation program, please visit the main FIPS 140-2 information page. For a complete list of Oracle products with FIPS 140-2 validations and Common Criteria certifications, please see the Security Evaluations website:

 ( http://www.oracle.com/technetwork/topics/security/security-evaluations-099357.html ).

Monday Feb 03, 2014

FIPS-- the Crypto “Catch 22”

Hello Oracle blog reader! My name is Joshua Brickman and I run Oracle’s Security Evaluations team (SECEVAL). At SECEVAL we are charged with shepherding certain Oracle products through security certifications and accreditations, mostly for government use. Today in my initial blog I’d like to talk to you about cryptography[*] (or crypto) as it relates to these government certifications.

First a little history; crypto actually goes back to classical Rome. The “Caesar Cipher” was used by the Roman military to pass messages during a battle. In World War II, Germany was very successful encrypting messages utilizing a machine known as “Enigma.” But when Enigma’s secret codes were famously broken (due mostly to procedural errors) it helped to turn the tide of the war. The main idea of crypto hasn’t changed though: only allow intended recipients to understand a given message—to everyone else it’s unintelligible. [†]

Today’s crypto is created by complex computer modules utilizing “algorithms.” The funny thing about crypto is someone is always trying to break it-- but usually using computers (also running complex programs). One of the U.S. government’s approaches to combatting code breaking has been via the Federal Information Processing Standard (FIPS) program maintained by the National Institute of Standards and Technology (NIST). NIST uses FIPS to publish approved algorithms that software needs to correctly implement in order to claim their products meet the FIPS standard. The FIPS standard defines acceptable algorithms; vendors implement their crypto to meet them.

So why would technology vendors need to comply with this standard? Well FIPS “140-2” defines the acceptable algorithms and modules that can be procured by the US government. In fact NIST keeps a list of approved modules (implementations of algorithms) on their website. To get on this list of approved modules, vendors like Oracle must get their modules and algorithms validated. Unfortunately for many technology providers there isn’t any alternative to FIPS 140-2 (version 2 of the current approved release). [‡] FIPS 140-2 is required by U.S. government law[§] if a vendor wants to do business with the government. The validation process is an expensive and time-consuming process. Vendors must hire a 3rd party lab to do the validation; most also hire consultants to write documentation that is required as a part of the process. The validation process for FIPS 140-2 requires that vendors prove they have implemented their crypto correctly against the approved algorithms. This proof is accomplished via these labs that validate each module is correctly implementing the selected algorithms.

FIPS 140-2 has also been adopted by banks and other financial services. If you think about it, this makes a lot of sense: there is nothing more sensitive than financial data and banks want assurances that the crypto they depend on to protect it is as trusted as the safes that protect the cash. Interestingly, smart-card manufacturers also require FIPS: this is not a government mandate, but rather a financial industry requirement to minimize their fraud rates (by making the cost for criminals to break the crypto in smart cards too high for them to bother). Finally the Canadian government partners with NIST on the FIPS 140-2 program known as the Cryptographic Module Validation Program (CMVP) and mirrors U.S. procurement requirements.

All of this would be the cost of doing business with the US (and Canadian) governments except that there are a couple of elements that are broken.

  1. Government customers who buy crypto technology require a FIPS 140-2 certificate of validation (not a letter from a lab or being on a list of “under validation”). In our experience, a reasonable timeframe for a validation is a few months. Unfortunately, after all of the work is completed, the final “reports” (which lead to the certificates) go into a black hole otherwise known as the “In Review" status. This is when the vendor, lab (and consultant) have done as much work as possible but are now waiting for both the Canadian and US governments to review the case for validation. The queue (as I write this blog) has been as long as nine months over the last couple of years. An Oracle example was the Sun Crypto Accelerator (SCA) 6000 product. On January 14, 2013 our lab submitted the final FIPS 140-2 report for the SCA6000 to NIST. Seven months later, we heard back our first feedback on our case for validation. We finally received our certificate on September 11, 2013. NIST is quite aware of the delays[**]; they are considering several options including but not limited to increasing fees to pay for additional contractors, pushing more work to labs and/or revising their review process--but they haven’t announced any changes that might resolve the issue other than minor fee increases. From our point of view, it’s really difficult to justify the significant investments required for these validations when you can’t predict their completion. If you think about the shelf life of technology these days, a delay of say a year in a two year “life-span” of a product reduces the value to the customer by 50%. As a vendor we have no control over that delay, and unless customers are willing to buy invalidated products (and they can’t by law in the U.S.) they are forced to use older products that may be missing key new features.
  2. NIST also refers to outdated requirements[††] under the Common Criteria. The FIPS 140-2 Standard references Common Criteria Evaluation Assurance Level (EAL) directly when discussing eligibility for the various FIPS levels[‡‡]. However, due to current policies with the U.S. Scheme of the Common Criteria (National Information Assurance Partnership or NIAP), it is no longer possible to be evaluated at EAL3 or higher. This prevents any vendor from obtaining a FIPS 140-2 validation (of any software or firmware cryptographic module) at any level higher than Level 1. One example of an Oracle product that we would have validated higher than Level 1 is the Solaris Cryptographic Framework (SCF). Originally coded to be validated at FIPS Level 2, Oracle SCF was forced to drop its validation claim down to Level 1. This was because NIST’s Implementation Guidance for FIPS 140-2 required that the Operating Systems be evaluated against a deprecated Common Criteria Protection Profile if vendors of crypto modules running on those OSs wanted the modules to be validated at Level 2. Unfortunately an older version of Solaris was Common Criteria evaluated against that deprecated Operating System Protection Profile. The version of SCF that we needed FIPS 140-2 validated didn’t run on that old version of Solaris. Oracle had market demands that required a timely completion of its FIPS validation so a business decision was made to lower the bar. We’ve pointed out this contradiction (as I’m sure have other vendors) but at this writing the problem is still not resolved by NIST.

Oracle is committed to working with NIAP and NIST to make both Common Criteria and FIPS 140-2 as broadly accepted as possible. U.S. and Canadian government customers want to buy products that meet the high standards defined by FIPS 140-2, and that many other security-conscious customers recognize. Along with many other vendors of crypto modules in our products, Oracle is very keen to see NIST’s queue of work brought down to a level that would allow the longest shelf life for our validations. We also would like to see NIST and NIAP work together to align their policies and interpretations of standards to provide greater selection of strong cryptography. These current obstacles are providing a reduced choice of FIPS 140-2 validated products. If removed, there will be a larger number of FIPS 140-2 validated crypto modules available for purchase. Increasing choice of validated products for the US and Canadian governments can only contribute to improved national security.



[*] According to Webopedia, “Cryptography is the art of protecting information by transforming it (encrypting it) into an unreadable format, called cipher text. Only those who possess a secret key can decipher (or decrypt) the message into plain text. Encrypted messages can sometimes be broken by cryptanalysis, also called code breaking, although modern cryptography techniques are virtually unbreakable.”

[†] “FIPS 140 Demystified, An Introductory Guide for Developers,” by Wesley Higaki and Ray Potter, ISBN-13: 978-1460990391, 2011.

[‡] FIPS 140-3 has been in draft form for many years. NIST has been pulling key elements of the new standard and adding them to FIPS 140-2 as “Implementation Guidance.”

[§] . “Federal Information Processing Standards (FIPS) are approved by the Secretary of Commerce and issued by NIST in accordance with the Federal Information Security Management Act of 2002 (FISMA). FIPS are compulsory and binding for federal agencies. FISMA requires that federal agencies comply with these standards, and therefore, agencies may not waive their use.”

[**] As noted in the summary of the recent 1st FIPS Conference, “…The current length of The Queue means that it can take developers many months to get their modules validated and hence available for procurement from federal agencies. In an increasing number of cases, products are obsolete or un-supported by the time the validation is finally documented. We heard how the unpredictability of The Queue is a problem too, since it greatly affects how developers can perform their marketing, sales and project planning.

[††] For example, http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf

“Security Level 3 allows the software and firmware components of a cryptographic module to be executed on a general purpose computing system using an operating system that meets the functional requirements specified in the PPs listed in Annex B with the additional functional requirement of a Trusted Path (FTP_TRP.1) and is evaluated at the CC evaluation assurance level EAL3 (or higher).”

[‡‡] There are four levels of FIPS, at level “1” all components must be “production grade” and level 2 adds requirements for physical tamper-evidence and role-based authentication. Levels 3 and 4 are typically for hardware.-- http://en.wikipedia.org/wiki/FIPS_140

About

This blog will focus on mostly government certifications, validations and accreditation programs.

Search

Categories
Archives
« February 2015
SunMonTueWedThuFriSat
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
       
       
Today