{"id":3559,"date":"2020-03-04T22:06:00","date_gmt":"2020-03-04T21:06:00","guid":{"rendered":"https:\/\/webdev.atsec.us\/?p=3559"},"modified":"2024-08-19T20:46:50","modified_gmt":"2024-08-19T18:46:50","slug":"zen-or-the-art-of-fips-certificate-maintenance","status":"publish","type":"post","link":"https:\/\/webdev.atsec.us\/zen-or-the-art-of-fips-certificate-maintenance\/","title":{"rendered":"Zen, or the Art of FIPS Certificate Maintenance"},"content":{"rendered":"\n<figure class=\"wp-block-image aligncenter size-full is-resized\"><img loading=\"lazy\" decoding=\"async\" width=\"858\" height=\"792\" src=\"https:\/\/webdev.atsec.us\/wp-content\/uploads\/2024\/07\/cards.png\" alt=\"\" class=\"wp-image-3561\" style=\"width:522px;height:auto\" srcset=\"https:\/\/webdev.atsec.us\/wp-content\/uploads\/2024\/07\/cards.png 858w, https:\/\/webdev.atsec.us\/wp-content\/uploads\/2024\/07\/cards-300x277.png 300w, https:\/\/webdev.atsec.us\/wp-content\/uploads\/2024\/07\/cards-768x709.png 768w\" sizes=\"(max-width: 858px) 100vw, 858px\" \/><\/figure>\n\n\n\n<p><font size=\"2\">by Andreas Fabis<\/font><\/p>\n\n\n\n<p>When we talk to our customers about FIPS 140-2 testing some questions regarding certificate maintenance frequently come up:<\/p>\n\n\n\n<ul>\n<li>\u201cWhat happens to my certificate if I make changes to my module?\u201d<\/li>\n\n\n\n<li>\u201cDo I have to re-certify every single time I make a small change?\u201d<\/li>\n\n\n\n<li>\u201cWhat if we want to patch a vulnerability?\u201d<\/li>\n<\/ul>\n\n\n\n<p>There are many factors that can lead to module or platform changes: technical, business and marketing, to name a few. Navigating the rules and options of FIPS 140-2 re-certification can be challenging, and currently there are additional factors and deadlines to consider:<\/p>\n\n\n\n<ul>\n<li>The switch from FIPS 140-2 to FIPS 140-3 (mandatory after September 22nd 2021)<\/li>\n\n\n\n<li>The switch from the Cryptographic Algorithm Validation System (CAVS) to the Automated Cryptographic Validation Testing (ACVT) (mandatory after June 30th 2020)<\/li>\n\n\n\n<li>The switch from FIPS I40-2 IG 7.15 to SP 800-90B compliance (mandatory after November 8th 2020)<\/li>\n<\/ul>\n\n\n\n<p style=\"margin-top:0;margin-bottom:0\">From a FIPS 140-2 point of view, the exact details of the re-certification process and the requirements for the different re-certification scenarios are explained in G.8 of the FIPS 140-2\u00a0<a href=\"https:\/\/www.blogger.com\/#\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">Implementation Guidance (IG)<\/a>. This article is intended to help customers understand the practical implications of the different scenarios.<br><br><strong>Non-security-relevant changes to the module or changes to the platform<\/strong><br>Changes to hardware, software or firmware components that do not affect any security relevant items within the module are covered by scenario 1 (also known as a 1-SUB). Changing the module platform (for a software module) or adding a new platform to an existing module are also common scenarios for 1-SUBs. The laboratory will review the vendor\u2019s documentation to make sure that no security relevant items are affected by either the change of module or the change of platform. In case of changing or adding a new platform, the module needs to be tested on the new platform. The lab then submits a package to the Cryptographic Module Validation Program (CMVP) that contains a letter explaining the nature of the change, the laboratory\u2019s assessment and\u2014depending on the changes\u2014an updated Security Policy and\/or draft certificate. Upon the approval of 1-SUB, the existing FIPS certificate will be updated to reflect the new version of the module or the new platform(s). The certificate expiration date remains the same.<br><br>Another option is to add the new platform as a <em>vendor affirmed platform<\/em>. These platforms will not be listed on the certificate itself, but in the Security Policy that is attached to the certificate listing. Vendor affirmation is not backed up by the CMVP and hence does not carry as much weight as laboratory testing and validation. It is up to the customer whether they accept a vendor\u2019s claim that the module works as expected on the affirmed platforms.<br><strong><br>Security relevant changes to the module<\/strong><br>If there are security relevant changes to the module itself the submission scenario depends on the amount of changes. If the changes are relatively minor (less than 30%), scenario 3 (3-SUB) is applicable. This means that the laboratory will assess the amount and nature of the changes, then perform the applicable testing to make sure the affected security functions still work as expected. The laboratory will submit a test report to the CMVP and upon positive review a new certificate will be issued which is valid for 5 years.<br><br>Scenario 3A (3A-SUB) is specifically meant to address vulnerability patches if the vulnerability is on the <a href=\"https:\/\/www.blogger.com\/#\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">official CVE list<\/a>. In this case the CMVP waives the NIST fee as an incentive to vendors to patch vulnerabilities. The laboratory will perform the applicable regression testing and submit an updated test report. The CMVP will process the 3A-SUB at the speed of 1-SUB. In this case the existing certificate will be updated and the certificate expiration date remains the same.<br><br>If the amount of security-relevant change is above 30%, the module will be submitted under scenario 5 (5-SUB) which is equivalent to a new validation.<br><br>A quick summary of the most common re-certification scenarios:<br><br><figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"692\" height=\"116\" class=\"wp-image-3560\" src=\"https:\/\/webdev.atsec.us\/wp-content\/uploads\/2024\/07\/Screen-Shot-2020-03-04-at-4.17.13-PM.png\" alt=\"\" srcset=\"https:\/\/webdev.atsec.us\/wp-content\/uploads\/2024\/07\/Screen-Shot-2020-03-04-at-4.17.13-PM.png 692w, https:\/\/webdev.atsec.us\/wp-content\/uploads\/2024\/07\/Screen-Shot-2020-03-04-at-4.17.13-PM-300x50.png 300w\" sizes=\"(max-width: 692px) 100vw, 692px\" \/><\/figure><\/p>\n\n\n\n<p><strong>What about FIPS 140-3?<\/strong><br>Modules tested under FIPS 140-2, and their reports submitted before September 22nd 2021, once validated, will stay valid for 5 years. Once FIPS 140-3 has become mandatory, any re-validation of a module validated under FIPS 140-2 will automatically be a 5-SUB under FIPS 140-3.<br><br><strong>Strategies<\/strong><br>The best validation strategy depends on the business needs, development cycles and other variables and may include:<\/p>\n\n\n\n<ul>\n<li>Re-validation of major releases only<\/li>\n\n\n\n<li>Re-validation every 6 or 12 months (accumulate changes)<\/li>\n\n\n\n<li>Re-validation based on customer demand<\/li>\n\n\n\n<li>Re-validation to patch critical vulnerabilities<\/li>\n<\/ul>\n\n\n\n<p>In the end the best course will be different for every organization. As a laboratory we can help you find the best solution for your particular needs.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>by Andreas Fabis When we talk to our customers about FIPS 140-2 testing some questions regarding certificate maintenance frequently come up: There are many factors that can lead to module or platform changes: technical, business and marketing, to name a few. Navigating the rules and options of FIPS 140-2 re-certification can be challenging, and currently [&hellip;]<\/p>\n","protected":false},"author":9,"featured_media":3561,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[7,6],"tags":[],"_links":{"self":[{"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/posts\/3559"}],"collection":[{"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/comments?post=3559"}],"version-history":[{"count":1,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/posts\/3559\/revisions"}],"predecessor-version":[{"id":3562,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/posts\/3559\/revisions\/3562"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/media\/3561"}],"wp:attachment":[{"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/media?parent=3559"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/categories?post=3559"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/tags?post=3559"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}