Lets say there is an industrial device communicating with a central system. Secure communication is required from an end to end point of view. From time to time keys of the devices must be renewed by receiving encrypted keys based on NIST key-wrap protocol. So the device shall unwrap the keys and store it internally on a safe place. As a producer of an encryption library we encapsulate this functionality within API functions, running on a high-end micro-controller. This library makes use of certain cryptographic primitives implemented in hardware on the MCU and is provided to the partner manufacturer "P" of the device, who implements the main part of the firmware. Naturally, there is a point in my software, where the key is just being unpacked and available in memory - at least temporarily. It was decided, not to use a HSM because of cost issues - of course I know, that the approach is sub-optimal.

The question is quite simple now:

The functions of the library are clearly debug-able by P, at least on assembler level. So what we do internally is not at all invisible to the partner. Even when the API functions do not directly return keys, I would say, that we cannot assume unwrapped keys to be "hidden" against P.

Is there any difference in terms of "security" between passing keys directly to the user of the library and hiding them within our routines as described? In fact, this type of "hiding" is more than weak and so I would guess, that it is worth exactly nothing and in fact not existent.

However, my management has other opinion and wants to convince me, that the key material is somehow "secure", as long as the key material is not exposed directly as an output of the library. However, they say, for I would return a key as output of a function, this "security" would be broken. For me, this point of view is more than ridiculous...but I want to hear, what other people say. Maybe I'm wrong.

For those, tempted want to downgrade my question:

Regarding the architecture, it was not at all my decision, to implement it in that way...beside the possibility of a side channel attack the key material is secure within the device. Our management just wants to hide any key material from the manufacturer of the firmware, just to be sure to prevent them from doing any "bad" things. I think, that this goal is not in the least fulfilled by this approach.

  • What's "downgrading" a question? Did you mean "downvoting"? If you think people will downvote if they don't see a paragraph, then that paragraph is important, and should be well-integrated into the rest of the post, not just tacked on at the end.
    – anon
    Commented Jul 12, 2019 at 15:40
  • There are cheaper forms of HSM, in the form of smart cards. Yes they're much more limited in the amount of processing power they have compared to a full HSM, but it might be sufficient if you don't have too much encryption traffic or if you use it only for encrypting the bulk encryption keys and signing hashes rather than doing all the processing on chip.
    – Lie Ryan
    Commented Jul 13, 2019 at 1:21

1 Answer 1


There's a saying in security: If an adversary has physical access to your hardware, it's not your hardware anymore. HSMs try to circumvent that rule, but even they aren't perfect; nothing is. HSMs will only delay the attacker for longer and up the stakes, making them want to default to an easier target. Because of that, no, it's not secure against the firmware creator.

There is one important security consideration I think you're missing, though. You're writing a crypto library. That means someone will be using that crypto library. And that person probably isn't a cybersecurity engineer. They might not even be a good programmer. By not passing back the key, you're effectively protecting them from themselves. That will help security.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .