Hi, thanks for answering. I have some more detailed notes inline
On 03/25/2015 05:41 PM, Robert Relyea wrote: > On 03/25/2015 04:30 AM, Jan Otte wrote: >> Hi, >> >> When finding out how to do key zeroization in NSS DB I stumbled upon >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=347450 >> >> The last comment states that key zeroization is not needed for FIPS, >> which is in contrast with the initial description. >> >> What is the reason behind this - why is the key zeroization in NSS DB >> not needed? > > This isn't about zeroization of the database, it's about zeroing the > internal databuffers from the database. Those buffers don't need to be > zeroized because the data in them is encrypted. Keys in your nss > database are stored encrypted, which is why you need to supply a > password before you use it. If you don't have to supply a password, then > the keys are still encrypted, but they key they are encrypted in can be > trivially calculated given an NSS database (the password is set to the > NULL string). While I get the idea of encryption of the DB, unfortunately from the FIPS point of view the DB content is considered plaintext. We got this statement from our consultant and it maps to the bug report - citing: BR> For NSS, we can interpret "and CSPs" as "and passwords/PINs". BR> Since password-based encryption is not FIPS Approved, our BR> key database's contents are considered in plaintext form, BR> even though we password-encrypt the contents using PKCS #5. So unfortunately, we need a method for zeroing out the DB content. Yeah I am aware that zeroing out a piece of data in encrypted DB is silly, but to get the FIPS 140-2 certification you need to play by their rules. I was simply hoping (after reading the last comment in bugreport) there is a FIPS-sound argument we could use to completely avoid zeroing out a DB. If not, we are considering overwriting the DB file on a disk by zeroes (I guess it is sqlite but actually have not checked for this) and re-initializing the DB afterwards. > > As for zeroization of the database itself, it depends on why you want to > do it. If you are trying to meet a particular security policy are just > paranoid, you can set the password to an arbitrarily random string that > you don't save (like the output of 128 bytes of /dev/random converted to > hex). Setting the password reencrypts each entry in the database with > that password. At this point you can simply do a database reset. (which > basically deletes the old database and creates a new empty database). If > you just want to 'get rid of your keys' you ca simply do a database > reset, though in that case it's possible that data blocks in your > database are still floating around on your harddisk free list. > > It should be obvious that both of these methods would get rid of all > your private and secret keys. What may not be obvious is the secret keys > used to encrypt your website passwords will also be gone... Even if you > didn't have an NSS password set initially (those passwords are also > always encrypted and if you loose or change your NSS key database you > will loose those passwords as well). > We are using NSS in a server solution for storing keys (for IPSEC) so there are no website passwords. Basically, zeroing out a DB means 'get rid of the keys in FIPS fashion'. Fortunately we don't need this zeroization functionality very often - it could be initiated on a user request only ('get rid of all keys'). It just needs to be there. > Also it may not be obvious that this only affects the key database, not > the cert database. The cert database stores cryptographicly public > information (that is information that can be sent publicly without > breaking cryptographic security). For example, your personal email and > client auth certificates are stored in the cert database. You can't use > them for signing, authentication, or email decryption however, without > the associated private keys, so the certs will still be accessible, but > they won't be usable as user certs (they won't show up in the user cert > side of the firefox cert view, for example). > Thourough answer, thanks for that. Jan > bob >> >> Thanks & best regards, >> Jan > > > > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
