This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

PROCESSOR-SDK-AM64X: Using HSM to build OPT keywriter application

Part Number: PROCESSOR-SDK-AM64X


Tool/software:

Hi Team

I did not get a satisfying answer to my question here https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1447510/processor-sdk-am64x-using-hsm-to-build-opt-keywriter-application so far. However the thread was simply locked. Maybe this was done automatically by the system. A response would be very much appreciated even if the response says that TI is not willing to investigate any further.

  • Walter, I will soon be running into this exact same issue - but I'm trying to work out how to use an HSM in the Yocto build flow at the moment !

    My assumption is that we need to configure 'openssl' to support a pkcs#11 'engine' or 'provider', but I need to know the TI way of doing that in order to progress.

    I will keep checking to see if you get a suitable answer.

  • Hi Walter,

    We reached the same conclusion as you. It is not feasible to keep SMEK/BMEK in an HSM at all times, because appending 32 bytes of random data during a wrapping operation is not something a standard HSM can typically provide.

    From my understanding, these 32 bytes are used to verify the success of the decryption. After decryption, the last 32 bytes are compared to the 32 bytes embedded in the rs value of the certificate extension.

    Wrapping SMEK/BMEK with TIFEK (public) directly would allow to make the secret keys non-exportable. However, I fear this is a breaking change that TI is not willing to implement.

    Best regards
    Raimar

  • Hi Raimer, Walter,

    I have followed through with Walter's suggestions, and have patched the otp_keywriter scripts to access an HSM successfully - but we are only storing SMPK and BMPK keys in the HSM.

    As we are not 'actively' using SMEK or BMEK in our usage, I confess that I haven't worried about these particular keys. If we were to encrypt our code, that would be different - but that isn't supported in the default Yocto builds today, which makes the choice somewhat moot Slight smile

    I've also managed to patch binman to support the HSM access through our Yocto build, though I find the openssl -> pkcs11 -> HSM device path to be quite flaky in operation; I "often" get first-time-through failures accessing the key in the HSM, with a repeated build just working (no changes, just re-build).

    Regards,

    David