jump to navigation

Paper: Security and Privacy for Implantable Medical Devices December 15, 2007

Posted by bransfor in : CS691i , add a comment

Backdating is dishonest in checkwriting and it’s dishonest in blogging, so I make no pretense of having posted this in a timely fashion.

On December 5, Tom presented to our security seminar preprint of a paper called “Security and Privacy for Implantable Medical Devices.” To summarize it briefly, the computers have figured out how to get inside of us.

The paper, by Dan Halperin of UW, Tom and Kevin Fu of UMass, Yoshi Kohno of UW and pacemaker expert William H. Maisel of Harvard and Beth Israel Deaconess Medical Center and is due to appear in IEEE Pervasive Computing, draws attention to a few interdisciplinary problems that have not received much ink or, it seems to me, much thought to date. This exploration of a previously under-examined topic is, to paraphrase the authors, the paper’s primary contribution.

IMDs — such as pacemakers and implantable cardioverter defibrillators (ICDs) — help people from inside, generally via wires poking into active organs. Pacemakers and ICDs use electricity to stimulate cardiac muscle. Even the earliest pacemakers, invented around 1953 and battery-powered from 1959 onward, included electronic circuitry for timing and so forth, so it is not surprising that modern incarnations (yuk yuk) have substantial computational capabilities. For the past twenty or so years, these devices have also been able to communicate with external devices via radio. Some of them can transmit strongly enough to relay information to an Internet gateway 30 feet away in the home.

These devices are sophisticated and inexorably getting more so. But are they secure? What does that mean? To answer the latter question, the paper constructs a security model for IMDs. This is tricky because of the tradeoffs (or “tensions”) that inhere. First, special considerations must be made for devices on which people’s lives depend. For example: the information on these devices must be accessible in emergencies; physicians should be able to interrogate them for the data they contain. But how does a physician prove physicianhood? How does a pacemaker know, in this age of medical paranoia, how much to divulge? The paper talks about various kinds of adversaries and gives a menu of design considerations that have implications on security and privacy. It describes tradeoffs like the previous example. Finally, to answer the question of where we go from here, it suggests some ways to improve perceived weak spots in the threat model, focusing on secondary information channels, authentication, and encryption.

The paper is strong in a few ways: first, it shows care on the part of the authors. It also introduces the subject well; the motivation is well covered and the discussion of possible future work offers many ripe fruits. It is not especially weak in any direction, but scratching around for a weakness to mention, I note that it is a bit unsatisfying to the reader who seeks specific technical information about these devices. However, given the secrecy that surrounds their design and the difficulty of obtaining a device for study, this shortcoming is understandable.

This is the first CS paper I’ve read that includes the term “anorgasmia.”

Paper: “Fast True Random Generator in FPGAs” November 29, 2007

Posted by bransfor in : CS691i , add a comment

Salma presented a paper called “Fast True Random Generator in FPGAs”. The point of the paper is that true randomness can be harvested from metastability of “D” flip-flops (DFFs) in groups. I learned a few things from the paper and the discussion that followed Salma’s presentation: first, some basic circuit concepts such as what flip-flops do, what glitches are, and what von Neumann correction does. Second, I learned about “correction” circuits that can do things like map n random bits onto m<n random bits. Third, I — along with at least a few of my classmates — learned about glitch attacks, attacks exploiting metastability’s tendency to vanish in favor of stability.

Why do DFFs exhibit metastable behavior? The paper says it’s because of thermal (and “environmental”) noise. At any rate, metastability gives way to stability after some amount of time, usually about 2 ns. One of the attacks we discussed in class involves introducing a glitch to slow signal propagation and therefore leave time for metastability to resolve itself.

I’m not competent to evaluate the validity of the paper’s EE claims. I am concerned that the paper pays little attention to attacks — fortunately we have the Burleson group for that — and doesn’t spend enough time introducing the topic (an invalid criticism if the intended audience is EE folks). I would like to see the paper say more about the numbers it discusses — e.g., the number of latches in the “second version” subsection of the “implementation” section. What happens if you use a value other than 100? One order of magnitude less? One order of magnitude more? Something else? The paper should also use more space for a discussion of randomness testing; what’s there now is vague and therefore weak.

Positives: the organization of the paper is nice, modulo the niggling changes above. The result is nice: emisson of one random bit per clock cycle up to the clock speed and the limitation imposed by the length of the metastability period.

I’m afraid my understanding of the paper is somewhat hampered by my ignorance about FPGAs. I’ve emailed a friend who might be able to recommend some reading, but until I’ve chased down some more information, don’t expect anything cogent from me on the topic.

Finally, Salma’s thesis topic is related to an implementation of the stuff in this paper.

Paper: “A Digital Design Flow for Secure Integrated Circuits” October 31, 2007

Posted by bransfor in : Uncategorized , add a comment

Even an EE dunce like me can understand this one! Tiri and Verbauwhede, Belgian computer engineers, describe a generic method that once and for all solves the problem of security-related ICs being vulnerable to power analysis attacks. The problem, in a nutshell, is that 1 and 0 draw different amounts of current, and if you play your cards right, you can figure out key material by observing the current draw. Clearly we can try to define bit state differently to get around the simple problem; the authors mention a current mode logic approach that works fine except that it’s super-inefficient and never conserves power. The authors proceed to introduce a new circuit layout technique and a new “design flow” that spits out attack-resistant ICs.

Strengths:
– Goal is good: specific algorithms needn’t be optimized because the IC designer has already done the work of SCA resistance.
– Fairly accessible to non-EEs, although the business about VLSI is hard to understand without experience. (Many people have a distaste for such things.)
– Appears reproducible (with the tools the authors have built).
– Great (if a bit dense) diagrams.

Weaknesses:
– Not much discussion of timing and EM radiation SCAs.

Questions:
– Are quantum computers vulnerable to the same types of attack?

Holcomb, Burleson, Fu: “Initial SRAM State as an Identifying Fingerprint and Source of True Random Numbers” September 11, 2007

Posted by bransfor in : CS691i , add a comment

Note: this paper was Slashdotted—that is, was subjected to various kinds of scrutiny by hordes of Internet users all at once—on September 10. I claim that I postponed reading the Slashdot thread until after writing these comments.

FERNS—Fingerprint Extraction and Random Numbers in SRAM—refers to a novel approach to two problems: uniquely identifying an electronic thing, and (not necessarily relatedly) generating random numbers. Previous work, of which there is plenty of discussion in the paper, has focused on the same problems, but with certain unpalatable limitations. The chief contribution of this work seems to be that it provides the desired functions in an elegant manner, without using special circuitry: it extracts “fingerprint” information and randomness directly from initial contents of cheap, ubiquitous SRAM.

Strengths:

Weaknesses: