24948
>> Nishanth Chandran: Hi. We're very happy to have with us Kevin Fu, who is Associate Professor at University of Massachusetts Amherst, soon joining University of Michigan at Ann Arbor. Kevin is very well known for his work on security of medical devices, won the TR35 Researcher
Award. Today he's going to tell us about implementing security protocols on embedded devices.
>> Kevin Fu: All right. Thanks for the introduction. I think this may be perhaps my fifth talk here. I think I do this on average about once every one and a half years.
So it's good to be back again. It's always a pleasure. So this is -- and in case you hear mumbling or voices in the background Amir Rahmati is on the Skype line. He's joining us and his booming voice is over the speaker system.
He's the lead student on this project. His name is in bold here.
He'll be presenting this at USENIX Security next week. If I make any mistakes, he may pipe up. Are you still there, Amir? Okay.
Anyhow, I'm sure he'll be back. Anyhow, so what I like to present today are actually two talks, depending on how much time we have. One hour; is that correct? One hour. So I'm going to talk, first of all, about interesting things to do with SRAM. So SRAM is a kind of memory that's found on pretty much every kind of digital logic in the universe.
It's how we implement L1 caches. It's how some microcontrollers implement their RAM. And we're going to use SRAM to do some unusual things when energy is one of our constraining factors. This is joint with Amir at UMAS; Mastooreh Salajegheh an intern here last year in G.
Lu's group; Dan Holcomb, Ph.D. student at Berkeley; Jacob Sorber, a new professor now at Clemson. Wayne Burleson, a design engineer at UMAS.
Okay. So what's the motivation here? There are a lot of devices out there that don't have access to a trustworthy clock. One large class of devices that fall into this camp would be battery-less devices.
Anyone use the Orca card? Okay. Almost everyone here has an Orca card for transportation payments. As you can imagine, there's no battery in there. And because of that lack of battery, it doesn't know what time it is. So there's no notion of time. While the card is being powered up to do a payment, it knows how much time is elapsing during a transaction, but it has no idea how much time has elapsed between transactions.

This is also true for passports, employee ID badges like this one.
They know exactly how much time has elapsed when you're using it but they're completely ignorant about time because time is fleeting. But we need to keep control. All right. I'm going to try to insert as many '80s and '70s references as possible in this talk.
So what do they have in common. Again, no long-running clocks. And the adversary controls the power and time. Whoever is powering up the device gets to choose when to shut it down. And these devices hold information that you probably don't want to leak. It could be private information.
So this has led to a number of security vulnerabilities by researchers across the globe. I'll highlight a couple. It would be difficult to enumerate them all. But there was one recent paper on dismantling the
MIFARE classic. This is a contact list smart card. It was used -- I believe there are billions of them in circulation at the time.
And it's a payment card mainly for transportation. And they found that using a brute force attack they could extract all the information to effectively clone the card.
This attack has been replicated in other attacks, the London oyster card, which I hope is working successfully now in the Olympics.
And there's just more and more papers coming out. As the industry fixes the card, somebody finds a new flaw. Typically exploiting this encryption oracle, because you can query the tag basically an infinite number of times. You can extract all sorts of information, and the card is really none the wiser. It doesn't know how to rate limit because it doesn't have a sense of time.
At best it can just set a counter and say I've been queried a lot.
And, oh, don't forget San Francisco. Okay. All right. So moving on to slide 4. This all basically boils down to brute force attacks affecting these time-unaware devices. This could be side channels, power analysis, DPA, for instance, pioneered by Paul [inaudible] group, simple reverse engineering. Sometimes when you don't know what the algorithm is as implemented, if you query the tag sufficiently a number of times you can start to deduce what the algorithm is.
And then just plain old brute force, guessing keys, and the problem is there's no speed limit today. So we're going to try to stop that using our time machine we call the Tardis, and in our threat model what we consider what's call semi-invasive attacks. This is more a term I think it's more familiar with the CHES community, the cryptographic hardware and embedded systems community. What this means the adversary can interact with the card from the outside but we're not going to consider an adversary who is able, for instance, to physically drill into the tag or inject ion beams.

But we are going to worry about outside attacks like heating up the card and cooling down the card. Okay. So to give you some more quantitative information on just what's going on when people attack these systems.
Here are five example papers and just how many queries it took each of these attacks to break the security of the system. And by break, I mean have enough information to clone a card. So here arranged, simplicity to more complexity, Shamir broke the UHF password. These are supply chain RFID tags, took only 200 queries to brute force guess the password. Takes about two seconds. If you work up to some of the more interesting things, over ten years ago Ian Goldberg and I think
David Wagner had reverse engineered some things in the GSM Sim cards in phones and were able to duplicate those Sim cards using about 150,000 queries, if you do 150,000 queries, you could extract enough information to simulate a Sim card. These problems are appearing again and again.
So our contribution here is a way to restore some sense of time keeping. And we're going to do that based on SRAM decay. These are the decay of one of the most common circuit elements found in digital logic. And we're going to exploit how this digital logic behaves over time when you remove power to create clocks or clock-like devices.
So I'm not an EE. This is going to be the most EE slide of the whole talk. I think my rule is only one transistor per talk. I apologize.
There's four here. So this is an SRAM cell. Each SRAM cell consists of approximately four transistors and has two other transistors to do some of the control logic. But as far as you need to know for this talk, an SRAM cell is a cylinder. And they didn't teach you that in
VLSI design? So an SRAM cell is a cylinder contains either a binary zero or one. This is the atomic unit as far as most computer scientists are concerned.
When you remove power from this digital logic, it starts to decay and it goes away. And it enters sort of an unknown state. And then when you power back up, it's going to power back up to one of two different things. You can probably guess. Either power up uninitialized as a one or power up uninitialized as a zero. The interesting thing about
SRAM is it tends to -- most of the bits tend to be physically random in their initialization and how they initialize after being powered off.
Not all of them but the vast majority of the BIPS behave in that way.
We're going to try to exploit that to create time keeping.
So luckily our computers today have more than one SRAM cell. If you have a large collection of SRAM, say 240 bytes is what we use, you can start to do some interesting statistics. You can count, for instance, after your system boots back up and you would like to know, if you would like to know how much time has elapsed during that downtime,

because that's what the adversary is trying to exploit to trick you, you just count the number of SRAM cells and you look at their values and you see how they differ from the values that you initialized. By counting them you can begin to essentially dead recon how much time has elapsed.
To give you an example, we took a photograph of a different Tardis and we put it into our SRAM memory and we would power down the system, in this case we powered it down after 150, 190, 210 seconds, and see what the picture looked like after we powered it back up.
So these are real experiments here. Happens to be on an MSP 430 microcrontroller. And we split the picture up actually into four pieces because it didn't fit into our memory. So this is actually four pictures assembled into one. But after 150 seconds you can see there's a little bit of pixilation. The memory is starting to degrade. Again we powered it off. We powered it back on. The Tardis was still there but it's beginning to dematerialize. At 190 seconds you get some significant degradation of the image. At 210 seconds it looks to me almost statistically random.
Question?
>>: We're using bit maps or [inaudible].
>> Kevin Fu: The question is were we using bit maps or JPEGs. Amir, do you happen to recall what we were using?
>>: Hello?
>> Kevin Fu: Amir, do you happen to recall, was it a JPEG?
>>: I don't have the audio anymore.
>> Kevin Fu: But we translated it into bit map, I believe. I'll have to double-check on that.
So what you can do, though, with the image, is you can start to go backwards. If you take an image you can try to guess how much time has elapsed. For instance, if you see this pixilated image and put it next to all your different sample points, you can guess, it's sort of in between the 190 and 210. I'm going to guess that we were off or between 190 and 210 seconds, based upon that memory decay.
So that's the intuition of the mechanism we're going to use to create these trustworthy local clocks that are unpowered, no batteries necessary, it's just running off the power that's remaining after you turn the system off.
>>: Is this temperature dependent?

>> Kevin Fu: It's very temperature dependent, and I'll be getting into our temperature chamber measurements.
>>: These properties change over long periods of time, like if you repeat this experiment a year later, would you have the exact same?
>> Kevin Fu: I don't have -- so the question is would these results change over time. And I believe the industry has a term for that.
MBTI, I believe, is the term. Essentially the degradation of circuits over time and exposure to heat. In theory, there should be some degradation. We haven't seen any.
And SRAM as far as I know is more resilient than, say, flash memory.
Flash memory does wear out. SRAM doesn't have that type of wear-out property. So we haven't seen any. But there could be some.
All right. So let me go over the Tardis algorithm and how we try to dead recon and guess time on our device. We initialize SRAM. In our particular implementation, we reserve about 240 bytes of the SRAM to do this. And we happen to just initialize it all to one. You could choose all zeros if you would like, you could choose a picture of your favorite cartoon character, whatever you like to do. But we chose all ones to simplify our algorithm.
Now, when the power turns off, the SRAM cells begin to decay. So when we power back up we just compute that decay. We count the number of bits.
But as was asked, as was pointed out just a second ago, what about the effective temperature? Temperature will affect how many bits are decaying when you have time as a factor. So we need to compensate for temperature. The way we do it is rather simple. After we boot back up we compute the SRAM decay and then in order to use essentially the right curve, that is, the right interpolation results, we measure the temperature. Turns out most microcontrollers have onboard thermal sensors. It can measure its own temperature.
Remember the computers that don't have temperature sensor, almost everything out there is actually a temperature sensor, it turns out.
It can behave like one. So we measure that temperature. That way we can figure out which curve to use in estimating the time delay.
After we do that measurement, we initialize the SRAM again to a known condition so that we can prepare for the next power off.
Of course, there is a very definite temperature range. And in our case we're using a very simple algorithm. But you could use a lookup table based on different temperature measurements for profiling your chip.
If you really wanted to be fancy, you could use curve fitting.

Right now we haven't found it necessary to do any kind of fancy like closed form solutions for computing how much time has elapsed based on temperature. And hopefully you'll see why in a moment we didn't choose that pathway.
>>: So it doesn't matter to which state you initialize? So, for example, if you initialize to all ones, they give better results or worse than to all zeros?
>> Kevin Fu: I'll get into that data a little bit. But it hasn't affected the statistical properties.
>>: Okay.
>> Kevin Fu: What it does affect is what's known as leakage current.
So it essentially speeds everything up. Oh. So one of the other factors influencing the decay of SRAM. There's temperature but there's also capacitor size. It turns out, as I was explaining over lunch to
Stewart, if you think back -- anyone taken an EE 101 sort of course?
Probably most people required to if you took -- okay. You may have recalled things like Devlin and equivalent and that fun stuff.
Basically you can represent any circuit as a series of the fundamental discrete parts. One of those discrete parts being a capacitor. Turns out that all circuits have some kind of nonzero capacitance and we'll explore that. There's also variation across chips. So we'll explore that today. I wasn't planning on talking about SRAM size on its impact.
So as to the question about the thermal setup. This is how we ran the experiments. I think the pictures are pretty clear up there. Slide
13. What we have is what's called a thermal chamber and an environmental chamber. This allows us to precisely set the temperature surrounding the chip that we're doing the test on.
And we have our infrared thermometer to help us gauge the temperature which is a fairly a precise thermometer. And we're using what's called the Texas Instruments MSP 430 as our experiment chip. It's a microcrontroller, and it has on-chip SRAM. And over there we have a
DAC.
The DAC is helping us to precisely control when we turn on and off the power. So, in other words, this is our programmable power supply right here. So we can get ground truth, in other words, over how much time has actually elapsed.
So to give you a feeling of just what kinds of time can you measure using just SRAM decay, here's a rough chart. I'll show you some more detailed data points in a moment. But what you'll find is there are basically three phases of time.

I like to think of the Tardis as an hourglass. So in stage one, you've just lost power, and so all the bits are intact. If you were to power it back up quickly you would expect to see all the bits there. But there's a magical threshold for this particular case, this particular temperature and this particular capacitor. Happened to be around
150 seconds. At that point is when SRAM cells began to decay, but not instantaneously. They all decayed at different points in time.
So that's when you enter the second stage where you can get some more precision in terms of how much time has elapsed. But it's a relatively short sliver of time.
For that reason at the moment we're not exploiting that sliver. At the moment we're only exploiting the Tardis to give us one bit of time.
Has the hourglass expired or not. That's what stage three is. So at stage three, in this case around 230 seconds, that's when all of the
SRAM cells have decayed. And so we have no way to distinguish whether it's been 250 or 400, we just know it's been more than 230 seconds at that point in time. Just like an hourglass.
And, again, this was with, at room temperature, and using a ten micro ferried capacitor which is relatively common for smart card applications.
Okay. So how about capacitor size? We tried all sorts of different capacitors to try to see how that would affect it. It turns out really temperature and capacitor size, these are all proxies to what we're actually measuring. The real causal effect is what's the current voltage on the voltage supply, and the capacitor is going to give us a different voltage depending on its capacitance.
So with no capacitor at all, we're typically able to get on the order of just measured in seconds of time. For security applications, we have found that to be sufficient because it allows us to stop these queries, what previously could have been thousands of queries per second. We can slow them down to one per second using this timer.
If you're on a smart card, you're likely going to see actually a built-in capacitor because it's got to store its energy somewhere when it's harvesting energy from RF. You'll typically see it at around ten micro farads and get up to minutes. And on some more advanced sensor devices like Josh Smith over at UW had a whisp sensor with a super cap, and the super cap was about ten mili farads I believe, and there you can get a timer that lasts many, many days without actually having to power the timer. It's just working off the leakage of your SRAM.
Okay. So here's some more detailed measurements about temperature. So each one of these data points is a measurement where we had to run that thermal chamber, get it to a precise temperature, measure it to make

sure it was actually that temperature and then use the DAC to power it up for the precise amount of time for that particular measurement.
And as you can see, in all cases, even when you crank it up to 50 degrees C with no capacitor whatsoever, you still get a measurable delay. That is to say, you don't need a capacitor in order to get any kind of interesting measurement. So here we're down at a fraction of a second when we've heated it up to 50. But at room temperature we're getting about -- where are we? -- looks like we're getting up to about two seconds at room temperature with no capacitor at all.
Question?
>>: Does that continue to scale or does it begin to melt?
>> Kevin Fu: The question is does it begin to scale with temperature?
The interesting thing is I forgot what the exact temperature is when the chip fails, you can continue to heat it, but at some point you've just destroyed your chip. We take advantage of that in our adversarial model because you can't go to infinite temperature. You can try to go to absolute zero. Luckily we don't need to worry about freezing attacks. Freezing actually helps us. It slows the timer down.
>>: [inaudible] a hundred C or 500 C.
>> Kevin Fu: Amir, do you recall what the maximum temperature without causing permanent damage to the MSP 430? I think it was on the order of like 200 degrees Celsius.
>>: The spec sheet says 120, if I'm not mistaken.
>> Kevin Fu: Okay. Question in the back?
>>: Maybe I missed something you said. Why is the Y axis stopping at
50 something percent?
>> Kevin Fu: Why is the Y axis stopping at 50 percent? That's actually a good question. SRAM, there are two large classes of memory.
SRAM and DRAM. And SRAM bits decay to effectively statistically random. So you're going to see 50 percent zero bits and 50 percent one bits. That measn decay, even though you set all your the bits to one.
If you asked me that question, and if I were Alex Halderman [phonetic],
I'd give you a different answer because he did work on DRAM a couple of years ago, remenance and decay and DRAM. DRAM is external memory.
SRAM think of it as L1 L2 cache. And DRAM think of it as the Sim card you buy at the shopping store. Those have capacitors rather than transistors to save the digital state and they do go to zero all of them.

Here we have to distinguish from random. Makes it a little bit harder.
Question in front.
>>: So is it feasible to trick the -- is the thermostat close enough, the thermistor close enough to the CPA you could have the thermostat read 50 while the chip itself wasn't communicating.
>> Kevin Fu: The question is effectively is the temperature sensor, can the adversary trick the temperature sensor, trick the CPU without tricking the temperature sensor because of the distance between the two physical components. I don't have an answer to that other than I know from thermal dynamics you're not going to have instantaneous heating.
The chip itself, the silicon, is small enough that it's hard to see with a visible eye. The packaging is large. It's mainly just the leads going to the pins. But the actual silicon is only 3,000 logic eight equivalents. If you think about how small transistors get today
3,000 logic eight is in a very small area. I don't have evidence. I would love to meet someone from the thermodynamics community to help me give you a formula. But my gut intuition it would be really hard to heat one part from a micron away from another. But that's my suspicion. There may be a way using a nonsemi-invasive attack like ion beams or some very targeted radiation, I suppose. But it's outside of our threat model.
We're trying to up the ante here, take an existing card that has known vulnerabilities and make it harder to break. Okay. Anyway, you can do this on all sorts of temperatures, and you are always going to see a curve. The temperature's basically changing that magic inflection point where the decay starts. As you heat up your memory, the timer will run out more quickly. So you'll have shorter timers. But the timers are all non-zero. And that's our goal here to get something greater than zero for a timer, from a security perspective.
There's also naturally some chip variation. All of our tests were done on the MSP 430. However, we did see variation even between individual chips. It's difficult to control the temperature perfectly. We only had about a two-degree precision on our thermal chamber. It's designed to actually have a much larger range, but we weren't allowed to install liquid nitrogen tanks in my lab. We basically could only do heating.
As you can see, there's some slight variation. The important thing to note is the shape of the curve is always the same.
So in this way we could train on one chip and then use that for the other chip and still have some relatively good precision.
>>: [inaudible] started random initial configuration and then you probably want to go somewhere [inaudible].

>> Kevin Fu: So the question is since the natural decay is to the statistically random case, what if you initialized memory to statistically random --
>>: Random given the initial condition, right?
>> Kevin Fu: Right. So, well, we kind of ignore that. The way we get around that is we initialize memory to a known pattern. That way we can do a delta. Basically X-or and then count. And we know the closer we get to 50 percent the closer we are to an expired timer.
I would imagine there could be some fancier algorithms to try to squeeze more information. It would be really interesting to see if we could do better than this.
There's some -- you can actually profile each individual SRAM cell.
I'm not sure if you're going to be able to exploit that extra information to get much more than a small constant factor better. But maybe you can.
About four -- I think it was about 4 percent, a small percentage of the bits always come up as zero or always come up as a one. Because of slight mismatches between the lengths of wire and the way the transistors are connected.
You might be able to do something interesting there. But identifying those bits since they're only small percentage might not be worth it.
It's more code space.
Okay. So we implemented this on our favorite platform of choice, the
UMAS MOO, a computational RFID tag we manufactured in our lab. It's based on the Intel WISP or UW WISP is what it's now called. Augmented it with a slightly beefier processer. So we call it the MOO. We augment it with piezo elements, so we can make little buzzing sounds, like tonal things.
So we did this in order to try to test the theory of could we make a squealing RFID credit card that squealed when you queered it too much.
Because naturally if somebody's querying your credit card in your wallet 100 times a second, that's probably not normal unless you're a really fast shopper.
So in this particular device, we measured the execution time and we found we could get about a 12 second timer with standard deviation about .1 seconds. So if you queried it faster than once every
12 seconds we are able to then make the tag beep and it acts as an audible alert to say something's fishy up in your wallet. It doesn't solve the problem, but it makes the wallet bearer more aware of their surroundings.

We have other applications that are in our full paper, such as e-passports and other battery-less devices.
Going back to the table. Again, here's that original table from the beginning of the talk about how many queries it took to break these various systems ranging from car immobilization to payment cards; you can see they range from about six seconds to two hours. If you assume a eight second Tardis to slow down each query, then it moves to a much more interesting minutes to days.
In some cases you're actually seeing a hundred X increase in the amount of time that the adversary needs to spend to get those same number of queries taken.
So this doesn't solve the security problem, but it significantly raises the bar to the adversary such that there's more chance the adversary will get noticed or exposed. And it also comes at no physical cost.
There's no change to the circuit here. This is just a software update to the existing program running on the device.
Okay. But there are ways to attack the Tardis. And the two most obvious ways at least to us were cooling and heating, because everything is about temperature here. Because they're semi invasive.
Those are the main attacks we worry about.
The good news is the cooling and heating, the thermal sensor seems to make it much harder to mount these attacks, especially if you're talking about one-second timers.
Being able to heat and cool a tag very quickly within a single second we think would be difficult. There is this other attack we haven't solved. We call it the pulse attack. This is where you're pulsing heating/cooling, heating/cooling, heating/cooling, and in an attempt to wear down that timer but then by the time the sensor reads the measurement, it's back to the normal temperature so it's none the wiser that not enough time has elapsed.
This probably would affect timers that are on the orders of minutes to days where you can actually do a pulse. But for a timer on the order of a second, I would like to learn more, but I'm not aware of any way to heat up a tag with that kind of precision, sub second precision.
There may be a way but I'm not aware of one that I could just carry in my back pocket.
>>: Lasers.
>> Kevin Fu: Lathe? What?
>>: Lasers. Heating anything --

>> Kevin Fu: Possibly. The problem, though, even with a laser, don't forget, it's not about precision of aim. Once you heat it, how long does it take for it to cool back down again? So, yes, you could use a laser to try to heat things up. In fact we found running the card heats it up two centigrade for each trial. We had to wait -- Amir, do you remember how long we had to wait between trials to get the card to cool itself down? Might have lost him.
But I think it was on the order of -- hello?
>>: The thermal chamber it took about like one, two minutes for it to cool back down.
>> Kevin Fu: Yeah, so just trying to compensate for its own computation took about two minutes to cool it back down. I'd be surprised if you could get like a liquid nitrogen or piece of ice to cool it back down in less than 1/10 of a second given that it has this plastic housing.
But, again, we're talking about semi invasive attacks. If you're going to bring in Sergey Sorbora from the UK from Ross Anderson's lab, he can do anything. He can extract AS keys from stones.
He's outside of our adversary model here. We're just trying to increase the difficulty in the amount of time it takes.
>>: So did you talk about exactly the defense mechanism like, for example, what would you do, like do you keep a counter in memory, or did you measure how random the bits look like when you get power back, what's actually the details of the defense here.
>> Kevin Fu: So the actual algorithm is in the paper. But I'll just give you the high level picture. The high level picture is we look to see if enough bits have decayed. And I think I mentioned in the beginning we don't use a closed form solution in our implementation.
We could try to find a polynomial that represents that lovely curve.
But because most of these devices are closer in spirit than RFID tags than desktop computers there's not enough CPU level to do that computation. For instance we don't have hardware multiply on our platform. So instead we chose the more simplistic approach of just look it up with a very small number of data points.
This gets us a one bit timer, essentially. So we know how much time would elapse for a given temperature. Whether it's expired. There's a lot more you can do if you have more CPU or if you have more space.
Anyhow with a pulsing attack I do think it's a real problem but we're relying on physical limitations for those short timers, the laws of thermal dynamics, how fast you can heat and cool.

If you really cared you could buy these things called thermal fuses.
In fact I think I believe for some Phipps 140 devices this is what they use to detect if you maliciously took your CPU and froze it. It will cause the chip to fail if you do funky things with the temperature. We stay away from modifying the circuit because it costs money.
>>: Can you clarify the algorithm. You count the number of bits and if it's below or above the threshold you just say no, I'm not going to answer your question?
>> Kevin Fu: Exactly. Exactly.
>>: Wouldn't it be safer to alternate the, like have the odd bits need to be zero and even need to be one? Seemed like you might have an electromagnetic pulse attack where it's some way just to attack all the ones in the SRAM, and if you're worried about that attack, then --
>> Kevin Fu: That's an interesting --
>>: From 0101 is the way to go.
>> Kevin Fu: Instead of using the 1111 pattern, use alternating 1s and
0s to defend against EMP attack that may cause all the bits to flip in one direction, is what you're saying. Yeah. It sounds like that would be a no-cost, from an implementation standpoint. So why not.
But I'm not familiar enough with the EMP to know how resistant it would be.
>>: Sounds cool, though.
>> Kevin Fu: Yeah. An EMP proof Tardis, that would be great.
Okay. All right. Moving on. Okay. So the main application I talked about today was defending against brute force sort of treating smart cards as encryption Oracles. But there are other applications you can imagine where this timer might help. We're not sure. But it's areas we'd like to explore.
So being able to implement time-outs and verification protocols, especially with RFID tags. RFID tags don't know how much time has elapsed before it gave a challenge to a reader. Now it might actually be able to implement a sense of time where it said you had too much time to think about that one maybe you cracked it so try again.
Maybe you could implement things like temporary ownership. If you think back to the resurrecting duckling program -- from the look on your face, not everybody is aware of what the resurrecting duckling problem is. Let me tell you what it is. I'm sorry, I'll forget the

student's group, but I know he's from Ross Anderson's group. Was it
Richard Clayton?
But a number of years ago they proposed the following solution: How does a new duckling know who is his or her mother? Well, when you are born, you look around and the first thing you see is your mom. And so that's how they said that's the resurrecting duckling problem. The way they'll solve it when you lose all state the first person you see is the owner that's who has the authentication controls of you.
So in some sense RFID tags are this way, whoever first sets the password is the owner. All right. There's also the double tap and passback attack where this might be able to help. This is where somebody's double charging your credit card. Now you might actually be able to know if somebody's double charging it. Or pass back, it's when somebody behind you is sort of doing this and you think they're being friendly but they're actually just getting your RFID payment card.
On the nonsecurity front, there could be some interesting applications with ultra low power sensors. So sensors today may implement what's known as a real time clock. This is a clock like we normally think of clocks. It's always ticking. The problem is you're paying for each clock tick even when you're sleeping.
So if you're to replace that real time clock with something like the
Tardis, now you wouldn't actually have to draw any power while you're sleeping. So this may replenish the energy you've been wasting on a clock you're not using.
The disadvantage is you end up with a coarse grained clock as opposed to something that has microsecond granularity. But for some sensor applications you may not need that kind of precision. I mentioned the e-passports. There's some interesting crypto research mainly in the
1990s. Saw there was a recent paper by Silvio Fadan and others at
Harvard and time released crypto.
It's not directly related, but it may actually trivialize the problem, because it -- it allows you to sort of insert a known quantity of time into computations. So in time release cryptography the problem was how do you make sure that someone can't open a message for given amount of time. Most of the solutions have to do with proofs of work, computation. The problem is people have different computing powers.
So the constant factors were tremendously large in between what Alice or Bob might be able to compute and therefore one might be able to cheat the system.
But, okay, moving on. There's quite a bit of related work in this space. In particular, with data remnants. The most interesting work would have been this data retention and SRAM. So Peter Gutman at
USENIX Security in 1996 and Sergey over in the UK did quite a bit of

research on just how long does SRAM hold its contents. They have quite a bit of temperature data on how long SRAM holds its contents. And their work kind of inspired some of our ideas.
We combined this with Fern's approach down at the bottom. Dan Holcomb, one of the students on the paper, had created what's called a puff. A physically and clonable function based upon SRAM decay. Turned out some of the bits always come up as one. Some of the bits always come up zero. He was able to identify individual chips just by how the SRAM powers itself up. That was sort of our inspiration for the Tardis thinking how else can we use SRAM to do interesting things.
Alex Halderman had a very interesting paper in 2008 at USENIX Security where he showed how you can uncover the contents of DRAM. Even if you take that RAM module physically out of the laptop, keep it frozen and you physically take it out of the laptop, plug it into a new laptop, you power it up, and guess what, it still contains the same bits you set.
That was on DRAM. Again, a different kind of memory technology, but it's similar in spirit. It's all about remenance decay.
There's plenty of other clocks you might consider using. Lamport clocks from the '70s, you could try using that.
But, again, we're here mostly about trying to install some kind of physical notion of time into the computation.
All right. So to conclude basically four points of which I hope you take home at least one. The Tardis uses the remenance decay of SRAM in order to estimate time. We use it as a one bit timer. Although you could try to use it for more than one bit depending on your application. Tardis makes brute force attacks harder. Doesn't eliminate them but it does make the attacks harder in that it takes more time.
The beauty is that it's pure software. There's literally no change at all to the hardware. So a manufacturer who creates a smart card could literally just update their firmware with this very small algorithm in order to have a sense of time to defeat these very simple oracle encryption attacks.
And the other interesting thing, at least to me, philosophically, is this is one of the few cases I'm aware of where we use remenance decay for good. Most security and privacy researchers think remenance decay is bad because it means privacy leaks. You can violate privacy. But here we're using it to actually improve the security of our system.
So let's see. It's 2:20. I've forgotten how long we have until 2:30.

>>: [inaudible].
>> Kevin Fu: Okay. So I think I'll take questions now. I do have some other material I'd be glad to talk about that has to do with other interesting things you can do with SRAM in order to make puffs. But I can talk about that later as I see the crowd thinning out.
But I see we have a question in the back.
>>: What's the smallest amount of SRAM you need for these segments to work?
>> Kevin Fu: Smallest amount of SRAM. And, Amir, please correct me if
I'm wrong, we've found is 240 bytes. But one of the students, Dan
Holcomb, told me that he could get something useful with as little as one byte; is that correct, Amir, with your recollection, are you still there?
>>: We can do it with 240 bytes but we can do it with much lower, smaller memory.
>> Kevin Fu: And actually maybe I'll have a follow-up question to your question. The natural question to ask after that is does more SRAM help, does it give you a more precise timer. That's what I would have thought. It does help with more precision but it comes at a really big cost. Because every additional SRAM cell you have increases leakage current. What this effectively does is drain your energy faster, so you actually get shorter clocks if you have more SRAM.
So there's a sweet spot where you need just enough SRAM to get the precision you need but not too much because then your timer is going to be really short.
>>: The platforms you're referring to, do you have any form of permanent storage when they're powered up?
>> Kevin Fu: The platforms we target do have permanent storage. So
I've talked with smart card manufacturers and the guy who invented the
Java card, told me, yeah, there's nonvolatile memory on there. In ours we happen to have Nor flash memory. I forgot how much. Something on the order of like 10 K, anyhow small. Nonvolatile memory is extremely expensive to add to a device. So it would be nice not to have any and it would reduce costs. SRAM is a relatively large chunk of -- this is why your L1 cache is limited. You're not going to have gigabytes today of L1 cache because it would take up too much space on the die. That's one of the limitations.
>>: In terms of that do you want to implement a timer, you did some operation that you know takes a second on the device, kept track of how far you've gotten, would that be enough? Some number of digits?

