Re: [GIT PULL] Load keys from signed PE binaries

James Courtier-Dutton
2013-02-27T11:49:36Z

On 27 February 2013 11:27, Alexander Holler <holler@ahsoftware.de> wrote:
> Am 27.02.2013 11:17, schrieb James Courtier-Dutton:
>
>
>> 3) Trust based on date. I trust everything from X that I put on my
>> system 2 weeks ago, but one week ago X got hacked, so don't trust
>> anything new from them until the hack has been stopped and the
>> revokation/correction steps have been completed.
>> E.g. the Bit9 case, where malware was able to be signed.
>
>
> Which date? In reality dates are (mostly) defined as fixed points, but
> computers just don't have such.
>
> E.g. currently you can't use modsign based on X.509 certificates if the date
> comes through USB, because modsign tries to load the certificate before
> before the USB stack comes up, which ends up with invalid dates (Not
> Before).
> And changing the system date isn't that hard for an attacker if he is
> already able to do other bad things.
>

Maybe date was not a good example.
I think a single chain of trust is risky.
Using multiple signatures on the same binary is better.
e.g. Redhat have signed it, but only load the module if both redhat
and Bit9 have signed it.
In this case, the risk it mitigated, as both Redhat and Bit9 have to
be hacked for the malware to get through.
Now, if a local administrator created a new signing key each time they
installed updates, and the system checked that both the redhat
signature and the local administrator signature were valid before
loading the module, this would give a form of signing based on date.
(the install date)
The local administrator could then quickly revoke the keys for a
particular day, and not have to wait for Redhat to revoke their keys.