26 Reply by dgarske

(1 replies, posted in wolfSSL)

Hi Daniel,

Your use case sounds very interesting and is one we do support. The handshake operations taking the most time are the cryptographic ones for asymmetric operations like shared secret and sign/verify. If you are using an ECC only cipher suite like ECDHE-ECDSA then you can enable our non-blocking crypto with TLS and break operations into much smaller chunks.

When the non-blocking build option is enabled the crypto calls will return WC_PENDING_E and you would just call the wolfSSL_connect/wolfSSL_accept API's again until complete.

This does require our asynchronous code from https://github.com/wolfssl/wolfAsyncCrypt.

We posted a nice blog on it here: https://www.wolfssl.com/wolfssl-bare-me … yptography

This use case is supported and used by many customers. However it might be useful to setup a call to walk you through it and hear about your use case. We will be emailing you directly to reach out.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

27 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi Leon,

Thank you for this report. Can you provide a Wireshark track of this and steps to reproduce? Does this happen with both TLS v1.2 and TLS v1.3?

Please confirm the wolfSSL client version you are using and which TLS server (if possible). It is also nice to get the logs with --enable-debug (DEBUG_WOLFSSL) and calling wolfSSL_Debugging_ON();.

Can you tell us a bit about your project and where you are located?

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

28 Reply by dgarske

(6 replies, posted in wolfTPM)

Hi Eduardo,

I am not aware of any issues generating the configuration files. Can you confirm you have both wolfSSL and wolfTPM cube packs installed and selected/enabled?

https://www.wolfssl.com/files/ide/I-CUBE-wolfTPM.pack
https://www.wolfssl.com/files/ide/I-CUBE-wolfSSL.pack

Both packs should generate their own conf files using these templates:
https://github.com/wolfSSL/wolfTPM/blob … t_conf.ftl
https://github.com/wolfSSL/wolfssl/blob … t_conf.ftl

Can you tell me more about your project and use-case? I can't attach files here, but you can send an email to support at wolfssl dot com to use our ZenDesk system to get support. I can send you examples of the generated files.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

29 Reply by dgarske

(6 replies, posted in wolfTPM)

Hi Eduardo,

I think you are seeing wolfTPM include wolfCrypt because we require it by default. We have Cube packs for both wolfSSL(wolfCrypt) and wolfTPM. wolfSSL(wolfCrypt) creates wolfSSL/wolfSSL.I-CUBE-wolfSSL_conf.h and wolfTPM creates wolfTPM/wolfSSL.I-CUBE-wolfTPM_conf.h.

If you want to use wolfTPM stand-alone you can disable the wolfCrypt support using WOLFTPM2_NO_WOLFCRYPT, however
you won't be able to do parameter encryption or import external private keys.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

30 Reply by dgarske

(6 replies, posted in wolfTPM)

Hi Eduardo,

Thanks for your interest in using our STM32 Cube pack for wolfTPM. I assume you generated the IAR project using the CubeMX tool? The tool is supposed to add a pre-processor macro `USE_HAL_DRIVER` to your project. If not please add it. Then it will use the generated configuration file `wolfSSL.I-CUBE-wolfTPM_conf.h`.

For reference wolfssl/options.h is a file generated from ./configure or CMake, which you are not using.

Can you tell us more about your project?

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

31 Reply by dgarske

(2 replies, posted in wolfCrypt)

Hi Pulkit,

Thanks for the question and talk this morning. You had WOLFSSL_SMALL_STACK defined and the HMAC struct was exceeding the available heap. The -125 error means an XMALLOC failed. Make sure you have all the SHA algorithms disabled that you do not need, leaving just SHA2-256 enabled. I also recommend removing WOLFSSL_SMALL_STACK in your case and increasing just the stack space in the linker script. Please let us know if you have any further issues.

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

32 Reply by dgarske

(3 replies, posted in wolfBoot)

Hi Arto,

Thank you for your interest in wolfBoot on the STM32. Which STM32 part are you trying to evaluate for?

We have automated testing that builds and runs most of the supported targets, so I am surprised you had issues. I will specifically try and reproduce the STM32G0 and STM32F4 issues.

We provide example configurations in config/examples that are good starting points, but typically you need some customizing for your specific part. The test-apps are really just for testing to demonstrate and can be useful for showing how to adjust your application to support the signed image header.

We will also reach out directly as we'd like to here about your project and how we can support you.

Thanks,
David Garske, wolfSSL

Go to forum: wolfBoot

33 Reply by dgarske

(3 replies, posted in wolfBoot)

Hi Info61,

Please make sure you also init/update the submodules. We use a git submodule for the wolfCrypt files required for the signing tools

git submodule init
git submodule update

Thanks,
David Garske, wolfSSL

Go to forum: wolfBoot

34 Reply by dgarske

(4 replies, posted in wolfCrypt)

Hi Thomas,

Correct. The buckets and number of buckets can be overridden at build-time. See https://github.com/wolfSSL/wolfssl/blob … mory.h#L99

The buckets `WOLFMEM_BUCKETS` and number of buckets `WOLFMEM_MAX_BUCKETS` can all be setup for your specific implementation.

I don't have a good template for the buckets with RSA. I would recommend logging the mallocs() using `WOLFSSL_DEBUG_MEMORY` to see what your heap profile looks like. Then setup buckets of appropriate size. The buckets are buffer pools are various sizes. If the next available size is not available it will select the next largest.

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

35 Reply by dgarske

(4 replies, posted in wolfCrypt)

Hi Thomas,

Can you try changing the RSA init to: 

wc_InitRsaKey(&rsaPubKey, hint);

?

Have you tried using a larger static memory pool? These get split into buckets so you won't have a large enough buffer. See WOLFMEM_BUCKETS. See https://www.wolfssl.com/docs/static-buffer-allocation/

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

36 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi MO380,

Was your LWIP already working previously? That appears to be an internal LWIP issue. Have you properly configured LWIP NATIVE?

Have you tried without WOLFSSL_LWIP_NATIVE defined, which uses the LWIP POSIX interfaces (connect/send/recv/close).

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

37 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi MO380,

Your build options likely have WOLFSSL_USER_IO set, which requires you setup your own callbacks using wolfSSL_CTX_SetIOSend and wolfSSL_SSLSetIORecv.

Try removing WOLFSSL_USER_IO and adding WOLFSSL_LWIP_NATIVE. Or if you have the LWIP POSIX layer enabled, you can just use our default POSIX ones by not defining WOLFSSL_LWIP_NATIVE.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

38 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi Patrick,

Yes that is a known issue and already fixed. You would need to update your wolfSSL. The latest is v5.6.6. You might be able to just pull over sp_cortexm.c if you are opposed to a full update.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

39 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi Patrick,

Can you confirm which API you are calling? Is it `wc_ecc_mulmod`? What ECC curve are you using?

If its one of the wc_ecc_mulmod and its one of the standard NIST prime curves like SECP256R1 then you can enable the Single Precision math speedups for Cortex M0 in sp_armthumb.c by defining the following build options:

WOLFSSL_HAVE_SP_ECC
WOLFSSL_SP_ARM_THUMB_ASM
WOLFSSL_SP_SMALL
WOLFSSL_SP_NO_MALLOC (optional)

This should provide a very significant speedup.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

40 Reply by dgarske

(3 replies, posted in wolfTPM)

Hi ZLam,

Thanks for your questions. Can you tell me where you are located and more about your project?

The TPM has endorsements key(s) and certificate(s) provisioned by the manufacture. See: https://trustedcomputinggroup.org/resou … ished-pdf/

It varies by manufacture, but it is typically ECC and RSA. There is a place in NV to get the signed certificate elements. We support using the endorsement key for a few things in wolfTPM: https://github.com/wolfSSL/wolfTPM/blob … edential.c

We will soon be adding support for extracting the EK certificate(s) as well.

You can see some of the EK certificate support in the IBM TSS stack here: https://github.com/kgoldman/ibmtss/blob … /ekutils.c

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

41 Reply by dgarske

(6 replies, posted in wolfTPM)

Hi,

Would you mind trying with the latest wolfTPM v3.1.0 cube pack?
https://www.wolfssl.com/files/ide/wolfS … 3.1.0.pack

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

42 Reply by dgarske

(16 replies, posted in wolfTPM)

Hi Grace,

The issue is your `wolfTPM2_CreateSRK` was modified to not pass in the auth, however you set it on the handle, so it tries to use it later even though the SRK doesn't have one.

The fix required is in your getPrimaryStoragekey to either pass the auth in on wolfTPM2_CreateSRK or don't set it later in the function `pStorageKey->handle.auth`.

The next issue is:

Crypto CB: PK ECDSA-Sign (4)
Error: Handle Number 1
TPM2_Sign failed 412: TPM_RC_KEY: Key fields are not compatible with the selected use
wolfTPM2_CryptoDevCb failed rc = 412
wolfTPM2_CSR_MakeAndSign_ex failure 0xffffff08: Error with hardware crypto use

Caused by this check in the TPM:

if(!IsSigningObject(signObject))
    return TPM_RCS_KEY + RC_Sign_keyHandle;

