Hi m_u_h,

wolfEngine FIPS checks only have an effect when using a FIPS validated (or FIPS Ready) version of wolfSSL/wolfCrypt under wolfEngine.

These "FIPS checks" are checks inside wolfEngine to help make sure the caller doesn't use non-FIPS modes or key lengths of some algorithms, including:

- Check that RSA key sizes are valid. For wolfCrypt FIPS, 1024-bit RSA keys can only be used for verification, not generation or signing.
- Check that RSA signatures with SHA-1 digests are valid. For wolfCrypt FIPS, SHA-1 isn't allowed for signing, only for verifying.
- Check that ECC P-192 usage is valid. For wolfCrypt FIPS, ECC P-192 isn't allowed for ECDH, key generation, or signing. Only allowed for signature verification.

By default, if using a FIPS validated version of wolfCrypt these checks are on by default.  The "enable_fips_checks" control command lets users override the default of all being enabled, and can pass a bitmask of available options from "include/wolfengine/we_fips.h".

Are you using a FIPS validated version of wolfCrypt with wolfEngine?

Thanks,
Chris

Hi Anika,

Let me look into this and I'll get back to you shortly.

Thanks,
Chris

Hi Renjith,

Are you able to share more details on the error that you saw for this?  Or, would it be easy to send over a simple sample app that reproduces the issue?  If so, I can help look into this further.  This may be due to a native build option that needs to change, or a higher-level JCE feature depending on the error.

We have several different math libraries available in native wolfSSL now that provide varying performance and features.  We have our normal big integer library, our fastmath library, and our newest SP Math library.  On most platforms, fastmath will be the default.  Switching over to our newer SP Math should give you performance increases for public key operations (RSA, ECDSA).

If you are uisng configure with wolfSSL, you can try the following options:

./configure --enable-sp --enable-sp-math-all <other options>

Our SP Math library does also have assembly optimizations for several platforms.  Depending on your target hardware, you may be able to add --enable-sp-asm to the above options.

Let me know if that builds OK, and what you see as far as performance goes.

Thanks!
Chris

Hi Beat,

I'm not sure that I am following the reasoning behind needing to reset "ret = 0" at that location in pkcs7.c.  It is expected behavior that "ret" would be set to ASN_PARSE_E in the following section of code for your use case, since tag != ASN_OCTET_STRING:

            /* get length of content in case of single part */
            if (ret == 0 && !multiPart) {
                if (tag != ASN_OCTET_STRING)
                    ret = ASN_PARSE_E;

                if (ret == 0 && GetLength_ex(pkiMsg, &localIdx,
                            &length, pkiMsgSz, NO_USER_CHECK) < 0)
                    ret = ASN_PARSE_E;
            }

Later on, we enter the "else" block like you mentioned above, where "detached" gets set to 1, "length" to 0, and "contentLen" to 0.  The next time "ret" is checked is inside the "#ifndef NO_PKCS7_STREAM" section right below that, where:

            /* content expected? */
            if ((ret == 0 && length > 0) &&
                !(pkiMsg2 && pkiMsg2Sz > 0 && hashBuf && hashSz > 0)) {
                pkcs7->stream->expected = length + ASN_TAG_SZ + MAX_LENGTH_SZ;
            }

Here, the value of "ret" won't matter since "length" has already been set to 0.  Then, just a little below that, we reset the value of "ret" with the following call:

            if ((ret = wc_PKCS7_StreamEndCase(pkcs7, &stateIdx, &idx)) != 0) {
                break;
            }

I re-ran your reproducer application against wolfSSL (current master), after making the following changes and verification passed successfully without the additional reset of "ret".  Changes to main.c:

1.  Removed setting "pkcs7.content" and "pkcs7.contentSz" explicitly. No longer needed for this use case after our previous modifications.
2.  Switched wc_PKCS7_VerifySignedData() to "wc_PKCS7_VerifySignedData_ex(), passing in "shaSumOfBinary".

I have re-attached the reproducer bundle I am using here.  Steps I am using to compile/test are:

$ git clone https://github.com/wolfSSL/wolfssl.git
$ cd wolfssl
$ ./autogen.sh
$ ./configure --enable-pkcs7
$ make
$ sudo make install

$ unzip signature_and_binary_v2.zip
$ cd signature_and_binary_v2
$ gcc main.c -lwolfssl
$ ./a.out -s 4dda5fe7-55d8-481a-b6eb-cf74b1b58d4d-d319ae60-1645-42b9-a9c0-eca4395587be.bin -b test.bin

calculated SHA256 of test.bin
56 d3 bb f1 e0 a9 27 b6 57 ba 90 ea 7d c0 ec e6 
ba 60 22 39 f0 ac 00 ad 8b 87 96 af ad 20 d1 40 
Sucessfully verified

Let me know if you think I'm still overlooking something, but this looks to be working as expected for this code path to me.

