This is my understanding of the rules, and I will freely admit that I am probably not qualified to give an appropriate discourse on this.
The secret key that is used to encrypt a private key is generated from the passphrase, which itself is not the secret key. It is a "Key Generator". In order for the application to be FIPS-compliant, the private key must never be exported (or written to disk) without being encrypted by some approved encryption algorithm of some form. 4.4 is apparently expounding on how to properly handle (even encrypted) private key material, regardless of whether it mentions encryption of that key material or not -- appropriate logical security mechanisms. (OpenSSH is not, itself, FIPS-certified. A version of OpenSSH that used the FIPS-certified OpenSSL would not export passphraseless private keys, and would refuse to accept an unencrypted private key, under rule 4.1.10.) Note that a key can be accessible to the system via a mechanism such as Windows 2000's syskey floppy disk, or a FIPS-approved storage module. [It could theoretically even be accessible from an SSL/TLS server, using a client (machine or service principal) certificate for authentication, as long as the SSL/TLS session used only FIPS-approved or FIPS-allowed algorithms, and the master server used a FIPS-approved security system, was appropriately physically controlled, and a passphrase or key disk required to restart it in the event of failure.] How far off am I? (I would really like to know, as I'm working on a project that would definitely benefit from FIPS compliance.) -Kyle H On 2/1/06, Mike McEwen <[EMAIL PROTECTED]> wrote: > I have a question about storage of private keys outside of the FIPS > module and about CSPs in general - > > > In section 4.1, Rules of Operation, rule 10 is given as: > > "Secret or private keys that are input or output from an application > must be input or output in encrypted form using a FIPS approved algorithm". > > What are the implications or this? > If keys are input in an encrypted form how do you decrypt them? > Doesn't the key you use to decrypt them have to be input into the > application in an encrypted form too, how do you ever input an > unencrypted key into your application to decrypt your encrypted keys?! > > Is this rule implying that for your application to be FIPS 14-2 > compliant you have to passphrase protect all your keys? Does a > passphrase not count as a key when input into your application? > > > Also in section 4.4, Critical Security Parameters, OpenSSH is given as > an example and it says: > > "The persistent per-user CSPs (public and private keys) are stored in > the ~/.ssh/ subdirectory and the application enforces the presence of > appropriate permissions (private key owned by the user account and not > world readable or group writable)" > > This doesn't mention any kind of encryption for the keys (I believe > encrypting private keys is optional in OpenSSH?). > > > So basically, what kind of protection do you have to have for private > keys and CSPs to conform to the security policy? > > > - Mike. > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
