RECENT BLOG NEWS

As wolfSentry gets ever closer to its first production release, we are introducing some exciting new capabilities, among them:

• Mature dynamic rule management, with automatic peer tracking, penalty boxing, O(1) release from penalty box, and realtime-safe (O(1)) limits on resource usage.
• Robust support in the configuration file and public API for user-defined data (key-value pairs) with freeform JSON values, to arbitrary (user-limited) depth, with a fully integrated API for processing and exporting JSON in DOM (random-access) mode.
• An API for setting user-defined configuration nodes as read-only.
• Improvements and extensions to the API for use by user plugins (action handlers) streamlining typical use cases involving dynamic rule insertion and update.
• Added examples/notification-demo/log_server
  • A standalone web server demonstrating HTTPS with dynamic insertion of limited-lifespan wolfSentry rules blocking (penalty boxing) abusive peers.
  • Mutual authentication using TLS, role-based authorizations pivoting on client certificate issuer (certificate authority), and wolfSentry event log retrieval, as a dynamically generated JSON array.

All of these and more are featured in wolfSentry preview release 7. For more details, clone wolfSentry from https://github.com/wolfSSL/wolfsentry, review ChangeLog.md and README.md, and “make test”.  If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfCrypt Benchmark (block bytes 1024, min 1.0 sec each)
RNG                775 KB took 1.010 seconds,  767.327 KB/s
AES-128-CBC-enc    325 KB took 1.010 seconds,  321.782 KB/s
AES-128-CBC-dec    325 KB took 1.000 seconds,  325.000 KB/s
AES-192-CBC-enc    250 KB took 1.040 seconds,  240.385 KB/s
AES-192-CBC-dec    250 KB took 1.020 seconds,  245.098 KB/s
AES-256-CBC-enc    200 KB took 1.010 seconds,  198.020 KB/s
AES-256-CBC-dec    200 KB took 1.000 seconds,  200.000 KB/s
AES-128-GCM-enc    275 KB took 1.050 seconds,  261.905 KB/s
AES-128-GCM-dec    275 KB took 1.050 seconds,  261.905 KB/s
AES-192-GCM-enc    225 KB took 1.100 seconds,  204.545 KB/s
AES-192-GCM-dec    225 KB took 1.110 seconds,  202.703 KB/s
AES-256-GCM-enc    175 KB took 1.030 seconds,  169.903 KB/s
AES-256-GCM-dec    175 KB took 1.020 seconds,  171.569 KB/s
GMAC Table 4-bit     1 MB took 1.000 seconds,    1.288 MB/s
AES-128-ECB-enc    314 KB took 1.000 seconds,  313.672 KB/s
AES-128-ECB-dec    343 KB took 1.000 seconds,  342.578 KB/s
AES-192-ECB-enc    225 KB took 1.000 seconds,  225.000 KB/s
AES-192-ECB-dec    236 KB took 1.000 seconds,  235.938 KB/s
AES-256-ECB-enc    200 KB took 1.000 seconds,  199.609 KB/s
AES-256-ECB-dec    189 KB took 1.000 seconds,  189.453 KB/s
SHA                  2 MB took 1.000 seconds,    1.953 MB/s
SHA-256              2 MB took 1.000 seconds,    2.051 MB/s
SHA-384            275 KB took 1.030 seconds,  266.990 KB/s
AES-128-CMAC       300 KB took 1.030 seconds,  291.262 KB/s
AES-256-CMAC       200 KB took 1.070 seconds,  186.916 KB/s
HMAC-SHA             2 MB took 1.000 seconds,    2.222 MB/s
HMAC-SHA256          2 MB took 1.000 seconds,    2.051 MB/s
HMAC-SHA384        275 KB took 1.040 seconds,  264.423 KB/s
RSA     2048 public         38 ops took 1.010 sec, avg 26.579 ms, 37.624 ops/sec
RSA     2048 private         2 ops took 1.950 sec, avg 975.000 ms, 1.026 ops/sec
ECC   [      SECP384R1]   384 key gen         6 ops took 1.080 sec, avg 180.000 ms, 5.556 ops/sec
ECDHE [      SECP384R1]   384 agree           4 ops took 1.560 sec, avg 390.000 ms, 2.564 ops/sec
ECDSA [      SECP384R1]   384 sign            6 ops took 1.340 sec, avg 223.333 ms, 4.478 ops/sec
ECDSA [      SECP384R1]   384 verify          2 ops took 1.020 sec, avg 510.000 ms, 1.961 ops/sec
Benchmark complete
Benchmark Test: Return code 0

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Doing FIPS responsibly since 2014!

