Wouldn't accessing the hardware encryption chip be safer than relying on an encryption library?

My question is prompted as a response to @SqueamishOssifrage replying on the "Properly securing a private key for remote storage" post, item #6 (I don't have enough points to reply to their comment).


it takes a lot of effort to audit your software stack well enough to guarantee it is reliably using the hardware AES support on all platforms that may be of interest to you.

If my desktop application is signed, wouldn't it be safer to use the chip?

Clarification based on answer received

yeah I'm basically looking for a secure solution to storing private keys. Your point #2, storing the key in the chip where the key never sees the light of day seems like the obvious solution. Thinking through what to do for potential problems (supporting different chips, a new vulnerability being found, etc.) makes that impractical for a small-time developer. At this point, implementing a software solution where keys perhaps are signed by multiple remote servers seems the way to go (you may compromise one remote server but can you compromise them all?). If there's a better design pattern than that, I would be interested in pursuing that. As it is, I don't trust a software implementation on a single computer to do it.

  • $\begingroup$ I don't really understand your update—specifically, how signing keys is relevant to keeping keys secret. It is hard to say what is useful for your application without more details of what you're trying to accomplish, what the nature of the keys are, what your security goals are, etc. If you want help with that, can you post those details in a new question, rather than evolve the existing question? $\endgroup$ – Squeamish Ossifrage Mar 24 at 13:53
  • $\begingroup$ with the software solution, I expose my private key to sign. I'm reaching for a general solution that would cover the common use cases. Based on your answer I conclude it isn't available. I hope it will be some day. thank you. $\endgroup$ – mar233 Mar 24 at 15:02

‘Hardware encryption chips’ could mean a couple different things: it could mean

  1. hardware that simply computes cryptographic operations with keys fed in by software, like Intel's AES-NI CPU instructions; or
  2. hardware that stores keys and computes cryptographic operations in them with defensive measures to prevent anyone from ever extracting the keys, like a YubiKey USB device or an HSM.

What I was addressing in the earlier post was only the first type.

If you can take advantage of your CPU's (say) AES and GHASH hardware, then it is probably faster and less vulnerable to timing side channel attacks than software AES.

But it's a lot of engineering work to audit the entire software stack in all instantiations that might arise to ensure that you really are taking advantage of the hardware—because,

  • for compatibility, software stacks usually have software fallbacks; and
  • for performance except in sensible software like BearSSL, software fallbacks are usually faster but leaky by default; and
  • timing side channels are usually silent meaning you won't ever notice the problem until someone on the other side of the planet steals your money through a leak in your Bitcoin wallet software.

Of course, you can get almost the same performance and essentially the same side channel resistance just by using ChaCha and Poly1305 instead, and then you don't have to do all that engineering and auditing work because the widely available ChaCha and Poly1305 software tends to resist timing side channels already, and you get a better security margin because ChaCha is a better design, and your software will be usable securely on a wider variety of platforms.

So, if you're choosing a cipher for a new protocol, then this argument favors ChaCha or XSalsa20 and Poly1305 over AES-GCM in order to avoid needing hardware for fast security. But if you're choosing an implementation when your protocol has already chosen AES-GCM, then it's safer to use AES-NI or similar to compute it if you can.

As for hardware devices that store keys, well, it's great if you can do that because then malicious apps on your phone/laptop/exobrain/advertisementIVdrip can't steal the keys.

But it also means someone can't just use your awesome app with a one-click install from the app store; instead they may have to carry around a physical device, or you may have to deal with vagaries of platforms like TPM in laptops and SE in iPhones and so on.

So it's more engineering work and usability hurdles. Which may be worth the security benefit! It's up to you as an engineer to make informed decisions about these tradeoffs, using particular information about your intended audience, usage, etc.

  • $\begingroup$ This doesn't seem to address any part of the question about hardware or software being more secure than each other in a global holistic context. Schoolroom crypto is wonderful, but hardly of relevance in the real world. What use YubiKeys in Ozz? $\endgroup$ – Paul Uszak Mar 24 at 0:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.