Imagine this scenario:
- On a particular PC is a service that provides cryptographic functions -- in particular AES-CBC and ECC (ECIES/ECDSA).
- The service provides access to a single key stored in an HSM -- the key itself is never visible to any software on the PC (including the service itself).
- Copying the service software to another PC will not provide access to the same key, since the HSM doesn't follow.
- However any app running on the same PC can request that the service perform arbitrary cryptography using the same key (there is no significant authentication, other than being on the same PC). (There might be a password to initially "unlock" the service after reboot, but for the purposes of this question assume it's already unlocked.)
Problems with the above aside, if an app wants to be able to "securely" encrypt data (such that another app on the same PC with access to the same cryptography service cannot decrypt it), am I correct that a reasonable way to do so would be something like this?
- Generate random nonce.
- Hash/encrypt nonce with some hard-coded fixed internal (semi-)secret (not using service).
- Use encrypted nonce as IV for data encryption via service.
- Write unencrypted nonce to file along with encrypted data.
- Read unencrypted nonce and ciphertext from file.
- Recover encrypted nonce via hash/encrypt using the same internal secret.
- Decrypt ciphertext using encrypted nonce as IV.
The theory being that this should be as secure as the secret itself is (and more secure against attackers without access to the service).
And which would be better, salt+hashing the nonce or encrypting it, or some other function?
Another possible variation would be to use the original nonce as IV but (reversibly) encrypt it before writing to the file. Though I've assumed that's either no better or slightly worse than the above.