D-kriptik Blog

Holiday season is NYC can be a painful time of year, but not for the reasons of which most people think. You see, during the holiday season, any watering holes to which you regularly go will likely throw many a free drink at you. Which leads to a problem – you want to go to all these places and see everyone for the holidays, but you don’t want to end up being carried home. So, now you either turn down those drink gifts from those around you or you end up in a tortuous state the next morning, both of which can hurt.

Which is to say, on this home stretch of the holiday season here in the USA, I wish everyone a happy holidays!

–

A post to the SAAG mailing list of interest to the FIPS 140 readers.

This decade many global financial institutions (e.g. banks, insurance firms, credit unions, and so forth) have said that their commercial (re-)insurers are pressuring them to deploy only FIPS-140 compliant algorithms & modes.

In a growing number of cases, there is even pressure from insurers onto major commercial firms, particularly financial firms, to use only equipment (including ordinary routers and switches, not just “security appliances”) that actually has obtained a FIPS-140 approval for the cryptographic module inside.

Further, a number of governments other than the US government have declared that implementations using cryptographic modules that have been approved under FIPS-140 are also acceptable for deployment within their country or government or both. The number of countries in this group appears to be growing, and seems visibly larger now than 8 years ago.

These are trends that people in the FIPS 140 arena have been talking about for a while, and I know I have seen and been involved with them by virtue of having had a strong window into “the vendor going for FIPS 140 validation” perspective for quite some time now. It is interesting to read someone else’s encounters with these things in a public forum.

So, besides the normal USA government requirements, support of at least a FIPS-approved algorithm suite has become a baseline requirement found almost everywhere now when cryptography is used, and every so often you even see pushes for FIPS 140 validation outside of the USA government. Given that, it is commonplace these days for standards, products, and such utilizing cryptography to include support for a FIPS-approved algorithm suite. Doing so not only brings into use a very commonly deployed, rigorously studied, and well-known set of algorithms, but it also facilitates products implementing those standards, products, and such in being able to go through the FIPS 140 validation process at some point. This makes even more sense since many of the people working on standards, products, and such utilizing cryptography are employed by companies that have to play in the FIPS 140 arena, and so there is often thought given to the FIPS 140 “validatibility” of modules implementing these standards, derived from these products, and such.

With the widespread notoriety of many of the algorithms that get rolled into NIST standards causing tons of eyes to look over these standards very closely, and with things like AES and now the next SHA being derived from open international competitions not to mention modes of operation and such being submitted by the outside world, none of this should come as a surprise.

-

Also of possible interest to FIPS 140 readers, a couple [1, 2] of useful posts on Metzger’s cryptography mailing list on the old topic of how to prevent the compiler from potentially optimizing away your “zeroizing” memset call in C. The sort answer, take advantage of volatile.

An example of how GnuPG does this from [1],

  /* To avoid that a compiler optimizes certain memset calls away, these
     macros may be used instead. */
  #define wipememory2(_ptr,_set,_len) do { \
                volatile char *_vptr=(volatile char *)(_ptr); \
                size_t _vlen=(_len); \
                while(_vlen) { *_vptr=(_set); _vptr++; _vlen--; } \
                    } while(0)
  #define wipememory(_ptr,_len) wipememory2(_ptr,0,_len)

And, [2] points to this 2002 MSDN article on the topic.

-

Finally, random software that has been popping up on some mailing lists I follow.

I remember using Maple quite a bit in college.

SAGE.

Use SAGE for studying a huge range of mathematics, including algebra, calculus, elementary to very advanced number theory, cryptography, numerical computation, commutative algebra, group theory, combinatorics, graph theory, and exact linear algebra.

And, I did lots of Lisp there too.

Clojure.

Clojure is a dynamic programming language that targets the Java Virtual Machine. It is designed to be a general-purpose language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. Clojure is a compiled language – it compiles directly to JVM bytecode, yet remains completely dynamic. Every feature supported by Clojure is supported at runtime. Clojure provides easy access to the Java frameworks, with optional type hints and type inference, to ensure that calls to Java can avoid reflection.

Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs.

Io.

Io is a small, prototype-based programming language. The ideas in Io are mostly inspired by Smalltalk (all values are objects), Self (prototype-based), NewtonScript (differential inheritance), Act1 (actors and futures for concurrency), LISP (code is a runtime inspectable/modifiable tree) and Lua (small, embeddable).

Wow, it’s been 10 years.

Nmap v4.50.

December 13, 2007 — Insecure.Org is pleased to announce the immediate, free availability of the Nmap Security Scanner version 4.50 from http://insecure.org/nmap/. Nmap was first released in 1997, so this release celebrates our 10th anniversary.

So, I will be moving to Bayside, Queens in a couple of weeks. Apparently, I spent part of my younger days around Bayside and Flushing, but I don’t recall either, so it is all new to me. But, the area is nice, Bell Blvd, the LIRR, and Crocheron Park are a couple of blocks away from my place in varying directions, I met what seemed to be all of my new landlord’s immediate family when accepting the place and they were a friendly, outgoing bunch, and the people in the neighborhood were very friendly. Overall, I am excited about moving into this little box in Queens.

That said, now I will not only be busy with work, but also with getting the apartment ready and then moving. So, posting here will probably suffer even more than it has.

Anyway, I saw Potter’s post today, and it sparked me to finish writing this one. Alas, it seems I have been writing a lot about this boring stuff recently, and quite a bit more follows in this messy post. Yet again, you may want to skip this. (I will try to make my next post a weekend post to lighten stuff up.)

-

I noted (“As to the future, a public draft of FIPS 140-3 should be coming down the pipe fairly shortly.”) earlier this month that the FIPS 140-3 draft was coming, and here it is for public comment. More information can be found here.

Announcing First Public Draft of Federal Information Processing Standard (FIPS) 140-3, a revision of FIPS 140-2, Security Requirements for Cryptographic Modules

Keep in mind, this is the proposed law. The actual translation of this into clear, testable requirements will come later.

The draft includes this quick summary of changes from FIPS 140-2.

FIPS 140-3 adds an additional security level and incorporates extended and new security features that reflect recent advances in technology. In FIPS 140-3, each of the eleven requirement areas in redefined. Software requirements are given greater prominence in a new area dedicated to software security, and an area specifying requirements to protect against non-invasive attacks is provided.

The new level (level 5) is interesting, but, probably more important to vendors (most of whom will never see any motivation to go for level 5) is the mention of software requirements gaining prominence. Software has always been an ambiguous area to FIPS 140, be it 140-1 or 140-2. Sure, getting software through a FIPS 140-2 validation is a routine process, but it involves well established hand-waving, so I think it would be good for NIST/CSE to work to formalize this area. (Unfortunately, I could not tell for sure how well FIPS 140-3 is going to do that – looks like we will have to wait for the derived test requirements.)

Anyway, I quickly glanced over the draft of FIPS 140-3, and I noted the following changes from FIPS 140-2.

Note: If you don’t know FIPS 140-2, the following will likely be worthless to you.

As seems to happen each standard revision, the sections have changed a bit. The Finite State Machine (FSM) model no longer has its own section and has been merged into Life-Cycle Assurance. A new section called Software Security has been created, which feels like a split off from the old Operational Environment requirements under FIPS 140-2. The Operational Environment requirements have been moved before the Physical Security requirements, and Physical Security requirements have been split into two sections, Physical Security and Physical Security – Non-Invasive Attacks. Cryptographic Key Management has been changed to Sensitive Security Parameter Management, and the EMI/EMC section has been removed. The Design Assurance section has been renamed Life-Cycle Assurance.

As far as the particulars of the sections went, the following jumped out at me as changes from FIPS 140-2.

1. Section 1 – Cryptographic Module Specification
   In this section, you say what your module is by specifying its components and drawing a boundary around them.

   I noted the following changes from FIPS 140-2.

   1. Level 5 has been added.

   2. You are now asked to define the cryptographic module type, which is three flavors right now: hardware, software, and hybrid. (Yes, no firmware.)

   3. The concept of “degraded functionality” has been formalized, in which security functions that fail self-tests are disabled while ones that pass self-tests can be permitted to operate.

   4. Level 5 has the same requirements as levels 3 and 4.

   Also, the documentation requirements look to have been moved to an Appendix rather than listed here.

2. Section 2 – Cryptographic Module Physical Ports and Logical Interfaces
   In this section, you discuss what flows in, around, and out of the module.

   I noted the following changes from FIPS 140-2.

   1. Level 5 has been added.

   2. Notice the change in the “data output interface” description. It now says “for a given communication channel” all data output must be disabled when an error state exists. (Of course, the self-test section does not make such a distinction.)

   3. Level 5 has the same requirements as levels 3 and 4.

   Also, the section name has been changed slightly from FIPS 140-2.

