Important News:SafeLogic's CryptoComply Achieves FIPS 140-3 Validation for 28 OEs and Receives Certificate #4781! Read the blog post!
Frequently Asked Questions
FIPS 140 Questions
What is FIPS 140-2?
FIPS 140-2 is the benchmark established by the National Institute of Standards and Technology (NIST) to specify security requirements for cryptographic modules and testing methodology for confirming conformance. The standard provides four increasing, qualitative levels of security: Level 1, Level 2, Level 3, and Level 4. These levels are intended to cover the wide range of potential applications and environments in which cryptographic modules may be employed. The security requirements cover areas related to the secure design and implementation of a cryptographic module. These areas include cryptographic module specification, cryptographic module ports and interfaces; roles, services, and authentication; finite state model; physical security; operational environment; cryptographic key management; electromagnetic interference/electromagnetic compatibility (EMI/EMC); self-tests; design assurance; and mitigation of other attacks.
Note: the -2 suffix represents the second version of the standard, not Level 2.
What is FIPS 140-3?
FIPS 140-3 is the third update to the FIPS 140 benchmark established by the National Institute of Standards and Technology (NIST) to specify security requirements for cryptographic modules and testing methodology for confirming conformance and will replace FIPS 140-2. FIPS 140-3 began validation testing in September 2020 and is based upon the ISO/IEC 19790 international standard. FIPS 140-2 testing is now closed, but those certifications will remain valid until they sunset, which could be as far away as 2026, so the transition will be gradual.
SafeLogic is actively working on getting FIPS 140-3 modules validated and certificates issued. In the meantime, SafeLogic continues to support and maintain FIPS 140-2 validated modules and certificates for its clients. SafeLogic will continue to keep its clients’ FIPS 140-2 certificates in active status. When FIPS 140-3 modules/certificates are available, SafeLogic will migrate its clients to the new modules/certificates.
As a SafeLogic customer, there is no need to worry about the FIPS 140-3 transition because SafeLogic has you covered and will make it happen for you in a seamless fashion, all as part of its MaintainCert offering. There is absolutely no rush to get to FIPS 140-3 because SafeLogic continues to maintain an active FIPS 140 certification for your company, and procurement officers do not care whether you have a FIPS 140-3 or 140-2 certificate, as long as you have an active certificate in your company’s name (i.e., you’re FIPS 140 validated).
Note: the -3 suffix represents the third version of the standard, not Level 3.
Why do I need FIPS 140?
If a vendor sells a product to the US Federal Government that includes a cryptographic module for the protection of sensitive data, the cryptographic module must be FIPS 140 validated. Also, the Government of Canada recommends that Canadian Federal Departments use FIPS 140 validated cryptographic modules. By having your cryptographic module validated, you are showing potential customers that your cryptographic module implements a minimum baseline suite of IT security and cryptography features. FIPS 140 is the de facto international standard for cryptographic modules. As of January 11, 1994, FIPS 140 standards are applicable to all Federal agencies that use cryptographic-based security systems to protect sensitive information in computer and telecommunication systems (including voice systems) as defined in Section 5131 of the Information Technology Management Reform Act of 1996, Public Law 104-106. This standard shall be used in designing and implementing cryptographic modules that Federal departments and agencies operate or are operated for them under contract. The adoption and use of this standard is available to private and commercial organizations. FIPS 140-3 has since been approved and placed in service, with the transition from 140-2 to 140-3 currently underway.
Does my entire product have to be FIPS 140 validated?
Vendors can choose their “module boundary.” That boundary may be the same as an entire product or it may be a subset of a product (e.g., software library, printed circuit board or integrated circuit chip). There is no requirement to make the cryptographic module include an entire product, especially as the standard only defines the requirements and testing of the cryptographic functionality.
How long does the FIPS 140 validation process take?
The traditional FIPS validation process can take as long as 16 months from start to certificate issuance. The validation phases are:
- Implementation under test – evidence and module has been submitted to the CMT lab and testing is underway.
- Review pending – testing has been completed and the lab report has been submitted to CMVP awaiting review.
- In review – A member of CMVP has been assigned and has begun the review of the lab report.
- Coordination – Questions from CMVP have been sent back to the CMT lab. Responses from the lab are then sent back to CMVP.
- Finalization – All questions have been satisfactorily addressed and the FIPS certificate is prepared for issuance.
In contrast, SafeLogic’s RapidCert service accelerates and simplifies FIPS 140 validations, yielding completion in less than 8 weeks!
How much does it cost to get FIPS 140 validated?
A fee is charged by the CMT laboratories for the testing of a cryptographic module. Testing time is variable, depending on the complexity of the cryptographic module, the overall security level and the individual security levels, and the completeness of the documentation evidence package. The test time varies depending on the following factors:
- Cryptographic module type – e.g.,. software, firmware, hardware, single vs. multi-function;
- Overall security level of the cryptographic module – 1, 2, 3, or 4;
- Accuracy and completeness of documentation; and
- The number of deficiencies identified by a CMT laboratory during the conformance testing process.
If a cryptographic module is being revalidated or if a new version based on a previously validated cryptographic module is being validated, the cost and time, typically, are less. NIST and CSE do not get involved in the contract negotiations between the vendor and a CMT lab. This is to ensure the independence of the validation authorities. Optimally, vendors may choose to hire outside consultants to prepare the necessary documentation for the module testing. These consultants will charge the vendor their fees for this service. Cost recovery is a fee provided to NIST by product vendors. A nominal fee is charged to cover the validation authority costs for the validation tasks and the program management responsibilities performed by NIST. CMVP cost recovery fees:
- Security Level 1: Base fee: $8,000
- Security Level 2: Base fee:$10,000
- Security Level 3: Base fee: $10,000
- Security Level 4: Base fee: $10,000
Talk to SafeLogic about an all-inclusive, fixed rate FIPS 140 validation based on CryptoComply to save on both hard and soft costs!
What are the different levels of FIPS 140 validation?
The FIPS 140 standard provides four increasing, qualitative levels of security. Each level covers 11 different areas of security. Level 1 is the least stringent and level 4, the most. Each subsequent level builds upon the requirements of the previous level. That is, Level 2 includes all of the requirements of Level 1 plus other requirements. The key difference in the levels is the way physical and logical access to the cryptographic module is limited to ensure its integrity. These levels are clearly indicated on each validation certificate and the strength and functionality of the cryptography is the same for each level.
Security Level 1
Security Level 1 provides the lowest level of security. Basic security requirements are specified for a cryptographic module (e.g., at least one FIPS-approved/NIST recommended algorithm (hereafter referred to as an Approved algorithm) or Approved security function must be used). No specific physical security mechanisms are required in a Security Level 1 cryptographic module beyond the basic requirement for production-grade components. An example of a Security Level 1 cryptographic module is a personal computer (PC) encryption board.
Security Level 1 allows the software and firmware components of a cryptographic module to be executed on a general purpose computing system using an unevaluated operating system. Such implementations may be appropriate for some low-level security applications when other controls, such as physical security, network security, and administrative procedures are limited or nonexistent. The implementation of cryptographic software may be more cost-effective than corresponding hardware-based mechanisms, enabling organizations to select from alternative cryptographic solutions to meet lower-level security requirements.
Security Level 2
Security Level 2 enhances the physical security mechanisms of a Security Level 1 cryptographic module by adding the requirement for tamper-evidence, which includes the use of tamper-evident coatings or seals or for pick-resistant locks on removable covers or doors of the module. Tamper-evident coatings or seals are placed on a cryptographic module so that the coating or seal must be broken to attain physical access to the plaintext cryptographic keys and critical security parameters (CSPs) within the module. Tamper-evident seals or pick-resistant locks are placed on covers or doors to protect against unauthorized physical access.
Security Level 2 requires, at a minimum, role-based authentication in which a cryptographic module authenticates the authorization of an operator to assume a specific role and perform a corresponding set of services.
Security Level 2 allows the software and firmware components of a cryptographic module to be executed on a general purpose computing system using an operating system that meets the functional requirements specified in the Common Criteria (CC) Protection Profiles (PPs) listed in Annex B and is evaluated at the CC evaluation assurance level EAL2 (or higher).
An equivalent evaluated trusted operating system may be used. A trusted operating system provides a level of trust so that cryptographic modules executing on general purpose computing platforms are comparable to cryptographic modules implemented using dedicated hardware systems.
Security Level 3
In addition to the tamper-evident physical security mechanisms required at Security Level 2, Security Level 3 attempts to prevent the intruder from gaining access to CSPs held within the cryptographic module. Physical security mechanisms required at Security Level 3 are intended to have a high probability of detecting and responding to attempts at physical access, use or modification of the cryptographic module. The physical security mechanisms may include the use of strong enclosures and tamper detection/response circuitry that zeroizes all plaintext CSPs when the removable covers/doors of the cryptographic module are opened.
Security Level 3 requires identity-based authentication mechanisms, enhancing the security provided by the role-based authentication mechanisms specified for Security Level 2. A cryptographic module authenticates the identity of an operator and verifies that the identified operator is authorized to assume a specific role and perform a corresponding set of services.
Security Level 3 requires the entry or output of plaintext CSPs (including the entry or output of plaintext CSPs using split knowledge procedures) be performed using ports that are physically separated from other ports, or interfaces that are logically separated using a trusted path from other interfaces. Plaintext CSPs may be entered into or output from the cryptographic module in encrypted form (in which case they may travel through enclosing or intervening systems).
Security Level 3 allows the software and firmware components of a cryptographic module to be executed on a general purpose computing system using an operating system that:
- meets the functional requirements specified in the PPs listed in Annex B with the additional functional requirement of a Trusted Path (FTP_TRP.1);
- and is evaluated at the CC evaluation assurance level EAL3 (or higher) with the additional assurance requirement of an Informal Target of Evaluation (TOE) Security Policy Model (ADV_SPM.1).
An equivalent evaluated trusted operating system may be used. The implementation of a trusted path protects plaintext CSPs and the software and firmware components of the cryptographic module from other untrusted software or firmware that may be executing on the platform.
Security Level 4
Security Level 4 provides the highest level of security defined in this standard. At this security level, the physical security mechanisms provide a complete envelope of protection around the cryptographic module with the intent of detecting and responding to all unauthorized attempts at physical access. Penetration of the cryptographic module enclosure from any direction has a very high probability of being detected, resulting in the immediate zeroization of all plaintext CSPs. Security Level 4 cryptographic modules are useful for operation in physically unprotected environments.
Security Level 4 also protects a cryptographic module against a security compromise due to environmental conditions or fluctuations outside of the module’s normal operating ranges for voltage and temperature. Intentional excursions beyond the normal operating ranges may be used by an attacker to thwart a cryptographic module’s defenses. A cryptographic module is required to either include special environmental protection features designed to detect fluctuations and zeroize CSPs, or to undergo rigorous environmental failure testing to provide a reasonable assurance that the module will not be affected by fluctuations outside of the normal operating range in a manner that can compromise the security of the module.
Security Level 4 allows the software and firmware components of a cryptographic module to be executed on a general purpose computing system using an operating system that:
- meets the functional requirements specified for Security Level 3;
- and is evaluated at the CC evaluation assurance level EAL4 (or higher).
An equivalent evaluated trusted operating system may be used.
How long is a FIPS 140 certificate valid?
The standard period is 5 years, unless the validated module has been modified, which can sometimes reset the clock. In other cases, technology can become obsolete, leading CMVP to deprecate algorithms or ban cryptographic techniques, which can force a validation to be moved to the Historical List before the 5 year period expires. SafeLogic ensures that validations will remain active as part of ongoing annual maintenance, regardless of these hurdles.
Strategic Questions
How do I stay competitive in the Federal and regulated market space?
The key to remaining competitive is to keep your product validations current with your latest releases on the latest platforms. With the rapidly changing technologies and frequent platform version upgrades, it is difficult to maintain compliance. SafeLogic maintains an aggressive validation maintenance roadmap to support the latest platforms and offers services to address any of your unique needs. More importantly, the tight validation boundary of CryptoComply allows your product to be updated and revised at the speed of innovation, while keeping the validated crypto module intact at the core. RapidCert’s accelerated timeline also creates a significant competitive advantage by beating rivals to market with validated solutions.
What do I have to do to meet government regulations on cryptography?
1. Identify your cryptographic module.
Define the “cryptographic boundary”. The boundary may be an integrated circuit chip, printed circuit board, a software library or a complete appliance product. This module must perform at least one cryptographic function approved by FIPS 140. Once the cryptographic boundary has been defined along with the supported platforms, documentation illustrating how the module meets the FIPS 140 requirements can be prepared.
2. Prepare documentation evidence.
The first document that must be prepared is the Security Policy. At a high level, the Security Policy defines the cryptographic module and how it meets the FIPS 140 requirements. This document covers all 11 areas defined by the FIPS 140 standard. The Vendor Evidence documentation provides greater detail about how the module meets the 11 areas of FIPS 140.
3. Submit evidence and the module to an accredited cryptographic module testing lab for testing.
Once the evidence documentation has been written, this set of documents along with the cryptographic module implementation is submitted to the CMT lab for their testing. The CMT lab will review the documentation for any discrepancies or issues and report them back to the vendor.
4. Address any issues or questions from the CMT lab.
The vendor must satisfactorily address all the questions and issues raised by the CMT lab. Once the CMT lab is satisfied by the responses and they have completed their testing and finalized their test report, they will submit their findings to CMVP.
5. Pay the necessary fees.
Paying the CMT lab fees are the responsibility of the vendor. Also, the CMVP charges vendors a “cost recovery” fee for their validation services.
Do I need FIPS 140 validation for FedRAMP / CMMC / NIST 800-171 / FISMA / etc.?
In short, yes. These government programs have all been built using NIST publications as building blocks, so they all reference NIST’s existing advisories and guidance on the proper usage of cryptography, known as FIPS 140.
For more technical insight on specific programs and dependencies, check out our repository of whitepapers.
How can I save time and money on these certifications?
CryptoComply’s “drop-in compliance” enables clients to achieve compliance with government regulations nearly instantaneously. This saves the time of going through the lengthy validation process. CryptoComply also saves engineering effort that would otherwise be needed to address CMT lab questions during the validation process – it’s ready to go right now! RapidCert slashes the validation timeline to less than 8 weeks and requires no additional effort from you team, while ongoing support contracts keep both the software and validation up-to-date and active. This alleviates the need for clients to expend precious time and money on maintaining the certification on their module.
SafeLogic Questions
What is CryptoComply?
CryptoComply is SafeLogic’s flagship product line, a family of FIPS 140 validated cryptographic software modules. They deliver core cryptographic functions for use on mobile and enterprise server operating system platforms and are designed to deliver standards-based “Drop-in Compliance” quickly and easily as direct replacements for popular open-source crypto providers like OpenSSL and BouncyCastle. CryptoComply delivers a single code library to support cross-operating system platforms. The same library can be used in applications across a variety of operating system platforms with the same programmatic interface while maintaining the FIPS 140 certification. CryptoComply accomplishes this by maintaining the same code base across multiple FIPS 140 validations. CryptoComply can reduce the time to reach FIPS 140 standalone validation by as much as 90% by plugging in the module and replacing non-validated software. Customers can enjoy instant compliance with the FIPS 140 requirements by replacing non-compliant cryptographic libraries with CryptoComply. FIPS 140 validations can take 16 months, sometimes even longer, but with CryptoComply, time-to-compliance can be dramatically reduced.
What is RapidCert?
RapidCert is SafeLogic’s turn-key accelerated FIPS 140 validation service, available to licensees of any CryptoComply module. When they choose RapidCert service, companies receive their validation certificate in less than 8 weeks, with no additional effort, saving significant time and money along the way. SafeLogic handles everything, including coordination with the testing lab and CMVP at NIST, and the cost is all-inclusive.
What are the advantages of CryptoComply and RapidCert together?
Manage Costs and Time
FIPS 140 validations can take up to one year and cost over well over $50,000 per module configuration. These costs can increase as the number of supported platforms increases. In the dynamic IT and security business, these delays and costs can magnify competitive and customer demand pressures. CryptoComply provides instant FIPS 140 compliance because the module has already undergone the validation process, and accelerates the validation process through RapidCert because the two are designed in tandem.
Licensing other third-party modules can cost hundreds of thousands of dollars per year. Through SafeLogic’s aggressive and flexible pricing model, customers will enjoy greatly reduced licensing and maintenance costs.
Eliminate Wasted Effort
Validations on a per product basis wastes time, money and effort. Save valuable resources by incorporating CryptoComply into multiple products or multiple product lines. Moreover, because CryptoComply is centrally maintained by SafeLogic on-going support costs are greatly reduced and duplication of effort is eliminated.
FIPS 140 validations are valid for a particular version of software running in a specific set of platforms. CryptoComply validations support a wide variety of operating system platforms. SafeLogic’s aggressive validation roadmap ensures that as new operating system versions are made available, CryptoComply FIPS 140 validations will be kept up-to-date.
Maintain Validation Status
With FIPS 140 validations, any changes to the module may force re-validations. Additional platform support may also require re-validations. Discovered vulnerabilities in the module code could force re-validations. CryptoComply contains only core cryptographic functions ensuring that only the most critical security-relevant changes are necessary.
CryptoComply has been designed to minimize the need to unnecessarily re-validate the module but SafeLogic will maintain validations for CryptoComply to support technology changes and new security threats.
Drop-In Compliance
For products currently using OpenSSL, CryptoComply is a drop-in replacement for the low-level cryptographic library (libcrypto) underlying the TSL/SSL code; the calls made by the TLS/SSL code are handled by CryptoComply.
CryptoComply provides direct compatibility with existing OpenSSL or other proprietary libraries. Developers merely have to re-build their code and point to the CryptoComply library rather than the OpenSSL crypto library.
Other versions of CryptoComply have been developed for maximum compatibility with other popular open source options and to streamline the replacement of proprietary modules and architectures.
RapidCert Services
In addition to maintaining an aggressive module validation maintenance roadmap, SafeLogic offers the option for affordable and timely custom platform support. Clients with unique requirements for platform support may opt to engage SafeLogic to update CryptoComply validations for these custom platforms. This service is offered at a competitive price and can be delivered in a reduced timeframe.
CryptoComply licenses allow customers to immediately claim FIPS 140 compliance by referencing the CryptoComply FIPS 140 certificate. For those customers that need certificates with their company and product name on it to claim FIPS 140 validation, RapidCert certificate services are available from SafeLogic. SafeLogic and CryptoComply can provide a RapidCert solution faster than any other alternative, with less time from engineering and less operational cost.
What’s the ROI on using CryptoComply and RapidCert in tandem?
Return on investment from using CryptoComply over repeatedly going through the FIPS 140 validation process on every platform upgrade is significant. Considering it can take 16 months to complete a FIPS 140 validation and cost tens of thousands of dollars in CMT lab fees, this can result in a significant ROI for clients who leverage CryptoComply modules with RapidCert validation services.
What do I have to do to meet the government regulations with CryptoComply?
Customers may choose to license CryptoComply with its existing FIPS 140 validation certificate and meet the government requirement for using a FIPS-validated cryptographic module. This gives the vendor “drop-in compliance” immediately.
For products currently using OpenSSL, CryptoComply is a drop-in replacement for the low-level cryptographic library (libcrypto) underlying the TSL/SSL code. The calls made by the TLS/SSL code are handled by CryptoComply which has implemented the latest decoupled OpenSSL cryptographic library. Developers merely have to re-build their code and point to the CryptoComply library rather than the OpenSSL crypto library. Because CryptoComply has already completed FIPS 140 testing, products using CryptoComply can immediately claim FIPS 140 compliance.
Does CryptoComply support AES?
Yes. We made sure that was supported from the start. CryptoComply supports the following algorithms:
- AES 128, 192, 256 (ECB, CBC, OFB, CFB1, CFB8, XTS, GCM, GMAC, CMAC)
What is the US export classification for CryptoComply?
Please contact SafeLogic to discuss export requirements and restrictions.
Can I get my own company name on the certificate?
Yes, absolutely! This is a key part of RapidCert. By completing a FIPS 140 validation in your company’s name, you have a clear certification story for procurement officers and other prospective buyers. This is far more valuable than just claiming compliance by virtue of deploying CryptoComply or another validated module.
Is a RapidCert FIPS 140 validation transferrable?
From a technical standpoint, yes, CryptoComply modules can be used in a variety of products and platforms, and a RapidCert validation can be updated or altered to reflect the usage. Note that CryptoComply is licensed for named products and platforms, so it is not directly transferable without appending the license agreement to include specified additions. This is done so that end users can review tested platforms to verify that the certificate applies to the products that they are procuring. SafeLogic can make this easy and seamless to ensure a solid certification story for your customers.
Has CryptoComply been FIPS validated on my platform?
SafeLogic is maintaining an aggressive roadmap for CryptoComply with plans to be validated on all the current major operating environments and system platforms. If your desired platform is not currently on our list, contact your SafeLogic sales rep to address your needs.
What is included with a CryptoComply Support Contract?
Check out the Support page for more information on what’s included and what can be added on.
Competitive Questions
What is SafeLogic's advantage over OpenSSL?
OpenSSL’s open source FIPS validation have all been moved to Historical status by NIST. The last FIPS-capable cryptographic module compatible with the OpenSSL libraries was v2.0.1, which had FIPS 140-2 certificate #1747 completed in July 2012. This module was documented in the 2.0 User Guide and substantially updated and improved the earlier v1.2 module, FIPS 140-2 certificate #1051, but was abandoned by the OpenSSL project when the 1.0.2 architecture went ‘End of Life’ at the end of 2019.
While the OpenSSL FIPS Object Module was built using the re-designed OpenSSL 2.0 to decouple the TLS/SSL code from the low level cryptographic library, the OFOM was still a complete SSL module. CryptoComply took full advantage of the OpenSSL re-design by validating just the cryptographic library separated from the TLS/SSL stack. This makes CryptoComply less exposed to reported vulnerabilities in the open source code. Historically, all of the reported vulnerabilities in OpenSSL were discovered in the TLS/SSL code. This is encouraging news that the core cryptographic functions are sound but means that the OpenSSL FIPS Object Module would need to be re-validated if/when vulnerabilities are discovered in the TLS/SSL code, while CryptoComply does not. This was also integral to why the OpenSSL FIPS Object Module was placed on the Historical List by NIST.
Some vendors may still attempt to follow the instructions in the OpenSSL FIPS Object Module Users’ Guide to claim FIPS compliance. Some of the challenges they can expect are:
- Government agencies are well aware that the open source validation is now Historical and will not accept dependent compliance claims
- Time-consuming algorithm testing on platforms not covered by the OpenSSL FIPS Object Module validation
- Restrictive compilation and build environment requirements
- No changes to source code or build scripts are allowed
- Module must be built from source code in strict accordance with instructions
SafeLogic offers significant time, effort, and cost savings compared to pursuing a FIPS validation on OpenSSL. FIPS 140 validation services are the core of our business and expertise and our experience and focus on customer success enable us to deliver unparalleled results by offloading your crypto requirements to SafeLogic.
CryptoComply offers the following advantages over the OpenSSL FIPS Object Module:
- Packaged solution available immediately Still carries active FIPS 140 validation
- Greatly reduced engineering effort engineering effort for validation
- Algorithm testing effort eliminated
- Build effort eliminated
Let SafeLogic help you navigate the latest patches and architecture with hands-on technical support and continuation of our drop-in replacement FIPS strategy! We can also assist with Extended Support for the EOL'd 1.0.2 architecture and solve your FIPS compliance issues if you were dependent on the now-Historical #1747 certificate.
Can SafeLogic help with the OpenSSL 1.0.2 End of Life?
For context, OpenSSL ended support for the 1.0.2 architecture on December 31, 2019. The problem is that 1.0.2 is the only available OpenSSL version that supports FIPS mode, so there is a gap in coverage until OpenSSL's 3.0 FIPS Provider is validated (originally rumored to be mid-2020 and heavily delayed.)
SafeLogic is providing Extended Support, providing patches as needed for OpenSSL 1.0.2 to keep it viable for our CryptoComply users that still rely on the 1.0.2 architecture. Extended Support is also be available ‘a la carte’, so please contact us for pricing if you need help or more info!
Can SafeLogic help with the Historical status of OpenSSL's #1747 FIPS 140-2 validation?
For context, OpenSSL’s FIPS Object Module 2.0, which had been validated and carried FIPS certificate #1747, was sent to the Historical List in September 2020 as the result of 186-2 KeyGen deprecation.
This means that any vendor relying on OpenSSL 1.0.2, the OpenSSL FIPS Object Module 2.0, and/or the OpenSSL FIPS 140-2 validations, including #1747, have been left in the lurch.
SafeLogic is offering Extended Support, providing patches as needed for OpenSSL 1.0.2 to keep it viable. We are also offering a CryptoComply module that is a drop-in replacement for the OpenSSL FIPS Object Module 2.0 but was not be moved to the Historical List, and we will produce a FIPS certificate specifically for you via the RapidCert program, so you will not be beholden to the #1747 validation if you would like to transition to CryptoComply.
Contact us for more info!
What is SafeLogic's advantage over the Microsoft/Apple/Android/Blackberry OS-supplied crypto libraries?
SafeLogic has two key advantages over the native OS-supplied crypto libraries.
First, from a security perspective, integrating CryptoComply into your application isolates all crypto API calls within your control and eliminates any potential vulnerabilities created by making calls out to the OS level. It reduces your attack surface significantly, provides peace of mind that you have configured it as you see fit, minimizes your engineering effort to provide crypto API compatibility to various operating environments that your customers request, and streamlines your efforts to deploy a single crypto library across all scenarios.
Second, from a compliance perspective, leveraging CryptoComply allows you to also use the RapidCert service. This delivers a FIPS 140 validation, in your name, in less than 8 weeks. This unique certificate number is posted on the NIST public website and available to be cross-checked and confirmed to belong to your company. It also displays the operating environments and some of the specifics of deployment. This creates a concrete certification story for procurement officers in the Public Sector, specifically the U.S. Federal market and the DoD and Intelligence Communities. Other regulated industries, such as healthcare and finance also look for the validation in your name, which proves that your deployment has met the strict benchmark requirements for cryptography. If you rely on the OS-level libraries, there is no easy way for your customers or an independent third party to confirm that your application has incorporated FIPS 140 validated encryption.
What is SafeLogic's advantage over another third-party library such as Mocana, WolfSSL, or RSA BSAFE?
SafeLogic’s focus on FIPS 140 validation is a key differentiator. We maintain an aggressive validation roadmap to keep up with the latest platforms, operating environments, and regulations. Other companies tackle cryptography first and worry about FIPS 140 later, or sometimes not at all. We only build FIPS 140 validated modules!
Best of all? SafeLogic doesn’t demand re-architecture of your product or vendor lock-in, we design CryptoComply modules as drop-in replacements for various popular open source crypto providers!