ICMC: ISO/IEC 19790 Status and Supporting Documents

Presented by Randall Easter, NIST; and Miguel Bagnon, Epoche & Espri.

Mr. Bagnon started out by explaining the structure of ISO, the IEC and SC27 working group.  The ISO standards body looks at  creating market driven standards, getting input from all of the relevant stake holders.  The SC27 focuses on security and privacy opics across 5 working groups.  The SC27 has 48 voting member countries - from Algeria to Uruguay!  There are 19 other observing countries. You can see a very wide representation of continents, countries, cultures and languages.

The WG3 Mission is security evaluations, testing and specification. This covers how to apply the criteria, testing criteria, and administrative procedures in this area.

The process is open to the world (as you can see), drafts are sent out for review by the public before becoming a final international standard.  Please participate if you can, it's the only way to have your opinion counted.

Mr. Easter then dove into ISO 19790, and the related standards: ISO 24759 (test requirements for cryptographic modules), 18367 (algorithm and security mechanisms conformance testing), 17825 (testing methods for the mitigation of non-invasive attack classes against crypto modules) and 30104 (physical security attacks, mitigation techniques and security requirements).

ISO 19790 was first published in 2006 and it was technically equivalent to FIPS 140-2, plus an additional requirements for mitigation of attacks for Level 4.  This standard has been adopted internationally and is being used around the world.

What Mr. Easter had been hoping would happen was that ISO 19790 and FIPS 140-3 would closely track each other, with ISO 19790 picking up all of the changes from FIPS 140-3.  FIPS 140-3 was so delayed, though, that ISO 19790 began to develop independently.

Mr. Easter noticed that there were no validation labs participating in the ISO standard, so he got permission to circulate the draft amongst the labs and to incorporate their comments, as he's the editor of the document.

This document has been adopted by ANSI as a US standard now as well.

At this time, it is not officially recognized by NIST and the US Government.

This is very frustrating to many vendors and labs, because FIPS 140-2 was published in 2001 and it is quite stale (hence the 170 page Implementation Guidance). Technology is changing, the original language in FIPS 140-2 wasn't clear to all, and there seems to be a way out - if only NIST would adopt it.

Until that happens, vendors are stuck implementing to FIPS 140-2.

How can you change this? Call up your NIST representative or friendly CSEC contact and ask for this.

This post syndicated from: Thoughts on security, beer, theater and biking!

ICMC: Key Management Overview

Presenters: Allen Roginsky and Kim Schaffer, NIST.

Key Establishment Methods

Key Establishment Methods in FIS 140-2 cover key agreement, key transport (including encapsulation and wrapping), key generation, key entry (manual, electronic, unprotected media), and key derivation.

The best method to make sure you do this right is to comply with SP 800-56A (CAVP KAS certificate required).

You can also use SP 800-56B, which is vendor affirmed right now. SP 800-56B is IFC based and key confirmation is highly desirable.

Or, you can use non-approved methods that rely on approved validated algorithm components. The shared secret is still computed per SP 800-56A with a CVL certificate. The kdf (key derivation function) then would be aproved (with a CVL certificate) per SP 800-56B and 80-56C.  There was a new version of SP 800-56A released in May 2013 that should help alleviate some of this convoluted cross referencing, and clarify many questions people have had over the last few years.

OR...you can even use non-approved, but allowed implementations.  That is, if your key strengths are consistent with SP 800-131A transition requirements.

Key Transport Modes

Key transport modes can be confusing as well.  Key encapsulation is where keying material is encrypted using asymmetric (public key) algorithm.  Key Wrapping, though, is where the keying material is encrypted suing symmetric algorithms. Both commonly provide integrity checks.

Approved methods would be an approved IFC based key encapsulation scheme as in SP 800-56B, key wrapping schemes (AES or 3DES based) as per PS 80038F, AES based authentication encryption m odes permitted in SP 800-38F, or as per SP 800-56A, a DLC-based key agreement scheme together with a key wrapping algorithm.

