I was "beached", sorry for the late reply.
On Thu, 7 Jun 2012, Alexander Graf wrote: > On 07.06.2012, at 05:10, Anthony Liguori wrote: > > On 06/07/2012 06:56 AM, Paul Moore wrote: > >> On Wednesday, June 06, 2012 01:56:52 AM Alexander Graf wrote: > >>> The other one (FIPS) is basically a list of encryption algorithms that are > >>> deemed OK and not crackable within seconds by anyone. > >>> > >>> Only one of the 2 doesn't help much. In combination they actually enhance > >>> security. This patch is only about FIPS though. > >> > >> I don't have much to add beyond what Alex already posted. FIPS 140-2 > >> outlines > >> a set of security requirements for systems implementing cryptography in a > >> variety of forms; the full requirements are likely beyond the scope here > >> but > >> you can always read the full specification (Google knows where to find the > >> document). > >> > >> The relevant portion appears to be annex A which lists the approved ciphers > >> and their approved uses; DES is not listed as an approved cipher and that > >> is > >> the main problem we are trying to solve right now. > > > > But does FIPS mandate that it's impossible for a user to use an unapproved > > cipher? > > > > IOW, is just having this feature implemented at the libvirt level good > > enough to satisfy FIPS? Do we really need to do this in QEMU? > > What would implementing it in libvirt buy us? That only stacks using > libvirt can be FIPS certified? That any time a management stack that > does not use libvirt they need to duplicate that code to be FIPS > certified? > > I would rather have the "FIPS certified" stamp on QEMU than on libvirt > ;). The same way you would usually certify openssl and any user of it > (usually) inherits the certification. So by having QEMU FIPS certified, > we could reasonably assume libvirt to be FIPS certified. And Ganesi (or > whatever it's called). And other stacks that don't go through libvirt > hell. > Just to add some small bits and pieces about FIPS-140-2 that may turn out to be useful, and clear up some misunderstandings. It is a crypto certification, which has not much to do with security, but rather with making sure that the algorythms used are implemented in such way that they produce testable results. FIPS defines a so-called module, which is a region of code in a program, library or whatever that contains the cryptographic routines. The software must make use of these cryptographic routines exclusively in order to be able to make a claim about FIPS compliance - or something similar. You'd want to minimize the code contained in the crypto boundary to be able to reduce the testing work for FIPS, but still have sufficient functionality. About such claims: There is a distinction between * The software makes use of a library that is FIPS-140-2 certified. * The software is FIPS-140-2 certified. There may be someone who is willing to pay for a FIPS-140-2 validation of qemu, but this is very unlikely. The weaker claim, "makes use of FIPS-140-2 certified crypto" is enough for most cases. About enforcement of algo use: FIPS-140-2 has four levels, of which 3 and 4 can only be achieved by hardware implementations (smartcards, crypto coprocessors, ...), 1 and 2 also by software. Level 1 says that the solution must only use approved algorythms, but there is no requirement about enforcing this. Level 2 requires enforcement. As a consequence, for qemu to be able to run with a crypto library that is FIPS-140-2 certified, it should be aware of the FIPS mode if there is any, and refrain from initializing cryptography that is not allowable (crypt(3) aka DES, but also MD5 (is a no-go)). In addition to that, qemu must not have any own algorythm implementations (convenient...). > Alex Thanks, Roman.