wolfSSL Inc. Stance:

OE Descriptions for software module “tested configurations” should include the toolchain used to compile the code and the OS the toolchain was employed on to allow for cross-compilation scenarios.

1. OLD: <OS> running on <platform> with <processor>
2. NEW: Compiled with <toolchain> on <OS> running on <OS> running on <platform> with <processor>
3. OLD: <Guest OS> on <hypervisor> running on <platform> with <processor>
4. NEW: Compiled with <toolchain> on <OS> running on <Guest OS> on <hypervisor> running on <platform> with <processor>
5. OLD: <Guest OS> on <hypervisor> on <Host OS> running on <platform> with <processor>
6. NEW: Compiled with <toolchain> on <OS> running on <Guest OS> on <hypervisor> on <Host OS> running on <platform> with <processor>

wolfSSL Inc. Reasoning and Justification:

wolfSSL Inc recently experienced how a toolchain change caused issues with the software crypto module where there were no change(s) to the OS, processor or module code.

• Scenario 1: Unmodified code, compiled for Intel silicon on Linux OS using gcc or older clang version
  • All CAVP vectors passing

• Scenario 2: Same exact code, same exact intel silicon, same exact Linux OS. Compiler updated to clang 15.0.1.
  • CAVP vectors for a single public key algorithm failing (all other algorithms passing)
    • Problem: The n-th bit of a signature blob was being set or cleared non-deterministically. The failure was highly repeatable in testing.
    • Fix: Use an alternate version of clang and submit a bug report to the toolchain dev team (still waiting on a fix).

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.  We offer free pre-sales customer support, we have FIPS evaluation options and our staff are knowledgeable and eager to help!

Doing FIPS responsibly since 2014!

wolfSSL Inc has been made aware of concerning practices in the FIPS space by certain software module vendors. The wolfSSL team feels these practices are to the detriment of the FIPS community and trust in the FIPS program.

• CLAIM 1: One does not need an operating environment (OE) listed on a FIPS cert, just having it mentioned in the security policy as “vendor affirmed” is good enough
• CLAIM 2: As long as the code compiles and no changes are made to the code it is “FIPS Validated”

wolfSSL Inc is not denying the first claim, some FIPS users may find a vendor affirmation sufficient for their FIPS needs however our team believes this practice has potential to be detrimental to trust in the FIPS program. Some software module vendors are abusing vendor affirmation as a loop-hole to avoid testing on new OEs’ that differ from tested configurations. Our team would outright refute the second claim as patently ridiculous. If software tested on Intel silicon and a Windows OS is compiled for VXWorks running on ARM silicon (regardless if no code changes were made) there is no way  to predict (without testing) that the software crypto will behave the same under this new OE as it did under a previously tested configuration. To be clear the wolfSSL team is not discussing physical hardware modules, only software modules.

wolfSSL Inc. Stance:

1. Vendor affirmation makes sense for a physical design. Hardware maker’s are capable of determining security relevant effect of a design change to a hardware module.
2. Vendor affirmation in some select cases might make sense for software modules but certainly not in a general sense or as a de facto approach to FIPS, especially when the OE being vendor affirmed is wildly different from the original “tested configuration”. This scenario should raise a red flag.

 It is near impossible for a software vendor to predict how changes to the processor or OS will affect the way the software executes regardless if it compiles without code changes. If/when the software vendor is unable to make a security relevant determination, testing should be performed to compensate.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.  We offer free pre-sales customer support, we have FIPS evaluation options and our staff are knowledgeable and eager to help!

wolfSSL is a growing company looking to add a top notch embedded systems software engineer to our organization. wolfSSL develops, markets and sells the leading Open Source embedded SSL/TLS protocol implementation, wolfSSL. Our users are primarily building devices or applications that need security. Other products include wolfCrypt embedded cryptography engine, wolfMQTT client library, wolfSSH, wolfTPM, wolfBoot, and wolfSentry.

Job Description:

Currently, we are seeking to add a senior level C software engineer with 5-10 years experience interested in a fun company with tremendous upside. Backgrounds that are useful to our team include networking, security, and hardware optimizations. Assembly experience is a plus. Experience with encryption software is a plus. RTOS experience is a plus.  Experience with hardware-based cryptography is a plus.

Operating environments of particular interest to us include Linux, Windows, Embedded Linux and RTOS varieties (VxWorks, QNX, ThreadX, uC/OS, MQX, FreeRTOS, etc). Experience with mobile environments such as Android and iOS is also a plus, but not required.

