chenxiaolong / Custota

Android A/B OTA updater app for custom OTA servers
GNU General Public License v3.0
56 stars 12 forks source link

Binary Transparency #76

Open 0cwa opened 3 weeks ago

0cwa commented 3 weeks ago

Rather than relying on a single server, would it be possible to check other servers to verify that the resulting builds are identical to one on your configured server? Basically to create a web of verification and reduce attack surface.

chenxiaolong commented 3 weeks ago

Can you describe what threat model you're trying to protect against with this?

It's unlikely I'll implement this (only some of the downloads are handled by Custota--the rest are handled by Android's update_engine), but I'm curious.


Currently, Custota always validates OTA signatures, which prevents a modified OTA from ever being installed. It also prevents downgrades to older OTAs, even if they're properly signed.

However, the JSON file that points to the latest OTA isn't signed. If a server is compromised, it can't make Custota install a malicious OTA, but it could prevent Custota from seeing that a new update is available. I plan to eventually add (optional) support for signing the JSON file and embedding an expiration timestamp inside. Then, if Custota downloads an expired JSON file, it could warn the user about a potential issue with the server. This would require the JSON file to be periodically regenerated, but would protect against a server holding back updates. This approach is the same as what certain Linux distributions, like Fedora, do to protect against the same risk with their package repos.

0cwa commented 3 weeks ago

The threat model is that even if a server was fully compromised that it wouldn't install an update as it would show the number of servers building the same image from your list that agree and disagree with your build. It's a double check on a server, so even if the sysadmin was lazy and a critical exploit became well known the server would be flagged.

If a server is compromised, it can't make Custota install a malicious OTA How so? If it has access to the keys couldn't it sign the OTA itself?

See: https://bintra.directory/

chenxiaolong commented 3 weeks ago

How so? If it has access to the keys couldn't it sign the OTA itself?

Yes, it could. Custota doesn't try to address the scenario of private key compromise at all. I guess an unstated assumption is that the server hosting the downloads is not also the system creating the OTAs.