Just a few quick and mostly old notes accumulated over the last few months…
–
FIPS 186-3 has been released, as announced here.
This notice announces the Secretary of Commerce’s approval of Federal Information Processing Standard (FIPS) Publication 186–3, Digital Signature Standard (DSS). FIPS 186–3 is a revision of FIPS 186–2. The FIPS specifies three techniques for the generation and verification of digital signatures that can be used for the protection of data: the Digital Signature Algorithm (DSA), the Elliptic Curve Digital Signature Algorithm (ECDSA) and the Rivest-Shamir-Adelman (RSA) algorithm. Although all three of these algorithms were approved in FIPS 186–2, FIPS 186–3 increases the key sizes allowed for DSA, provides additional requirements for the use of RSA and ECDSA, and includes requirements for obtaining the assurances necessary for valid digital signatures. FIPS 186–2 contained specifications for random number generators (RNGs); this revision does not include such specifications, but refers to NIST Special Publication (SP) 800–90 for obtaining random numbers.
[...]FIPS 186–3 allows the use of 1024, 2048 and 3072-bit keys. Other requirements have also been added concerning the use of ANS X9.31 and ANS X9.62. In addition, the use of the RSA algorithm as specified in Public Key Cryptography Standard (PKCS) #1 (RSA Cryptography Standard) is allowed.
In the announcement, some of the changes between the last draft and the final document are covered in a comments received and NIST response format. I found the most interesting NIST responses to be…
This permits the use of a public key algorithm and key size that is stronger in security than a hash algorithm, so long as both provide sufficient security for the digital signature process. The use of hash algorithms that provide equivalent or stronger security than the public key algorithm and key size is still encouraged as a general practice.
NIST studied the suggestion and decided not to impose further restrictions on the selection of the public exponent e. Such restrictions would negatively impact NIST’s Cryptographic Module Validation Program (CMVP) by precluding the validation of currently accepted implementations without providing a significant increase in security.
NIST reviewed the comments and made the appropriate changes to ensure alignment with respect to the generation and management of ECDSA domain parameters. NIST deleted the statement ‘‘ANSI X9.62 has no restriction on the maximum size of [the cofactor]’’, since the current version of X9.62 imposes limitations on the size of the cofactor. NIST also revised statements regarding elliptic curve domain parameter generation for purposes other than digital signature generation.
I commented on an early draft here and mentioned a later draft here.
Update:Annex A and Annex C of FIPS 140-2 have been updated to reference FIPS 186-3.
The algorithm testing tool has been updated to include testing for FIPS 186-3 algorithms, with some exceptions. As found the announcements,
New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS8.0). This version of the CAVS tool activates the FIPS 186-3 DSA2 validation testing with the exception of generation and validation of provably prime domain parameters p and q and canonical generation and validation of domain parameter g. It also requires the IUT to specify the assurances necessary for valid digital signatures specified in FIPS 186-3.
The exceptions to the algorithm testing tool are vendor affirmed for now, as per an update to the FIPS 140-2 Implementation Guidance.
Validation testing for FIPS 186-3, Digital Signature Standard (DSS) is separated into the three digital signature algorithms. Validation testing is available for FIPS 186-3 DSA, with the exception of the domain parameter generation and validation method listed above. These methods, along with FIPS 186-3 ECDSA and RSA, will require vendor affirmation until validation testing is available in the CAVS tool.
Update: NIST has released a new version of the algorithm testing tool (8.1) that “addresses several minor modifications and enhancements to CAVS including the Addition of a cover letter template, the addition of more efficient elliptic curve routines for NIST binary (e.g.., B-163 and K-571) curves, and the modification of several minor issues.”
-
Speaking of FIPS, the FIPS 140-2 implementation guidance (IG) has been updated over the last few months. There has been much in the way of important and clarifying guidance, translating both “FIPS lore” and the forward thinking on algorithms/protocols as well as revs to FIPS 140 into the current requirements.
New Guidance
o04/01/09: 3.2 Bypass Capability in Routers
o04/01/09: 9.5 Module Initialization during Power-Up
o03/24/09: 7.9 Procedural CSP Zeroization
o03/10/09: 1.14 Key/IV Pair Uniqueness Requirements from NIST SP 800-38D
o03/10/09: 5.3 Physical Security Assumptions
o03/10/09: 7.8 Key Generation Methods Allowed in FIPS Mode
Modified Guidance
o03/10/09: G.1 Request for Guidance from the CMVP – Updated NIST POC.
o03/10/09: G.5 Maintaining validation compliance of software or firmware cryptographic modules – Updated references to firmware and hybrid modules.
o03/10/09: G.13 Instructions for completing a FIPS 140-2 Validation Certificate – Updated examples.
o03/10/09: 1.9 Definition and Requirements of a Hybrid Cryptographic Module – Updated to include hybrid firmware modules.
o03/10/09: 7.1 Acceptable Key Establishment Protocols – For Key Agreement; added the KDF specified in the SRTP protocol (IETF RFC 3711) is allowed only for use as part of the SRTP key derivation protocol. For Key Transport; wrapping a key using the GDOI Group Key Management Protocol described in the IETF RFC 3547.
I don’t think any of these are a surprise, but reading through it might be useful. Much has been set done cleanly here, with the possible exception of IG 9.5, which seemed more confusing than clarifying to me, but maybe that was a case of my (unfortunately) “knowing” too much about the FIPS world. Anyway, the changes to or additions of IGs 1.9, 7.1, 7.8, and 1.14 are perhaps of the most interest.
Since I have been coming at things from a more deployment side these days, I think IG 5.3 helps to illustrate how to interpret FIPS 140-2 validation results as applied to the selection and deployment of FIPS modules.
The four physical security levels of FIPS 140-2 are focused on the protection of the modules CSPs by the module itself independent of the environment the module is deployed. Therefore selection of a security level is greatly influenced by the environment the module is to be deployed. At a Level 1 security level, which does not itself provide physical security protection, in the right environment, may be an acceptable solution because the environment provides the required physical security protection features.
In this same deployment regard, IG 1.14 makes the following note.
2. The standard sets the minimum security requirements. The buyer is free to demand that the module allows for longer names. Users should be smart enough to name their modules in such a way that name collisions become extremely rare.
Also, for the old timers, the following was an area of debate back in the day. Now it is officially documented in an IG 7.8.
To be used in FIPS mode, a secret value K can be any value of the form:
K = U XOR V, (1)
where the components U and V are of the same length as K14, are “independent” of each other, and U is derived, possibly using a qualified post-processing (see below), from the output of an approved RNG in the module that is generating K. In addition, each component may be a function of other values (e.g., U = F(U’), or V = F(V’)).
The security strength of the generated value K is equal to the larger of the security strengths of U and V. In general, the security strength of K is determined by the security strength of U, and the security strength of U is the minimum of the length of U (and K) and the security strength of the RNG used to generate U. Therefore, the length of U (and K), and the security strength of the RNG used to generate U shall meet or exceed the security strength required for K. However, a vendor can claim that the security strength of the generated value K is determined by the security strength of V if it can be demonstrated that V has a higher security strength than U.
Update: NIST released revised implementation guidance. Besides “certificate annotation examples” added to a few sections, there was the following modification.
08/04/09: 7.1 Acceptable Key Establishment Protocols – For Key Agreement; removed the KDF specified in the SRTP protocol (IETF RFC 3711). For Key Transport; added reference to EAP-FAST and PEAP-TLS.
-
Since I am on this topic, I guess a quick note that a number of new revs of the CAVS were released in months prior is in order. Most were bugfixes and tweaks, but there were some additions to supported algorithms. E.g.,
[04-15-09] — New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS7.4). This version of the CAVS tool adds the capability to test DRBG (NIST SP 800-90) implementations that do not have the optional reseed function.[...]
[03-12-09] — New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS7.1). In addition to minor modifications to enhance the tool, Version 7.1 of the CAVS tool adds testing for the draft of FIPS 186-3, Digital Signature Standard, Digital Signature Algorithm and file formating changes to the NIST SP 800-90 (DRBG) files to make them more similar to those used for other algorithms. As of the CAVS 7.1 release date, FIPS 186-3 is still in draft. No validations will be processed for this algorithm.
Update: NIST released the CAVS Management Manual. As per the announcements,
[08-17-09] — Posting of the CAVS Management Manual. The purpose of the CAVP Management Manual is to provide effective guidance for the management of the CAVP and other parties in the validation process.[...]
-
Switching direction, upgrading Gnome from 2.24 to 2.26 on FreeBSD through the ports went mostly smoothly. As always, follow the FAQ. I had been using xulrunner for a while, but I was happy to see this change for the removal for FF2.
A FreeBSD port of libxul-1.9 has been added as an alternative Gecko provider to Firefox 2. This can be used by setting WITH_GECKO=libxul in /etc/make.conf.
And, on Ubuntu, this deadlock hit me after upgrading to Ubuntu Jaunty (2.6.28-11.server). I have been manually loading the padlock drivers for quite some time via /etc/modules. To avoid the issue, I added in manual loading of the generic kernel crypto implementations for aes, sha1, and sha256 prior to loading the padlock drivers.
-
Moving along, this gives me deja vu, yet made me laugh. (Please consider avoiding that previous link and the first link in the following blockquote’d text if you mind profanity.)
[...]Listen to his comedy bit about the DC metro system, which is he says is “the [...] Tron compared to NYC subways[...]
Having lived both in NYC and DC metro areas and having ridden both the NYC subway and the DC metro quite a bit, I think there are two points to make about the DC Metro system.
- The DC Metro is minor in scope compared to the NYC subway. Not only is it a fraction of the size moving a fraction of the people, but it is only part-time.
- The DC Metro system is designed like an X, and much of that X only has a single track going in each direction. So, if anything goes wrong in your part of the X or the center of the X, well, lets just say you are out of luck.
Now, because of point 2, even if DC blows up in size and develops a late-night night-life, it would be quite difficult to do away with point 1 in any significant fashion without some fundamental design changes. Even if you could magically do away with unexpected problems in the system (and, yes, that would have to include rainy and snowy days), you are stuck juggling trains between single tracks best case or shutting down parts of the line and running shuttle buses worst case for basically any line maintenance, significantly impacting service on those parts of the system and on the overall system as you move closer to the center of the X. This becomes even more acute due to the increased wear and tear that lovely, underground center of the X suffers, especially as you ramp up service to handle more people or longer hours.
The NYC subway system, by contrast, looks like a bunch of parallel lines that crisscross here and there, and these multitudes of lines generally have multiple tracks supporting each direction. While there may be sparse coverage at some points (e.g., parts of Queens come to mind) and a large concentration of lines at other points (e.g., Manhattan), you still tend to end up with lots of independent enough ways to route around much of the maintenance work and unexpected problems such that the effect on the overall system tends to be quite limited and interruptions to the particular parts undergoing work or suffering issues can be mitigated/minimized (e.g., the handling of maintenance work on the 7 line happening right now), even in spite of 24/7 operation.
Like so much else that varies between NYC and its neighbors, there is a big difference in the scale/scalability and availability requirements of public transportation for an enormous 24/7 city accustomed to public transit and a large 18/7 city accustomed to the beltway. So, when it comes down to how to spend limited resources, one gets beauty sleep, the other keeps on keeping on. 
-
Finally, it has been a while since I have pointed out notably pleasant customer service experiences. So, here is some praise for the LIRR cleaning crew in Penn Station left in a comment.
To Whom It May Concern, I would like to praise all the cleaning men and women who work in the station. They all do a fantastic job on keeping the station clean.