Location is flexible. For the right candidate, we’re open to this individual working from virtually any location.

How To Apply

To apply or discuss, please send your resume and cover letter to resumes@wolfssl.com. 

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

We’re happy to announce that wolfEngine 1.2.0 has been released! wolfEngine is an OpenSSL engine that helps users migrate to a FIPS-validated cryptography library (wolfCrypt) all while continuing to use OpenSSL. This new version includes some improvements to our RNG and RSA code as well as support for our FIPS 140-3 candidate code on Windows. You can read the full changelog at the GitHub link above.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Doing FIPS responsibly since 2014!

INTRO (wolfSSL FIPS service(s)):

(skip to next paragraph for “What is FIPS”)

 FIPS is rightly viewed as a complex process with a steep entry learning curve. Lucky for customers of wolfSSL Inc. our management and engineering team have taken the time to learn the documentation surrounding the topic and developed all the tooling necessary to complete FIPS validation testing of the wolfCrypt cryptographic module in coordination with an NVLAP accredited FIPS lab. In order to FIPS validate a new product or operating environment (OE), wolfSSL asks for simply a customer’s hardware, compiler/toolchain (IDE etc), and a guide such that one of our FIPS developers can sit down with nothing but a laptop and achieve compiling and running a hello-world.c application on the target product to be FIPS validated. Yes you read that right, wolfSSL does not need your proprietary application software, just a hello-world.c application to get started. The CMVP validates the cryptographic module running on the target, not the applications that are consuming that cryptographic module. The wolfSSL team will standup the wolfCrypt module on your target product and take it through the certification process as quickly as possible leaving your dev team free to focus on preparing the end product while FIPS certification is taking place simultaneously!

HISTORY (What is FIPS):

  Since there are so many options for securing information, the U.S. and Canadian governments recognized in the 1990’s a need to standardize those algorithmic methods deemed to be the most secure and enforce use of only those algorithms in critical government systems. To “encourage” adoption of the requirements by the two governments, the organizations NIST (National Institute of Standards and Technology)¹ and the CCCS (Canadian Centre for Cyber Security)² were called upon to fulfill that mission. The two agencies were to collaboratively:

1. Decide which algorithms were the best/strongest
2. Evaluate: If an algorithm had multiple modes or key lengths which modes or key lengths (if any) were considered too weak and should be excluded?
3. Determine if there were other requirements aside from just having the algorithms implemented correctly
   1. Did the algorithms NEED to be re-tested periodically? (IE as the device was powering up)
   2. Did the module need to be checked periodically to see if it had been tampered with since the factory? (IE an integrity check, etc)
4. Finally to enforce/encourage adoption of these standards by federal agencies belonging to either government. (Eventually expanded to include medical and some private entities as well)

These standards were called the “Federal Information Processing Standards” or FIPS. These standards were documented in a series of “Special Publications” (SP’s).

  Out of a need to document which cryptographic modules and vendors were abiding by the standards set forth, a “certification” program was decided as the best approach. Vendors who made cryptographic modules could submit for and be awarded a certificate if their module was found to be compliant with all standards applicable to that module. The certificates would be hosted on the U.S. based NIST website so that federal agencies (or the public) could “browse” the available FIPS certified modules.

  It was a big job for the two agencies to handle alone, so in 1995 NIST and CCCS established two organizations called the “CMVP” (Cryptographic Module Validation Program)³ and CAVP (Cryptographic Algorithm Validation Program)? to handle testing Cryptographic modules for compliance with the standards. These two organizations would also handle issuing the certificates for vendors and products that passed algorithm testing and were found to meet all applicable standards outlined in the SP’s. 

  The CAVP issues algorithm certificates (which are a prerequisite to submitting a module for FIPS certification to the CMVP). The CMVP issues FIPS certificates for “tested configurations” or “operating environments” found to pass the CAVP testing and be in compliance with the standards. Both certificate types (CAVP algo certs and CMVP FIPS certs) are hosted on the NIST website. The certificates are public domain and can be searched by anyone.

  Once established, the CMVP and CAVP needed to establish a way to “test” the modules. To that end they called upon the NVLAP (National Voluntary Laboratory Accreditation Program)? to accredit “third-party” testing laboratories that would serve as an intermediary between the vendors seeking FIPS certification and the CAVP/CMVP bodies.

  A last step in the history of FIPS was adoption of software modules. Originally when the standards were written, only dedicated hardware could perform the heavy lifting necessary for cryptographic mathematical operations so the standards were designed with ONLY hardware modules in mind. Doing cryptography in software at the time was impractical and therefore not considered in the original standards. As general purpose CPUs advanced, eventually it became feasible to implement algorithms in software and have those expensive math operations executed by a general purpose CPU in a reasonable amount of time. Once this reality arrived the standards were “adapted” to allow for both hardware and software modules. To this day there are “some scenarios” in the standards that only seem to make sense for hardware (See our blog post on vendor affirmation and how some software vendors are exploiting a loophole in the standards that was intended for hardware). NIST, the CMVP and CAVP have done a lot of work in the past few years bringing about the latest 140-3 standards and wolfSSL Inc is very excited to be one of the first software modules with a commercial FIPS 140-3 offering!