The fix for that issue is in your importECKey function where you setup the `attributes`. Replace `TPMA_OBJECT_decrypt` with `TPMA_OBJECT_sign`.

The next issue is:

Error: Parameter Number 3
TPM2_Sign failed 992: TPM_RC_TICKET: Invalid ticket
wolfTPM2_CryptoDevCb failed rc = 992
wolfTPM2_CSR_MakeAndSign_ex failure 0xffffff08: Error with hardware crypto use

You cannot use `TPMA_OBJECT_restricted` for an externally imported key.

Then wolfTPM2_CSR_MakeAndSign_ex is returning the size of the resulting DER and you assume rc == 0 on success. Replace your main.c like 864 `if (rc != TPM_RC_SUCCESS) {` with `if (rc < 0) {`.

Now the code works.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

43 Reply by dgarske

(16 replies, posted in wolfTPM)

Hi Grace,

I was able to reproduce and find one of the issues. Your crypto callback context does not have tlsCtx->eccKey set, so it is NULL and the ECC sign doesn't known which TPM key to use.

Patch:
Move `tpmCtx.eccKey = &key;` below the `XMEMSET(&tpmCtx, 0, sizeof(tpmCtx));` in `generate_CERT`.

Also one bug:
-        rc = getPrimaryStoragekey(&dev, &storage, TPM_ALG_ECC);
+        rc = getPrimaryStoragekey(dev, &storage, TPM_ALG_ECC);

However it still fails with various auth errors.

I see you are importing an external private key, but then also calling `getECCkey` which ends up trying to create a new key.
The imported key will output to your device_key.bin. There is another bug with using this. I'm still tracking it down in your code.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

44 Reply by dgarske

(16 replies, posted in wolfTPM)

Hi Grace,

Please share me your full source code (you can email it to me). I will try to reproduce and debug.

Note: I usually use a TPM simulator like https://github.com/kgoldman/ibmswtpm2 and wolfTPM's --enable-swtpm option to debug locally on my PC. Its the best way to make sure you code works before deploying on hardware.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

45 Reply by dgarske

(16 replies, posted in wolfTPM)

Hi Grace,

Looks like both the wolfCryptTest and wrap_test are passing. The error is not on the get_random, that worked fine. It is something after that. Can you please run your generate_CERT with wolfSSL debugging enabled? Call `wolfSSL_Debugging_ON();` from wolfssl/wolfcrypt/logging.h. This should provide helpful details as to why it's failing. Are you able to use GDB and step into the failing code in the crypto callback? I suspect the real error is being overwritten with the bad function arg.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

46 Reply by dgarske

(16 replies, posted in wolfTPM)

Hi Grace,

I will send you an email directly.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

47 Reply by dgarske

(16 replies, posted in wolfTPM)

Hi Grace,

Can you run the wolfcrypt/test/testwolfcrypt on the target? This will confirm your algorithms are working.
Can you run the example/wrap/wrap_test run correctly? I'd like to see the GetCapabilities report and see if it passes the RNG test.
If you are using the --enable-devtpm option it uses /dev/tpm0 and the --enable-advio and --enable-i2c options won't apply, but it should not cause issues.
Why are you using `--enable-asynccrypt`? This requires the files from wolfAsyncCrypt repo and is not common.
Is there a reason you have all crypto and all openssl compatibility on?

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

48 Reply by dgarske

(16 replies, posted in wolfTPM)

Hi Grace,

The error is `BAD_FUNC_ARG = -173,  /* Bad function argument provided */`
The command before the failure is `TPM_CC_GetRandom = 0x0000017B,`

Can you share me the build options you are using for both wolfSSL and wolfTPM?
Which TPM simulator are you using? Guessing ibmswtpm... have you tried removing the NVChip file to reset the NV?

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

49 Reply by dgarske

(6 replies, posted in wolfTPM)

Hi,

Looks like an issue with the EncryptDecrypt function due to auth. I will try to reproduce and fix. Note this is not likely a feature you will use and the rest of the tests look good. Using symetric AES on the TPM is uncommon because it is slow.

Also I recently added the CFB to the Cube template. See https://github.com/wolfSSL/wolfssl/pull/7171

Can you tell me more about your use case? If you’d like to keep it private you can email support at wolfssl dot com.
Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

50 Reply by dgarske

(6 replies, posted in wolfTPM)

Hi,

You will need to manually add WOLFSSL_AES_CFB to the generated conf file wolfSSL.I-CUBE-wolfSSL_conf.h.

We will consider adding a checkbox for CFB in the cube pack configurator.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM