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.