Any key encapsulation scheme employing an IFC based methodology that uses key lengths specified in SP 800-131A as acceptable or (through 2013) deprecated.   When AES or 3DES are used for wrapping, a CAVP validation of the algorithm is required.

Key Generation Methods

People often mistakenly believe that because they are using a good RNG, that they must be doing the right thing for key generation... not always the case!  You still need to follow SP 800-133 and IG 7.8 (Implementation Guidance).

The vendor needs to identify the method used and account for the resulting length and strength of the generated keys. This is about the generation of a symmetric algorithm key or a seed for generating an asymmetric algorithm key; the the generation of an asymmetric algorithm domain parameters and RSA keys.  See IG 7.8 and the future versioin of SP 800-90A.

You can use SP 800-132 for password-based key generation for storage applications only.

Key Entry

Implementation Guidance (IG) 7.7 provides examples explaining the FIPS 140-2 requirements. Key entry/output via the GPC internal path is generally N/A.  Key establishment over the unprotected media requires protection.  Split knowledge entry for manually distributed keys at Levels 3 and .

Key Derivation

When you're deriving a key - it's coming from something else. If you're deriving from a shared secret (per SP 800-135rev1), that includes the following protocols and their key derivation function are included: IKE (versions 1 and 2) , TLS (1.0->1.2), ANSI X9.42 and X9.63, SSH, SRTP, SNMP and TPM.  You can also drive from other keys, which is covered by  SP 800-108 - which also includes IEEE 802.11i key derivation functions (IG 7.2).



 This post syndicated from: Thoughts on security, beer, theater and biking!

ICMC: The Upcoming Transition to New Algorithms and Key Sizes

Presented by Allen Roginsky, Kim Schaffer, NIST.

There are major things we need to be concerned about – we need to move from old, less secure algorithms to the new ones. This includes the transition to 112-bit strong crypto and closing certain loopholes in old standards

The algorithms will fall into the following classes:

• Acceptable (no known risks of use)
• Deprecated (you can use it, but you are accepting risk by doing so)
• This is a temporary state
• Restricted (deprecated and some additional restrictions apply) 
• Legacy-Use (may only be usd to process already-protected information) 
• Disallowed (may not be used at all)

And of course, these classifications can change at any time. As you all know, the crypto algorithm arena is ever changing.  I asked a question about the distinction between Legacy-Use and disallowed.  It seems to me that you might find some old data laying around that you’ll need to decrypt at a later date.  Mr. Roginsky noted that they didn’t really cover this when they did the DES transition, and you might be okay because decrypting is not really “protecting” data.

When we get to January 1, 2014, 112-bit strength is required.  Two-key 3DES is restricted through 2015. Digital signatures are deprecated though 2013 if they aren’t strong enough.   This is an example where you could continue to use them for verification under “Legacy-Use” when we reach 2014.

Non SP-800-90A RNGs are disallowed for use after 2015 – you won’t even be able to submit a test report after December 31, 2013 if you don’t have an SP-800-90A RNG.

There is a new document everyone will want to review: SP 800-38 – it explains the use of AES and 2Des for key wrapping.

SHA-224, 256, 384, 512 are all approved for all algorithms. SHA-1 is okay, expect for digital signature generation. There are other changes around MACs and key derivation.

We’ll also be transitioning from FIPS 186-2 to FIPS 186-3/4.  Conformane to 186-2 can be tested through 2013.  Already validated implementations will remain valid, subject to the key strength requirements.  Only certain functions (such as parameter validation, public key validation and signature verification) will be tested for 186-2 compliance after 2013.  What this really means is that some key sizes are gone” after 2013: RSA can only use 2048 and 3072 keys.

Make sure you also read Implementation Guidance (IG) 7.12: RSA signature keys need to be generated as in FIPS 186-3 or X9.31.

