While we ( / I) don't know exactly what the fake private key is, there are two sensible (standard?) guesses we can make here. For a confirmation we probably would need access to the CloudHSM OpenSSL engine implementation.
So first, why do we need a fake private key at all? Well, we need a way to tell the system (a.k.a. AWS' HSMs) about which key we are talking and OpenSSL doesn't support identifiers or handles natively with the CLI interface, so we need a work-around and these fake private keys are exactly that. They are means to designate specific keys within the HSMs.
So what do these files actually contain? There are two sensible options:
- They contain a handle, that is an identifier. This means that they essentially just contain a string which says "if you see me, use key X on HSM-cluster Y", but they don't actually contain the private key.
- They contain the encrypted private key. This means that the HSMs would (symmetrically?) encrypt the private key and put it in this file, so they don't have to keep it in their own storage. This may be accompanied with an identifier for the symmetric key, similar to (1). Also this would mean that deleting the key is as simple as deleting all copies of the fake private key and no interaction with the HSMs for key deletion is required.