## Microsoft has Not actually Excluded Linux from UEFI.

This posting was the result of an error on my part, which led to more errors, in more postings.

My problem was, that even though the Linux version in question can be installed in UEFI mode, doing so without the Secure Boot option, disables all cryptographic checks on the booted image. Doing so simply installs the Linux version to use the UEFI BIOS system rather than Legacy, but without providing any EFI signatures for the image.

I apologize for the error.

Dirk

## Some Notes on the Merits of Hybrid Encryption

In my most recent postings, I sort of took the perspective, that ‘RSA’ is the only form of public key cryptography. But in reality, this is far from true.

As far as the actual public-key methods go, there is also ‘El-Gamal’ and ‘Diffie-Hellman’ in public use, as well as ‘DSA’. The last of those is only useful for signing, not for encrypting. But what that means in practice, requires that people understand another concept in public-key cryptography, which is called ‘hybrid encryption’, which marries one of the public key exchanges with strong, symmetrical encryption. Symmetrical encryption is any scheme where the same key can be used to decrypt, which was used to encrypt. Symmetrical methods in use include ‘AES’ and ‘Blowfish’, and several others.

A concept which exists purely with RSA, is that a sender of a message can use the public key of the recipient to encrypt, so that only the recipient will be able to decrypt, using his own private key.

Well, if we consider SSL-secured Web-sites, we do not see that our Web-browser needs to build any public and private key-pairs. And so according to that, it might be imaginable that the server has a public key to receive data with securely, but it is not obvious how the browser receives data securely from the server. And what actually happens with SSL, is that a pseudo-random key is built essentially by the client, and is then sent to the server securely via RSA. That key is then used by both peers, to send and receive the actual user data via strong, symmetrical encryption. And this idea, of only using public key-exchange to encrypt a strong, symmetrical key once per session, is referred to as hybrid encryption.

This also makes sense from the standpoint, that a single public-key, RSA encryption requires much more CPU time, than the repeated use of AES aor Blowfish.

TLS key exchange is based on methods, that more closely resemble Diffie-Hellman than RSA, but again forms a basis of hybrid encryption.

And this is also why SSH, which is also known as ‘Secure Shell Protocol’, only requires that the client have a DSA key. Given that an SSH client uses his public key to authenticate himself, in theory an SSH server can be set to allow RSA authentication, but then all the client must do is to encrypt a piece of data which he cannot control, using his private key, to prove to the server that he is in fact the owner of a stated public key.

Hence, for SSH authentication, DSA works just as well for the client to use.

Dirk

## Kanotix makes it easy, to install a Linux version on a UEFI motherboard.

The Linux versions I have stayed with in my past, are Kanotix versions. This does not change the fact that they are Debian-based; it only means that the Kanotix Team has simplified the packaging of a specific Debian system, so that it is ready to go.

Kanotix Dragonfire -> Debian / Wheezy (obsolete),

Kanotix Spitfire -> Debian / Jessie (actual).

I have never had to do this. But if we wanted to install Linux on a UEFI-BIOS Motherboard, Kanotix makes it easy. They have a fabled installer called their ‘Acritox Installer’, which allows the user to specify an arbitrary part of the file system, which should be mounted from non-root disk partitions. Typically, this was done with the ‘/home‘ mount-point, using a Linux-oriented file system, such as ‘ext4‘. But for UEFI, we need to tell Acritox, to make  custom, FAT32 mount-point at ‘/boot/efi‘ , which therefore has its own partition.

The fact that this needs to be done, implies that this partition, which will either need to be a ‘Primary MBR’ or ‘Any GPT’ partition, will be readable by the BIOS, even before the O/S boots. This is the logical place where the O/S will store the signatures, of all the Images which are supposed to be bootable. Hence, there has been no special change to the format, in which the actual ‘initramfs‘ images are stored, but rather, every time we do an ‘update-initramfs‘, doing so will also add an entry to this FAT32 partition, for the newly-added image.

(Edit 04/05/2016 : ) According to the fact that I have discovered a major error in my thinking, it is also a fact, that this partition does not really store EFI signatures…

Dirk

## Some Hypothetical Thinking, on Public Key Cryptography and UEFI

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:

1. The encrypted hash of the original code,
2. The vendor public key,
3. 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:

1. The encrypted hash of the code + The vendor public key,
2. 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.

Dirk