The deadlines are coming up – don’t delay!

 This post syndicated from: Thoughts on security, beer, theater and biking!

ICMC: Reuse of Validation of Other Third Party Components in a 140-2 Cryptographic Module

Presented: Jonathan Smith, Senior Cryptographic Equipment Assessment Laboratory (CEAL) Tester, CygnaCom Solutions

What is component in this context?  An algorithm, 140-2 module, third party library, etc - not a hardware device.  There is more interest in this area, as more validations are occurring.  Requirements are not obvious in this area, and there isn't a lot of guidance to follow.

Let's say you want to reuse an algorithm that has its CAVP certificates - if you wan to leverage that validation, you have to make sure you are talking about the same Operational Environment (OS/processor for software) and that there is no change within the algorithm boundary when you embed it within a module.  CAVP boundaries are not as well defined as CMVP, but for all intents and purpose it is the compiled binary executable that contains the algorithm implementation.

When you're reusing someone else's algorithm, you will have a hard time to make sure all of the CMVP self-tests are all being run at the right time. You may not be able to reuse it with out rebuilding it.

Now you may want to use an entire validated module - first make sure you have the correct validated version.  If you can use it completely unchanged, you will have to reference the other module's certificate.  One note, if the embedded module is Level 2, but your code only meets Level 1 criteria - the composite module could not be evaluated higher than Level 1. Now, the inverse is not necessarily true - you might be embedding a Level 1 module, but your different use cases may allow you to get a higher level for the composite module.

To reuse this module, again, you need to have an unchanged operational environment the same as trying to reuse an algorithm.  The new module boundary must include the entire boundary of the included module. You'll need to have a consistent error state - you cannot allow one part of the composite module to enter an error state while the rest of the system continues serving crypto.

Your documentation can quite frequently reference the embedded module's documentation, leaving certain tasks up to the embedded module.  Make sure the new capabilities of the composite module are documented.

A question came up about using multiple vendor's modules together, where they each have their own validation certificate.  Mr. Easter (CMVP) recommended we read Implementation Guidance (IG) 7.7 for detailed advice on this concept.

There was a question about if the embedded module was validated before new IG came out - what then?  As long as the embedded module meets SP800-31A, then the old certificate fully applies and you will not have to bring it up to the new IG.

This post syndicated from: Thoughts on security, beer, theater and biking!

ICMC: FIPS and FUD

Ray Potter, CEO, Safelogic.

Mr. Potter has seen lots of vendors jumping into the FIPS-140 bandwagon when they see another vendor claiming FIPS-140 certification, without understanding what that meant.  That other vendor may have simply gotten an algorithm certificate for just one algorithm, for example.

FIPS-140 is important - it provides a measure of confidence and a measure of trust.  A third party is validating your claims.  FIPS-140 is open and everyone in the world can read the standard and the IG and implement based on these and understand what it means to be validated. Most importantly, FIPS-140 is required by the US Government and desired by other industries (medical/financial/etc).

Having this validation shows that you've correctly implemented your algorithms and you are offering secure algorithms.

See claims like the module has been "designed for compliance to FIPS 140-2", or "it will be submitted" or "a third party has verified this" or "we have an algorithm certificate" or "we have implemented all of the requirements for FIPS-140" - none of these is truly FIPS-140-2 validated.

Once you have a certificate in hand from the CMVP, then you're validated.

But even when the vendor has done the right thing for some products, sales can just get this wrong - too eager to tell the customer that everything is then validated.

So, Mr. Potter has encountered honest mistakes, but he's also seen sales/vendors outright lie about this, because it simply takes too long and is too expensive to do this.  Why do this? Make the sale - hope your in process evaluation completes before the sale.

Issues that exacerbate the situation: unpredictable CMVP queues, new Implementation Guidance (IG) that is sometimes retroactive, and uneven application across the government.  Some government agencies may accept different phases (in validation) - where others require a certificate in hand.

Vendors get frustrated when they are in the queue for months, then get some retroactive IG that requires code changes - they don't see this as worth the effort.

We can help: educate your customers on the value of FIPS-140 validations and what it really means to be validated, only use validated modules and follow strict guidelines for claims.

There are some people that will take another FIPS-140 validated implementation, repackage it and get their own certificate for the same underlying module but with their name as the vendor on the cert.

I asked about why some vendors are doing validations of their crypto consumers, when they've already got a validation for the underlying consumer.  Mr. Potter noted that some people might do this because they need to cover the key management aspects that the consumer is doing that weren't covered in the other evaluation, or that the consumer may actually have some if it's own internal crypto in addition to what they are getting from the underlying module, or that they simply are trying to make a very important customer happy.

This post syndicated from: Thoughts on security, beer, theater and biking!

ICMC: Understanding the FIPS Government Crypto Regulations for 2014

 Presented by Edwards Morris, co-founder Gossamer Security Solutions.

Looking forward to what new regulations are going to mean for older algorithms and the protocols that use them, right away there seems like there may be work for us to do.

Security strength of various algorithms are not straightforward to calculate, as it's based on how it's used and how big the key is, etc.

In May 19, 2005, DES is being sunset, because it has less than 80-bits of security.  Because this sunset applies to the bits of security, DH and RSA with key sizes smaller than 1024-bits are included.

Originally the DES transition gave people two years to migrate to AES or 3DES.

As a part of this, NIST released SP 800-57, which included recommendations for key management.

This was harder than anticipated, due to lack of standards, available 140-2 approved products and the sheer size of deployments - so then NIST 800-131A was born.

NIST 800-131A includes more details on the transitions, terminology and dates.  Some 80-bit crypto will be deprecated in 2013 and others in 2015.

The devil is in the details, of course,  SP 800-131A refers to SP800131B, which is in draft and ultimately because FIPS-140-2 Implementation Guidance.  Digging into all of these requirements, how can you tell if TLS can still be used?

Mr. Morris dug into  various protocols to help us interpret this standard.

IPsec

IPsec is made up of so many RFCs, so getting the big picture is not an easy task. It also has so many possible options.  SP 800-57 Pat 3 details this guidance.  Three IPsec protocols allow a choice of algorithms: IKE (for key exchange), ESP and AH.

You can avoid using IKE by using manual keying (acceptable 2014+, but what a pain to configure/deploy), IKEv1 (unacceptable in 2014) and  IKEv3 (acceptable 2014+, if configured correctly).

For encryption in IPsec, you'll be okay with ENCR_3DES (in CBC mode), ENCR_AES_CBC (CBC mode only), and a few others.  You'll be able to use SHA1 as an HMAC, but not alone for signatures (wow, does this get twisted).

Mr. Morris continued through what would be acceptable for Pseudo-random functions, Integrity, Diffie-Hellman group and Peer Authentication - too quickly for me to type all of those algorithms, but I will try to update this if I can get access to the slide deck.

It's not as simple as which algorithm you use, but again how you use it, which sized keys, etc.

IPsec is well positioned for this - as long as you configure it correctly.

TLS

TLS is not the same things SSL v3.0. TLS is equivalent to SSL v 3.1.  TLS 1.0 is acceptable. SSL, though, is not allowed by CMVP.  Since 1.0 is acceptable, that essentially means that TLS 1.1 and 1.2 are also acceptable, as long it's configured correctly (seeing a theme here?).  For example, if you use pre-shared keys in lieu of certificates, ensure the key is greater or equal to 112 bits.

You won't be able to use the following key exchanges: *_anon, SRP_*, KRB5. (though Mr. Morris hasn't dug through the Kerberos standards, yet, to see where they will be with these 2014 requirements.

SSH

This is not covered by SP 800-57, so this is harder to figure out if it's okay or not. There are problems when the RFCs require things that are no longer considered secure: Single DES are required to be implemented, but by having them available in your implementation - this will be a problem.

