I read another question about an embedded https daemon, which got me wondering:

How might one maintain secrecy about the private key within such an embedded system?

My logic is: If the device ships with the key inside it, and someone can obtain [a version of] the physical device, they can get the data out of it (including the RSA private key.) Right?

Once they have the private key:

  1. What stops them from sniffing your network traffic, and decrypting everything you send to the server?
  2. What stops them from pretending to be the device (MITM attack)?

3 Answers 3


Yes, they can likely manage to extract your private key from the device. Even if you encrypt the key and don't keep the decryption key on the device (eg: you must enter a password to decrypt the key when you boot), there are techniques for extracting the key (eg: cold boot attacks). And, depending on the deployment scenario, you may not even be able to force a password to be entered on boot. In the end, there's no security without physical security.

In answer to your question:

What stops them from sniffing your network traffic, and decrypting everything you send to the server?

The ability to sniff TLS traffic in the face of a disclosed private key can be prevented by using TLS ciphers that support perfect forward secrecy. In these ciphers, the private key is only used for authentication and not encryption.

What stops them from pretending to be the device (MITM attack)?

Nothing (unless you have physical and virtual network infrastructure that ensures that an MiTM can't occur - this likely requires a secure network).

  • A cold boot attack is not appliable here! The OP considers the attack on the hardware transmit stage. Cold boot is applicable when the attacker can access a system just closed. This is very important especially for the FBI. And MitM is quite possible.
    – kelalaka
    Commented Nov 15, 2021 at 22:04

HTTPS uses asynchronous keys. One key is public, another is private. You do not need the private key to setup a secure connection, hence it is kept on the server thats on the other side of the internet, not in your embedded device.

When an embedded system wants to setup a secure connection, the only thing needed, is for the device to be able to see that the public key of the server is the unfalsified, original public key. This is done by checking that the key is signed by a certificate authority.

The only way you would be able to sniff the traffic is if you can manipulate the embedded device into trusting your home made fake self-signed certificate.

The thing with asynchronous communication is, that the PRIVATE key is kept away from anyone at all on a machine that nobody can get into. You use the public key to ENCRYPT data, and the private key to DECRYPT it. The private key cannot be derived from the public key.

  • @kelalaka during a TLS handshake the public private keypair is used to generate and exchange a symmetric key for the continuation of the TLS session. This part of the secret is called the "premaster secret" wich is generated by the client and then encrypted using the verified public key of the serverside. Source: cloudflare.com/en-gb/learning/ssl/…
    – RoyB
    Commented Nov 15, 2021 at 22:12
  • That does not exist in TLS 1.3 and TLS 1.2 mostly uses the ECDH.
    – kelalaka
    Commented Nov 15, 2021 at 22:21
  • You should make a distinction about the version and the usage.
    – kelalaka
    Commented Nov 15, 2021 at 22:32

Put a different key pair in each device. Then if someone buys one and extracts the private key, it's useless for attacking anyone except themself. And if an attacker manages to get physical possession of someone else's device, it's game over for them no matter what you do.

You must log in to answer this question.

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