The Process (validating a module):

  Today a hardware or software vendor will work in coordination with an NVLAP accredited lab to complete algorithm testing and receive algorithms certificates.

(Milestone 1 of a FIPS certification effort)

  Once the vendor receives the prerequisite CAVP certificates they will perform operational testing with the same NVLAP accredited lab. Once all testing evidence has been captured and everything reviewed and approved by the NVLAP quality assurance department, the lab is ready to submit everything to the CMVP.

(Milestone 2 of a FIPS certification effort)

  The CMVP will coordinate with the vendor via the NVLAP accredited lab and once all requirements have been satisfied the CMVP will either issue a new FIPS certificate or update an existing certificate if the vendor is adding an operating environment to an existing certificate.

(Milestone 3 of a FIPS certification effort)

Submission Scenario(s) supported by wolfSSL Inc:

• New cert (draw a new module boundary around specific algorithms and certify from scratch resulting in a new certificate)
• OE addition (Add an OE to an existing certificate)
• Revalidation (redraw the module boundary of an existing validated module to include new or remove existing algorithms from the boundary description)
• Vendor Affirmation – wolfSSL is a software module vendor. As a responsible FIPS vendor wolfSSL feels that software vendors are generally incapable of determining how a change to the CPU or OS will affect the cryptography (especially if the CPU or OS changes completely). As such wolfSSL Inc does not currently offer Vendor Affirmation as a path to FIPS. Special circumstances MAY exist but would need to be evaluated on a case-by-case basis.
  
  Timeline estimates for the various scenarios change over time. If you would like an up-to-date estimate for a given submission scenario please contact support@wolfssl.com for the latest.

Summary:

– wolfSSL Inc can make the process of certifying your product painless and hands-free once we have the product and basic instructions for getting a hello-world app up and running on the target!

– FIPS is a set of standards, detailed in Special Publications, that need to be met in order to be awarded a FIPS validation/certification published on the NIST website. A FIPS certificate, with the product listed in the certificate, is required to sell product(s) to medical, federal or military agencies and often required by some private sector entities as well.

– The process can take time so please plan accordingly!

If you have any other questions about FIPS or the process or wolfSSL Inc please contact either fips@wolfssl.com or support@wolfssl.com anytime. We offer free pre-sales customer support, we have FIPS evaluation options and our staff are knowledgeable and eager to help!

¹ The National Institute of Standards and Technology (NIST) was founded in 1901 and is now part of the U.S. Department of Commerce. NIST is one of the nation’s oldest physical science laboratories. To promote U.S. innovation and industrial competitiveness by advancing measurement science, standards, and technology in ways that enhance economic security and improve our quality of life. – https://www.nist.gov/about-nist

² The Cyber Centre is the single unified source of expert advice, guidance, services and support on cyber security  for government, critical infrastructure  owners and operations, the private sector and the Canadian public. – https://www.cyber.gc.ca/en/about-cyber-centre

³ The Cryptographic Module Validation Program (CMVP) is a joint effort between the National Institute of Standards and Technology under the Department of Commerce and the Canadian Centre for Cyber Security, a branch of the Communications Security Establishment. The goal of the CMVP is to promote the use of validated cryptographic modules and provide Federal agencies with a security metric to use in procuring equipment containing validated cryptographic modules. – https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program

? The CAVP was established in July 1995 by NIST and the Government of Canada’s CCCS. CSD’s Security Testing, Validation, and Measurement Group (STVMG) manages the validation testing of cryptographic modules and their underlying cryptographic algorithms through the CAVP and CMVP. – https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program 

? The National Voluntary Laboratory Accreditation Program (NVLAP) provides third-party accreditation to testing and calibration laboratories in response to legislative actions or requests from government agencies or private-sector organizations. NVLAP-accredited laboratories are assessed against the management and technical requirements published in the International Standard, ISO/IEC 17025:2017. – https://www.nist.gov/nvlap

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.