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.



Print Friendly, PDF & Email

My Goal in Maintaining Multiple Older Computers

In this posting, among others, I wrote that I am doing private work to keep an old Acer Aspire 5020 laptop running, which has a single-core CPU that runs at 1.8GHz, and which only has 1GB of RAM. And so a good question which some people might ask would be, ‘What is the point?’

One reason I do that, is the fact that I feel a need to have multiple computers on my LAN, that are Linux machines. Most of my up-to-date machines do run Windows, but there are certain things I need Linux to do, and for which only a Linux computer can network properly, with the other Linux computers. And so to keep an old laptop from 2005 alive, seems to make some sense to me.

Besides which, a laptop from 2005 can do things under Linux, that a Windows machine from 2016 can do, as long as the Linux version on the old laptop is decently up-to-date.



Print Friendly, PDF & Email

I have just opened up one of my laptops.

One of the laptops I own is dual-boot, and is named ‘Venus’ when running in Linux mode. This is a very old laptop, dating back to the year 2005, an Acer Aspire 5020.

In recent months it has been overheating. I have struggled with this problem for some time. But just last night I decided really to do something about it. I opened it up and cleaned its cooling system with a toothbrush.

This was the first time I ever opened up a laptop. I did it with the help of a suggested video. And I am amazed, that after I put everything together again, it still works! Not only that, but it does not overheat anymore.

(Details : )

Before working on this project, I studied This Video.

In my experience, the job of undoing and then refastening many screws is not that difficult to accomplish. But, there were two points to this procedure which I found to be real obstacles:

  1.  At some point in time, one needs to remove a plastic Bezel in the back of the surface of the tablet, which is seen during normal use.
  2.  After that, and after removing the keyboard (easy), one finds a plastic panel which holds the touch-pad, and which needs to be removed.

What I found difficult in both cases, was the fact that these are thin plastic parts held in place by small molded hooks all around the edges, and with no formal fastening mechanism. One needs to use the elasticity of the plastic, to get these hooks to unhinge one at a time, progressively loosening the part.

It is plainly clear, that ever exerting too much force on either plastic plate, will cause it to break. So in both cases I needed to be very patient, and resolve never to exert force exceeding some threshold, even though each part had not yet started to budge.

One hint with how to make part (1) above slightly easier, is to swivel the display back 180 degrees, because the back bezel is also a unit with shrouds over the display hinges. Thus, the hinge-shrouds need to be able to move straight up, and by exerting gentle upward force on the shroud with one hand, and on some edge of the bezel with the other, it is easier to get it started.

What makes part (2) above harder than it seems in the video, is the fact that the audio jacks at the bottom of the laptop during use, are part of what hold it in place, and also count as hinges, which need to be unhooked in a logical way, before any progress can be made with the touch-pad plate.

Also, when disconnecting the display, it is important to note that it has two connections. One is a multi-pin, small-signal connector, that sends video data to the LCD pixels. The other is a high-voltage, very-low-current cable, which connects to a special component underneath the touch-pad plate, and on the side of the motherboard facing away. The gentleman in the video mistakenly referred to this component as “the WiFi block“, perhaps assuming that this laptop used its display panel as a kind of antenna?

The old LCD displays used an electroluminescent back-panel, that needed to be driven by a voltage near 1-2 kV. Since we have taken the battery and the power cable out, there is no danger of electrocution. But as it goes with high-voltage, low-current supplies, it is crucial not to compromise the very thin insulation on this cable as we go.

And, the two leads of this cable need to be reconnected later, via clasps that can also be a bit tricky to secure first, and then maybe secure slightly more, with needle-nose pliers.


When I reassembled my laptop, I found I had made two major mistakes:

  1. I had forgotten to reconnect the ribbon from the touch-pad to the motherboard.
  2. I had failed to reconnect a small power-lead to the motherboard properly, which led to an error message about the wired Ethernet port not working. I had tried to make a connection, but the connector was crooked, so that no electrical continuity was formed.

And so I needed to do this whole exercise 1 + 1/2 times. Luckily for me, the way the touch-pad ribbon connects to the motherboard is such, that one does not need to take the second plastic plate out, just to complete this connection – at least on my version of the laptop. I only needed to undo and redo the back bezel.

Malfunctions resulting from (1) and (2) above are now resolved.

Also, the way the keyboard ribbon connects to the motherboard is a bit tricky to figure out. The manufacturers made it a bit too short to reinsert into its connector easily. The trick to doing that was, to flip the keyboard over completely, so that its ribbon does a backwards loop. That allows us to hold the connecting ribbon short, and to reinsert it into its connector.

The connector for the keyboard ribbon has a saving grace, in that it has a small plastic part that slides out partway when the ribbon is pulled out. This needs to be pulled out, before the ribbon can be reinserted, with the conductive surfaces facing downward. And then, the plastic part can be pushed all the way back in – when successful – and thus hold the ribbon in place as we carefully reorient the keyboard to normal. And one hopes not to yank this ribbon back out.

When I was done I had broken two of the plastic hinges on the back bezel, but astoundingly, that bezel seems to have adequate stability minus those two tabs.

And, I had failed to reinsert two of the ~20 screws at first.

There are dark screws that come short, medium, and long. It is important to remember where the long ones came from: The topmost two corners of the back. And there are 6 shiny screws I can recall, which are all interchangeable.

One shiny screw and one dark screw of medium length fell out of my grasp, and could not be found quickly. I have found both missing screws by now. But by now, the keyboard is being secured with one shiny screw instead of two. Again, it seems to have adequate stability.

And the missing dark screw is about to get put back into the last screw-hole of the back.

If I was to undertake to install the missing shiny screw as well, I would have to take the back bezel off again, to expose the keyboard. I am not ready to do that, and because the KB is also sandwiched into place, I do not think it absolutely needs both screws to hold it as well.


Also, here is a note on taking out the optical drive: That optical drive has a plastic edge-plate. If one has gotten over-confident with it, one can mistakenly pull the edge-plate off the optical drive, instead of pulling the drive out of the laptop. If that happens, two very small parts come loose, and if we value putting the laptop together again correctly, it is important not to lose those parts. Assuming this accident did happen to us.

One is a small dark plastic, almost rectangular piece, which forms the Eject Button. The other is an even smaller transparent piece, which is the Drive LED window. The mere fact that those two pieces were on the loose, did not mean in my case that anything was permanently damaged. They were fit in place loose during the assembly of the laptop by a machine.

The trick to putting those back, is to insert the transparent part into the dark part, and then to place the dark part back onto the electrical contacts, so that the transparent window is indeed in front of the LED, Before attaching the edge-plate back over both, thus sandwiching them.

The contacts for this switch and its LED are recessed inside the side of the optical drive. It can all be reassembled manually, into exactly the state which the manufacturers left it in.

Luckily, this laptop has an optical drive without a tray that extends. When I push the Eject Button again, after my work, sound comes from the inside, as it would if the drive was to eject a disk by itself. And the LED blinks through my reattached LED Window. And the faceplate stays put as it should.


The two critical components which were overheating before – according to the ‘gkrellm’ Linux widget – are now running 20⁰C cooler than they were before, under heavy use. And everything works.



Print Friendly, PDF & Email

Chrome For Linux Upgrade Glitch Fixed By Google

One of the facts which I had observed about the Google Chrome browser version, which is meant for Linux, was that Google no longer provides a 32-bit version of its binaries. In keeping with this, Google has also removed the section in its code repository, which would make a 32-bit version available. Hence, I can only be subscribing to the 64-bit upgrades. Yet, my Linux computer ‘Phoenix’ has its package manager set up, to query a repository for both the 64-bit and the 32-bit versions of any package by default, and then to download and install the packages which are relevant.

In this earlier posting, I observed how this can lead to an error message when running ‘apt-get update‘. What I had done, was to make minor configuration changes like so, which I had needed to re-apply, after every upgrade to Chrome.

Well Google has caught up with the scenario which I was describing. As of their latest upgrade, their own ‘cron.daily‘ symlink will properly put the following source into ‘/etc/apt/sources.list.d/google-chrome.list‘ :

deb [arch=amd64] stable main

You may note, that the script from Google now includes the ‘[arch=amd64]‘ parameter, which means that I won’t have to make any manual adjustments to this configuration detail of my machine, every time the Chrome browser receives an upgrade.

Thank you, Google!



Print Friendly, PDF & Email