One concept which exists in public key cryptography, is that a piece of text can be signed, which means that its hash-code can be found, and then encrypted by the private key of a signer, such that both the encrypted hash-code – the signature – and the public key of the signer, can be attached to the piece of text as two fields. The public key can then be used by a verifier to decrypt the signature, and the hash-code of the text can be recomputed, so that the two resulting pieces of code can be compared. If they are equal, the signature is valid.
But in many cases, this is not itself meaningful enough, simply because any signer could use any key-pair, and the signature would always be verified as valid. Hence, another aspect to public key cryptography is, that the public key of the signer can itself be signed by a Certificate Authority, and this signature can be supplied as a third field by the signer, transforming his public key into a certificate.
Further, in the case of open communications such as email, instead of including the actual public key, a key fingerprint is included, and the task is left up to the recipient, to fetch the public key used by the sender, from a public key server, via the supplied key fingerprint. This is simply done to keep messages shorter.
Once the recipient has the required public key (belonging to the other person) in his keyring, his email client can fetch it from there locally as needed.
The world of Windows software is different in many ways from the world of Linux software. If I was simply to compile some program I had written and email that to my Aunt in Germany, asking her to run the executable, she would get an error message, because my Windows EXE File was not signed with a code signature. I could buy a code-signing certificate from any one of a number of Certificate Authorities. But to do so would also be quite expensive for me. But then the overall scheme would be as I just described.
I have pondered the case of UEFI, where every BIOS needs to be signed, and where the O/S kernel image also needs to be signed before the BIOS will execute it. This type of signature might be different in some ways from the purely software-based one.
The assumption is that the motherboard cannot go online, to check the vendor public keys against a Certificate Revocation List.
If the public key of the hardware vendor needs to be signed as well, this could conceivably imply, that there exists one master key-pair, and that the public key of this master key-pair would be stored with every BIOS. The BIOS would need to be able to rely on this one master key to validate all signatures.
And then, if such a master key-pair was ever compromised, this would mean that all the hardware signatures are also compromised.
Instead, the picture I have of this in my head differs slightly. I might be inclined to think of such a signature as having three fields:
- The encrypted hash of the original code,
- The vendor public key,
- The encrypted hash of the vendor public key, using an assumed master private key.
What the established terminology does, is to pair each encrypted hash with the associated public key, and to refer to this as one structure. Hence, officially, a UEFI signature may only exist as two parts:
- The encrypted hash of the code + The vendor public key,
- The encrypted hash of the vendor public key + One out of several master public keys.
It seems entirely possible to me, that the BIOS actually stores a list of hash-codes, of available master public keys.
What I do know is that the public keys can be revoked. And I think that one common reason for which they are sometimes revoked, is the impression that can be had by the Authority, that the security practices of the vendor are not strict enough. I.e., if a certain BIOS maker was to create a BIOS, which is so permissive, that it simply allows a user to bypass the validation of any signature, especially that of the O/S kernel, this would form grounds to revoke his keys.
Admittedly, I do not know of UEFI-capable BIOS versions, which are that lax.