Thanks,
Chris

Hi Beat,

I have put up a small fix in the following Pull Request to wolfSSL that should fix your use case:

https://github.com/wolfSSL/wolfssl/pull/3996

Testing here with your sample app, with this change, your signature correctly verifies with wc_PKCS7_VerifySignedData_ex().

Best Regards,
Chris

Hi Beat,

I had a chance to look over your examples and believe you may have just been mis-using the wc_PKCS7_VerifySignedData API for use with detached signatures.

wc_PKCS7_VerifySignedData() can verify detached signatures, but your application needs to explicitly set the content and content size using the "pkcs7.content" and "pkcs7.contentSz" structure members before doing the verification.

Internally in pkcs7.c we do some detection of empty content in the PKCS#7/CMS bundle and purposefully set our internal error state to ASN_PARSE_E.  But, we recover from that error state later on once we realize the user has set the pkcs7.content and pkcs7.contentSz correctly.

I have attached a modified version of your main.c (here as main_verifySignedData.c) where I explicitly set these two struct members before doing the verification.  Compiling this against the current version of wolfSSL, I am seeing a verification success.

I did also change wc_PKCS7_VerifySignedData_ex() to the normal wc_PKCS7_VerifySignedData() in your sample application.  wc_PKCS7_VerifySignedData_ex() requires as inputs the PKCS#7/CMS "head" and "foot" as inputs that would have been received as outputs from the corresponding call to wc_PKCS7_EncodeSignedData_ex().  My guess was that you did not have these available and meant to use wc_PKCS7_VerifySignedData() instead.  But, please correct me if I am wrong.  wc_PKCS7_VerifySignedData() also handles calculation of the message digest internally, so I removed that logic from your sample code.

Best Regards,
Chris

Hi,

Yes, wolfCrypt PKCS#7 API can be used to decode a p7b certificate and extract out an X.509 certificate.

You will want to use wc_PKCS7_Init() to initialize a PKCS7 structure, then use wc_PKCS7_VerifySignedData() to decode the p7b certificate.  wc_PKCS7_VerifySignedData() will place decoded X.509 DER-encoded certificates into the pkcs7->cert array, with the size of each stored in the pkcs7->certSz array.

The following GitHub Issue has more details on API usage:

https://github.com/wolfSSL/wolfssl/issues/3638

Can you share more details about the project you are looking to use wolfCrypt in?

Thanks,
Chris

Hi thomas.zeng,

wolfCrypt's PKCS#7/CMS implementation doesn't have support for CAdES-BES currently.  This is something our team could look into adding for you if needed, under our consulting services.  We would need to add re-implement CMS CAdES-BES support ourselves in wolfCrypt instead of porting the pull request you mentioned, for licensing reasons.

wolfSSL does have an OpenSSL compatibility layer which includes a large number of the most commonly-used OpenSSL API.  Our compatibility layer does have some OpenSSL PKCS7 API support, which can be seen in the <wolfssl/openssl/pkcs7.h> header file:

https://github.com/wolfSSL/wolfssl/blob … sl/pkcs7.h

We don't yet have the CMS_sign() API wrapped yet, or the CMS_ContentInfo structure.  It looks like there may be some work required to fill out missing OpenSSL CMS API support if you would require that.  Another route would be to switch to the wolfCrypt PKCS7/CMS API instead of using the OpenSSL compatibility layer.

Is this something you would be interested in exploring further?

Best Regards,
Chris

Hi vaslion18,

Yes, wolfSSL can be used on Android for secure SSL/TLS communication.  We typically see Android users use wolfSSL through our JNI layer, since most applications are written in Java.  But, if you are only looking to use wolfSSL at the native C level on Android, you will be able to directly call native wolfSSL API.

wolfSSL itself is only an SSL/TLS layer, and does not include any HTTP functionality.  You would need to have other logic, or libraries for HTTP, but could route those through wolfSSL for SSL/TLS.

For getting wolfSSL compiling and running on Android, you may be able to reference some of our example projects here:
https://github.com/wolfSSL/wolfssl-exam … er/android

These example projects use our JNI wrappers, but you may be able to use the examples as reference for compiling the native wolfSSL library.  I believe you will need to re-compile wolfSSL for each unique Android architecture you are using.

If you have any additional questions, feel free to ask, or email our support team directly at support@wolfssl.com.

Best Regards,
Chris

Hi jlagerquist,

Thanks for the suggestion!  We now have a wolfBoot forum:

https://www.wolfssl.com/forums/forum11-wolfboot.html

Best Regards,
Chris

Hi pkolte,

Thanks again for bringing this issue to our attention.  This will be fixed in the next release of wolfSSL JNI.  We are currently working on a substantial improvement to wolfSSL JNI with the addition of a JSSE provider.  This has been fixed as part of that effort.  You will no longer need to worry about size limitations when calling WolfSSLSession.write().

Thanks,
Chris