Open vbwagner opened 6 years ago
here I've described (in Russian as SF text) configuration of the tree of trust for newly bought notebook in the world where digital signing of open source binaries is ubiquitous.
@vbwagner
Yes, I'm currently researching options for storing root certificate, so that it can not be remotely changed in a system with enforced trust. For now the easiest option is to embed root cert into kernel image (this way platform owner can rebuild a kernel with his own set of keys). It seems that this is the only option for platforms without secure storage (tracked as #3).
tracked as #4
Of course signing proxy or rebuild-from-source is a viable solution. I'm concerned about being able to:
Yes, I'm concerned about packages with security bugs in them. However if user can somehow install vulnerable package instead of fixed one, he already has root access (this or that way). DigSig supported revoking individual signatures, so I thought that this feature is at least worth mentioning.
PKI is very important issue.
Unsigned packages from distrbution is not a problem.
So, for organization, which maintains dozens of servers with same distribution, it is possbile one way or another, to buiid its own repository where all packages are identical with upstream, except all binaries are signed.
I'm not convinced that we need separately revocable certifficate for each package.
It is clear why we might need to distrust software publisher we've trusted before - say private key was stolen. But I don't think that it is good idea to place burden to the signature system and PKI to block execution of individial, correctly signed binaries.
Only attack I can imagine which can be countered by this mechanism is
CRL format as specified by RFC5280 stores only seraial numbers of revoked certificates, so each certificate authorty can revoke only certificates it issued. So, if we are able to revoke only certificates of software publishers, which we cross-sing with our root CA, we need to maintain (in the kernel space, UEFI variables etc) only one relatively short CRL. If we consider each software publisher as CA which issues new certificate for each binary package it publishes, we have to maintain dozens of CRL, and these CRLs might have thousands of entries (for instance, if distribution have 30000 packages and 3% of them get security updates during distribution lifetime).