You asked: Is there a standard documentation, which says these are FIPS compliant ciphers / macs / kex algorithms.
I haven't found such a quick reference, and I really wouldn't trust such without doing the research myself. So, go back to the original source material. Start with NIST's CSRC listing of FIPS publications at http://csrc.nist.gov/publications/PubsFIPS.html , then look at FIPS 200 for all of the FIPS mandates, including the requirements of where cryptography must be performed. *Do not shirk these or think that you can ignore any one or several of them because they don't make sense or seem trivial. They have the force of law for Federal procurement, and someone must personally sign and certify that the deliverable meets absolutely every one of these requirements; if even one of them is found to have not been met, that person will likely go to prison, the company you work for may have to give back some or all of the money it received from the contract, and other unpleasantness can and probably will occur.* Then, look at FIPS 140-2 (including annexes A through D) for the approved algorithms which you must select from. Absolutely all cryptography must be done in a FIPS 140-2 validated module which is approved for that particular algorithm, or it cannot be FIPS compliant. When you're done there, go to the Special Publications page and look at SP 800-38 and SP 800-38A through F, for recommended modes of operation for specific algorithm types. I don't know if the FIPS documents absolutely require that only recommended modes be used, but it's safe to say that you absolutely should not use any modes of operation that SP 800-38 etc do not recommend. n.b.: I am not a lawyer, and this is not legal advice (it is intended more as a friendly suggestion that you should really verify exactly what your legal obligations are). I suggest that you consult with a US-based attorney who is used to dealing with federal procurement contracts and contract law. I would suggest making a checklist of everything in the FIPS publications that needs to be guaranteed, and then (before delivery) going through every line of those lists and verifying that they are met in absolutely all circumstances. Have the person who actually verified it sign and date that checklist line. And ensure that you keep all of the code in the deliverable as well as all materials you reference -- including the FIPS and SP 800-38 series of documents -- in a secure repository (backing it up to offline tape -- not just an external server you mirror it to -- regularly). Document exactly where each piece of external code came from, and who put it into the system. Use paper, not just electronic files, and keep those papers in heavy-duty secure and fireproof filing cabinets and safes. Force your employees to actually sign those papers when they add something to the system. Scan them, sign/maybe encrypt them, and store them into another secure repository (you really don't want this to be the same one that you keep the source code in) that you back up to tape. And also, keep track -- also on paper -- of exactly who has what keys to which safes. You truly do not want to find that your records have been tampered with in the middle of an audit or investigation. It also can't hurt to scan the pages in and sign/encrypt them to ensure that nothing has been tampered with, and you should also put those in yet another secure repository, which you also back up to tape. And keep a really comprehensive retention schedule for those tapes, with off-site storage too, that will last *at least* until the specified end date of the procurement contract, and preferably for 7 years after that. Yes, this is an incredible amount of overhead, and an incredible amount of additional cost. It will probably also (given my experience with programmers and the culture of "get it done without showing how") introduce a severe culture clash. Unfortunately, governments really like to be able to audit exactly where any fault was introduced, and will usually come down really hard on anyone or any company who doesn't give it the opportunity to do so. FIPS compliance should really be said to be an entire documentive process of development, not just "what the software must do". You have to be able to *show*, with documentation, that the person signing the delivery compliance certificate signed it in good faith. The reward for doing this? To be able to pick up more government contracts, and to be able to figure out where problems happen so you can analyze their patterns. This is how government works. The upshot is, as long as you show that you're operating in good faith, with the best capacities you have available, they probably won't come down on you too hard for not meeting every one of the things they try to press you for. "Why don't you have this?" "We didn't know we should until some random guy on the Internet pointed out that we might need it. You certainly never gave us a syllabus on what you would demand if you audited us. So, we couldn't budget the resources to keep that information." (They do understand the word "budget".) Good luck! -Kyle H (Also, if you want to be taken seriously, you should probably get rid of the Comic Sans MS font.) On 7/16/2014 6:41 AM, Sadhana wrote: > Thanks Steve. > Is there a standard documentation, which says these are FIPS compliant > ciphers / macs / kex algorithms. > > Meaning I would need to know, if aes128-cbc is FIPS compliant/ > aes128-ctr is FIPS compliant. > Similarly for macs, kex algorithms as well. > > > > On Wed, Jul 16, 2014 at 4:47 PM, Steve Marquess-3 [via OpenSSL] > <[hidden email] </user/SendEmail.jtp?type=node&node=52092&i=0>> wrote: > > On 07/15/2014 09:38 AM, Sadhana wrote: > > > Hello All, > > > > I have a requirement to make Openssh FIPS compliant. It would > be really > > helpful, if you could answer the > > below question and correct me if I am wrong. > > > > I also understand there is a module called as fipscanister.o is > introduced > > in Openssl. > > This ensures, FIPS compliancy. This also, exposes the API > FIPS_mode and > > FIPS_set_mode. > > We have already integrated openssl with fipscanister.o. > > > > Is there any way by which, Openssh can make use of fipscanister > module > > directly? > > > > I understand, Openssh needs to call FIPS_mode, FIPS_set_mode to > ensure it > > operates in FIPS mode. > > I understand, few of the ciphers, MACs, kex algorithms are fips > compliant > > and few others are not. > > Hence, openssh code has to be modified to allow only those which > are fips > > compliant. > > > > Are there any more stuff which needs to be done? > Yes. Converting an application to use the "FIPS capable" OpenSSL and > qualify as using a FIPS 140-2 validated crypto module *can* be as > simple > as adding a FIPS_mode_set() call. However, modifying OpenSSH for FIPS > 140-2 compliance is non-trivial as OpenSSH implements a number of > cryptographic operations outside of OpenSSL. It's not enough that > only > cryptographic algorithms allowed by FIPS 140-2 are used, those crypto > operations must be performed *within* a validated module. > > Or in other words, an application which hopes to claim to satisfy the > USG/DoD requirements for FIPS 140-2 validated cryptography must use > validated module(s) for all relevant cryptography. The "FIPS capable" > OpenSSL libraries satisfy that requirement but only if OpenSSL is > used > exclusively. > > You can find a patch at > > > > http://opensslfoundation.com/export/openssh/openssh-6.0p1.fips-revised.patch > > which adapts a now obsolete version of OpenSSH to use the FIPS > capable > OpenSSL. New inlined cryptography has been added since then so I > suspect > additional non-trivial work will be necessary. I haven't been keeping > track but other newer patches may be available elsewhere. > > Also note than in a U.S. DoD context you'll probably need x.509 > support > as well (this is available in patches from Roumen Petrov). > > -Steve M. > > -- > Steve Marquess > OpenSSL Software Foundation, Inc. > 1829 Mount Ephraim Road > Adamstown, MD 21710 > USA > +1 877 673 6775 s/b > +1 301 874 2571 direct > [hidden email] <http://user/SendEmail.jtp?type=node&node=52085&i=0> > [hidden email] <http://user/SendEmail.jtp?type=node&node=52085&i=1> > gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc > > ______________________________________________________________________ > > OpenSSL Project http://www.openssl.org > User Support Mailing List [hidden email] > <http://user/SendEmail.jtp?type=node&node=52085&i=2> > Automated List Manager [hidden email] > <http://user/SendEmail.jtp?type=node&node=52085&i=3> > > > ------------------------------------------------------------------------ > If you reply to this email, your message will be added to the > discussion below: > > http://openssl.6102.n7.nabble.com/Making-Open-SSH-FIPS-compliant-tp52064p52085.html > > To unsubscribe from Making Open SSH FIPS compliant, click here. > NAML > > <http://openssl.6102.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > > > > > ------------------------------------------------------------------------ > View this message in context: Re: Making Open SSH FIPS compliant > <http://openssl.6102.n7.nabble.com/Making-Open-SSH-FIPS-compliant-tp52064p52092.html> > Sent from the OpenSSL - User mailing list archive > <http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html> at Nabble.com.
smime.p7s
Description: S/MIME Cryptographic Signature
