17397
>> Seny Kamara: So it's a pleasure to have Mastooreh Salajegheh visiting us. Mastooreh is
from UMass and works with Kevin Fu who is also visiting us. And she'll be speaking about
security for RFID.
>> Mastooreh Salajegheh: Thank you. I'm presenting CCCP Secure Remote Storage for
Computational RFID tags. And this is a joint work with Shang [inaudible] and Kevin Fu from the
University of Massachusetts Amherst and Ariel [inaudible] from RSA.
So before I begin, let me give you a high level view of the work. It's sometimes more efficient to
do something remotely instead of locally. For example, it's cheaper in terms of money to ask
China to build some products for you and ship it to the United States instead of producing the
items in the United States.
So here efficiency means money. Another example, a more technical example, it's faster to store
something in a remote RAM via networking instead of storing that in the hard drive.
So here by efficiency I mean time. Those are very studied examples. I'm going to introduce a
new example here which is in RFID tags, it's more energy efficient to store something remotely
instead of storing that locally into flash memory.
I'm going to focus on that example and tell you that if we want to -- if we want to store something
remotely, you need to have some security. You need to consider security.
So let's see what kind of devices I'm talking about. I'm talking about battery-less RFID tags. And
they are for identification and these devices usually are scanned by RFID readers and they send
by a static ID so it knows what it's scan and what items it's talking to.
So how could we make these RFID tags more powerful? They don't have a volume in
architecture. So maybe if we add a multi-processor to them and then add some flash memory
and nonvolatile storage to them and maybe some sensors. Like temperature humidity so that
they can monitor their environment, we will have a more powerful battery-less RFID tag.
But Intel has done that. They have built NTVs which is wireless identification and sensing
platform, which in general we call them computational RFID tags.
So let's see some characteristics of these three RFIDs. They are essentially battery-less mini
computers, and since they are battery-less they are maintenance-free, meaning we can simply
implant them inside the bridge without worrying about changing the batteries from time to time.
So and since they are battery-less they need to harvest the energy somewhere from the RFID
reader that they are intracting indeed and store that harvested energy into a capacitor which is
leaking. So as we know a capacitor, small capacitors leak energy in exponential decay. So in a
few seconds the CRFID tag loses its energy whether it uses it or not.
So let's use that energy to do something good. So this battery-less mini computers are small.
They are maintenance-free. They are nice, we can use them. It's very, very difficult to access,
but there's an issue here.
The local storage and nonvolatile storage that CRFID tags are using is energy intensive, meaning
that the write operation is much more expensive than the read operation. So if you're going to
store something, you need to expend a lot of energy. If I tell you the read operation is almost the
same, consumes the same amount of energy as the CPU operation, you can see that flash
memory is much more expensive than CPU.
There's another issue. This nonvolatile storage, it's [inaudible] memory, meaning if you want to
reuse that memory you need to first erase the memory and then write something, and as you can
see erase is also an expensive operation.
So storing something basically means erasing the memory and then writing something and there
are two most expensive operations available on the CRFID.
And, finally, this expensive, energy expensive local storage is very small. Currently we have
about 32 kilobytes of flash memory available on this platform which about one kilobyte of that is
assigned for information memory.
So we're looking for an alternative for this storage, something low cost. The rest of the talk I'm
going to tell you how we can provide CRFID tags with secure removed storage and how can we
use this secure removed storage to make CRFID tags more powerful.
So if you look at the costs of CRFID memory modes we can see there that the main component
that's the most power consuming component is radio. So there it makes sense to avoid radio as
much as possible and instead try to focus on the CPU and flash memory.
But if you look at CRFID tags, surprisingly radio is very cheap. So why not use radio and focus
on radio and avoid flash? Yes, go ahead.
>>: Can you define the mode? Half of it ->> Mastooreh Salajegheh: Yes, so a mode has batches. It's a mini computer but it has batches
which they last about several months. And they are also very restricted in terms of their
resources.
They have very limited amount of RAM and tiny flash and low bandwidth and as we can see their
radio is very expensive.
>>: So essentially a mode in RFID with battery?
>> Mastooreh Salajegheh: Yeah, I guess. Maybe an RFID is a more productive battery.
So in CRFID tag radio consumes less energy than the local storage. Let's also outsource our
storage to a reader. Since the memory is cheap on the run in an RFID reader we can save a lot
of energy on the CRFID tag by focus on the radio and outsourcing this storage to a radio.
So it should be simple. The CRFID tag sends its data via radio to the RFID reader. The RFID
reader stores that data for the CRFID and then later on the CRFID sends the RFID reader sends
that data back to the CRFID.
But what if the reader doesn't send back the original data to the CRFID. So there's a problem
here. A reader is not necessarily trust worthy. We need to make and provide some security and
make sure of some essential security goals here.
Integrity, authentication, confidentiality, data operation and by data operation I mean the tag
needs to make sure that it's receiving the latest data that it has sent to the reader so that on a
CRFID, the RFID reader or any other third party is not going to do a replay tag on the CRFID and
availability. But we're not addressing availability in this work. It's more like the CRFID syntax.
It should be simple to provide those security to provide the CRFID tag with the security goals.
But remember what devices we're talking about. They don't have any battery. They have a tiny
capacitor to store the harvested energy. They reboot every few seconds. They have a small
RAM, expensive flash memory. The communication is [inaudible] and it's low bandwidth.
So considering all those resource limitations how could we provide security to the CRFID tag?
We have a hypothesis, that is that it's possible to provide the CRFID tag with removed storage
that is secure and still it's less energy consuming than storing something locally. So we hope that
we can use the already developed security modules so that we provide the security remote
storage and the security overhead does not overshadow our savings from using remote storage
instead of local storage.
So the first goal is confidentiality. We chose to use a string cypher here. Particularly I'm talking
about X store, store your data with them through the random Kia string. X Store is a very energy
efficient operation. And the only challenge here is that we need to somehow provide CRFID tags
with kia streams, random kia streams. So they're like random bits that you're going to X Store
your data with that and protect the confidentiality of your data.
But computing the kia streams is energy intensive. We need to somehow avoid computing the
kia streams on runtime and somehow provide CRFID tags with kia streams. I'm going to address
that later.
The other security goals, integrity and authentication. So the typical solution would be use H
match [inaudible] or other Mac schemes. But they are memory and energy intensive, especially if
the data that you are working on is small, it's going to use a lot of memory in the beginning.
So we chose to use universal hash function-based max. And the way forward you call the HF on
the data and you exhort the hash result on the kia stream and you make your message
authentication code and send that to the reader.
So particularly we use UMAC, which is fast and energy efficient. We have implemented that on
these and it works well. So, again, here there's a challenge and that's again we need to provide
the CRFID tags with kia stream. But if we can do that, if we can provide CRFID tags with kia
streams we are solving two problems.
Next we need to provide the tags with data freshness. So in that case we need to keep some
sort of estate to make sure that freshness of the data. But we need to store that estate locally.
Because the CRFID only trusts itself and nobody else. But if we're storing something in
nonvolatile memory locally that means using the flash memory again, then we are back to square
one. So how are we going to address that problem?
First of all, we are trying to keep that estate for the data freshness as minimum as possible. And
next we are introducing a new approach called hole punching. So basically if we are storing
something in binary mode in the memory, let's say you have a stored number 7 in the binary
format in your memory and you want to store an 8, that's not possible. Because you need an
erase before you can write anything to the memory.
You can see here you need to change the force speed that is 0 to a 1 and you cannot do that with
a simple write. You need to do an erase first.
But if you stored -- so you do an erase and then store your number 8 there. But if you are storing
your number in unary format which is like punching seven holes into your memory and then
represent number 7 and later when you want to store 8, you just need to punch another hole to
have 8 holes which represent 8 in unary format.
>>: If erase only costs as much as write as the previous assign you can erase individual bits so
gray code would get you into a factor of two binary counter.
>> Mastooreh Salajegheh: Erase works in blocks. So it erases one block which sometimes is
about 128 points. So using hole punching we are avoiding erase and we are changing one bit at
a time which is more energy efficient.
Okay. Let's go back to that kia stream that we said both the matching scheme and the encryption
schemes need those pseudo random kia streams. And as long as we don't reuse the kia streams
we are safe. Apparently the United States was able to decode the messages from Russia since
they were reusing the kia streams. So we don't want to make the same mistake.
Let's say there are some good power season that tack has enough energy and is able to compute
the kia streams by calling a blog cypher store kia streams in flash memory, although that is
energy expensive but we're in a good power season and then erase the old and new kia streams.
So whenever the tag has enough energy and it's in a good power season I'm going to define that
it's going to opportunistically compute the kia streams and later on runtime the kia stream -- the
marking scheme and encryption scheme are going to use the kia streams and protect the security
of the CRFID.
So what do I mean by good power season? There are times when the CRFID tag is idle. So, for
example, CRFID is awake. It has power sets some energy but it doesn't have anything to do
anymore so it can uses use that energy and precompute some kia streams and store them into
flash memory.
Or another example: Maybe CRFID is close to an RFID reader. And it's harvesting energy from
that RFID reader but the RFID doesn't speak the language of that CRFID it doesn't know what
encryption scheme or matching scheme the CRFID is using and it doesn't have access to the
data that CRFID has stored.
So the CRFID tag could harvest energy from that RFID reader but it cannot talk to it. It cannot
send any data. So it can just use that energy and opportunistically compute some more kia
streams and store them into flash memory.
So, so far I have addressed the security goals and I have told you how to make a secure
removed storage for CRFIDs now I'm going to tell you how to use that secure removed storage to
enable CRFIDs to do general computation and become more powerful.
CRFID tags can do some cryptography, for example, we can see that we can implement an run
RC 5 on these. But could they do any larger computation? Could they run publicly cryptography
with the small amount of energy that they have available? Could they do modular exponentiation,
and the answer is no that's because they have very small leaking energy storage and since this
storage is leaking every few seconds the CRFID tag loses its power and lose whatever it has
computed so far. So it forgets what it has computed so far.
So the goal here is computational purpose. We want to make sure that the CRFID is able to
finally finish a program, meaning that more computational progress I mean change of
computational estates towards a goal. For example, completing a loop for a CRFID.
So in other words I mean we want to eliminate the [inaudible] which is rolling all computation and
then a restart happens and we should redo all the computation we have done so far.
Well, there is a word called [inaudible], which introduce a solution here. If you have seen the
movie Memento there's a guy who suffers from short-term memory loss and he just needs to take
notes and tattoo information on his body so next time he wakes up he can read those tattoos and
remember what he was doing.
So the idea here is similar. The CRFID tag has some tasks to do, has some energy. It starts
doing some tasks and then it finds out it's losing its energy and it's going to die soon. So it takes
a note. It takes whatever it computed so far into local flash memory and then it dies. It loses its
energy. Later on it receives more energy. It harvests more energy. It retrieved the information
from flash memory and it could continue a task.
So something like public cryptography can be possible using this approach by finishing the
computation over multiple life cycles.
But the problem here is that Memento has used flash memory and flash memory is energy
intensive. So could we do any better? We can use the secure removed storage. And that's what
CCCP cryptographic computational continuation passing is about, use the secure removed
storage and check point your information remotely to be able to do more computation.
So the CRFID is accepting its computational estate to a reader but that's not going to happen
because the CRFID cannot start a communication. It does not have autonomous communication.
It must wait for the RFID reader to start the communication.
So the reader sends a query and along with that some energy to the CRFID. The CRFID
harvests energy. Uses that energy to do some task and then says to the reader I'm losing my
energy, I need to store something.
The reader says this is the message size you can use, and the CRFID encrypts its data,
constructs the Mac and sends the cypher tags and Mac to the reader and the reader stores that
information for the CRFID.
Later on, when the CRFID wants to retrieve its information, the reader sees the CRFID, sends
cypher tags, and it matches CRFID along with some energy. The CRFID verifies the
authentication and authenticity and integrity of the message, decrypt the data, and finds the
computational estate and continues its task and finally finishes whatever it was computing.
So, so far I've told you how to make a secure removed storage and how to use it to make
CRFIDs more powerful. We've done some experiments to see if that secure removed storage
consumes less energy than flash memory. So the experiment I've set up was like this: We
programmed the device with a task which was storing locally or remotely and then we give it -- we
charge the device to 4.5 volt and then we let the device run long without access to any voltage,
any energy supply and then we observed the voltage rub and execution time of the device. And
half of CVS squared we use information. We computed the energy consumption of the device
doing that task.
So here are the results. The red line is the secure removed storage in a full mode protecting
confidentiality, authentication integrity and data freshness and the blue line is local storage.
As you can see somewhere between 64 and 128 bytes there's a crossbone and after that the
secure removed storage stays below the blue line which shows that it consumes less energy than
the local storage.
And the blue line here just represents writing to the flash memory. It assumes that the memory is
fresh and you don't need to do an erase. So it's the best case for the flash memory.
We also implemented CCCP with just authentication, if you just care about authentication and
integrity of the messages you are sending. And that's the purple line. And the no security just
reusing the secure remote test storage, and that's like baseline for CCCP and other protocol that
uses remote test storage, everything would stay above the green line. And finally if you are using
flash memory, you are doing erase and write. So the black line is the worst case scenario for
storing locally.
So everything that's using local storage will stay between the blue line and the dashed black line.
So showing you the results, I'm going to conclude my talk. We've seen that local storage is
energy expensive for CRFIDs and surprisingly the radio is cheap. So remove test storage is a
low cost alternative for the CRFIDs and we were able to provide CRFIDs with the remote storage,
which is secure and yet it consumes less energy than the local storage.
So with that I'll take questions. Yes.
>>: The power ratios you quoted are the technology of the chip and the WISP.
>> Mastooreh Salajegheh: Yes.
>>: Every year [inaudible] brings the transistors in the computer does not shrink the transistor
used for the radio frequency because it has no [inaudible] whether it's a real antenna. How many
years before your advance is gold? The black line -- the difference between the black and green
I see a few years to do business.
>> Mastooreh Salajegheh: The radio is using only -- the radio technology that CRFID is using is
just one transistor.
>>: But a big one?
>> Mastooreh Salajegheh: I don't know about that.
>>: Big one.
>>: Happens to be a big one but it's changing the impedance of the antenna.
>>: Yeah. So it has to tell every -- it's not going to shrink more so, I guarantee you that.
>>: I'm not sure. Probably not.
>>: Playing devil's advocate as usual.
>> Mastooreh Salajegheh: So any other questions?
>>: Not really a question, but recently an Air France jet went into the Pacific. They have a load
of flash ROM sitting at the bottom of the Pacific. They claim it's too difficult to broadcast on the
radio. And I know they're lying but -- if [inaudible] they would have had the black box available in
Paris headquarters.
>>: Not sure if you'd be using CCCP, though, because harvesting energy from under the
ocean ->>: No, you do it while the plane is running.
>>: What is the claim [inaudible].
>>: I'm sorry?
>>: Just the distance, what is the claim?
>>: The real claim is that pilots don't like management snooping and management doesn't like
lawyers snooping. They you can't afford the energy to transmit.
>>: My guess, they also don't know how to get their security right. So broadcasting those details
might not be so good and secure.
>>: It would be a fun DTM to build plane-to-plane.
>>: Plane-to-sight. You don't have line of sight without the plane.
>>: Okay.
>> Seny Kamara: No further questions?
[applause]