3. Section 3 – Roles, Services and Authentication
   In this section, you discuss the operators and services of the module.

   I noted the following changes from FIPS 140-2.

   1. The maintenance role has finally been retired! Bravo!

   2. Level 5 has been added.

   3. Explicitly requires that default authentication information by changed upon first-time authentication. (This is not a change in practice over what was required under 140-2.)

   4. Explicitly states that default authentication information (e.g., a default password shipped with a module that must be changed during initialization) does not need to meet zeroization requirements. (This is not a change in practice over what was required under 140-2.)

   5. The default authentication information must be unique per module unit delivered if used to control access to the module for first-time authentication. Note the “If the module employs default authentication data to control access to the module for first-time authentication” – in effect, this requirement will likely become “not applicable” for most modules under level 3.)

   6. Strength of authentication requirements have been upped.
   6a. Less or equal to a 1 in 100,000,000 chance of false acceptance per authentication attempt. (up from 1 in 1,000,000)
   6b. Less than or equal to a 1 in 10,000,000 chance of false acceptance of a single authentication attempt over multiple attempts at authentication over the course of a minute. (up from 1 in 100,000)
   6c. Strength of authentication requirements must be met by implementation, not procedural controls.
   6d. Password selection must check for weak passwords.

   7. Levels 4 and 5 require two-factor authentication.

   8. Show the module’s version number and zeroization have been added to the list of services a module must provide.

   9. Alternating and exclusive bypass have been merged.

   10. Software loading is now address in this section.
   10a. Logic for loading software shall be disconnect from data output.
   10b. An Approved authentication technique must be used to validate the software (i.e., the software load test). The newly loaded software cannot be executed until this check has passed.
   10c. It is now explicitly called out that for a module claiming a non-modifiable operational environment, this technique must be required by the module itself and not through the use of procedural controls.
   10d. The newly loaded software must undergo the standard cryptographic algorithm tests (e.g., KATs) before providing security services.

   11. Level 5 has the same requirements as levels 3 and 4.

4. Section 4 – Software Security
   In this section, requirements for the software components of a module are detailed.

   I noted the following changes from FIPS 140-2.

   1. This section used to be the first part of Section 6 (Operational Environment) under FIPS 140-2.

   2. Level 5 has been added.

   3. At level 1, only Approved authentication techniques may be used to integrity check software. This may imply that non-approved integrity checks are no longer allowed if software is involved, even with a non-modifiable operational environment.

   4. At level 1, the software cannot provide a service to an operator to read itself.

   5. At level 1, the software must verify the format of externally provided data if said data has a specific format.

   6. At level 2, the integrity check must use a digital signature, and the private key used to generate the signature cannot be stored within the module.

   7. At level 3, there must be a command provided by the software to perform its integrity on demand without powering down the module, and provide to the operator the result of this test and a newly computed hash of the software. This hash value shall be zeroized from the module once this command has completed.

   8. At level 4, the critical security parameters and software stored on the module must be encrypted (I guess as much as possible, as you do need to be able to decrypt), including the software integrity test code and data. The key(s) or key components used to encrypt the software must not be stored on the module.

   9. At level 4, the vendor must provide the key used to encrypt the software to the customer. The customer can choose whether or not to change this key.

   10. At level 4, the key and integrity test data must be freshly general for each instance of the module provided by the vendor.

   11. At level 4, the encryption algorithm and mode used must be Approved.

   12. At level 5, the public security parameters must also be stored encrypted.

5. Section 5 – Operational Environment
   In this section, requirements for the operating system of the module are discussed.

   I noted the following changes from FIPS 140-2.

   1. Level 5 has been added.

   2. The language is much clearer with regards to when these requirements apply, although the applicability has not changed at all. Examples are given.

   3. Firmware is not used in the section anymore (nor really anywhere else in the draft).

   4. Limited operational environment is gone!

   5. The requirements make much more sense to today’s operating systems. In other words, much less hand-waving required. (Not new via interpretation, but now explicitly stated)

   6. At level 1, explicitly requires all software commands in a session to run on behalf of a single operator.

   7. At level 1, explicitly requires that critical security parameters are zeroized before an operator’s session ends and a new operator’s session is begun.

   8. At level 1, explicitly requirements that processes spawned by the module are owned by the module.

   9. Multiple concurrent operators are now allowed at level 1, moving requirements from level 2 under FIPS 140-2 to level 1 here.
   9a. At level 1, the operating system must provide discretionary access controls that can be configured to setup roles and use these roles to control access to who can execute the software, modify the software and its data, and read the software’s data.
   9b. At level 1, the operating system must prevent operators and processes (other than OS processes) from modifying executing cryptographic processes.
   9c. At level 1, the operating system must prevent operators from gaining access to other operator’s sensitive security parameters.
   9d. At level 1, the operating system must prevent operators and external executing process from reading the software.

   10. Explicit requirements for CC certification of the operating system have been removed from the level 2 requirements. (This does not necessarily mean these requirements will not appear in the derived test requirements or just become a standard part of meeting level 2 operational environment requirements.)

   11. At level 2, the security policy must explicitly state whether identification and authentication are performed by the module’s code or the operating system. (This is not a change in practice over what was required under 140-2.)

   12. Explicit requirements for CC certification of the operating system have been removed from the level 3 requirements. (This does not necessarily mean these requirements will not appear in the derived test requirements or just become a standard part of meeting level 3 operational environment requirements.)

   13. At level 3, operators in the user role must be prevented by the operating system from modifying the module’s software, system sensitive security parameters, and audit data stored within the operational environment.

   14. Explicit requirements for CC certification of the operating system have been removed from the level 3 requirements. (This does not necessarily mean these requirements will not appear in the derived test requirements or just become a standard part of meeting level 4 operational environment requirements.)

   15. At level 4, a new, specific list of auditable events is provided.

   16. Level 5 has the same requirements as level 4.

6. Section 6 – Physical Security
   In this section, the physical embodiment of the module is specified and the requirements for phsyical security are given.

   I noted the following changes from FIPS 140-2.

   1. Level 5 has been added.

   2. At level 5, tamper response components shall be protected from being disabled.

   3. At level 5, critical security parameters must be protected from disclosure even if the tamper detection is disabled.

   4. At level 5, environment failure protection is required.

7. Section 7 – Physical Security – Non-Invasive Attacks.
   In this section, the requirements for physical security against attacks not requiring physical contact or direct observation of the module are described.

   I noted the following changes from FIPS 140-2.

   1. This section is brand new to FIPS 140-3, which means all of these requirements are new.

   2. At levels 1 and 2, there are no requirements.

   3. At level 3, the module must protect against timing analysis attacks.

   4. At level 4, the module must protect against simple power analysis and differential power analysis attacks.

   5. At level 5, the module must protect against attacks taking advantage of electromagnetic emanations. (TEMPEST shielding anyone?)

8. Section 8 – Sensitive Security Parameter Management
   In this section, the requirements for handling sensitive security parameters, such as keys, are given.

   I noted the following changes from FIPS 140-2.

   1. This section is the FIPS 140-3 evolution of the Key Management section from FIPS 140-2. The name change makes sense, as the section deals with more than just keys.

   2. Level 5 has been added.

   3. Keys for cryptographic algorithm tests are explicitly defined as public security parameters.

   4. Keys for the software integrity test are explicitly defined either as a critical security parameter (for software modules or the software portion of a hybrid module) or a public security parameter (for hardware modules, or software in the hardware portion of a hybrid module).

   5. Entropy and entropy sources are dealt with explicitly.
   5a. A self-test is required for entropy sources.
   5b. Entropy input into the module must have a claimed minimum value that the module checks to see if it is sufficient for the security strength of the random bit generator (formerly known as the random number generator).
   5c. Seed and seed keys explicitly excluded from requiring an Approved random bit generator for generation. (This is not a change in practice over what was required under 140-2.)

   6. IVs required to be random must be randomly generated using an Approved random bit generator.

   7. Software modules are explicitly dealt with for critical security parameter entry/output, allowing critical security parameters to be input by/output to the host operating system in either plaintext or ciphertext form. (This is not a change in practice over what was required under 140-2.)

   8. The treatment of key establishment is cleaner.
   8a. Electronically entered critical security parameters must be both encrypted and their integrity verified (only encryption was required under FIPS 140-2.); however, note the following in parenthesis as part of this requirement – “(e.g., by an Approved security function or an Approved or Allowed key establishment method).”

   10. Password hash values are explicitly considered critical security parameters. (This is not a change in practice over what was required under 140-2.)

   11. At level 1 and 2, zeroization of critical security parameters can be accomplished procedurally if desired.

   12. At level 3, the module must handle zeroization of critical security parameters itself.

   13. At level 5, the module must also zeroize all public security parameters. Temporary public security parameters must be zeroized when no longer needed.

   14. The allowance of OTAR in radio devices has been removed.

