There are fairly affordable FIPS 140-2 Level 2 USB HSMs.
Kingston makes a fairly decent one. It's how we manage our root of trust right now. Two of those with root identity and reciprocally signed exec identities. All of the artifacts stored in git RSL repos on the HSM, the two HSMs sync'd via signed commits and merges so we have an audit trail, one HSM is stored on-site and the other off-site, and one can be checked against the other to measure for tampering. All of the initial provisioning happens on an air-gapped machine with intermediate artifacts that only live in a temporary RAM disk that itself is encrypted with a 4096 byte key that is never known to anyone (it's fed straight into the ecrypt tooling and discarded).
The next layer out from that is all Yubikey based.
It's an extremely cumbersome process to do normally, but we invested a fair bit of time in creating automated key ceremonies of different shapes to handle different parts of the process.
Nope, you're absolutely right. We'd just adopted the colloquialism internally compared to the Yubikeys, and I'd lost context for the whole purpose of our key ceremonies was originally to be able to treat those IronKey devices tacitly like HSMs.
As the other users said if you're using one the drives listed at https://www.kingston.com/en/usb/encrypted_security they seem to be just "encrypted drives", without any support for internal signing operations.
If that's so you're doing all the key operations on the computers at which they're connected, and you've come up with an extremely cumbersome process that gives you very little protection.
Adding to the insult, there actually exist many cheap USB proper cryptographic tokens, that really do all the operations internally and have even FIPS 140 level 3 certifications. They are just slower and have less physical protection, features and storage than "proper" thousands-dollars HSMs.
Note that the FIPS certification of those Kingston drives means just that the key with which the data is encrypted cannot (easily) be extracted.
I stumbled again at this post; "the key cannot be extracted"???
Why on earth would a portable drive need to store the decryption key for its data, however protected??
Actually I've never looked before into "encrypted drives" and I don't know what do they do or what purpose exactly do they serve, I must have written that thinking about HSMs and other signing devices.
It does seem indeed that at least those Kingston drives do not store the encryption key (actually, they store it but encrypted with the password).
I'm not sure what purpose do the FIPS certification and all those physical protections serve, then.
Yeah, I don't think those are really HSMs. Just a very secure USB stick.
The whole idea behind an actual HSM is that you never trust any computer it is plugged into, it is designed to be impossible to retrieve the key stored in the device via any means. All signing operations are done internally in the device itself - you simply can't mess up and accidentally leak key information.
Kingston makes a fairly decent one. It's how we manage our root of trust right now. Two of those with root identity and reciprocally signed exec identities. All of the artifacts stored in git RSL repos on the HSM, the two HSMs sync'd via signed commits and merges so we have an audit trail, one HSM is stored on-site and the other off-site, and one can be checked against the other to measure for tampering. All of the initial provisioning happens on an air-gapped machine with intermediate artifacts that only live in a temporary RAM disk that itself is encrypted with a 4096 byte key that is never known to anyone (it's fed straight into the ecrypt tooling and discarded).
The next layer out from that is all Yubikey based.
It's an extremely cumbersome process to do normally, but we invested a fair bit of time in creating automated key ceremonies of different shapes to handle different parts of the process.