I feel like I am beating a dead horse with the start of this post. I tried to go a little off course from there.
-
Another discussion of FIPS 140 has been kicked off on SAAG. Besides the kick off message (on including FIPS-approved algorithms in a possible IETF recommended set of crypto algorithms), this post (on product customer demand for FIPS 140) and this post (on the general pain of the process) are probably of most interest, but the entire thread may be worth a read if FIPS 140 matters to you. (Oh, and this made me laugh.)
This post of mine from a year ago seems relevant to some of what is being said.
- A vendor has been put at a competitive disadvantage because they do not have FIPS 140 validation. Perhaps their competitors have it. Perhaps a bid requires it. Whatever the case may be, they don’t have it, so now they want to tear it down.
Also found here are people that just dislike FIPS 140 or, perhaps, standards in general.
- A vendor has gone through the process, and it was quite painful. So, now they vent about all the changes they had to make, how silly particular requirements were, how incompetent the lab staff was, etc.
- An expert tells stories of how the requirements are ambiguous and the labs all vary in how they interpret the requirements.
Also found here (and often quite different from the previously described expert) are people that have run into FIPS a number of times over the years, which has caused them exposure to differing requirements without having seen the evolution of those changes.
In that lengthy post, I discuss some points often causing pain.
- Vendor misunderstanding of the FIPS 140 requirements and terminology.
[...]- Vendor misinterpretation of lab (or NIST/CSE) questions and issues.
[...]- Labs can, and do, make requests and recommendations.
[...]- New labs, new lab staff, new technologies, and new revisions of FIPS 140 (and related) standards can make for created requirements. (This is where you can find the most variation among labs.)
[...]
Anyway, I think a couple of additional points might be relevant to some of what I read in the latest SAAG thread.
First, I don’t think the concept of failure in a FIPS validation effort is quite so rigid as is being implied in parts of the SAAG discussion. During a FIPS validation effort, the lab (during testing) or NIST/CSE (during review) may bring up issues that a vendor has to address. These issues are often areas in which the module may be failing to meet particular FIPS requirements. This does not mean the module “fails,” it just means that the issues raised must be addressed before the module “passes.” In general, issues often boil down to some of the following:
- Clarification – the issue raised is just seeking some short clarification about the product’s workings and/or how a requirement is met. A quick written or verbal response (e.g., answering a question) can often be enough.
- Documentation – the issue raised is about incorrect, confusing, or incomplete documentation. Modifying the documentation is normally the fix here. (Even though what follows in 3 is often what vendors dread most, 2 can also lead to much pain if the lab starts questioning technical aspects of the product and heads down all sorts of testing paths that would otherwise have been avoided (i.e., prepare documentation that gives the lab what it needs in an easy to use form).)
- Technical – the issue raised is actually a technical problem with the product in regards to meeting the requirements. Here is where the product itself may have to be modified, and this is what most vendors want to avoid once they are knee deep in the validation (i.e., get the product meeting the requirements before the lab testing gets underway).
In all three cases, the “failure” can be corrected and the product can continue on with its validation. Depending on the issues raised, labs will often continue working on the validation effort in other areas while the vendor is working on addressing the issues; however, there is, of course, a point where the lab will need certain issues addressed before being able to move forward – this is where the third case can be especially problematic.
Second, this brings us to the “restarting” portion of the discussion in that thread. In general, if the issues raised can be addressed in a timely manner and based on the version of the product at that moment going through validation, then there should be no “restart” issue. However, if the issues raised take a long time for the vendor to fix and/or require a switch in the version of the product such that the new version includes a large number of other changes in the product (e.g., a switch to a new version of the product with a whole suite of new features), this could cause a “restart.” I generally think of these restarts coming in these two forms.
- The lab can no longer move forward with the effort while waiting on the vendor to address issues, so the project is put on hold. Depending on time frame here, lab resources will be moved elsewhere and lab knowledge of the product will deteriorate. When the vendor is ready to start back up, the lab has to restaff the effort, rebuild its knowledge of the product and the validation effort, and generally kick things off again.
- The changes were rolled into a new version of the product, and this new product is dramatically changed from the one that began the validation effort. The lab will have to figure out what has changed and determine how much of their work performed to this point can be reused, much like in a revalidation scoping but more awkward. If this is in combination with 1, this could get close to starting over.
Needless to say, you want to avoid going down this road.
-
Since I mentioned TrueCrypt in a previous post, look at this.
HotPlug allows you to seize and move a computer without losing power. (Video demos.) See also: MouseJiggler.
Yep, you guessed it.
How to circumvent Whole Disk Encryption
The key: Do not allow the encryption to activate. Low level encryption such as Vista’s Whole Disk Encryption (WDE) can halt an investigation. Use HotPlug and Mouse Jiggler to prevent encryption technologies from activating. If you can carry away the computer while it’s still logged in, you maintain full access to the hard drive.
In short, the plaintext key is often stored (cached), or authorization to access the plaintext key is stored (cached), in volatile memory (e.g., RAM) when using things like full disk encryption, so that data read from/written to disk can undergo transparent (to the user) processing. When the computer is powered down, goes to sleep, etc., assuming the hardware/software properly handles things, the (easy) access to the plaintext key is lost (e.g., the cached key or authorization to use the key is wiped). This gear is meant to prevent the circumstances that cause that wiping from happening.
Think of TrueCrypt – if you are using system disk encryption on your home desktop, then you know that, once you have entered your password at boot, the stored encrypted key is decrypted and the plaintext key is then stored in memory by TrueCrypt to transparently encrypt/decrypt data as it is written to/read from disk (i.e., you only enter your password once per boot). Anyone taking control of your desktop at that point has full access to your encrypted drive. However, if you pulled the plug, then the plaintext key would be lost. Well, this gear allows an attacker to grab your desktop and remove it from your home without it losing power (or hibernating).
-
Now this phenomenon sounds a little familiar.
Over 90% of people responded physically, for example with an exaggerated stare or a wave. Almost half responded verbally – more men than women. Here, says Professor Shuster, the sex difference was striking. 95% of adult women were praising, encouraging or showed concern. There were very few comic or snide remarks. In contrast, only 25% of adult men responded as did the women, for example, by praise or encouragement; instead 75% attempted comedy, often snide or combative as an intended put-down.
I mentioned this impact with regards to attire in this post.
(Side note, I have an old, bright red Futura t-shirt that says “For love or money”. With many, it generates mostly “for love!” comments and generally leads to conversation about values and the like. With others, it often inspires awkward mockery, as is the case with almost any loud attire.)
The “others” here are generally straight men showing negative interest, while the “many” are usually straight women or gay men showing positive interest. Perhaps this makes sense, as I am likely viewed as a potential rival to the former and a potential suitor to the latter.
Whatever the case may be, I always enjoy hacking peoples’ thoughts and behavior with something so simple as a t-shirt. As such, my custom t-shirts often play to this effect quite nicely.
-
ABC2 has obtained new video of Baltimore police officer Salvatore Rivieri in action at the Inner Harbor. This time he confronts Billy Friebele, an artist from Washington D.C., who was videotaping at the Harbor last summer.
Friebele told ABC2 he was taping the reactions of passersby to a box he was moving with a remote controlled car. Officer Rivieri is seen on tape kicking the box off of the car and then kicking the car. The officer then orders Friebele to leave the area.
Small world. I knew Billy back in college.