Hi Daniel,

The macro OPENSSL_EXTRA will need to be defined for wolfSSL to be built with the *_X509_* API. This is API in the compatibility layer which eases integration into applications previously using OpenSSL. Once at the point you are at, with the examples compiling and running, you can then adjust which macros are defined for configuring how wolfSSL is built. For example in the example IDE/LINUX-SGX/sgx_t_static.mk file there is the Wolfssl_C_Extra_Flags variable that OPENSSL_EXTRA could be added to. Note that this macro define should be added to both the building of libwolfssl and to the compiling of the application.

We've not tested with the additional functions built with SGX, there might be system calls in the compatibility layer that need worked around for running smoothly with SGX.

Here are some non SGX examples that do not use the compatibility layer API that could be referenced (https://github.com/wolfSSL/wolfssl-exam … er/certvfy).

These are also examples that show using a CA to verify a signature without using the compatibility layer API (https://github.com/wolfSSL/wolfssl-exam … ertmanager).

Thanks chaudhryfaisal for your patience on this,

I made progress and got it to the point of being able to collect benchmarks. It should be good for a PoC and initial benchmarking. I ended up hard setting the cpuid flags due to the SGX restrictions between trusted/untrusted. It's likely the CPU you are using supports the same things (i.e avx2, avx2, aesni) but that could be a potential pain point. There is more that could be done to the wolfSSL code for determining the CPU capabilities at runtime.

The wolfSSL changes and benchmark numbers I collected when testing it are located here (https://github.com/wolfSSL/wolfssl/pull/8463).

The updated example application used to collect the benchmark numbers is located here (https://github.com/wolfSSL/wolfssl-examples/pull/488)

Please give it a try and let me know through support@wolfssl.com if there are any issues encountered.

These changes get AES-NI use closer. (https://github.com/wolfSSL/wolfssl/pull/8463) and (https://github.com/wolfSSL/wolfssl-examples/pull/488). It passed unit tests using SIM mode. But had an issue with aes-gmac using HW mode. Possibly a buffer alignment issue. I'm not sure when I will be allocated time to farther investigate the aes-gmac unit test. Could you give it a try with your SGX SDK and compiler and see if these changes work for you?

Hi Iycboy,

Eric is correct that, the public key portion is necessary in addition to the private key for signing. Just as a side note though you can generate the public portion given the private portion of the key. Check out the API wc_ed25519_make_public and wc_ed25519_import_public.

The question is if we should be trying to do this automatically in wolfSSL given a sign request where the public portion of the key is not set, just the private key. Will discuss that internally, in the mean time though generating and importing the public key is how you could avoid having to send / store the public key portion. Or if you could send /store the public key portion with the private key then altering the DER being passed to wc_Ed25519PrivateKeyDecode to also contain the public key would avoid the public key generation step.

Regards,
Jacob

Not sure, maybe OpenSSL key generation on Windows is just slow.....

Mac i7 with wolfSSL does around 6 generations per second for an average of 178.508 ms per generations. Without disabling any safe guards.

./wolfcrypt/benchmark/benchmark
...

RSA     2048 key gen         6 ops took 1.071 sec, avg 178.508 ms, 5.602 ops/sec
...

For the 20 seconds on the device there could be multiple factors 32bit vs 64bit for one, have ran into that previously or optimizations with the build flags. We would have to do some optimization investigations under a support contract for faster speeds.

Regards,
Jacob

I don't see any benchmark values internally for the AM3352. We have a benchmark for a Rasperry PI at 1500 MHz with a 2048 bit RSA key generation. It took a little under a second at 700 ms. That was with --enable-fastmath and --enable-sp --enable-sp-asm.

Hi Scotty2541,

The function wc_SetDatesBuffer takes in a DER formatted certificate to use the date from it.

There is two main options for setting the date:

1) Set it directly in the Cert structure using the current API's you have listed. This is setting beforeDate, beforeDateSz, afterDate, afterDateSz, daysValid.

2) Use the compatibility layer APIs and create the certificate using WOLFSSL_X509 structure. This has the API's wolfSSL_X509_set_notBefore and wolfSSL_X509_set_notAfter. The function test_wolfSSL_X509_sign2 in tests/api.c has code testing the setting of a certificate date when creating it.

Regards,
Jacob

Hi Donnie.dump,

Can you tell us some about the background of how wolfSSL is being used? If the details can not be put on a public forum like this please contact us through support @ wolfssl.com.

wolfSSL natively does support unnammed and custom curves when compiled with ./configure --enable-ecccustcurves. The JSSE wrapper does not support custom curves though.

Regards,
Jacob

The wolfssl-py if being used looks at the default location of /usr/local when built by running "pip install". A couple ways to go about it would be to install wolfSSL at that default location having been compiled with the static RSA macro or to build wolfssl-py using the environment variable USE_LOCAL_WOLFSSL=/wherever/wolfssl/install/is/

To build wolfSSL with static RSA enabled go to the wolfSSL directory "cd wolfssl/" and run "./configure CPPFLAGS=-DWOLFSSL_STATIC_RSA --prefix=/wherever/wolfssl/install/is/  && make install".

Regards,
Jacob

The main wolfSSL library will need compiled with SNI and Supported curves enabled. If adding in the functions enc_wolfSSL_CTX_UseSupportedCurve and enc_wolfSSL_set_SNI it looks like by default those are off with the library build and the example. SNI is enabled with the HAVE_SNI macro and supported curves are enabled with the HAVE_SUPPORTED_CURVES and HAVE_TLS_EXTENSIONS macros.

Regards,
Jacob

Hi Kannan,

Just to double check possible places that could cause the undefined issue. Did you build the BSP after xilsecure was added?

Regards,
Jacob

Hi Abbey,

There may be an options.h or some settings in the way. Please try from a fresh directory with the following commands on Linux (plus the one change you did in the Makefile).

(download and unzip wolfssl 4.1.0)
cd wolfssl-4.1.0/IDE/LINUX-SGX
make -f sgx_t_static.mk HAVE_WOLFSSL_TEST=1 HAVE_WOLFSSL_BENCHMARK=1 all
cd ../..

git clone [url]https://github.com/wolfssl/wolfssl-examples[/url]
cd wolfssl-examples/SGX_Linux
#(if SGX_SDK is not already set then)
export SGX_SDK=/opt/intel/sgxsdk
make SGX_MODE=HW SGX_PRERELEASE=1 SGX_WOLFSSL_LIB=../../IDE/LINUX-SGX/ WOLFSSL_ROOT=../../ SGX_DEBUG=0 HAVE_WOLFSSL_TEST=1
./App -t

If the issue persists after a fresh attempt using the above commands let me know and we can dig into it more to debug what is going on.

Regards,
Jacob