There are lots of reasons why a vendor might choose to offer a non-FIPS mode. There are even some (but perhaps fewer) good reasons why a security-conscious enterprise would or should choose to make use of such modes.
The first non-FIPS case that comes to mind involves the use of a non-FIPS algorithm or mode. MD5, single-DES, CAST, etc., are all non-FIPS approved algorithms, but may have some utility for backwards compatibility. Even if all of the encryption algorithms are FIPS -approved, that particular mode of operation might not be approved, or might not have been at the time the module was certified. For example, the use of RSA for key exchange is not FIPS approved, although it is approved for digital signatures. HMAC, AES Galois Counter Mode, and the various "tweak" ciphers now being proposed many or many not fall into that gray area, although most can be composed as a series of ECB operations with pre- and post-processing. Other areas of concern may be the time required to complete all of the power-on self tests, which FIPS 140-2 requires be completed before ANY cryptographic operations are performed, vs. the draft FIPS 140-3 specification which only requires that they be completed before that particular usage is first performed. So if you implement some relatively expensive but optional and infrequently used function (e.g., ECDSA), you may cause a 10 to 15 second delay in smart card logon. A vendor might very reasonably choose to offer a non-FIPS mode to avoid the unnecessary overhead in that case. Finally, some functions may be required for FIPS Level 3, such as a secure channel for all PIN entry and key exchange, which may be difficult or expensive to do on all platforms. Rather than downgrade the product's rating to level 2, the vendor may choose to offer a non-FIPS mode that might be even worse, while still claiming level 3 (although no one will use the product in that fashion.) As usual, the devil is in the details, and reading the Security Policy carefully before purchasing the product is essential to an informed decision. Bob Robert R. Jueneman Chief Scientist SPYRUS, Inc. www.spyrus.com 1860 Hartog Drive San Jose, CA 95131 408-392-4307 (Office) 408-422-2378 (Cell) Please note the new address and office telephone number. See http://www.spyrus.com/productdemo.asp for a brief video regarding the SPYRUS Hydra Privacy Card. This message and any attached documents may contain SPYRUS confidential information and may be subject to privilege or exempt from disclosure under applicable law. These materials are intended only for the use of the intended recipient. If you are not the intended recipient of this electronic message, you are hereby notified that any use of this message is strictly prohibited. Delivery of this message to any person other than the intended recipient shall not constitute any waiver of any privilege. If you have received this message in error, please delete this message from your system and notify the sender immediately. Thank you." -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, May 02, 2008 11:00 AM To: fde@www.xml-dev.com Subject: FDE Digest, Vol 20, Issue 2 Send FDE mailing list submissions to fde@www.xml-dev.com To subscribe or unsubscribe via the World Wide Web, visit http://www.xml-dev.com/mailman/listinfo/fde or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of FDE digest..." Today's Topics: 1. FIPS 140-2: When operated in FIPS mode? (Flagstone, Spyrus, Utimaco, Poinsect, MobileArmor) (Ali, Saqib) 2. Re: FIPS 140-2: When operated in FIPS mode? (Flagstone, Spyrus, Utimaco, Poinsect, MobileArmor) ([EMAIL PROTECTED]) 3. Re: Fujistu announces 2,5 inch SATA HDD with FDE (Duane Dyar) 4. Re: Microsoft COFEE, - Alternatively a True Brute Force Attack on RFID (Allen) ---------------------------------------------------------------------- Message: 1 Date: Thu, 1 May 2008 12:54:40 -0700 From: "Ali, Saqib" <[EMAIL PROTECTED]> Subject: [FDE] FIPS 140-2: When operated in FIPS mode? (Flagstone, Spyrus, Utimaco, Poinsect, MobileArmor) To: fde <FDE@www.xml-dev.com> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 I was looking at the FIPS 140-2 Certificate[1] for the Stonewood's Flagstone product, and it has a clause that says "(When operated in FIPS mode)". What does this clause mean? I was under the impression that since Flagstone only implement FIPS validated encryption algorithms (128-bit AES CBC/ECB and ANSI X9.31 AES 128 bit RNG) there would no non-FIPS mode. I later found out that, Spyrus, Utimaco, Poinsect, MobileArmor have the same clause. 1. http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140crt/140crt779.pd f ------------------------------ Message: 2 Date: Thu, 1 May 2008 15:47:25 -0500 From: <[EMAIL PROTECTED]> Subject: Re: [FDE] FIPS 140-2: When operated in FIPS mode? (Flagstone, Spyrus, Utimaco, Poinsect, MobileArmor) To: <fde@www.xml-dev.com> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Just because they use FIPS approved or validated algorithms doesn't mean they are FIPS validated modules. There is much more than just correctly implementing the algorithm to FIPS mode. Some that come to mind are zeroizing the key store if a tamper is suspected, or if account lock-out numbers are reached, etc. Depending on the level of validation physical keys (dongles, USB, smart cards) are needed to enable the device. Most encryption products have the option of running in FIPS mode or non-FIPS mode. Generally FIPS modes are far more restrictive and slower than necessary for typical non-classified usage. But, if you are storing the root of your PKI on the disk, it would probably be considered a best practice. Eric Lengvenis Security Architecture This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ali, Saqib Sent: Thursday, May 01, 2008 2:55 PM To: fde Subject: [FDE] FIPS 140-2: When operated in FIPS mode? (Flagstone, Spyrus,Utimaco, Poinsect, MobileArmor) I was looking at the FIPS 140-2 Certificate[1] for the Stonewood's Flagstone product, and it has a clause that says "(When operated in FIPS mode)". What does this clause mean? I was under the impression that since Flagstone only implement FIPS validated encryption algorithms (128-bit AES CBC/ECB and ANSI X9.31 AES 128 bit RNG) there would no non-FIPS mode. I later found out that, Spyrus, Utimaco, Poinsect, MobileArmor have the same clause. 1. http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140crt/140crt779.pd f _______________________________________________ FDE mailing list FDE@www.xml-dev.com http://www.xml-dev.com/mailman/listinfo/fde ------------------------------ Message: 3 Date: Thu, 1 May 2008 16:16:18 -0500 From: "Duane Dyar" <[EMAIL PROTECTED]> Subject: Re: [FDE] Fujistu announces 2,5 inch SATA HDD with FDE To: <fde@www.xml-dev.com> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" You can modify the Windows operating system to use a FIPS Mode Operation by opening the MMC console and changing the local security policy. This will enable either a FIPS 140-1 or 140-2 validation mode depend on the OS (Vista or something older). Duane -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hubbert Smith Sent: Wednesday, April 30, 2008 11:21 PM To: fde@www.xml-dev.com Subject: Re: [FDE] Fujistu announces 2,5 inch SATA HDD with FDE Hi all, great thread, by the way. Pls keep it coming. I'm not an expert, but I have read the spec. FIPS does define "cryptography modules". FIPS does not require encrypted drives http://en.wikipedia.org/wiki/FIPS_140 http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf so, I did not read anything that says that the "cryptography module" _must_ be a disk drive and I did not read anything that says the cryptography module _cannot_ be a laptop. I guess what I'm attempting to sort out ... it appears FIPS compliance for laptops can be attained with O/S level encryption, today. (am I wrong?) so are we attempting to solve a problem of FIPS compliance for _all_ laptops or are we attempting to improve performance for _some_ FIPS compliant laptops? cheers Hubbert ----- Original Message ---- From: Scott S <[EMAIL PROTECTED]> To: fde@www.xml-dev.com Sent: Wednesday, April 30, 2008 6:52:51 PM Subject: Re: [FDE] Fujistu announces 2,5 inch SATA HDD with FDE This might be possible for desktop computers where space is not a constraint. However, in laptops (which are the computers that are most vulnerable to theft and lost) where form factors are so specific and compact, it would be problemmatic, especially to make it generic enough to fit all brands. There is also the manufacturing aspect of it. Integration of components brings down the overall cost of production. Once components are separated out, it will be another product line with its own margins and price points. Scott On Tue, 29 Apr 2008, Simson Garfinkel wrote: > Would it not be possible to certify an encryption module that fits > between the hard drive and the host computer? This would allow you to > use off-the-shelf drives while maintaining certification... > > > On Apr 29, 2008, at 8:40 PM, Ali, Saqib wrote: > >> This is precisly the issue with obtaining FIPS certification for hard >> drives. >> >> Hard Drive design and development moves at a extremely rapid pace. >> Time to market and innovation is key in the disk drive business. >> Manufacturers like Hitachi, Fujitsu and Seagate have to release newer >> hardware every month to keep ahead of the competition. Whereas >> obtaining FIPs certification is a slow and time consuming process. By >> the time these manufacturers obtain FIPS for a certain hardware, that >> hardware is already few generations old. >> > _______________________________________________ > FDE mailing list > FDE@www.xml-dev.com > http://www.xml-dev.com/mailman/listinfo/fde > _______________________________________________ FDE mailing list FDE@www.xml-dev.com http://www.xml-dev.com/mailman/listinfo/fde ________________________________________________________________________ ____________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ _______________________________________________ FDE mailing list FDE@www.xml-dev.com http://www.xml-dev.com/mailman/listinfo/fde ------------------------------ Message: 4 Date: Thu, 01 May 2008 17:43:38 -0700 From: Allen <[EMAIL PROTECTED]> Subject: Re: [FDE] Microsoft COFEE, - Alternatively a True Brute Force Attack on RFID To: Cryptography <[EMAIL PROTECTED]> Cc: ekmi <[EMAIL PROTECTED]>, fde@www.xml-dev.com Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Funny you should be talking about this just as EFF references an article on BoingBoing where the "brute force attack" of choice against RFID is a hammer. ;-> As to the Microsoft COFEE brute forcing passwords using tools on a USB key, I'd guess there is a lot of FUD involved. I don't believe one could shoehorn a Rainbow Table of a reasonable size into any current USB key, so one would be reduced to either LANMAN attacks or wiping the SAM file of the computer itself running ISOLinux. This would destroy the validity of the evidence for courtroom evidence purposes as not being able to prove that the data was not tampered with. A true brute force attack against 10 characters and a 66 (U/L alpha and numeric plus 4 non-alphanumeric) or so key space at 15X10^6 keys/second - average decent dual core rate - would take about a year assuming that you had a terabyte of storage on a portable USB drive with a pre-computed table that might conceivably take as little as 3+ years to pre-compute at 15x10^9 keys/second. Add one more character to the password length or increase the key space and pre-computing the Rainbow Table is a couple of hundred years or more. So then what are you left with? You can map the files without the password if the disk is not encrypted and get a lot of information that way, but forget this if the drive(s) or the files are encrypted. FCCU Linux has almost all the tools one needs and it will fit and run from a USB key, so who needs Microsoft? The takeaway is encrypt the drive/files and use a password of at least 12 characters and a key space of U/L alpha, numeric and the common other keys and your computer is secure enough for the moment. Tomorrow? Who knows. Allen BTW, Thanks to "Rainbow Chain Hash Cracking Calculator" by Tom Sullivan for the figures on key strength. If you can't find a copy of this, I'll send you one. Adam Shostack wrote: > My understanding, based mostly on what I've read in the press, is that > COFFEE is a set of scripts that run existing tools, making it easier > for law enforcement to do things which are already known to be > possible. Note the words "executing 150 seperate commands," which, I > think, would be odd if this was something other than scripts, but > appear in a lot of the news stories. > > For example, I believe that there are several freely available > password cracking tools and some commercial ones. For example, you can > order John the Ripper to decrypt a system password on some operating > systems. I have no idea if a password cracker is included. > > Speaking for me. > > Adam > > On Wed, Apr 30, 2008 at 03:36:28PM -0400, Arshad Noor wrote: > | It can be "ordered to decrypt system passwords"??? So, I wonder > | what attackers can do with this... > | > | Arshad Noor > | StrongAuth, Inc. > | > | "Microsoft revealed its development of a digital forensic analysis toolkit at a security conference yesterday as part of a wider discussion of how technology can be used to fight crime. The Computer Online Forensic Evidence Extractor, or COFEE for short, is a USB thumb drive that contains software capable of executing approximately 150 separate commands. Once plugged in, COFEE can be ordered to decrypt system passwords, display a history of internet activity, and search the system for evidence...." > | > | http://arstechnica.com/news.ars/post/20080429-new-microsoft-law-enforcem ent-tool-bypasses-pc-security.html > | > | --------------------------------------------------------------------- > | The Cryptography Mailing List > | Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > ------------------------------ _______________________________________________ FDE mailing list FDE@www.xml-dev.com http://www.xml-dev.com/mailman/listinfo/fde End of FDE Digest, Vol 20, Issue 2 ********************************** _______________________________________________ FDE mailing list FDE@www.xml-dev.com http://www.xml-dev.com/mailman/listinfo/fde
