3

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)?
Community
  • 1
Eric Seastrand
  • 171
  • 6

3 Answers3

4

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).

Neil Smithline
  • 14,842
  • 4
  • 39
  • 55
  • 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 Nov 15 '21 at 22:04
0

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.

RoyB
  • 101
  • 1
  • @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: https://www.cloudflare.com/en-gb/learning/ssl/what-happens-in-a-tls-handshake/ – RoyB Nov 15 '21 at 22:12
  • That does not exist in TLS 1.3 and TLS 1.2 mostly uses the ECDH. – kelalaka Nov 15 '21 at 22:21
  • You should make a distinction about the version and the usage. – kelalaka Nov 15 '21 at 22:32
0

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.

Joseph Sible-Reinstate Monica
  • 7,519
  • 3
  • 24
  • 35