1 Reply by brett

(2 replies, posted in wolfCrypt)

Hi Felix,

As you correctly noticed, crypto callbacks currently don't provide a generic copy/free callback, or any mechanism to track ownership. This must be implemented by the user on top of the cryptocb framework.

Is there a portable way (not device-specific) to get notified when wolfSSL copies or destroys a hash context, or to customize this process?

For SHA variants, have you looked at the WOLFSSL_HASH_FLAGS option? This should do just what you are looking for - it will add flags to the context indicating whether or not the struct is a copy or the original. I imagine that using this combined with adding a refcount to your custom context should be enough for your cryptocb to know when to free the custom context when a finalization operation is detected?

Also, rolling your own end-to-end HSM solution (or even just the client side) on TC3xx via crypto callbacks is a big endeavor. Have you considered using wolfHSM? wolfHSM would do all of this for you, and is tightly integrated with wolfCrypt/wolfSSL as well as wolfBooot. We created it because we were tired of seeing so many customers "reinvent the wheel" with proprietary solutions built on top of wolfCrypt, and so set out to develop a uniform end-to-end solution to do exactly what you are trying to do (and more!).

https://www.wolfssl.com/products/wolfhsm/
https://www.wolfssl.com/documentation/m … index.html
https://github.com/wolfSSL/wolfHSM

Please get in touch if you would like more information about wolfHSM!

Go to forum: wolfCrypt

2 Reply by brett

(1 replies, posted in wolfBoot)

Hi there,

Thanks for your interest in wolfBoot on AURIX!


What is the reason behind it ? Why not 0xA000_0000 ?

This is due to compatibility with one of the demo examples for wolfHSM on the AURIX platform. If you are just using wolfBoot without wolfHSM, then you can feel free to modify how wolfBoot utilizes the address space however you wish, as long as you also update the appropriate wolfBoot configuration preprocessor macros accordingly (ARCH_FLASH_OFFSET, WOLFBOOT_PARTITION_BOOT_ADDRESS, WOLFBOOT_PARTITION_UPDATE_ADDRESS, etc.). Note that this is done for the fixed demo project addresses by the AURIX helper script (tools/scripts/tc3xx/wbaurixtool.sh) when invoked with the "target" sub-command.

- For more information on wolfHSM see: https://www.wolfssl.com/products/wolfhsm/
- For more information on how wolfBoot integrates with wolfHSM, see: https://github.com/wolfSSL/wolfBoot/blo … wolfHSM.md and the wolfHSM integration section of the README you are referencing.
- Further information about the HSM subsystem on AURIX is restricted by Infineon NDA. Please reach out to your Infineon sales representative.

It seems that to edit the UCB STAD address I need a licence for winIDEA that I do not own and I dont know how to get it

You don't need winIDEA specifically to edit the UCBs, you just need to be able to program those flash sectors. This can be done using the Infineon provided memtool and the onboard "mini wiggler DAP", an external programmer like a Lauterbach device, or even from source code running on the device.

Note that the wolfBoot documentation does assume a general understanding of how the AURIX platform works, including how to program and configure the device. The AURIX platform is quite complex and the UCBs are a fundamental aspect of the system configuration, so I would urge you to consult the reference manual for the device to learn more. I would also recommend reach out to your Infineon sales or support contact for more information and training material.

Best,
Brett

Go to forum: wolfBoot

3 Reply by brett

(2 replies, posted in wolfCrypt)

Hi jlewis,

Thanks for reaching out.

The core wolfHSM code does not rely on dynamic memory allocation, so the only thing that would need dynamic allocation would be wolfSSL/wolfCrypt (if configured as such). Some wolfHSM tests, simulated transports, or port-specific code for POSIX targets may use dynamic allocation, but this can be excluded by the end user.

It says:
"You can configure wolfSSL with --enable-staticmemory or by defining the WOLFSSL_STATIC_MEMORY macro. However, this feature is limited to basic TLS connections and currently is not supported in wolfCrypt."
And I've seen elsewhere that wolfCrypt is needed for wolfHSM.

Apologies, that FAQ is slightly outdated - there are wolfCrypt APIs that support static memory, specifically those that take a HEAP_HINT pointer. If you are using those APIs then you can guarantee everything is allocated statically. If APIs are used that don't support it when building with WOLFSSL_STATIC_MEMORY, then those calls will fail.

Also, do I need wolfHSM in order to run wolfSSL on an HSM?  Or is it just helpful?

You can absolutely run just wolfSSL or wolfCrypt in your custom HSM application, but wolfHSM provides built-in functionality that will save you lots of time. We saw many customers spending considerable effort building custom HSM solutions with wolfSSL/wolfCrypt, which is why we developed a complete solution in wolfHSM that will work out-of-the-box.

Best,
Brett

Go to forum: wolfCrypt