3 ms·

I keep wondering if package managers (be it Google Play, apt or dnf) are in need of a solution like Certificate Transparency. Like Certificate Transparency, it

by pfg 11y ago

I keep wondering if package managers (be it Google Play, apt or dnf) are in need of a solution like Certificate Transparency. Like Certificate Transparency, it would not necessarily prevent a backdoor(/certificate) from being pushed to selected users, but it would guarantee detectability, at least after the fact. If the package as a whole is included in the log, it would also allow BinDiff-style reverse engineering of any backdoor. Application developers could scan the log for unauthorized builds of their software (i.e. key compromises), and I imagine there are some things you can do with gossip protocols for end-users as well (i.e.: how popular is this build? Am I the only one running it?). This would solve part of the trust issue both for proprietary and open source software (I mean, who's actually using or verifying reproducible builds?). It would also be a huge problem for intelligence agencies or other adversaries who want to do this undetected.

zmanian 11y ago
Yes binary transparency for package managers is extremely needed esp because we've been widely publicizing this vulnerability a lot now with no real fix.
mike_hearn 11y ago
It would be interesting but I suspect ultimately futile. Certificate transparency works because detected problems are actionable: the bad certificates can be revoked and, if necessary, so can the entire CA that was compromised. There is no way to revoke an app store, as there's only two of them that matter. So if the transparency system revealed subversion .... then what? There'd be a big uproar for a few days, but nobody would know who the target was, or what the bad app was doing, and there'd be no action that could be taken.
- pfg 11y ago
  I think the actual implications wouldn't be too different in production. Those are the main scenarios where Binary Transparency might be of use: 1. An application developer's private key gets compromised (either through a breach or an inside job). Binary Transparency would allow the developer to monitor the log server for any unauthorized binaries and, once detected, investigate the source of the attack, rotate keys and possibly blacklist the affected binary (not sure if a mechanism like that exists at the moment, but it would make sense with Binary Transparency). 2. The application developer is coerced into signing a binary including a backdoor. Binary Transparency would guarantee that there's a public record of a modified binary being released. This alone would probably make any adversary think twice about doing this, especially if they want to stay unnoticed. In addition to that, gossip protocols and dedicated auditors could allow users to detect odd releases even if the developers were gagged. This might very well result in the app being effectively revoked because users stop trusting it. Both scenarios would at the very least allow the backdoor to be reverse-engineered. Ultimately, I'm afraid you're probably right and the limitations and complexity of this approach probably won't make it viable for a long time. Maybe the thinking will change if we see some high-profile cases where apps are backdoored - that's what got the ball rolling for Certificate Transparency, after all.

by pfg 11y ago

zmanian 11y ago

Yes binary transparency for package managers is extremely needed esp because we've been widely publicizing this vulnerability a lot now with no real fix.

mike_hearn 11y ago

It would be interesting but I suspect ultimately futile. Certificate transparency works because detected problems are actionable: the bad certificates can be revoked and, if necessary, so can the entire CA that was compromised. There is no way to revoke an app store, as there's only two of them that matter. So if the transparency system revealed subversion .... then what? There'd be a big uproar for a few days, but nobody would know who the target was, or what the bad app was doing, and there'd be no action that could be taken.

pfg 11y ago
I think the actual implications wouldn't be too different in production. Those are the main scenarios where Binary Transparency might be of use: 1. An application developer's private key gets compromised (either through a breach or an inside job). Binary Transparency would allow the developer to monitor the log server for any unauthorized binaries and, once detected, investigate the source of the attack, rotate keys and possibly blacklist the affected binary (not sure if a mechanism like that exists at the moment, but it would make sense with Binary Transparency). 2. The application developer is coerced into signing a binary including a backdoor. Binary Transparency would guarantee that there's a public record of a modified binary being released. This alone would probably make any adversary think twice about doing this, especially if they want to stay unnoticed. In addition to that, gossip protocols and dedicated auditors could allow users to detect odd releases even if the developers were gagged. This might very well result in the app being effectively revoked because users stop trusting it. Both scenarios would at the very least allow the backdoor to be reverse-engineered. Ultimately, I'm afraid you're probably right and the limitations and complexity of this approach probably won't make it viable for a long time. Maybe the thinking will change if we see some high-profile cases where apps are backdoored - that's what got the ball rolling for Certificate Transparency, after all.