Monday Mar 30, 2015

Improving the Speed of Product Evaluations

Hi there Oracle Security blog readers; Josh Brickman here again. Today I want to share some of our thoughts about Common Criteria (CC) evaluations specifically those under the US Scheme of the CC run by the National Information Assurance Partnership (NIAP). NIAP is one of the leaders behind the significant evolution of the Common Criteria, resulting in ratification of a new Common Criteria Recognition Arrangement last year.

Background

In 2009, NIAP advocated for a radical change in the CC by creating Protection Profiles quickly for many technology types. As described by NIAP[i]:

In this new paradigm, NIAP will only accept products into evaluation claiming exact compliance to a NIAP-approved Protection Profile. These NIAP-approved Protection Profiles (PP) produce evaluation results that are achievable, repeatable, and testable – allowing for more a more consistent and rapid evaluation process.[ii]

Using this approach, assurance activities are tailored to technologies and eliminate the need for evaluation assurance levels (pre-cast assurance activities that were generically used for most CC evaluations also known as EAL’s). Another key element is the goal of eliminating variables such as lab experience and a subjective evaluator influencing the results. As a result, these changes help make evaluations less “gameable” – a great idea. Even better – with the new approach, instead of requiring confidential internal documentation and sometimes limited amounts of source code, the labs will now only evaluate what is available to any customer---the finished product and its documentation. New Protection Profiles describe assurance testing activities; in theory, a vendor could take the same product and documentation to different labs and receive consistent results.

One other objective of NIAP’s vision of a revitalized CC is based on the goal of 90 day evaluations. Under the new paradigm, evaluations should take less than six months (their current time limit) – and after labs and vendors develop experience with the new process, ideally complete them in three months. For vendors, this is a terrific development as it maximizes the amount of time an evaluated product can remain on the market before a new version is released. Customers also benefit greatly from this change - if a product can be certified quickly, a greater number of new products will be available for procurement by customers who require products to be CC-evaluated before acquisition. Using the old system, a product often was outdated – replaced by a new version with new functionality - by the time it finished an evaluation.

There is a lot to like with these developments – vendors benefit from a consistent and timely process, customers benefit from greater choice in evaluated products, and labs stand to benefit as more vendors send more products for evaluation using resources that are scalable.

Entropy Evaluation

Unfortunately, there are a few bumps along this road to assurance nirvana. As security researchers have known for some time, sources of entropy are critical for encryption as they help ensure random number generation is suitably random. As such, NIAP introduced requirements for entropy assessments for every product going through an evaluation.[iii] Not a bad idea on the surface, however, in the commercial marketplace the mix of technologies, intellectual property (IP), and approaches to development mean it is hard to evaluate entropy (to ensure it is following good practices) without reviewing confidential design documents and—potentially—source code. As noted in Atsec’s insightful blog from September 2013:

The TOE Security Assurance Requirements specified in Table 2 of the NDPP[iv] is (roughly) equivalent to Evaluation Assurance Level 1 (EAL1)[v] per CC Part 3. […] The NDPP does not require design documentation of the TOE itself; nevertheless its Annex D does require design documentation of the entropy source--which is often provided by the underlying Operating System (OS). Suppose that a TOE runs on Windows, Linux, AIX and Solaris and so on, some of which may utilize cryptographic acceleration hardware (e.g., Intel processors supporting RDRAND instruction). In order to claim NDPP compliance and succeed in the CC evaluation, the vendor is obligated to provide the design documentation of the entropy source from all those various Operating Systems and/or hardware accelerators. This is not only a daunting task, but also mission impossible because the design of some entropy sources are proprietary to some OS or hardware vendors.

At first NIAP stated that Entropy Assessment Reports (EARs) would be OK to submit in draft form in order for an evaluation to start. But NIAP found that finalizing the EAR was taking weeks and months because often the expertise—or documentation—did not exist in the vendor’s development organization. Vendors also found that NIAP did not trust the labs to evaluate the EAR’s and decided to insert their own experts from the Information Assurance Directorate (IAD) into the process. In practice this means that the EAR must be evaluated by IAD before it can be approved; no other evaluation element in the NIAP scheme requires this oversight except that of entropy. More problematic, some disclosure of the entropy source code and design documentation for entropy generation is now required by NIAP. As I noted above, some vendors may have no trouble providing this extra information to complete an entropy assessment, however, if your product relies on an external or third-party entropy source, you may be unable to provide the material (even if you are willing, your source may not wish to cough up their IP).

Speeding Up, or Slowing Down?

NIAP has a six month evaluation time limit with a public goal of 90 days for an evaluation. An evaluation involves a vendor providing evidence and a 3rd party lab evaluating it against certain criteria (in this case the Common Criteria). On the one hand, we have a new Protection Profile paradigm that streamlines evaluations and removes requirements for source code and confidential data provided. However, with the introduction of Entropy Assessment Reports (EAR), vendors are increasingly unable to complete an evaluation within the 90-day window. NIAP’s solution is to evaluate an EAR BEFORE a CC evaluation can start. We see this happening now within the NIAP scheme and in other schemes trying to evaluate against NIAP PP’s. There are good reasons why NIAP is so concerned with entropy, yet we need to examine how best to meet these requirements in the context of the current IT ecosystem. As Atsec noted in the same blog:

In theory, a thorough analysis on the entropy source coupled with some statistical tests on the raw data is absolutely necessary to gain some assurance of the entropy that plays such a vital role in supporting security functionality of IT products…..However, the requirements of entropy analysis stated above impose an enormous burden on the vendors as well as the labs to an extent that they are out of balance (in regard to effort expended) compared to other requirements; or in some cases, it may not be possible to meet the requirements.

So how do we meet this need for entropy assessment and align it with market realities? Certainly we should talk about how to best leverage previous entropy assessments for products that rely on external sources to speed evaluations and address IP protection depending on who "owns” the entropy. A more immediate next step is to move entropy evaluation into the traditional Evaluation phase of the project. This may impact an evaluation’s timeline, but it will allow everyone to work off the same clock. Just let vendors into evaluation[vi] that have a Security Target compliant to a NIAP PP without a completed EAR. If a final EAR is not provided, they cannot complete the evaluation. Why is this simple change important for vendors? Because customers can procure products if they are on the “In Evaluation” list. Because evaluations will be time bound and since NIAP already does a good job making sure companies don’t just put up products they don’t intend to evaluate, this is a good way for buyers to start the long process of acquiring the enterprise technology they need. Buyers can always put into contracts requirements that the products complete CC evaluations with the appropriate consequences if they don’t. Vendors will be incented to finish the evaluations by the very customers who are demanding them in the first place.

Finally once we move the EAR to be completed after the product has started the evaluation, let’s do some measuring for a while. Once we have a sense of how long these evaluations really take we can reset expectations.



[i] https://www.niap-ccevs.org/Documents_and_Guidance/ccevs/scheme-pub-1.pdf, National Information Assurance Partnership/Common Criteria Evaluation and Validation Scheme, Publication #1, February 2014.

[ii] Ibid, page 1

[iv] The NDPP is the Network Device Protection Profile the 1st PP written by NIAP under the new style.

[v] EAL1 is the lowest level of assurance and doesn’t require any confidential info from vendors

[vi] The In Evaluation List allows buyers to purchase products that require CC evaluations before the certificate is awarded. In order to get on the In Evaluation list, a Security Target must be evaluated by the lab. Current rules also require a final EAR.

Thursday Mar 05, 2015

Oracle Java Card Platform Implementation Completes EAL5+ Common Criteria Evaluation

Oracle is pleased to announce that the Oracle Java Card Platform Implementation for Infineon on SLE 78  has achieved a Common Criteria certification at Evaluation Assurance Level (EAL) 5 augmented by AVA_VAN.5 “Advanced methodical vulnerability analysis” and ALC_DVS.2 “Sufficiency of security measures” under the German Certification Body (BSI).  EAL5+ is the recognized standard security requirement for smart card hardware and software, and is mutually recognized by 10 European countries under the current SOG-IS agreement. 

The Java Card Platform Implementation for Infineon on SLE 78 is conformant to the Java Card Protection Profile Open Configuration Version 3.0.

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’s Java Card technology provides a secure environment for applications that run on smart cards and other devices with very limited memory and processing capabilities. Multiple applications can be deployed on a single card, and new ones can be added to it even after it has been issued to the end user. Java Card is the established standard for the secure application platform for smart cards, deployed in over 10 billion SIM cards, payment cards and identity cards around the globe by the Java Card eco-system serving the needs of consumers, employees and citizens.

The Java Card Platform Implementation for Infineon on SLE 78 Certification Report and Security Target can be viewed on the Bundesamt für Sicherheit in der Informationstechnik (BSI) 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).

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
« March 2015
SunMonTueWedThuFriSat
1
2
3
4
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
31
    
       
Today