Recommendations

Look for documentation and configuration guides that can help there, or get independent evaluations of the software that you're deploying (companies like Gossamer will look at how you're using even opensource software like Apache, OpenSSL, OpenSSH, etc)

This post syndicated from: Thoughts on security, beer, theater and biking!

ICMC: Building a Corporate-Wide Certification Program - Techniques that (might) work

Tammy Green, Security and Certification Architect at Blue Coat, came into what seemed like a simple task. She had had some Common Criteria experience when she joined Blue Coat, their product had previously been evaluated at FIPS-140-2 level 2, and they had already signed contracts with a consulting firm (Corsec) and lab.  Should've been easy, right?  Her new boss said it should take about a year and only 20% of her time.  Two and half full time years later... yikes.

One of the biggest problems was getting internal teams to work with her - even people involved in the previous validations didn't even want to talk to Ms. Green about it.

Nobody wanted to do this - they want to work on the new shiny features that they can sell, how does a process that takes 2 years (often not complete until after a product is EOL) help them?

It's hard to see the long term picture - you want to sell to the government, you need FIPS-140-2 validations.

Ms. Green didn't want to do this herself again afterwards. Instead of running away, she worked on setting up a certification team locally (her boss hiring a program manager helped to encourage it).

In addition to having the program manager, you need a certification architect.  You can't use the same architect as the product architect, because that person is busy designing shiny new features.

You need to work with the development team well in advance - fit your FIPS-140-2/Common Criteria schedule into their development schedule. You can't screw on the necessary tests and requirements as an afterthought, and you don't want to delay a schedule because requirements are dropped in at the end.

Target the right release: because FIPS-140-2 takes so long, you need to pick a release you plan on supporting for a long time.

Ms. Green found that after time... engineers stopped replying to her emails and answering her phone calls.  You need to identify key engineering resources to work with and their management needs to commit to those engineers dedicating 10-20% of their time to these validations.

Once you get this set up and have educated engineering, you'll find they'll reach out to you in advance - better timing!

Her team keeps track of what needs to be done: file bugs and track them.  You'd think the project manager for the product team would do this, but what she's found is that the bugs get reprioritized and reassigned to a future release.  Someone who understands validations needs to track these issues.

Ms. Green recommends that you create the security policy from existing documents: don't rely on engineers doing this. They simply don't understand what goes into this document or why it's important.  Instead, use engineering and QA to validate content.

It's important to convince QA continue to test FIPS mode and related features, as some customers may still want to run in FIPS mode (even though it wasn't validated) or that the release would be ready for validation if something went horribly wrong with the older release in validation.

Schedule time to prep. Ms. Green has 4-8 hour long meetings to make sure everyone understands what's important. Take time to prepare, make sure everyone knows what will be expected from the lab visit and have a test plan formalized in advance.  It's actually a lot of work to set up failures (the lab evaluators require that you demonstrate what happens when  a failure happens, even though you have to inject the failure to force it).  Debug builds, builds you know will fail, multiple test machines, platforms, etc.

To keep your team from killing you... or damaging morale, celebrate the milestones. Mention the progress in every status report, celebrate the milestones, do corporate wide announcements when you finish.

Do a post mortem to understand how this can be improved: give your engineering team a voice! Listen and take action based on what worked and didn't.

Update tools and features to make this easier next time: keywords to bugs and features, modifying product life-cycle, add questions related to FIPS to templates.

Suggestions/questions from the audience:
Make sales your best friend.  Validations/certifications are not fun, nobody does them for fun - you do this to make money.
Get the certification team involved as early as possible: from the very beginning - marketing design meetings.
Why don't you run your FIPS-140 mode tests all the time?  Time consuming, slower, not seen as a priority when there are no plans to validate.


This post syndicated from: Thoughts on security, beer, theater and biking!