1 Topic by Felix P (edited by Felix P 2025-06-18 02:13:29)

  • Registered: 2025-06-18
  • Posts: 2

Topic: Crypto Callbacks: Managing HSM hash context and context copying

Hi all,

I’m integrating the wolfSSL (v5.7.6) library into an Infineon Aurix (tc3xx) which utilizes a HSM (etas Cycur HSM). I'm trying to offload various crypto functions to the HSM and am running into issues.
Because the HSM is not stateless, each hash operation needs its own session/context, which must be managed per hash object.

Current approach:

On first update, I allocate a context from a memory pool and store it in the devCtx pointer of the wolfSSL hash object.

On finalize, I close the HSM session, free the context, and set devCtx to NULL.

I'm currently not yet at the point where I actually feed the HSM with data, as I am testing if the opening and closing of sessions with the pools themselves work.

Problem:
I’ve observed that wolfSSL sometimes internally copies (clones) the SHA256 context via the wc_Sha256GetHash() function - including my devCtx pointer.
This results in both the original and the copy calling finalize (and freeing the same context), leading to double-free or resource leaks, because there’s no way to distinguish the “real” owner from a clone.

I’ve noticed:

Some device ports (e.g., for ESP, PIC, STM32) and features like WOLFSSL_ASYNC_CRYPT seem to support callback hooks or custom context copy/free handling.

But I haven’t found a generic, portable way to handle context lifecycle events (copy/clone/free) for my own MCU/HSM, or a way to enable these hooks via public configuration.

My questions:

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

If not, is patching the library to add these hooks the only solution, like adding my own wc_Sha256* functions? Another idea would be to omit the sha256.c file and compile in my own instead that handles lifecycle and so on.

Are there plans to expose such lifecycle hooks for generic crypto callback users, or are there any existing workarounds (besides buffering all hash input)?

Why I need this:
My HSM context can’t be blindly copied or freed multiple times.
I need to track ownership, ideally with explicit create/copy/free callbacks, to avoid double-free and allow robust session management - especially if wolfSSL hashes in parallel or clones contexts internally.

Any advice, or pointers to a non-device-specific solution, would be greatly appreciated!

Thanks!

Share

  • brett
  • Moderator
  • Offline
  • Registered: 2024-10-01
  • Posts: 3

Re: Crypto Callbacks: Managing HSM hash context and context copying

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!

Share

  • Registered: 2025-06-18
  • Posts: 2

Re: Crypto Callbacks: Managing HSM hash context and context copying

Hello Brett,

thank you for your response.

brett wrote:

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?

I actually noticed these flags five minutes after I made the post.

The issue here is that I can use the "is copy" flag to know if the wolfSSL-SHA object is a copy so I don't free my resources, but there are some occasions where the getHash function is called (which does a copy + finalize of the hash object to get the digest) but the original might not call the finalize function. So my idea of "free on finalize" wouldn't work out if the original never finalizes.

My current solution is just patching the wolfSSL code to notify me on init/copy/free plus reference counter which seems to not leak any resources and not run into issues, yet. For testing purposes I'm still doing software hashing and the HSM ownership stuff is running in parallel just to test the sanity of everything. I'll try to actually feed the HSM on Monday.
I'll probably go with the patching + ref counter approach with every other domain (AES, signing and whatever else comes up).

Regarding wolfHSM:
My colleagues are actually evaluating it but have nothing that I can use right now, so I'm stuck with etas for the time being so I can get the proof-of-concept stuff out of the door.

Also, I'm currently in contact via mail with someone from your German colleagues who might be able to clarify some stuff.

Share