3 ms·

If the user is MITM'd, what's preventing the attacker also replace the signature to verify against?

kuhsaft 2y ago
The signature would use asymmetric encryption, so unless the attacker had access to the signing key, it would be impossible for the attacker to sign a modified version of the payload. EDIT: I see what you mean. radicaldreamer stated that a malicious root certificate is installed, but signature validation wont help there. But, it will help when downloading from mirrors or HTTP.
pixl97 2y ago
You verify against the signature that's in the current version. Now this may mean that you need to do stepped upgrades to versions that are cross signed to get new certificates. That or you have at least one https update method that gets a signing cert for the application.
- littlestymaar 2y ago
  And how do you ensure the integrity of “the signature that's in the current version”? Because live patching the signature in a program to force verification of an invalid payload is exactly how many software/game cracks work.
  - pixl97 2y ago
    I mean, if you can't verify the integrity of the application you're already running then it's already game over. You're talking about downloading another executable and running it to life patch which is the exact opposite of what I'd suggest. The currently running (trusted) executable downloads and verifies the signature of the binary. Then after verification you execute it. If your trusted binary is validating invalid data then you've already messed up somewhere.
    - littlestymaar 2y ago
      Re-read the thread, because you're misunderstanding the threat model here. The starting point was: an attacker has control over the system so that “the end user could be MITM'd already with a root certificate maliciously installed on their device”. In that case, there's nothing “trusted” on your machine anymore and all bets are off. Doing signature verification in app instead of relying on HTTPS is security theater[1]. [1] or it could be “defense in depth” but that's an argument I'd only accept from someone who really understands what they're talking about, and only in a context where everything else being being done properly. Most of the time “defense in depth” is just an argument for the security theater.

The signature would use asymmetric encryption, so unless the attacker had access to the signing key, it would be impossible for the attacker to sign a modified version of the payload. EDIT: I see what you mean. radicaldreamer stated that a malicious root certificate is installed, but signature validation wont help there. But, it will help when downloading from mirrors or HTTP.

pixl97 2y ago

You verify against the signature that's in the current version. Now this may mean that you need to do stepped upgrades to versions that are cross signed to get new certificates. That or you have at least one https update method that gets a signing cert for the application.

littlestymaar 2y ago
And how do you ensure the integrity of “the signature that's in the current version”? Because live patching the signature in a program to force verification of an invalid payload is exactly how many software/game cracks work.
- pixl97 2y ago
  I mean, if you can't verify the integrity of the application you're already running then it's already game over. You're talking about downloading another executable and running it to life patch which is the exact opposite of what I'd suggest. The currently running (trusted) executable downloads and verifies the signature of the binary. Then after verification you execute it. If your trusted binary is validating invalid data then you've already messed up somewhere.
  - littlestymaar 2y ago
    Re-read the thread, because you're misunderstanding the threat model here. The starting point was: an attacker has control over the system so that “the end user could be MITM'd already with a root certificate maliciously installed on their device”. In that case, there's nothing “trusted” on your machine anymore and all bets are off. Doing signature verification in app instead of relying on HTTPS is security theater[1]. [1] or it could be “defense in depth” but that's an argument I'd only accept from someone who really understands what they're talking about, and only in a context where everything else being being done properly. Most of the time “defense in depth” is just an argument for the security theater.