Re: Full Disk Encryption solutions selected for US Government use
On 8 Oct 2007 10:12:58 -0700, Stephan Somogyi wrote: At 02:11 +1300 09.10.2007, Peter Gutmann wrote: But if you build a FDE product with it you've got to get the entire product certified, not just the crypto component. I don't believe this to be the case. FIPS 140(-2) is about validating cryptographic implementations. It is not about certifying entire products that contain ample functionality well outside the scope of cryptographic evaluation. That's more of a Common Criteria thing. Yes, but an FDE product built on the OSSL FIPS module would not likely meet the FIPS 140-2 check box, as there is potentially more FIPS 140-2 relevant functionality in the FDE product beyond what was validated in the OSSL module, such as, say, the whole key life cycle for the FDE product. That does not necessarily mean all of the FDE product is FIPS relevant, so perhaps the FIPS relevant functionality in the FDE product could be self-contained and validated by itself, or perhaps the whole FDE product could be validated and the irrelevant functionality just excluded from the FIPS requirements, etc. (As Gutmann says though, vendors sometimes successfully employ a bit of hand-waving here, so you never quite know what will satisfy the FIPS check box.) At 14:04 +0100 08.10.2007, Ben Laurie wrote: ? OpenSSL has FIPS 140. OpenSSL FIPS Object Module 1.1.1 has FIPS 140-2 when running on SUSE 9.0 and HPUX 11i, according to http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2007.htm#733 In the context of a conversation about whether something formally has FIPS validation or not, the details are important. Yes, the details are important. The OSSL FIPS module was tested on those platforms, but is vendor affirmed on other platforms, assuming the module meets the vendor affirmation requirements described in the FIPS 140-2 implementation guidance on a given other platform. -Andrew - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Full Disk Encryption solutions selected for US Government use
| A slightly off-topic question: if we accept that current processes | (FIPS-140, CC, etc) are inadequate indicators of quality for OSS | products, is there something that can be done about it? Is there a | reasonable criteria / process that can be built that is more suitable? Well, if you believe a talk by Brian Snow at the NSA - see http://www.acsac.org/2005/papers/Snow.pdf - our whole process has to change to get assurance, from the beginnings of the design all the way through the final product. I suspect he's right - but I'm also pretty sure that the processes involved will always be too expensive for most uses. They'll even be too expensive for the cases where you'd think they best apply - e.g., in protecting large financial transactions. An analysis of the costs vs. the risks will usually end up with the decision to spend less and spread the risks around, whether through insurance or higher rates or other means. We keep being told that inspection after the fact will give us more secure systems. It never seems to work. You'd think that the experience of, say, the US auto industry - which was taught by the Japanese that you have to build quality into your entire process, not inspect *out* lack of quality at the end - would give us some hint that after-the-fact inspection is not the way to go. Given all that ... a FIPS 140-2 certification is actually a pretty reasonable evaluation. It can be because it's trying to deal with a problem that can be constrained to a workable size. You know what's supposed to go in; you know what's supposed to come out. (This still works better for hardware than for software, though.) Where FIPS 140-2 breaks down is that ultimately all it can tell you is that some constrained piece of the system works. But it tells you nothing, and *can* tell you nothing, about whether that piece is being used in a proper, secure way. (Again, this is somewhat easier with hardware, because the system boundaries are much more sharply defined - and because of the inflexibility of hardware, they are also much smaller.) Beyond this is Common Criteria, which can easily be more about paperwork than anything real. Until someone comes up with a new way to approach the problem, my guess is that we'll see more stuff moved into hardware, with limited security definitions above the hardware that we can have some faith in - but as little of real value to be said above that as there is today. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Full Disk Encryption solutions selected for US Government use
On Oct 8, 2007, at 4:27 AM, Steven M. Bellovin wrote: On Mon, 18 Jun 2007 22:57:36 -0700 Ali, Saqib [EMAIL PROTECTED] wrote: US Government has select 9 security vendors that will product drive and file level encryption software. See: http://security-basics.blogspot.com/2007/06/fde-fde-solutions-selected-for-us.html OR http://tinyurl.com/2xffax Out of curiousity, are any open source FDE products being evaluated? --Steve Bellovin, http://www.cs.columbia.edu/~smb Out of curiousity, Vista (BitLocker) was not mentioned? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Full Disk Encryption solutions selected for US Government use
We submitted a letter to the Program Manager, that while they RFP was asking for an FDE solution, they really needed to focus on Key Management across the agency, rather than the actual encryption solution itself, before they deployed any encryption product. We proposed our open-source Symmetric Key Management System (SKMS) software - StrongKey - as a solution since it includes utilities to perform file, directory and column-level database encryption using FIPS-certified tokens: smartcards, HSMs and software modules (NSS). Given that the solution we proposed was OSS, that it could leverage any FIPS-certified token through their published JCE/PKCS11 library, and that the StrongKey protocol is winding its way through OASIS towards becoming the Symmetric Key Services Markup Language (SKSML) with the support of 33 companies/individuals including the DoD, we believed that this solution was optimal for the government from many different points of view. However, because the RFP was narrowly written for FDE products only, our submission was not accepted. That's life in the Federal procurement lane they think they're buying a state of the art security solution and they don't realize that the state of the art has already shifted under their feet. Arshad Noor StrongAuth, Inc. - Original Message - From: Steven M. Bellovin [EMAIL PROTECTED] On Mon, 18 Jun 2007 22:57:36 -0700 Ali, Saqib [EMAIL PROTECTED] wrote: US Government has select 9 security vendors that will product drive and file level encryption software. See: http://security-basics.blogspot.com/2007/06/fde-fde-solutions-selected-for-us.html OR http://tinyurl.com/2xffax Out of curiousity, are any open source FDE products being evaluated? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Full Disk Encryption solutions selected for US Government use
At 02:11 +1300 09.10.2007, Peter Gutmann wrote: But if you build a FDE product with it you've got to get the entire product certified, not just the crypto component. I don't believe this to be the case. FIPS 140(-2) is about validating cryptographic implementations. It is not about certifying entire products that contain ample functionality well outside the scope of cryptographic evaluation. That's more of a Common Criteria thing. That said, one problem with selling FIPSed products to USG is that some auditors are sticklers for version numbers. They can require proof/repwarrant that the FIPSed version of the crypto is actually in use. Audit appeasement requirements frequently cause considerable annoyance to both vendors and the end user. At 14:04 +0100 08.10.2007, Ben Laurie wrote: ? OpenSSL has FIPS 140. OpenSSL FIPS Object Module 1.1.1 has FIPS 140-2 when running on SUSE 9.0 and HPUX 11i, according to http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2007.htm#733 In the context of a conversation about whether something formally has FIPS validation or not, the details are important. Back to the original question... At 11:27 + 08.10.2007, Steven M. Bellovin wrote: Out of curiousity, are any open source FDE products being evaluated? As far as I recall, none such were submitted for consideration. Bear in mind that the process isn't just about software, but that a commercial entity submits both a product that meets the list of capability checkboxes, and that the entity itself is viable and can provide support and the like. s. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Full Disk Encryption solutions selected for US Government use
Arshad, Some of the solutions already include a KMS. One of the key requirements of this particular RFP was Transparency. Can you please elaborate more on how StrongKey KMS would have improved on transparency? Thanks saqib http://security-basics.blogspot.com/ On 10/8/07, Arshad Noor [EMAIL PROTECTED] wrote: We submitted a letter to the Program Manager, that while they RFP was asking for an FDE solution, they really needed to focus on Key Management across the agency, rather than the actual encryption solution itself, before they deployed any encryption product. We proposed our open-source Symmetric Key Management System (SKMS) software - StrongKey - as a solution since it includes utilities to perform file, directory and column-level database encryption using FIPS-certified tokens: smartcards, HSMs and software modules (NSS). Given that the solution we proposed was OSS, that it could leverage any FIPS-certified token through their published JCE/PKCS11 library, and that the StrongKey protocol is winding its way through OASIS towards becoming the Symmetric Key Services Markup Language (SKSML) with the support of 33 companies/individuals including the DoD, we believed that this solution was optimal for the government from many different points of view. However, because the RFP was narrowly written for FDE products only, our submission was not accepted. That's life in the Federal procurement lane they think they're buying a state of the art security solution and they don't realize that the state of the art has already shifted under their feet. Arshad Noor StrongAuth, Inc. - Original Message - From: Steven M. Bellovin [EMAIL PROTECTED] On Mon, 18 Jun 2007 22:57:36 -0700 Ali, Saqib [EMAIL PROTECTED] wrote: US Government has select 9 security vendors that will product drive and file level encryption software. See: http://security-basics.blogspot.com/2007/06/fde-fde-solutions-selected-for-us.html OR http://tinyurl.com/2xffax Out of curiousity, are any open source FDE products being evaluated? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Full Disk Encryption solutions selected for US Government use
Saqib, ALL the solutions include a KMS. They all must, because encryption keys must be generated, escrowed, recovered, managed, policies defined, etc. for any encryption to work. And *that* is the problem - each of the KMSs is implemented in the vendors own design, using the vendor's proprietary API and protocol. Since the DAR RFP finally settled on 9 different FDE solutions, the end-result is that the agencies must now manage nine different KMSs and deal with all that that entails: 9 different KMS implementations, 9 different operating procedures, 9 different training sessions, 9 different audits, and on and on... In reality, the agencies are probably going to have to manage more than 9 KMS, because the RFP did not address encryption of databases, devices (other than disks) and application data that is not persisted to disk. And that is the precise problem that StrongKey addresses. It is a single enterprise-wide symmetric key-management system (SKMS) that provides an open-source API for any application to integrate, and a potential OASIS protocol that can work in most environments and platforms. Our design goal for StrongKey was that it must function like DNS or DHCP - a centralized server environment that defines and manages all KM functions and a single library on the client to handle requests for any application on the client while using an industry-standard protocol to get KM services from the server, securely. Even the IEEE 1619.3 WG has recognized the importance of integrating their KM protocol for storage devices into an Enterprise Key Management Infrastructure (EKMI) and has carved out a name-space within its protocol for the OASIS work. WRT transparency, StrongKey provides key-management services - not FDE - unless an OS driver integrated the StrongKey API or the SKSML protocol. The open-source implementation provides file, directory and column-level database encryption - but does not perform any of this automatically unless the application has integrated the Symmetric Key Client Library (SKCL) into it. While the standard response to this statement is - applications will never get modified to perform encryption and that all customers want automatic and transparent encryption/decryption at the storage layer, our contention is that once you automatically encrypt/decrypt at the disk-drive layer, the attackers will just move up one layer above the application/OS stack and read-off the plaintext (see slides 21 and 22 for graphics) as the disk-drive decrypts it for them. Customers will then need to encrypt at a higher-layer to protect data agin: http://www.oasis-open.org/committees/download.php/24594/ekmi-webinar.pdf Customers need to protect data - but they do not need to address the same problem more than once. Encrypting at the disk-firmware layer is a short- term solution that will diminish in protection-value very quickly. Until the data is encrypted/decrypted in the final application that uses it, attackers will keep moving up the application stack. Note that this does not mean that encryption-enabled applications are invulnerable to attacks; all it means is that the attack-surface has now been reduced to a minimum and that developers/security professionals can focus their energy on protecting the area that matters most - the actual applications that use sensitive data. Arshad Noor StrongAuth, Inc. - Original Message - From: Saqib Ali [EMAIL PROTECTED] To: Arshad Noor [EMAIL PROTECTED] Cc: Cryptography cryptography@metzdowd.com Sent: Monday, October 8, 2007 11:52:28 AM (GMT-0800) America/Los_Angeles Subject: Re: Full Disk Encryption solutions selected for US Government use Arshad, Some of the solutions already include a KMS. One of the key requirements of this particular RFP was Transparency. Can you please elaborate more on how StrongKey KMS would have improved on transparency? Thanks saqib http://security-basics.blogspot.com/ On 10/8/07, Arshad Noor [EMAIL PROTECTED] wrote: We submitted a letter to the Program Manager, that while they RFP was asking for an FDE solution, they really needed to focus on Key Management across the agency, rather than the actual encryption solution itself, before they deployed any encryption product. We proposed our open-source Symmetric Key Management System (SKMS) software - StrongKey - as a solution since it includes utilities to perform file, directory and column-level database encryption using FIPS-certified tokens: smartcards, HSMs and software modules (NSS). Given that the solution we proposed was OSS, that it could leverage any FIPS-certified token through their published JCE/PKCS11 library, and that the StrongKey protocol is winding its way through OASIS towards becoming the Symmetric Key Services Markup Language (SKSML) with the support of 33 companies/individuals including the DoD, we believed that this solution was optimal for the government from many different points of view. However
Re: Full Disk Encryption solutions selected for US Government use
Peter Gutmann wrote: Ben Laurie [EMAIL PROTECTED] writes: Peter Gutmann wrote: Given that it's for USG use, I imagine the FIPS 140 entry barrier for the government gravy train would be fairly effective in keeping any OSS products out. ? OpenSSL has FIPS 140. But if you build a FDE product with it you've got to get the entire product certified, not just the crypto component. (Actually given the vagueness of what's being certified you might be able to get away with getting just one corner certified, but then if you have to use a SISWG mode you'd need to modify OpenSSL, which in turn means getting another certification. Or the changes you'd need to make to get it to work as a kernel driver would require recertification, because you can't just link in libssl for that. Or...). A slightly off-topic question: if we accept that current processes (FIPS-140, CC, etc) are inadequate indicators of quality for OSS products, is there something that can be done about it? Is there a reasonable criteria / process that can be built that is more suitable? iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Full Disk Encryption solutions selected for US Government use
US Government has select 9 security vendors that will product drive and file level encryption software. See: http://security-basics.blogspot.com/2007/06/fde-fde-solutions-selected-for-us.html OR http://tinyurl.com/2xffax - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
