Your SlideShare is downloading. ×
Slides
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Slides

245

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
245
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Add RSA
  • DELETE?
  • DELETE?
  • Intro immobilizer systems, someone had the idea to prevent a vehicle from starting unless the original key is physically present. This is kind of the idea behind a key in the first place, but simply getting the lock in steering column to let you in just isn’t enough now a days. The goal is that even if hot-wired, the fuel injection system will not operate and hence the vehicle does not start. Now, the typical car theif is stopped. How it works… There is a little RFID chip inside of each key, and an RFID reader inside of the steering column, and the reader will only send the signal to the fuel injection (or whatever mechanism) to allow the car to start if the correct response is received from the key when asked. Driver possessing the original key gets in the car, inserts and turns the key, (and now in an instant, unnoticable to the driver) the reader sends out a message to see if the key is present. [queue animation] This request for an ID will power the RFID chip inside key that is in the ignition, and the key will respond with the correct ID, otherwise the vehicle will not start. You can try it, if you’ve got a new car, wrap some tin foil around the top of your car key and try and start the car… it will not work.
  • Eventually, manufacturers made it increasingly difficult to get access directly to the immobilizer system, they probably moved it farther inside the car and just left the antenna out near the steering column so that it could still operate. In any case, these RFID chips in these keys weren’t very smart. They pretty much yell their name to anyone who asked them too. Which brings us to a pretty easy attack and way to get around one of these immobilizer systems. Someone has there car key with RFID chip implanted inside, and some car thief has an RFID reader (depicted here is a TI evaluation kit reader and antenna). [queue animation. The innocent victim steps out of his car, and is moseying along with his key in his pocket, and the bad guy has his reader in his briefcase. The bad guys reader is constantly sending out requests for car key IDs if they are present [queue animation], and when he walks passed the poor guy, his car key responds. [queue animation] Now the theif has the additional information he needs to be able to steal the victims car.
  • Now, the theif programs another RFID chip, in this little key ring (using the same RFID reader in his briefcase. He walks up to the car, breaks in as he normally would, places his own RFID device near the steering column inside, and finally hot-wires the car. The RFID reader in the car asks What is your ID? And the RFID chip the thief has programmed responds with the correct ID. The immobilizer system then gives the OK for the car to start. And the thief can drive away. So, this attack is doable, but it definitely requires a little more work on the thief’s end to be able to get the ID in the first place. There must first be some radio contact with the chip inside the car key in order to aquire the ID information. This isn’t so hard though if you ever plan on handing your car key over to someone. Imagine having a valet park your brand new Expedition, or handing your key to someone at a car wash, an expensive vehicle, but you are confident he can’t cut a copy of your key that will work. Well, he can. He can cut the key, copy the RFID chip’s ID into another chip, look at your address on the registration card in your glove box, and come pick it up later in the week. In fact, making a copy of the chip takes < 1s, far faster than cutting a metal key.
  • At a high level this is how it is done, of course, there is often more to it that than that. In any case, all the theif has to do is get inside the car, work his magic and whatever it is he has done, he can now drive the car away.
  • RFID technology has been around for a little while now. Little chips can store identification data on them, in a manner such that each of these little chips is unique (if necessary). They can also have the ability to do simple logical operations (simple circuits). An RFID tag reader can read a tag without ever making physical contact with it using radio waves and magnetic fields. They powered by the reader through the area with the creation of a magnetic field, this way the chip requires no battery. For the most part, they are very very cheap. < $.05 in some cases. Great news for many businesses. Maybe you’ve seen them on clothing, library books, inside proximity cards, car keys. Applications in shipping, tracking, inventory, also access control, anti-theft devices…. And many more. Example: Truck pulls into a warehouse, RFID scanner is positioned near the rear of the truck and records arrival inventory as merchandise is moved off the back of the truck. Example: Employee walks up to a building, doesn't want to take out his swipe card, sticks his hip out toward the reader and is granted access.
  • Intro immobilizer systems, someone had the idea to prevent a vehicle from starting unless the original key is physically present. This is kind of the idea behind a key in the first place, but simply getting the lock in steering column to let you in just isn’t enough now a days. The goal is that even if hot-wired, the fuel injection system will not operate and hence the vehicle does not start. Now, the typical car theif is stopped. How it works… There is a little RFID chip inside of each key, and an RFID reader inside of the steering column, and the reader will only send the signal to the fuel injection (or whatever mechanism) to allow the car to start if the correct response is received from the key when asked. Driver possessing the original key gets in the car, inserts and turns the key, (and now in an instant, unnoticable to the driver) the reader sends out a message to see if the key is present. [queue animation] This request for an ID will power the RFID chip inside key that is in the ignition, and the key will respond with the correct ID, otherwise the vehicle will not start. You can try it, if you’ve got a new car, wrap some tin foil around the top of your car key and try and start the car… it will not work.
  • Eventually, manufacturers made it increasingly difficult to get access directly to the immobilizer system, they probably moved it farther inside the car and just left the antenna out near the steering column so that it could still operate. In any case, these RFID chips in these keys weren’t very smart. They pretty much yell their name to anyone who asked them too. Which brings us to a pretty easy attack and way to get around one of these immobilizer systems. Someone has there car key with RFID chip implanted inside, and some car thief has an RFID reader (depicted here is a TI evaluation kit reader and antenna). [queue animation. The innocent victim steps out of his car, and is moseying along with his key in his pocket, and the bad guy has his reader in his briefcase. The bad guys reader is constantly sending out requests for car key IDs if they are present [queue animation], and when he walks passed the poor guy, his car key responds. [queue animation] Now the theif has the additional information he needs to be able to steal the victims car.
  • Now, the theif programs another RFID chip, in this little key ring (using the same RFID reader in his briefcase. He walks up to the car, breaks in as he normally would, places his own RFID device near the steering column inside, and finally hot-wires the car. The RFID reader in the car asks What is your ID? And the RFID chip the thief has programmed responds with the correct ID. The immobilizer system then gives the OK for the car to start. And the thief can drive away. So, this attack is doable, but it definitely requires a little more work on the thief’s end to be able to get the ID in the first place. There must first be some radio contact with the chip inside the car key in order to aquire the ID information. This isn’t so hard though if you ever plan on handing your car key over to someone. Imagine having a valet park your brand new Expedition, or handing your key to someone at a car wash, an expensive vehicle, but you are confident he can’t cut a copy of your key that will work. Well, he can. He can cut the key, copy the RFID chip’s ID into another chip, look at your address on the registration card in your glove box, and come pick it up later in the week. In fact, making a copy of the chip takes < 1s, far faster than cutting a metal key.
  • We purchased an evaluation kit from TI, about $400. This gave us a reader, antenna, some RFID chips to use. We could then start messing around with them, programming them, reading them, etc… we could also communicate with our car keys and speedpasses which was kind of fun. Later we bought a big gate antenna, its about 3 feet high, 1 foot wide, and we’d have visitors stand in front of it and it and we would tell them the types of RFIDs they had on them. Next we wrote an API (basically a programming interface) to communicate with the reader. This allows us to not have to use TI software, make rapid tag queries, easily record results, choose our own encryption key, etc.. As for our reverse engineering, by sticking a chip above the reader antenna and holding it there with a clamp, we have a blackbox that we can analyze responses given any data we send to it.
  • Before we could get started, we ran into our first security feature that prevented us from actually writing our own secret passcodes into chips for testing. A checksum is a value used for verifying that a message was received properly, and in these protocols, it is appended to some of the messages that are sent [queue animation]. This checksum has a secret input value, that is only available by NDA, and is used in every chip produced. This was relied on as a security measure to prevent an attacker from producing a valid message (responses, that sort of thing) unless the secret value is known. Problem 1: If somebody figures out this value, suddenly this security feature is uselses, because it is used in every chip, and now everyone knows it. Problem 2: It is extremely easy to figure out. The secret value is only 16-bits long, I mentioned ealier that this is a string of 1’s and 0’s. 16-bits means that there are only 65 thousand possibilities. Whenever a tag responds to a query, it uses this secret value to create a checksum, so what we did was guess what the secret value was and try computing the same checksum. We were able to guess this value in about a few ms. Less than a second.
  • We started some initial experiments aimed at figuring out what the secret algorithm was, and the first thing we did was set the secret passcode to 0, and try some encryptions. Here, these numbers are writing in what is called hexidecimal. It’s a numbering scheme that goes from 0 to 9 and then A to F, basically representing 0 to 15. These were the results we got and we thought, hey, these don’t look very random at all. All 0 bits must be a weak key of sorts, there are probably other weak keys as well… but we weren’t sure. Anyway, it was pretly interesting.
  • Next we tried a few more experiments, this time with a little different values. We noticed that when we sent a string with FD at the end, rather than all F’s, we got all Fs anyway. And that when the FD was on the otherside, we got FD followed by all Fs. We also noticed that it kind of looked like a pattern was developing, so we hypothesized that the 24-bit response we were getting [change slide] was actually a 40-bit response, 40-bits just like the challenge, but truncated so that we only got a portion of it.
  • Found this in a publically avaliable document, a presentation given by TI employees in 1996. It is also found in an automotive conference publication, describing an immobilizer system. Ironically, the presentation was describing better ways to design the chip, so that it is more secure... in 1996. Here is exactly wha is going on in the picture: Each clock cycle of the chip, all the bits of the challenge and the secret key get mixed up in this routing network and go to different f-boxes. The f-boxes then take the inputs and determine the special output given those inputs. Kind of like a talbe lookup, if I get inputs xyz, I do output abc. Those outputs are then inputs to another set of f-boxes which do something similar, and then those outputs go to a final f-box. The output of that f-box is then put in the first register of the challenge and all other challenge registers shift by 1, the last one dropping off. ALso, every 3 clocks, the key will shift once. During a shift, these bits here are binary xor-ed together to get a new bit that is put on the left side. Again, all the other key bits are shifted right with the last bit dropping off. So that is what is going on in this picture. Our first thought was wow, that saves us some trouble. But is this thing even correct? Not entirely, firstly, the diagram is very incomplete. Secondly, it is inaccurate in many ways. It is incomplete because it does not show us where each of these bits go, and then what happens to them once they get there. The bulk of our academic research we were doing here, was on reverse engineering the exact algorithm that was being used. The algorithm is secret, and all we have is access to what we call a "black-box oracle" meaning we can set an encryption key, send it any challenge and get the corresponding response. It gets kind of complicated here, but a full description of each detailed step we took in uncovering the cipher is only at our website rfidanalysis.org. I'll gloss over most of the technical details, and show you the steps we took at a high level in recovering the full cipher.
  • First we wanted to verify that the general structure of the algorithm was correct. We noticed that the challenge registers initially contain the challenge bits, and that the same registers contain the response bits after 400 clock cycles. The diagram indicates that after 1 clock cycle, the challenge is shifted over by 1. We assumed that if this is correct, by giving our "black box" a challenge, and then the same challenge shifted over by 1, we should get two responses, one of which is identical to the other, but shifted over by 1. This didn't exactly work, meaning the diagram was incorrect, but it did work when everything was shifted over by two. Our best guess was that two bits were added after each clock cycle rather than one, the first inconsistancy with the diagram. [queue animation] This however, gave us just what we need to reverse engineer the cipher. We were able to guess what 2 bits come out of this last f-box and are put into the front of the challenge registesrs, after every single clock cycle.
  • Next, we had to figure out whether this key scheduling mechanism was right. It wasn't. To keep doing our test with different keys, we needed to know how the key schedule worked, so we could update it through programming ourselves. So we had to then guess what the next key would be after 3 clock cycles. We guessed that the key is shifted by 1 to the right, with a new bit added on (sometimes a 1, sometimes a 0). We could then just guess which bit was added (a 1 or a 0), and determine whether or not we were right by looking at the responses again. If we were right, one of the responses we had would be the same as the previous response, but shifted. [queue animation] Turns out the bits were not correct, but we had now recovered the key schedule portion of the cipher.
  • Being able to now walk through each individual step of the encryption algorithm, even though we didn’t know what it did, we knew something about it at the end of every clock cycle. [queue animation] The next inconsistancy was that we found out the actual number of clocks was 200, rather than 400.
  • Next we performed a little statistical test, to get some more information about the cipher. The goal of the test was to determine if certain bits in the challenge or key had a heavier affect on the 2-bit output after one clock cycle. Our test had some bizzarre results. The last two bits always affected the output. This led us to believe that the cipher was in fact something known in the cryptography world as a fiestel cipher.
  • And we determined that the last two bits of the challenge registers are combined mathematically with the outputs of the last f-box before being added back into the challenge registers. [queue animation] We still had no idea what the routing networks were. Meaning which bits of each challenge and key register went into each f-box, and then which f-box outputs went into each second layer f-box, and finally which second layer f-box outputs went into the last f-box. [queue animation] We also had no idea what the f-boxes did themselves when given the different inputs.
  • In any case, we developed and used some methods for figuring this all out, and they're described in detail in our paper online. After running our tests, we were first able to discover which bits of the challenge affected which second layer f-box. [queue animation] Then we noticed that the pattern was kind of uniform, so it was easy to guess the remainder. [queue animations] And we guessed and then tested that the key bits had the same affect. [queue animation]
  • Then we continued and guessed which bits affected which f-box, this test takes a few days to run in entirety, but again it was pretty uniform, [queue animation] after we had found one, and it is very quick to guess and verify a correct route if you've got it right.
  • So now all that was left was determining the tables that each of these f-boxes represent. One by one we went through, and tried all the possible inputs to each one, and just recorded the outputs that came out of the last f-box, and we were able to map out each one of them. [queue animation]
  • First lets verify that we’ve got it right… We code up the algorithm, and program a chip and our algorithm with some secret passcode, then we give both of them challenges and verify that the responses are the same. Ok, that works. Lets recover the secret 40-bit encryption key off of the chip, the secret passcode. If we've got the secret passcode, we can impersonate a chip! The cipher is very weak, utilizing only a 40-bit key. Now, 40-bit is a huge number, a little over a trillion, but not too huge in the world of computers. This means that an attacker could guess every possible key in some short amount of time, and have recovered the key when he finds the one that works. This is known as a brute-force attack. In cryptography, brute-force is kind of boring, it is more interesting to find mathematical weaknesses, or problems with the cipher itself that allow you to recover the secret key without having to guess all possibilites. Still, there is no need to find a mathematical weakness because you can just guess the key rather quickly. In the end, we did find some weaknesses however, but they are besides the point.
  • So we started doing some thinking about how fast we could actually guess the secret key on a chip using brute force. This requires getting a hold of 2 challenge/response pairs in order to fully recover the key. This can be done in just two messages to a RFID chip in someones pocket, and you can do about 8 per second. Desktop computers aren't remarkably fast compared to special hardware designed for the sole purpose of some operation. We can perform about 200k encryptions/second on a Pentium IV, meaning it would take about 31 days on average to guess the correct key. Lucky for us, there are circuit boards you can buy to perform software operations, they are relatively cheap and very very fast, and very easy to use. We can perform about 16 million encryptions/second on a $200 FPGA device, meaning it would take about 9 hours on average.
  • There is a quick and easy speedup for this if you want to spend more money. The more money you spend, the faster you can get this to work. We bought 16 FPGAs for $3200 and had each of them searching a subset of all the possible keys. This way we are 16 times faster. We could now recover secret key information in about 35 minutes. Since it comes down to more money equals faster, you can just keep buying more and getting faster results. For example, if you spent the amount of a $32,000 car, you can make your money back by stealing just one, and it should take on averate 3.5 minutes, worst case it should take 7 minutes.
  • Another solution for the car stealing entrepreneur, may be to build a huge lookup table, it is pretty expensive overall, but it is fast. First you buy a big storage computer, with about 5 terabytes of data ($10-15k), and record the encryption of a challenge using all 40-bit keys. Then, the attacker can send that challenge to a chip, get the response and look up in the table what key was used to encrypt it. This solution is kind of expensive, but its a one-time deal. Imagine something like this connected to the internet. Now, any theif around the world can get a response from a victim and can lookup the the secret passcode online. Still, stealing a single new Ford Expedition could pay for the whole system.
  • The most scientific way to do it. Is to use what is known as a time-memory tradeoff to speed things up. It combines the speed of using a lookup table in a computer (should only require about 9 GB in the case of these chips) and the speed of an FPGA. It is inexpensive, and portable. It should be able to recover a secret passcode on the order of a few seconds.
  • After building some equipment to recover the secret keys in the lab, we came up with some scenarios and tests to show that this could happen in the real world. Our first test was to see if we could covertly scan a victim. I’ll play this video. Inside the laptop is a TI evaluation kit reader and antenna, some custome software we wrote on the laptop, and a 9volt battery to power the reader. All we had to do was come within a few inches of victim, and within < 1 sec, enough data is aquired to then crack the secret key. We were actually pretty surpised how easy this snooping was.
  • The next step is to take the information we got to our lab. Or in a real world situation, connect to our equipment over the internet, or call in the information. Down the line, if we were to build the time-memory tradeoff device, we could actually do this out in the field. The cracker goes at it for a while, and eventually the code is recovered.
  • The next step is to build (or already have built) something that can respond to a reader as a chip, and take it to a gas station and buy gas, and then use it to start a car. Our version that we built is a big, bulky, prototype to get started with. We used a computer we already had ($1000), with a data aquisition board ($1000), and a uninterruptable power supply ($300) to make it portable, and some parts from our evaluation kit. Installed custom software to listen for challenges, transform them using the recovered secret key, and return responses, all using radio waves. It should be noted that this thing we built was only a prototype, and was easier for us to use in our experiments because we were experimenting in uncharted waters, and we can still use the equipment for other tasks. Emulating a transponder by no means requires this equipment. A chip itself is capable of doing it, and that fits in a car key. In fact, TI keeps arguing that our whole attack is impractical, because of this one fact that we didn’t actually build a portable device. Almost as if they are challenging us to do it. My response would be that there really isn’t any scientific research involved in building one of these devices, and its only purpose is to commit a crime anyway. We aren’t trying to enable criminals when we don’t have to. And if they’re really like us to, we can get an eager undergrad at our institute to build one as a project or something, and post the schematics and part list to the internet as proof… but I don’t think they’d actually want us to do that.
  • We’re not really electrical engineers, so this is the device I would build. It has a circuit for computing encryption (you can use an FPGA $200) and circuit for recieving and generating radio signals (you can use an FPAA $200). Still, these devices are easy to use for someone like me, a computer scientist, but someone else of average experience could build one of these things rather easily for probably < $100. We havne't built these ourselves, but we have spec-ed them out and designed some circuits.
  • So now here are some videos of us out in the field actually buying gas without a speedpass present, and starting a car with a metallic copy of the key.
  • To reiterate the importance and damage of the attack, here is another example of how to do it. An attacker builds, purchases or otherwise aquires a magic device, that allows him to do the following: copy the ID data off of a car key chip when within a couple feet of a victim, and replay that ID data to any reader that asks for it. He can put it inside of a briefcase, schoolbag, shopping bag, coat pocket, etc… so that it can’t be seen. The attacker then watches someone get out of their new SUV and he wants to steal it. He then walks past the victim and his magic device says "what is your ID" and the chip in the key responds "My ID is X". Then the theif waits as the person walks away, breaks into the car, hot-wires the car, and when the reader in the new SUV says "What is your ID", the magic device says "My ID is X". The immobilizer system is bypassed and the car starts, the theif drives away. These devices can be built. There are commercial devices to do almost exaclty this, but I don't know of any commercial products that do it and are also portable, they may or may not exist. Building these devices is not hard, it takes a little bit of electrical engineering knowledge (to build a circuit board), and a little bit of radio frequency knowledge (to communicate as a chip or reader), and you can build one of these devices that is about the size of an iPod. The knowledge to do so is not elite by any means, in fact a college student or even a bright high schooler could design a circuit like this and build one. So now you’re thinking, yeah so what, car thieves are high-school drop outs, they don’t have this knowledge. Well, once a design is made, which is really the hardest part, anybody with a little experience can build one. And, all it takes is one person to repeatedly build these devices, and many many car theifs to use them over and over again. So, in the end, the magic box is a realistic device, mainly because there is no good security used between RFID chip and reader.
  • So, what is the damage that can be done if THIS RFID system is broken, and RFID chips can be copied? We know in the case of a car immobilizer, it is pretty bad if you’re giving your key out to people like valets, mechanics or known car thieves, but still, a car thief needs to have targetted you to be able to steal your car. If they haven’t had access to you, they can’t steal your car, and if they don’t have access to your car, it doesn’t matter if they swipe your code. Speedpass is a little more vulnerable though, you don’t need to know anything about the person to fraudulently make charges to their credit card. A criminal can walk around a mall or conference center or hotel lobby with his briefcase snagging peoples speedpass codes. He can then use any code he gets (potentially many of them) and use them at any gas station! Now, I should mention that ExxonMobile says that it has back-end fraud protection mechanisms in place, but aren’t willing to comment on them. That is fair enough. One such measure is to restirct purchases on an individuals speedpass to 2 / day. Another that they’re starting to do at some locations is request your billing address zipcode. This provides some extra protection as well, but then you’re wrecking the ease of use factor, and not all of the stations do this. Then there may be some other fraud detectio mechanisms that are probably pretty easy to create, such as don’t allow me to use my speedpass in CA and MD on the same day, or at least raise a flag. Still, at this time, if you can copy speedpasses fraud can be committed on an individual basis or potentially on a wide-scale.
  • Transcript

    • 1. Attacking and Defending RFID Systems Matthew Green Johns Hopkins University
    • 2. Who am I?
      • Ph. D. student, Johns Hopkins University Information Security Institute
        • Advisor: Dr. Avi Rubin
      • Work funded, conducted jointly with RSA Laboratories
        • Dr. Ari Juels, Michael Szydlo
      • Fellow Students
        • Stephen Bono, Adam Stubblefield
    • 3.
      • RFID Tags: Introduction and Background
      • General security/privacy threats
      • Examination of fielded systems:
        • E-ZPass
        • TI DST-40 (Speedpass, Immobilizer)
      Overview
    • 4. Radio Frequency Identification
      • Limited computing device
        • Identification, data storage, cryptography
      • Contactless: Integrated RF transceiver
        • Communicates with RFID reader
        • Range: <1cm to 0.5km
    • 5. Radio Frequency Identification
      • Basic RFID simply broadcast an ID
        • Simple, short/medium range RF protocol
        • May include collision detection
      Activate ID=“0987654”
    • 6. Active vs. Passive Tags
      • Active tags contain internal power
        • Long scan range, greater capabilities
        • Larger form factor, higher cost
        • Limited battery life
      Request ID=“0987654”
    • 7. Active vs. Passive Tags
      • Passive tags receive power from reader
        • Small, low cost
        • Shorter read range (several feet max)
        • Tag capabilities limited by available power
      Power ID=“0987654”
    • 8. Low-Cost RFID Tags
      • “ RF Barcode”:
        • Tag contains fixed serial number
        • No line-of-sight, scan many items
      • Severely limited devices
        • Cost is dominating factor
        • $.50 to <$.05 goal cost
        • Dominates Moore’s law
        • Security by obscurity or physical limitations
    • 9.
      • Higher cost range, more capability
        • Up to $5 per transponder
        • Cryptography, challenge-response
      • Applications
        • Access control/Theft deterrence
        • Electronic Payment and Toll Collection
      Wireless Authentication Devices
    • 10. Challenge/Response Authentication
      • Authentication using cryptography
        • Secret never broadcast over the air
        • Challenge is always different
      (Power), Challenge: 8394839 Response: 3434323 Encryption algorithm, SECRET KEY Encryption Algorithm, SECRET
    • 11. Capabilities and Applications Tag Capabilities Identification + Data storage (R/W) Symmetric crypto (challenge response) Public key crypto (challenge response) Retail, supply-chain Applications Electronic payment Building/facility access control Vehicle Immobilizers High-security e-payment Advanced features, privacy Increasing Cost, Size & Power Consumption
    • 12.
      • Tag capabilities don’t always match the application
      • Identification-only tags used for security applications, e.g.,:
        • Building access control (prox cards)
        • Vehicle immobilizers
      But in the Real World…
    • 13. Defeating simple Immobilizers
      • Immobilizer System
      ID Number ID Number Many (older) designs use simple RFID chips QUERY? ID Number
    • 14. Defeating simple Immobilizers
      • How to clone a key:
        • Scan target key, get ID number.
      Query? ID Number
    • 15. Defeating simple Immobilizers
      • How to clone a key:
        • Scan target’s key, get ID number.
        • Replay response to vehicle.
      QUERY? Cloned ID
    • 16. Our Work
    • 17. Our Questions
      • Are RFID systems being deployed securely?
        • Are “secure” technologies secure?
        • Practical attacks?
      • Why we’re asking them
        • If we don’t ask, who will?
    • 18. The Process
      • Examine widely-deployed platforms
      • Reverse-engineer devices/protocols
        • Overcome physical reader limitations
        • Study cloning and tracking
        • Other attacks on protocol or device
    • 19. Our Targets
      • EZ-Pass
      • ExxonMobil Speedpass (TI DST)
    • 20.
      • High-speed toll collection
        • Widely deployed
        • Real $$
        • Large read distance
        • Reader, protocol not available to the public
      E-ZPass
    • 21. The E-ZPass System
      • Tags interrogated by fixed readers
        • Signal read at highway speeds
        • Deliberately limited range within booths, but can (possibly) extend to 100+ ft
    • 22. E-ZPass Transponder
      • Active (powered) transponder
        • Frequency of Operation: 915/914MHz
        • Data transmit rate: 300-500Kbps
    • 23. Anatomy of an E-ZPass Transmitter Antenna Control Chip Battery Receiver Receive Filters Transmit Filters
    • 24. Determining the Protocol
      • Bad news : Tags don’t do anything until they’re activated.
      • Good news : We have tags, a car, and plenty of toll-booths!
    • 25. Software Radio Approach
      • Snoop the toll-booth protocol using software and commodity PC hardware
      Antenna Transverter (~900MHz -> ~40MHz) Software-tunable Radio (0-60MHz) -> (<20Mhz) ADC Board E-ZPass Reader ~900MHz RF Transaction
    • 26. Franken-Pass Shortcut
      • Tag already has antenna and transceiver equipment, so let’s use it
      ADC Board E-ZPass Reader
    • 27. Franken-Pass Tx/Rx Lines PC E-ZPass Reader
    • 28. Field Test #1
      • Location: Fort McHenry Tunnel Toll booths, Baltimore Harbor
    • 29. Field Test #1
      • Equipment list:
        • Modified M-Tag
        • PCI-DAS4020 DAC Card
        • Shuttle XPC SG85
    • 30. The EZ-Pass Protocol
      • Stage 1:
      20 μ sec activation pulse
    • 31. The EZ-Pass Protocol
      • Stage 2:
      20 μ sec activation pulse 516 μ sec response (256 bits + CRC?) Manchester Encoded
    • 32. The EZ-Pass Protocol
      • Stage 3:
      20 μ sec activation pulse 516 μ sec response (256 bits + CRC) OPTIONAL 256-bit write phase …?
    • 33. Attacking EZ-Pass
      • Plenty of power, plenty of read range… … but no security in the tag
        • Toll booth cameras
      • No protection against tracking
        • Anyone can activate the tag, potentially track hundreds of cars
        • Not so useful for us, though: FCC regs limit activation power
        • Doesn’t affect “eavesdropping”
    • 34. Texas Instruments DST
      • Vehicle Immobilizers
      ExxonMobil Speedpass
    • 35. Texas Instruments DST
      • Operating Frequency: 134 KHz
      • Power: Passive
      • Read range: ~1ft
      • Security : challenge/response protocol
        • 40-bit challenge, 40-bit key, 24-bit response
    • 36. DST Immobilizers
      • Challenge/Response Immobilizer System
      40-bit Key Uses random challenge and cryptography 40-bit Key Challenge=X Response=Y
    • 37. DST-40 Operation DST-40 40-bit Challenge 24-bit Serial, (Truncated) 24-bit Response Challenge, Key Tag’s Response compare 40-bit Challenge, 40-bit Key 40-bit Response Reader = Encryption Algorithm
    • 38. What is ?
      • TI Proprietary block cipher
        • Available by NDA only
      • Even with good cipher, 40-bit key is a major weakness
        • Brute force guessing
        • Full precomputed key table ~5TB
    • 39. DST Immobilizers
      • Defeating a DST Immobilizer
        • Get response from original key.
      Challenge=X Response=Y
    • 40. DST Immobilizers
      • Defeating a DST Immobilizer
        • Get response from original key.
        • Recover secret key.
    • 41. Security Analysis
      • Getting Started
      • Purchase TI micro-reader evaluation kit ($400).
        • Reader, antenna.
        • Publicly available.
      • Write a better interface.
        • Makes analysis easier.
    • 42. Security Analysis
      • Bad security feature
        • Uses a secret value to create CRC.
        • All transponders share the same secret value.
        • Guessed secret value with computer in < 1 ms.
      Data (S/N, etc…) CRC Transponder Reader General Read Key (40-bit) CRC Program Passcode
    • 43. Security Analysis Initial Experiments Secret code 0x0000000000 Challenge 0x0000000000 0x2222222222 0x5555555555 0x7777777777 0x8888888888 0xAAAAAAAAAA 0xDDDDDDDDDD 0xFFFFFFFFFF Response 0x000000 0x222222 0x555555 0x777777 0x888888 0xAAAAAA 0xDDDDDD 0xFFFFFF
    • 44. Security Analysis Initial Experiments Secret code 0x0000000000 Challenge 0xFFFFFFFFFF 0xFFFFFFFFFD 0xFFFFFFFDFF 0xFFFFFDFFFF 0xFFFDFFFFFF 0xFDFFFFFFFF Response 0xFFFFFF 0xFFFFFF 0xFFFFFF 0xFFFFFD 0xFFFDFF 0xFDFFFF
    • 45. Security Analysis Initial Experiments Secret code 0x0000000000 Challenge 0xFFFFFFFFFF 0xFFFFFFFFFD 0xFFFFFFFDFF 0xFFFFFDFFFF 0xFFFDFFFFFF 0xFDFFFFFFFF Response 0xFFFFFF FFFF 0xFFFFFF FFFD 0xFFFFFF FDFF 0xFFFFFD FFFF 0xFFFDFF FFFF 0xFDFFFF FFFF
    • 46.  
    • 47. Walking Backwards challenge signature Known initial 40-bit challenge Known 24-bit signature 400 shifts later...
    • 48. Walking Backwards challenge shifted chal signature shifted sig Guess next challenge See if it yields next signature Repeat...
    • 49.  
    • 50.  
    • 51. 200
    • 52. Single round output tests
    • 53. ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
    • 54. ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
    • 55. ? ? ?
    • 56. ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
    • 57. Security Analysis
      • We have the cipher, what now?
      • Make a software version.
      • Guess a secret key
        • 40-bit secret keys are not very strong
          • 1,099,511,627,776 possible secrets.
        • Brute-force attack
          • Send a Speedpass a challenge, record the response.
          • Encrypt challenge with all possible secrets.
          • Find which one produces the correct response.
    • 58. Security Analysis
      • How fast can you guess?
        • Software is slow
          • 200,000 encryptions / sec.
          • On average, takes 31 days.
        • Hardware is fast
          • Commercially available FPGA ($200).
          • 16 million encryptions / sec.
          • On average, takes 9 hours.
    • 59. Security Analysis
      • How fast can you guess?
        • More FPGAs
          • 16 x 16 million encryptions / sec.
          • On average, takes 35 minutes.
          • More $$$ = Faster
    • 60. Security Analysis
      • How fast can you guess?
        • Huge storage table
          • RAID array storage system.
          • 5,000 Gigabytes.
          • Expensive ($10-15k).
          • On average, takes < 1 s.
    • 61. Security Analysis
      • How fast can you guess?
        • Time/Memory Tradeoff
          • Best of both worlds.
          • Inexpensive (<$1000).
          • On average, takes < 1 minute.
          • Very portable.
      +
    • 62. Real World Testing Scanning a Victim ( http://rfidanalysis.org) Equipment: TI evaluation kit, laptop
    • 63. Real World Testing
      • Extracting the secret passcodes
        • 16 FPGAs, average time 35 min.
        • Cracked Speedpasses and Immobilizer chips.
    • 64. “ The Mobilizer” Emulating a real transponder Big, Bulky Prototype. Small PC ($1000). DAC Board ($1000). UPS ($300). Eval kit antenna ($50). Custom software (Free).
    • 65. Real World Testing Emulating a real transponder A 1 st Generation Device (not actually built). FPAA ($200). FPGA ($200). Homemade Antenna ($0). +
    • 66. Real World Testing Field Tests: (http://rfidanalysis.org)
    • 67. More practical attacks
      • Making this easier.
        • A device that does everything for you...
      Recover ID Transmit ID
    • 68. Speedpass Making this easier. Copied tag can be used anywhere. Charges directly to victim’s credit card.
    • 69. Fixing the problem
      • Immediate Fixes
        • Very few
        • Systems too widely deployed for simple upgrade.
        • Tin foil works.
        • Diligence on the part of the consumer.
    • 70. Fixing the problem
      • Long term Fixes
        • Use standard encryption algorithms.
          • AES, HMAC-SHA1, 3DES
          • No security through obscurity.
        • No single-tag compromise should compromise the whole system.
          • As with the secret checksum values.
        • Use longer key lengths.
          • If that is not possible, understand this limitation!
    • 71. Conclusions
      • Widely deployed systems offer no, or limited security
        • Solutions on the way, however
      • Privacy protection (tracking) not considered
      • Attacks are practical-- RF interface can’t even stop computer scientists!
    • 72. The Paper
      • S. Bono, M. Green, A. Stubblefield, A. Rubin, A. Juels, M. Szydlo. “Analysis of a Cryptographically-Enabled RFID Device”, Usenix Security 2005:
        • http://rfidanalysis.org
    • 73.  
    • 74. The DST+ (or “How not to fix the problem”)
      • Mutual Authentication
        • Make the reader authenticate itself to the tag
        • Stops attackers from gathering challenge/responses (in theory)
        • Prevents tracking attacks
      • Double Encryption (two separate keys)
        • Encrypting twice must be twice as good
    • 75. Problems with these approaches
      • Mutual Authentication
        • Another source of plaintext/ciphertext pairs, from the reader
          • Might actually enable key recovery WITHOUT access to a tag
        • May require that many tags share a key-- one compromised key defeats system
      • Double Encryption
        • Meet in the middle attacks

    ×