Secure boot signing infrastructure - feedback request

[Ben Hutchings]

On Wed, 2017-10-11 at 21:48 -0300, Helen Koike wrote:
[...]
> I did a summary about the current discussion here:
> https://wiki.debian.org/SecureBoot#Wrap-up_of_the_discussions_so_far
> Feel free to edit this wiki or let me know if I forgot something.
> 
> Questions:
> * About item 2.1. (reproducible builds), if we strip the signatures from
> the binaries before doing the comparison is the reproducible build
> criteria acceptable? Can we just strip the signatures and if the result
> is the same we consider it reproducible? Or is changing the criteria ok?

The Reproducible Builds project has consistently set the standard that
results must be bit-for-bit identical.  I don't think we should expect
it to add an exception that requires parsing archives and executables
to verify that they're "mostly reproducible".

> * About item 2.2. Would it be ok if we just have a easy revoke mechanism?
> In Shim there is already a MokListX (a blacklist of keys or binary
> hashes), but the current way to update this list is if the user has
> physical access to the machine, but I was talking with the Shim upstream
> maintainer and we agreed that we could implement a solution where we
> could feed a blacklist to shim, and if this list is signed by the
> vendor_cert (aka Debian's key in our case), and if it is a newer version
> of the list, shim would update MokListX without requiring user
> intervention (it would be an equivalent to KEK for UEFI)
> Is this solution acceptable? If we have an easy way to revoke, then we
> can easily undo an attacker's work. We can sign everything automatically
> (if the package is in a whitelist) without the need for the ftp masters
> to review each upload manually.

I think we will need some sort of reliable mechanism to revoke
signatures, however we implement signing.

> * Item 2.4 seems the strongest argument to me against the buildd
> approach, but the byhand approach seems to complicated, or we need to
> reformulate it, any suggestions?

I think that it should be possible to mitigate these problems by
combining the proposed signing service with the earlier plan of doing
two source uploads:

Firstly, the signing service would not provide the signatures in plain
text but would encrypt them using a developer's GPG key (or multiple
keys).  Key selection might be done by specifying the key fingerprint
in the source package (which could be problematic for binNMUs), or in
the signing service configuration (which would effectively prevent
source NMUs).  This makes the signing service useless to an attacker
who only compromises a buildd briefly.

Secondly, the detached signatures would be uploaded as an extra package
to a separate archive suite, similar to the way debug symbol packages
are now handled.  Those extra packages could easily be ignored when
attempting to reproduce the build.  But I don't know whether dak's
logic for debug symbol suites is sufficiently general to handle this.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20171122/d19fb32c/attachment-0001.sig>