Re: shim-signed (was: Firmware - what are we going to do about it?)
On Tue, 2022-04-26 at 16:04 +0200, Marc Haber wrote:
> On Sat, 23 Apr 2022 13:54:59 +0200, Ansgar <ansgar@43-1.org> wrote:
> > Why?
>
> If only I knew. I myself don't feel to comfortable to rely on
> Microsoft being able to pull the plug on us any time. I don't know
> whether they can, but I imagine some kind of revocation mechanism
> being in place.
As with all certificate systems, the revocation system is fairly broken
;-)
> > Because it contains a third-party signature for which the private
> > key is not included in Debian? The same is true for signatures in
> > debian-archive-keyring, debian-keyring, ca-certificates, wireless-
> > regdb, and many other packages.
>
> A running system doesn't rely on any of those.
It will also work if Secure Boot is disabled (which should be possible
on at least all x86 systems). If you want Secure Boot w/ Microsoft's
key[1], then you obviously have to rely on Microsoft's key.
[1]: As far as I understand, one reason it's Microsoft's key is that
nobody else wanted to run a CA for this.
> > Debian's buildds build shim (binary package: shim-unsigned); the
> > binary generated by Debian is then signed by Microsoft's key.
>
> And we have a mechanism to check whether the code is actually the
> same?
You can do that even manually:
+---
| $ diff -u <(hexdump -C ../s/usr/lib/shim/shimx64.efi) <(hexdump -C shimx64.efi.signed) | head -n 26
| --- /proc/self/fd/11 2022-04-26 16:35:32.983515245 +0200
| +++ /proc/self/fd/17 2022-04-26 16:35:32.983515245 +0200
| @@ -11,12 +11,12 @@
| 000000a0 00 72 06 00 00 00 00 00 00 20 02 00 00 20 02 00 |.r....... ... ..|
| 000000b0 00 00 00 00 00 00 00 00 00 10 00 00 00 02 00 00 |................|
| 000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
| -000000d0 00 00 0d 00 00 04 00 00 9b 82 0e 00 0a 00 00 00 |................|
| +000000d0 00 00 0d 00 00 04 00 00 bb af 0e 00 0a 00 00 00 |................|
| 000000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
| *
| 00000100 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 |................|
| 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
| -*
| +00000120 00 00 00 00 00 00 00 00 e8 1f 0e 00 78 21 00 00 |............x!..|
| 00000130 00 f0 07 00 0a 00 00 00 00 00 00 00 00 00 00 00 |................|
| 00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
| *
| @@ -57279,5 +57279,540 @@
| 000e1fb0 44 00 6c 6f 61 64 5f 6f 70 74 69 6f 6e 73 00 50 |D.load_options.P|
| 000e1fc0 4b 45 59 5f 55 53 41 47 45 5f 50 45 52 49 4f 44 |KEY_USAGE_PERIOD|
| 000e1fd0 5f 69 74 00 58 35 30 39 5f 4e 41 4d 45 5f 45 4e |_it.X509_NAME_EN|
| -000e1fe0 54 52 59 5f 69 74 00 |TRY_it.|
| -000e1fe7
| +000e1fe0 54 52 59 5f 69 74 00 00 78 21 00 00 00 02 02 00 |TRY_it..x!......|
| +000e1ff0 30 82 21 6b 06 09 2a 86 48 86 f7 0d 01 07 02 a0 |0.!k..*.H.......|
| +000e2000 82 21 5c 30 82 21 58 02 01 01 31 0f 30 0d 06 09 |.!\0.!X...1.0...|
+---
If I remember correctly:
- the first change (~0xd0) should be a checksum of either the file or
just the header
- the second change (~0x120) is the offset of the signature table in
the database (0xe1fe8) and its size.
- the third change (~0xe1fe0) is appending the signature
You can also extract the signature, attach the signature to the
unsigned file and verify you get the same binary (src:shim-signed does
this[2]).
[2]: https://salsa.debian.org/efi-team/shim-signed/-/blob/52f43dc447fdc4fbb948a5883c0a04077aeb7dd4/Makefile#L9
One could also teach diff tools to strip/ignore signatures. This would
be useful if we decide to sign ELF executables, files lists or binary
package themselves: without excluding the signature, no package would
be reproducible any longer...
Ansgar
Reply to: