I am working on a project where I need to securely encrypt and decrypt files on a product without the ability for direct communication or key derivation after the product is sold. The challenge is that I can only store encrypted data on the product without any means to communicate with it post-sale. I've explored using private-public key encryption, but as this is not a classical exchange scenario, I'm seeking advice on alternative methods. Any suggestions for secure encryption and decryption on a product without post-sale communication would be greatly appreciated. Thank you!

Edit for more insight: Our objective is to establish the authenticity of our data, particularly when encrypting license keys and securing encoded commands. Before transmitting sensitive information, such as license keys, we employ digital signatures using our private asymmetric key. This signature acts as a unique identifier, verifying that the data originated from us. When recipients receive the data, they can verify its authenticity using our public key. – This process ensures that only our software, possessing the corresponding public key, can decrypt and validate the license keys or execute secured commands. By employing digital signatures, we prevent unauthorized parties from forging data or executing unauthorized commands, thereby enhancing trust and security in our software. –

For now we are using deprecated functions of OpenSSL who allow the private key RSA encryption (rsa_private_encrypt) and public key RSA (rsa_public_decrypt). We generate a symetric key, encrypt it with priv rsa and then use that key to encrypt data. on the hardware we store only the encrypted symmetric key and encrypted data along with the public rsa key. Im not sure if this is 100% effective for our purpose but needed to get rid of these functions (deprecated) but no other open source cryptolib offers that.. that is why I decided to look for better ways.

  • Will both encryption and decryption be taking place on the same device? If so, then symmetric encryption (where the same key is used for both encryption and decryption) might be more appropriate than asymmetric encryption.
    – mti2935
    Mar 9 at 20:59
  • 1
    A warm welcome to the community. Please elaborate on your use case with more technical details. Mar 9 at 22:34
  • Cross posted to cryptography (under a different nick). Please don't crosspost. Mar 10 at 11:04
  • @mti2935 please check post, put more info, thanks a lot
    – mrx
    Mar 11 at 1:09
  • @SirMuffington please check post, put more info, thanks a lot
    – mrx
    Mar 11 at 1:09

1 Answer 1


It sounds like you're trying to hide data from your own customers while giving them physical access to the product. This is fundamentally impossible in the strictest sense. You can make it hard to get to, require advanced skills and even expensive equipment that itself requires skill to operate, but you can't make it impossible. Up to you how much this inconvenient fact of reality matters, and how much effort you want to spend on trying to do the impossible anyhow.

There is no way, in pure software, to reliably achieve the goal you describe. You can embed a public key in the product, and use that to verify signatures, but you can't (meaningfully) use it to decrypt commands; it's mathematically possible (with RSA specifically, not all digital signature schemes support this), but it doesn't add meaningful security because public keys are public and anybody else could use one to decrypt it too. You could embed a private or symmetric key and use that for decryption, but it would immediately be compromised the first time somebody with a bit of reverse engineering skill decided to poke your software.

Even the "include a public key to verify signatures" approach can be bypassed if the attacker is able to either edit the binary / key file to use their own public key (letting them sign commands/data with their own private key), or edit the binary to skip over the check entirely. Since in this case the "attacker" is presumably the customer, who has direct physical access to the system where the software runs, you generally must assume they have such capability. If your product is pure software, you can protect against an unskilled attacker who can't be bothered to download a tool, but that's it. This is a variant of the fundamental problem with DRM (Digital Rights Management) systems.

With hardware security features, you could do better. HSMs / secure enclaves let you store per-device keys, and use them in software, without letting a user extract or modify those keys. This can be used to create decryption and verification software that needs to be signed before it can be loaded into the HSM/enclave, and can only be signed by your own key. This signed software thus can't be modified by an attacker.

Any software running outside of the secure element can still potentially be reverse engineered and/or extracted, so it could for example be changed to take actions without the secure element being involved at all, or to ask the secure element to decrypt some data and then expose the plaintext to the attacker. To prevent that, you need a secure boot chain, where the hardware verifies that the bootloader hasn't been tampered with, the bootloader verifies the OS or embedded software, etc. This is possible using a feature often found in modern hardware called a TPM (Trusted Platform Module), and can even be done in a way that permits updates (they have to be signed with the same private signing key, but if you keep that key properly secured you should be OK). If your hardware supports secure boot natively, you should use it (and disallow user-added verification keys!).

Ultimately, in cases like this it comes down to how much risk you're willing to accept. If somebody decrypting this data is an existential risk to the company, you're going have a bad time, and should probably go back to the drawing board. If you're just trying to keep people basically honest with licensing and aren't going to be too fussed about a bit of piracy, then sure, you can do this. Just don't assume it's unbreakable. Even hardware security can be bypassed by sufficiently advanced attackers (though it raises the bar a lot).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .