Why Not Silverlight

Recently, Microsoft has been pushing its relatively new Silverlight web technology. Microsoft is posing it as a competitor to Adobe's Flash technology. I don't like either of these technologies due to their proprietary nature. Flash has been around for quite a while, and is nearly ubiquitous. It has become so prevalent that it is very annoying to browse the Internet without it. I am not going to help Microsoft create the ubiquity of another such proprietary technology.

Microsoft is trying to push out Silverlight via Windows Update. On all the computers I keep updated, I have specifically opt-ed to not install this update. There is an open source implementation of Silverlight being written, but even if it is written to spec, Microsoft's will inevitably have bugs, and their implementation will become a de facto standard, similar to how the rendering engine of Internet Explorer 6 was, for a long time, the de facto standard of how web pages should be rendered.

The same holds true for Flash; there is an open-source implementation, but it does not work nearly as well as Adobe's implementation. This continues to be a point of annoyance as Linux distributions generally don't come with proprietary code on the install disc.

Hard Drive Encryption Vulnerability

Within the past few days, a vulnerability in the implementation of hard drive encryption was publicized. The problem applies to just about all hard drive encryption schemes -- Windows and Linux alike.

The Problem

The root of the problem is the same as the problem with DRM; the computer must hold the decryption key in order to be able to make use of the encrypted resource. This has been implemented by storing the key in RAM, which, common knowledge tells us, loses its contents when power is lost. This common knowledge assumption has a caveat that is not common knowledge; this loss of memory is not instantaneous. The memory may hold its contents for minutes after it loses its power. If the RAM is chilled before having its power cut, it will hold its contents for hours.

There are several ways that this can be exploited. If someone steps away from their laptop for a moment, an attacker could cut the power, connect an external device from which to boot, and their device could copy the contents of the memory onto itself. Somewhere in this copy of the memory would be the encryption key, which can be used to read the contents of the drive.

A Possible Solution

The article I referenced says that "There seems to be no easy fix for these problems." The hardest part of that assertion to contradict is the "easy" qualifier. However, upon reading about this problem, a seemingly obvious solution came to me. Modern processors have plenty of registers as well as on-board cache. Why not reserve one or more of these registers to hold an encryption key? If using a register would be too expensive, surely it would not be too expensive to use some of the plenteous cache that modern processors possess.

Upon considering this, I realized that people may very well want to have more than one encryption key. A possible solution for this is to store a key (say, a 256-bit key) that is randomly generated each time the system is booted. It could be stored in the manner I described above. This key could then be used to encrypt any other encryption keys before they are stored in RAM, and to decrypt them anytime they are retrieved. The only thing that needs to be done is to ensure that this randomly-generated key does not ever find itself in RAM.

A Word of Caution

Before writing this, I searched through the several hundred comments on the article, and found that several other people had mentioned the processor cache, asking if it were vulnerable. This indicates to me that this solution is, to some extent, common sense. It would be necessary to have security experts examine this approach before anyone tried to implement it, so as to avoid another disaster similar to what happened with the fatal weaknesses of WEP.