>> Kevin Fu: Well, let's see, yes, but can you do this when you're powered off?
>>: Keep track of how far you've gotten; next time you power up you say okay, do 64 more.
>> Kevin Fu: So is there a way to use nonvolatile memory to make a more interesting timer. So that's actually that's how it's done today.
So manufacturers do invest in small amounts of nonvolatile memory to store counters, they're called transaction counters. I forget if it was Visa or MasterCard, one of them has a transaction counter. After you have, I think the card we tested, this was five years ago, after you do 10,000 transactions it just stops and you have to get a new card.
I call that a denial of service attack.
>>: [inaudible] not just the counter.
>> Kevin Fu: Exactly.
>>: What you're suggesting.
>> Kevin Fu: So counters can give you a physical total limit, if you think about integrating over all time, but the nice thing about timers, now you can have this card work infinitely long but for any given period of time you can bound how many queries happen in a given period of time. A counter alone is not going to be able to do a time-bound.
>>: I think the solution you're proposing would implement a rate, not just the counter alone, right?
>> Kevin Fu: You mean combine the two.
>>: Combine -- his solution is different [inaudible] if I understand correctly. And the idea is you know what the time is somehow. You start computing, the occupation it's very predictable in how long it will take. And it has regular periods where you snapshot the state of that occupation and you know you've done three rounds of that computation, then it took two this long if -- sort of left this much.
>> Kevin Fu: Right. Except the processor is not running when the power -- so it's solving a different problem, I guess. That would tell you how much uptime you had. It could tell you uptime.
>>: You can say I'm only going to -- I'm going to rate limit, give me this much uptime because I'm willing to --
>> Kevin Fu: How is that different from a transaction counter?

Maybe that's more a floating point. It's more probabilistic.
>>: Minimal time between increments of the counter, transaction counter.
>>: So depending on -- suppose you -- I'm going to allow you to guess passwords, passwords, but one password every ten seconds, but for every -- whereas the counter will basically say after three guesses we're done, we're not talking to you anymore.
>> Kevin Fu: That's how it's done today actually in French passwords.
>>: Right. This would basically say rate limit. To say you slow down.
That's one point.
>>: Destroy a password.
>> Kevin Fu: I'm sorry?
>>: You can just destroy a password remotely.
>> Kevin Fu: Actually I have a picture -- I think I have a slide on the French passport. No, not here. Sorry. I don't have the French passport. The way the French passport works, after you make, until you've made a correct query, it introduces an artificial delay in its response time. But it doesn't have a way to reset the delay. So it will continue to delay you forever until you get a correct answer. So that's how they implemented it today. There's no sort of back off -- there's no notion of time.
>>: Seems another way you could do this is -- suppose NIST or some entity with a lot of bandwidth was willing to answer questions in a form what time is it and would sign up.
If you had such an entity and all your readers were online, you could rate --
>> Kevin Fu: Don't they have this service?
>>: Okay. If that service exists what you could do --
>> Kevin Fu: How do you know that --
>>: You keep track of the last time that you were asked to charge or whatever and then anybody -- and anytime somebody asks you to do something else they have to prove that the current time is -- they tell you what the current time is and it has to be 12 seconds more than the last time.

>> Kevin Fu: I think there may be a little bit of a sort of circular argument. The proposal is you use a trusted third-party to give you a signed time saying here's the time and here's the signature. But don't forget you need to guarantee freshness of the signature. How do you guarantee the freshness of a signature, you have a clock. But there's no clock to be able to guarantee the freshness --
>>: I see. Haven't used your card in the last 12 days it can start with 12 days ago and go --
>> Kevin Fu: Yeah. So it's a real Catch-22. And ultimately what it comes down to, and like Ross Anderson and [inaudible] talk about this, ultimately you need a trustworthy clock. At some point you just need physical security. And here we're trying to give you some physical security with a physical clock that comes at no cost. In other words, you've already paid for it because you're already draining your battery. And we're going to use that drain or, excuse me, drain your capacitor. We're using that drain as a way to measure just like a water clock would or an hourglass.
Okay. But I guess I'll stop there. I'll be happy to take any other questions off line or if you want to know more about puffs, I've got more material on that. So thanks.