9. Section 9 – Self-Tests
   In this section, the self-test requirements are described.

   I noted the following changes from FIPS 140-2.

   1. Power-up self-tests have been renamed pre-operational self-tests, which is more appropriate.

   2. Level 5 has been added.

   3. A critical time period must now be specified, which states the maximum operational time before the pre-operational tests must be repeated.

   4. The result of each pre-operational test must be output via the status output interface.

   5. If the module does not output an errir status on failue of a self-test, there must be a documented process (in the Security Policy) by which an operator can determine the module entered an error state.

   6. The module shall allow operators to call the pre-operational tests on demand. This used to explicitly state rebooting the module, resetting the module, etc met this requirement, but it no longer does. That may or may not indicate a change here.

   7. The software integrity test must use an Approved authentication technique. (formerly, a non-Approved technique could be used in modules with non-modifiable operational environments)
   7a. At level 1, this check can be a MAC or a digital signature.
   7b. At level 2, this check must be a digital signature.

   8. There is now an explicit requirements about when to use a KAT versus a pairwise consistency check for the pre-operational cryptographic algorithm tests for asymmetric crypto algorithms.

   9. A pre-operational bypass mode test has been explicitly added, and it is as confusing as ever. (This is not a change in practice over what was required under 140-2.)

   10. A conditional self-test has been added for key agreement.

   11. The bit count required for the continuous random bit generator test has been increased. If the random bit generator generates data in blocks smaller than 64 bits, then the data must be pooled to some amount greater than 63 bits and then the test initialized and performed from there.

   12. A min-entropy assessment test is now required for the output entropy sources. The calculated min-entropy must be greater than the min-entropy required by the random bit generator the data will be seeding. (This is the big change to these requirements.)

   13. The conditional bypass mode test has been clarified nicely and makes no sense at all. (IMO, this test should be made the pre-operational bypass mode test, and the conditional test should be changed to happen when the new rules are being activated.)

   14. All levels have the same requirements.

10. Section 10 – Life-Cycle Assurance
    In this section, requirements around the development and deployment of the module are discussed.

    I noted the following changes from FIPS 140-2.

    1. This section has been renamed from Design Assurance, which makes sense as it always dealt with a bit more than just the design of a module.

    2. Level 5 has been added.

    3. The configuration management requirements that used to apply to all levels have been switched to just levels 1 and 2.

    4. Levels 3-5 add to the configuration management requirements of levels 1 and 2 by requiring automated configuration management.

    5. Design requirements have been split from development requirements. Other than this move, level 1-3 design requirements remain the same.
    5a. Level 4 has been scaled back slightly, as it now requires an informal proof between the design and the functional specification.
    5b. Level 5 has picked up where level 4 was scaled back, requiring a formal modeling.

    6. Finite State Machine model requirements have been moved into this section.

    7. Development requirements have been cleaned up by removing design requirements and added to a bit.
    7a. At level 1, if software is included in the module, then details on the compilers, configuration settings, and methods used to compile code must be provided.
    7b. Levels 2 and 3 have been merged, so level 2 now requires custom integrated circuits to be implemented using a high-level HDL.
    7c. Level 5 has the same requirements as level 4, which is documentation specifying pre- and post-conditions for all components, functions, and procedures.

    8. Vendor testing is a new area added to this section.
    8a. At levels 1 and 2, the functional testing performed by the vendor must be documented. Confusingly, this testing is referred to as the testing defined in the module’s functional specification called out in 10.2, but a functional specification is not required at level 1 according to 10.2.
    8b. At levels 3-5, low-level testing must be performed. This is testing of components or groups of components as defined by the design documentation for level 3 (and up).

    9. At levels 3-5, authentication data provided by the vendor must be used to authenticate to the module upon delivery of the module from the vendor. (If you remember in Section 3, there were requirements that this data be unique for each device shipped by the vendor.)

    10. Crypto-Officer Guidance is referred to here as Administrator Guidance (in Appendix A it is back to Crypto-Officer Guidance), and User Guidance is referred to here as Non-Administrator Guidance (in Appendix A it is back to User Guidance).

11. Section 11 – Mitigation of Other Attacks
    In this section, countermeasure to attacks not covered by FIPS 140-3 can be discussed by a vendor.

    I noted the following changes from FIPS 140-2.

    1. Level 5 has been added.

    2. Levels 4 and 5 require specification of the methods used to mitigate attacks and methods for testing the effectiveness of the mitigation techniques.

As far as the Annexes go, there have been changes there too.

1. No more Protection Profiles listed in the Annexes. This goes hand in hand with no mention of Common Criteria in the requirements.

2. Annex B lists the allowed security functions.

3. Annex C lists the approved sensitive security parameter management techniques.

4. Annex C lists the allowed sensitive security parameter management techniques.

-

So, what are my thoughts after a quick pass through this draft of FIPS 140-3?

• First, I think FIPS 140-3 has added a decent level of rigor over FIPS 140-2, but just how rigorous will be left up to the derived test requirements and what happens during those first few (and always quite painful) validations under the new standard.
• Second, this whole level 5 thing seems a bit off to me. I thought the point of FIPS 140 was to provide requirements for modules to be used in sensitive but unclassified (SBU) environments, with the intent to use COTS products. Level 4 always seemed way more GOTS than COTS as well as beyond anything needed for SBU environments. So, now NIST/CSE have come up with level 5, which is level 4 on steroids. Much like level 4, I can’t really see any commercial company building a product that meets those requirements, unless a paying customer tasked them with doing so, and being tasked with such a gig seems unlikely to happen in the SBU world. In other words, unless the CMVP has been tasked with requirements for classified environments now, this seems like a waste of resources.
• Third, I think level 3 has gotten quick a little harder to achieve based on this draft. Not only are their additional physical security requirements (timing analysis), but the whole default authentication data being both required (by virtue of the Life-Cycle requirements) and forced to change for each device shipped (by virtue the Roles, Services, and Authentication requirements) means a new process must be put in place for most vendors, given common practice is to just burn the same image to every device and have some sort of default login that is the same across all devices. Not to mention that on-demand software integrity check with hash value output.
• Fourth, the bypass mode test has not been fixed at all with regards to things like VPNs, which is the main place you find bypass these days. The conditional test seems like a test for testing’s sake (check to see if the configuration has changed before changing it), and I think this should become the pre-operational bypass mode test as well as the conditional bypass mode test but performed before enabling the configuration (instead of before changing the configuration). (I pick on this because it has always irritated me. I guess it will be sticking around.)
• Fifth, it is hard to tell exactly how well this will deal with software at this point. It could be that this might be something to look for resolution to in the derived test requirements.
• Sixth, I felt there were some inconsistencies in requirements and language. (There are some examples noted above in my breakdown of changes.) It could also be that the derived test requirements remove this inconsistency by clarifying the meaning of some of the wording.
• Seventh, I am not quite sure some of the Roles, Services, and Authentication requirements requirements match with how protocols and authentication really work. For example, authentication to a module over a TLS session using a password. Oftentimes, this involves negotiating an encrypted/MAC’d session, then you authenticating to the module, which means unauthenticated access to cryptographic services. Do we need to keep look the other way here?
• Eighth, the two physical security sections could be merged without issue.
• Ninth, is mitigation of attacks going to get any more traction this time around than it did in FIPS 140-2? Perhaps NIST/CSE should start a new Annex that lists attacks they think should be mitigated in SBU environments based on level.

—

I covered an aspect of software/firmware/hybrid module validations in my last post, which is one of the ambiguous areas left in FIPS 140-2. Another I have discussed in passing in a previous post was the seeding requirements under FIPS 140-1 and FIPS 140-2.

• Under FIPS 140-1, IIRC (and it has been 6 or so years since I last looked at it), there were no explicit requirements around PRNG seeding. So, one could get away with using a clock as the seed to the PRNG. Most often, labs would point this out as a problem, but, without FIPS teeth, they could just recommend that a vendor change it, not require that they change it. While I have never heard of a lab recommending that a vendor use the system clock alone to seed the PRNG, it was possible under 140-1 for that to happen. (Requiring it, well, no.)
• Under FIPS 140-2, this hole in the standard was fixed. Sure, it took interpretation of the key management requirements to translate to all FIPS-approved PRNGs that seed themselves internally having a seed that meets a baseline strength requirement, and that baseline seed strength requirement had to be translated into a set of entropy gathering techniques that the labs thought reasonable, but, that happened fairly quickly after the release of FIPS 140-2, and there are now standard techniques that all labs smile upon at this point. (And, no, the labs (and NIST/CSE) do not accept solely the system clock being used to seed a PRNG.)

Well, a post to the Metzger’s Cryptography mailing list explicitly asked about the entropy requirements for seeding PRNGs under FIPS 140-2. A solid response to that post can be found here, which provides pointers to the key management requirements I alluded to in the paragraphs quoted above. I also chimed in in the thread.

(Interestingly, with the entropy source test included in the draft of FIPS 140-3 (see above), the requirements in question sort of become moot under FIPS 140-3 as currently drafted, as that test serves to check that the min-entropy of the seed is greater than or equal to the security strength required for the PRNG being seeded. It could be a useful exercise to calculate min-entropy now if one has the time, as this would not only serve as a decent rationale for meeting current requirements but also takes a step towards the possible future of FIPS 140.)

—

Update: Rather than make yet another post on these drafts flying out of NIST, I figured I would just add the information here.

In the stream of drafts flying out of NIST this last month or so, we can add a couple more, Draft Special Publication 800-106, Randomized Hashing Digital Signatures,

NIST announces the release of draft Special Publication 800-106, Randomized Hashing Digital Signatures. This Recommendation provides a technique to randomize the input messages to hash functions prior to the generation of digital signatures to strengthen security of the digital signatures. Please submit comments to quynh.dang@nist.gov with “Comments on Draft 800-106″ in the subject line. The comment period closes on September 17, 2007.

And Draft Special Publication 800-107, Recommendation for Using Approved Hash Algorithms.

NIST announces the release of draft Special Publication 800-107, Recommendation for Using Approved Hash Algorithms. This Recommendation provides guidance on using the Approved hash algorithms in digital signatures applications, Keyed-hash Message Authentication Codes (HMACs), key derivation functions (KDFs) and random number generators. Please submit comments to quynh.dang@nist.gov with “Comments on Draft 800-107″ in the subject line. The comment period closes on September 17, 2007.

I get lots of questions about FIPS 140-2. I get questions about technical requirements, documentation requirements, process requirements, and everything in between, like costs. Not sure why people asked me all these questions – it may be that I just answer their questions for free if I know the answer.

Anyway, I normally refrain from posting such content to this blog, as it is boring; however, I have had a few people ask me about the Implementation Guidance (IG) just posted by NIST/CSE. It seems taking software through FIPS 140-2 validation still presents concerns for at least first timers. So, rather than repeat myself again, I decided to write this up in a short post. If you don’t care about FIPS 140-2 documentation, I highly suggest you stop reading now, unless you are having difficulty sleeping.

Before I get started, I need to point something out. In the simplest terms, the FIPS 140-2 Security Policy (SP) can be thought of as summarizing how a module meets the FIPS 140-2 requirements (i.e., a summary of the Vendor Evidence (VE) from the Derived Test Requirements (DTRs)) coupled with instructions on how to operate the module in compliance with the FIPS 140 requirements, all done without including proprietary information, as this document will be made public, unlike other FIPS documentation. As such, once you have responses for the VEs for your module, deriving this content for the SP is a mostly straight-forward process.

Keeping this in mind, lets look at the latest IG issued by the Cryptographic Module Validation Program (CMVP).

Question/Problem
For a software, firmware or hybrid cryptographic module, what are the requirements of the logical diagram contained in the security policy as specified in VE.14.01.01?

Resolution
The logical diagram must illustrate:
• the logical relationship of the software, firmware or hybrid module with respect to the operating environment. This shall include, as applicable, references to any operating system, hardware components (i.e. hybrid) other supporting applications, and illustrate the physical boundary of the platform. All the logical and physical layers between the logical object and the physical boundary shall be clearly defined.

Since this is pointing to VE14.01.01, we are dealing with requirements for the SP, from Appendix C of the DTRs. So, let us look at the DTR entry in question.

AS14.01: (Levels 1, 2, 3, and 4) The cryptographic module security policy shall be included in the documentation provided by the vendor.

Required Vendor Information
VE14.01.01: A diagram or image of the physical cryptographic module (if appropriate) shall be included in the security policy. The image may be used to indicate the security relevant features of the cryptographic module (e.g., tamper evidence, status indicator(s), user interface(s), power connection(s), etc).

Required Test Procedures
TE14.01.01: The tester shall verify that the diagram or image is representational of the cryptographic module tested.

Notice there is no reference to a “logical diagram” here and it seems to be discussing only the physical module. Those were points of confusion to the people that asked me about the IG, as they wondered why NIST/CSE referred to a “logical diagram” without the DTR entries making mention of it.

Now, software can be an area of ambiguity when it comes to FIPS 140-2 requirements if you have not been through a software validation before; however, the reality is that taking software/firmware through FIPS validation is a smooth process at this point, so really it just comes down to experience and understanding the “FIPS lore.” I alluded to this in a previous post.

For example, software validations are the most common area of difficulty for new labs or lab staff. Software does not fit well into FIPS 140-2, and so you can hear ridiculous requests from new FIPS 140 people in this regard.

Anyway, if you use a little fuzzy thinking here, you may notice something in the VE requirement quoted above – it sort of brings to mind the block diagram required in section 1. Exactly, and that is from where you should derive your diagram for the SP. NIST/CSE point this out in an additional comment.

Additional Comments
The logical diagram must convey basic information to the operator of the cryptographic relationship respective to the operating environment. The logical diagram could be a subset of the block diagram specified in AS.01.13.

Notably, NIST/CSE like to see block diagrams included in the SP for all modules, not just software/firmware/hybrid modules. So, while VE14.01.01 implies that just a picture of the physical device is adequate for a hardware module, it is common practice to include the block diagram(s) for the module as well. In other words, block diagrams matter for all modules and should be included in the SP, albeit potentially watered down to remove proprietary information.

Ok, so lets look at the VE requirements for AS01.13.

AS01.13: (Levels 1, 2, 3, and 4) Documentation shall specify a block diagram depicting all of the major hardware components of the cryptographic module and their interconnections, including any microprocessors, input/output buffers, plaintext/ciphertext buffers, control buffers, key storage, working memory, and program memory.

Required Vendor Information
VE01.13.01: The vendor documentation shall include a block diagram showing the hardware components and their interconnections. Components to be included in the block diagram shall include, as applicable:
1. Microprocessors
2. Input/output buffers
3. Plaintext/ciphertext buffers
4. Control buffers
5. Key storage
6. Working memory
7. Program memory
8. Other components types not listed above

VE01.13.02: The block diagram shall also include any (semi-) custom integrated circuits (e.g., gate arrays, field programmable gate arrays, or other programmable logic).

VE01.13.03: The block diagram shall show interconnections among major components of the module and between the module and equipment or components outside of the cryptographic boundary.

VE01.13.04: The block diagram shall show the cryptographic boundary of the module.

So, now we see what is required for a block diagram; however, you are thinking, “Great, but there is still no reference to software/firmware components or logical diagrams.”

Fair enough, this is a core ambiguity in FIPS 140-2 stemming from FIPS 140’s hardware roots. To get passed this limitation, you need to understand how to interpret these requirements for software/firmware components, which is basically just some FIPS lore.

“Ok, so tell me what to do,” you think.

Well, in order to fit software/firmware into FIPS 140-2, break the block diagram down into two block diagrams, one covering physical components that can be thought of as a physical block diagram, and one that includes software/firmware components that can be thought of as a logical block diagram. For example, for a software module that runs on a general purpose Pentium-based computer, the physical block diagram can just be a general depiction of a block diagram for a general purpose Pentium-based computer showing the core components, their interactions, and where information crosses into/out of the computer, and the physical cryptographic boundary surrounds all of these components, representing the case of the computer. The logical block diagram, on the other hand, will be quite a bit more meaty – it needs to depict the various software components, and the interactions between those components as well as the outside world, and the logical cryptographic boundary here encloses all of the module’s software components, representing the software/firmware as it is packaged up for the validation.

(Oh, and while you are drawing these diagrams, it would be good to bang off some of the VE requirements in section 2 of the DTRs as well. You can do this by including information flows and labeling these flows using the FIPS categories.)

“Great, I think I get it. But, what should I do for the SP?”, you say.

Remember what I said a few paragraphs back about the SP – “[...]summarizing how a module meets the FIPS 140-2 requirements[...].” So, take your logical block diagram, strip out any proprietary information and/or water it down, and insert it into the SP. Simple enough.

-

FYI, another draft released in June, this time for a mode of operation.

GCM, submitted to NIST by David McGrew and John Viega, combines a variation of the Counter Mode for encryption with an authentication mechanism that is based on a universal hash function. The underlying (approved) block cipher must have a block size of 128 bits (i.e., the AES algorithm) and the size of the authentication tag is 96-128 bits.

[via some mailing list posts and this article sent over by Ray Potter a few days ago]

Update: I just read this interesting mailing list post about what has led up to the current 800-38D draft…

Joux made some concrete suggestions for changing GCM at the end of
Section 5:

1. replace the counter encryption for MACs by the classical
encryption with the block cipher usually used with Wegman-Carter MACs.
2. use a strong key derivation at the beginning of the algorithm
and computing a different key for each different purpose (one for
encryption, one for intiializing J, one for the keyed hash and one
for the MAC encryption).

The current draft of SP 800-38D did not accept Joux’s modifications
to the algorithm, but responded to the Joux comments in several
concrete ways:
(a) the provision for variable-length IVs is omitted from the new
draft, and
(b) the draft elaborates on the requirement that initialization
vectors (IVs) must be unique across all implementations with a given
key:
(i) The critical importance of this requirement is indicated.
(ii) For validation of a module to the requirements of FIPS
140-2, an IV “generation unit” is required to be within the
cryptographic boundary of the module.
(iii) Two IV constructions are outlined: one that relies on
deterministic elements to meet the uniqueness requirement, and one
that relies on an output string from a random bit generator.
(iv) Some design and implementation considerations with
respect to IVs are discussed.

And where it may go…

While NIST determined that the GCM mode should be added to the “NIST
Crypto Standards Toolkit”, there have been extensive discussions with
respect to the utility of the Joux submission. There is a
possibility that NIST might recognize the Joux variant as well. I
suggested that the needs of protocol developers be considered as a
primary driver for this decision. As a result, Morrie Dworkin (the
author of 800-38D) will be presenting at SAAG to get a feel for the
level of interest in such a mode.