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

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

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

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

Hi Grace,

Can you enable the DEBUG_WOLFTPM and WOLFTPM_DEBUG_VERBOSE (or --enable-debug=verbose) options and provide logs? I suspect it will help guide what the error is. Oh and you should also enable the wolfSSL debugging using --enable-debug or DEBUG_WOLFSSL.

I suspect there is a missing build option for wolfSSL or you haven't properly set the crypto callback TpmCryptoDevCtx .rsaKey or .eccKey.

Thanks,
David Garske, wolfSSL

Hi Alessandro,

The RsaKey can be either a public only or private key. Depending on that you can do either a public only operation or public and private. The public modulus and exponent must be known. You would use the wc_RsaPublicKeyDecodeRaw API to import those. Example: https://github.com/wolfSSL/wolfTPM/blob … 0-L3092C34

Thanks,
David Garske, wolfSSL

Hi Alessandro,

I assume your key size is 2048-bit. The RsaPublicEncrypt uses PKCSV15, so the max input is not the key size. To public encrypt an already padded 256-byte you would want to use `wc_RsaDirect`.

/* Function that does the RSA operation directly with no padding.
 *
 * in       buffer to do operation on
 * inLen    length of input buffer
 * out      buffer to hold results
 * outSz    gets set to size of result buffer. Should be passed in as length
 *          of out buffer. If the pointer "out" is null then outSz gets set to
 *          the expected buffer size needed and LENGTH_ONLY_E gets returned.
 * key      RSA key to use for encrypt/decrypt
 * type     if using private or public key {RSA_PUBLIC_ENCRYPT,
 *          RSA_PUBLIC_DECRYPT, RSA_PRIVATE_ENCRYPT, RSA_PRIVATE_DECRYPT}
 * rng      wolfSSL RNG to use if needed
 *
 * returns size of result on success
 */
int wc_RsaDirect(byte* in, word32 inLen, byte* out, word32* outSz,
        RsaKey* key, int type, WC_RNG* rng);

Thanks,
David Garske, wolfSSL

Hi Febin,

That is a generated file. Have you followed the instructions here?
https://github.com/wolfSSL/wolfssl/tree/master/tirtos
https://www.wolfssl.com/documentation/U … I-RTOS.pdf

I recently did build TI-RTOS for a project successfully, but it was difficult getting the packages setup.

I also recently pushed some fixes for the TM4C here: https://github.com/wolfSSL/wolfssl/pull/7018
Those are in the latest v5.6.6 release.

Thanks,
David Garske, wolfSSL

Hi Ethan and John,

Its difficult getting the environment setup. Would one of you mind sharing a CCS project with me?

I've got wolfSSL building using the instructions at https://www.wolfssl.com/documentation/U … -RTOS.pdf, but having trouble importing the TLS echo example. I may just end up creating a simple wolfCrypt_test project from scratch.

So far I've pushed my cleanups to: https://github.com/dgarske/wolfssl/tree/ti_aes , however no real fixes in AES GCM yet.

Feel free to email support at wolfssl dot come directly with any examples and reference this forum link.

Thanks,
David Garske, wolfSSL

Hi RCuller,

The input password will need to be padded to block size before being encrypted. The block should still decrypt properly even if you use a larger size. If you can explain how the encryption works it will help us guide you. Hopefully the example will provide some clues.

If you'd like to take this to a private channel you can email support at wolfssl dot com and we'll provide free pre-sales support.

Thanks,
David Garske, wolfSSL

Hi mnzdbz,

Because you are using WOLFSSL_SMALL_STACK it uses heap instead. If you remove the small stack option it will use stack and not heap.

Which mode of AES? There are AES tables as you found. Not using the tables slows down the operation because it must compute values. Are you building the .c code with optimizations enabled like "-Os" or "-O2"? Those make a big different.

Besides WOLFSSL_AES_SMALL_TABLES you can also play with WOLFSSL_AES_NO_UNROLL to see how that impacts performance and code size.

Thanks,
David Garske, wolfSSL

Hi mnzdbz,

How is your stack configured? Fast math (tfm.c) uses stack not heap. The correct size for FP_MAX_BITS is your maximum key size * 2 (for multiplication of two big integers).

You would likely need about 8KB of stack with your configuration. If you would like to use heap I recommend the following build settings.

#define WOLFSSL_SP_MATH_ALL
#define WOLFSSL_SP_SMALL
#define WOLFSSL_SMALL_STACK

This will use our sp_int.c with heap allocations.

Thanks,
David Garske, wolfSSL