Practical Cellphone Spying
Slides (OpenOffice) from my Defcon talk – hopefully video will be coming soon as well.
A few notes about the demo and results.
Firstly, power output. I was transmitting a total of 25 milliwatts – for a point of comparison that’s about as much power as a typical LED while a small flashlight consumes over a hundred times more. My antennas have 13dBi forward gain, giving me an EIRP of half a watt. That’s really not much power at all; I’ve heard from several people that the signal couldn’t be picked up at the back of the room. This was deliberate – I kept the effective range as small as possible to limit the chance of catching a cellphone whose owner hadn’t been informed about the demo. I suspect that many, many more handsets would have connected if I’d used even marginally more power.
During the talk at least 30 handsets connected to my tower; there were probably many more than this but the logs were all destroyed on-stage (I broke the USB key into several pieces – last I heard Agent X had the remains). Logged data included IMSI, IMEI, all numbers that were dialed, and of course audio recordings of all calls made (a total of 17 calls were connected during the talk). I don’t know how many calls were attempted; it’s possible that many more people may have heard the warning and hung up before Asterisk tried to connect the call. I’ve not heard from anyone that they saw any kind of warning on their handsets despite the lack of encryption on my network.
A couple of defenses: AT&T apparently have a service offering voice & SMS encryption, I can’t find much more info on it and it’s reportedly only available to business and government users. I’d very much like to see it deployed more widely; it’s a good approach to the security problems in GSM (assuming it works as stated). Blackberry is another good option – they add a second layer of crypto for data (not sure if it adds anything for voice) and I’ve been told they have a setting to disable 2G. This is a Very Good Thing; I’d love to see someone add this setting to Android as well if it’s at all possible. In the medium to long term GSM simply needs to be turned off; it’d be more work to fix it than it would be to upgrade (given that 3G/3.5G/3.9G/4G are all available, are being deployed now, and offer far superior security).
Some points about the legal shenanigans that surrounded this talk. I never heard first-hand that AT&T were planning to sue; the rumour certainly came to me from a credible source (meaning I had to take it seriously) but I’m very glad it turned out to be incorrect. I’d like to thank the FCC for taking the time to talk to me on such short notice; while it certainly would have been nice if they had expressed any kind of opinion about the demo I at least appreciated the opportunity to hear their concerns about the talk and explain the mitigations that had been put in place. Talking to the feds in advance of such a big event is always a great option, and I was glad to have the opportunity to do so here.
Finally, I’d like to say a really big thankyou to the EFF; without their assistance the talk would not have gone ahead (the demo certainly wouldn’t have). If you want to see more work like mine at more venues like Defcon, go ahead and donate. They’re worth it 
//edit: I also owe a big thankyou to the Goons (many of whom aren’t actually listed on that page). They did an absolutely superb job with helping me lug all my gear around, find places to set up and people to assist, and generally making everything go. Ply them with alcohol at every possible opportunity – they put in an amazing amount of effort at Defcon and really don’t get to enjoy the show much. Thanks, guys
Extreme-Range RFID
Now that I’ve given the first of my Vegas talks I wanted to post everything online for anyone who couldn’t attend in person.
Slides are here (OpenOffice format)
Whitepaper is here (PDF)
ID-Me
217 feet is the range I set; I believe that’s a world record (beating both the 69 feet from Flexilis at Defcon 13 and the 65 meters claimed by ThingMagic in a Google Tech Talk). My equipment is capable of far more but I hit the limit of my range; a chainlink fence a few hundred yards away was reflecting the RF power, meaning that more power led to greater interference and hence lower range. That 217 feet used just 10W of RF power; my current amp is rated at 70W and will probably deliver a hundred watts if it’s cranked right up – it should be plenty capable of 500+ feet reads.
I’m keen to demo this in-person while in Vegas; the demos at the talk are always constrained by the room (again, reflections from the chairs, the people, and the back wall of the room) so if someone can come up with a suitable place to test I’m happy to demo multi-hundred-feet reads. I suspect that the top of a building would be ideal; reflections from the ground should be directed outward and not pose a problem (it’s also worth noting that the commercial reader I started with has a lot less problem with reflections, however it’s not legal to just amplify the signal directly for reasons I discuss in the talk).
If anyone has ideas on how to set this up please get in touch; if all else fails I’ll try to get the folks from Guinness World Records to officially certify the read range, and/or set up a demo for press back in California at a later date.
Additionally I’m going to run an RFID read range competition at Defcon next year (details to come at Defcon). I had a huge amount of fun playing with this stuff, I learned a lot, and can think of about a thousand ways to improve on my own record. Think you can do better? Do it – and bring the results to Defcon next year!
Defcon update
Unfortunately, I’ve heard that AT&T may be considering suing me to stop my talk. I can’t understand why this would be the case, and I hope that if it’s true, they will contact me first to discuss their concerns.
Let me clarify some things about my talk. First, I’m not doing anything to AT&T’s or any other network. I’m just going to do a demonstration of my attack. It will not affect the 911 service. Nor will it interfere with anyone’s ability to call 911 unless you’re both in (or near) the demonstration room and also have a GSM phone. The demo will not affect people on Sprint or Verizon or any CDMA network. If you’re nowhere near the Riviera you won’t be affected.
So if you’re in the room, need to dial 911 and you have a GSM phone you can just raise your hand and shout. In the extremely unlikely situation that someone near the room with a GSM phone connects to my demo network and also needs to dial 911, I am taking the extra precaution of ensuring that that person will be connected to someone local who can call for or send help.
I wanted to be clear that the EFF haven’t just given me carte blanche here. I doubt they’ll ever say “Intercepting cellphone calls is perfectly fine as long as you do X Y and Z” – what I’ve done with their help is try to work out a way to minimize any legal risk associated with the demo, and to do it safely, so that I can show people an important problem with GSM. I wouldn’t say I have EFF’s “stamp of approval” on the demo, but they’ve certainly offered plenty of helpful advice and I’ve been trying to take all of it.
The EFF have also asked not to be involved in the data destruction. I’m open to suggestions for a trusted third-party to either destroy the logs generated during my demonstration or verify that they’re wiped.
Hopefully that’ll explain my talk to anyone with safety concerns and head off any unnecessary and unfortunate legal actions. I’m open to talking further with AT&T or anyone about this. Here’s hoping for no major hiccups…
Privacy concerns at Defcon
I’m planning to give a pretty spectacular demonstration of cellphone insecurity at Defcon, where I will intercept the cellular phone calls of the audience without any action required on their part. As you can imagine, intercepting cellphone calls is a Very Big Deal so I wanted to announce at least some of the plan to reassure everyone of their privacy.
First and foremost – I’m not just making this stuff up. I know when to get advice from a good lawyer, and in this case I’m taking the advice of the very best there is: the EFF. They’ve been kind enough to offer their help and I’m taking it – this is what we’ve worked out.
1. If you’re in an area where your cellphone calls might be intercepted, there will be prominent warning signs about the demo including the time and date as well as a URL for more info. This will be the only time when unknown handsets will be allowed to connect; at all other times only pre-registered handsets will be granted access. You will be clearly warned that by using your cellphone during the demo you are consenting to the interception, and that you should turn your cellphone off during that time if you do not consent. A recorded message with essentially the same info will also be played whenever a call is made from the demo network.
2. The demo itself will be performed from a machine with no hard drive, only a USB key for local storage. At the end of the demo this USB key (including all logs, recordings, and other data) will be handed over to the EFF for destruction. No logs, recordings or other data will be exported from the machine except as necessary to connect calls during operation.
3. Transmit power will be kept to a maximum of 250mW (for comparison, a handset is typically 2W) and will comply with all relevant FCC regulations to operate in the band.
4. At all times, for all connected handsets, a best-effort will be made to connect calls successfully to their destination. It is unlikely that any 911 service can be provided, however a best effort will be made to connect any emergency calls to a suitable local destination.
Also, to be clear, my demonstration should not affect handsets on Verizon or Sprint in any way. The technology I’m working with is GSM and these are not GSM networks; if your handset is not capable of GSM (it must have a SIM card) then it will not possible for your calls to be intercepted by my equipment. That said, I invite all of my attendees to bring a GSM cellphone with them and participate – the more the merrier!
Illegally detained by Costco
I’ve never been a fan of “bag-checkers” at store exits – I value the rights that the 4th amendment gives me and I object to waiting in line to be searched like a criminal. So, when leaving the Costco in Mountain View today I ignored the queue for the search squad and walked straight out the door, with my usual “no thanks” as I left. It’s the same approach I’ve adopted at all stores that try to execute searches; it usually serves me well.
In this case though, I was set upon by 3 employees (eventually including the manager, a chap named German) who grabbed hold of my cart and refused to let me leave until they had seen not only my receipt and the contents of my cart, but also wanted to see inside my handbag (which was in the cart). Nuh-uh, no way, not gonna happen – I was told that it was store policy to “check receipts to ensure that I hadn’t been charged twice for anything” and everyone insisted that it had nothing to do with theft prevention. This despite the manager stating clearly that if he had noticed a DVD in my purse while “checking my receipt” he would have assumed it was stolen and acted accordingly.
After 20 minutes of arguing back and forth with them (during which time I wasn’t allowed to leave, just stand out the front of the store), I eventually gave up and tried to show him my receipt (since he claimed to no longer care about the contents of my bag); he then tried to argue that he didn’t care about my receipt either and that I had been free to leave the whole time. I didn’t need to be told twice so I started walking towards my car; I got as far as unloading the cart into my trunk before the police showed up.
I don’t know if it’s just Mountain View PD or all cops, but this guy really wasn’t happy when I declined to show him my ID or give him my name. I tried to explain that I had declined the search initially but later had offered both the receipts and the trolley contents, and the whole time I had just been trying to leave – by this time the manager and I were both rather riled up, and leaving seemed the most sensible way to defuse things. Again though, the manager claimed he had never detained me and that I had been free to leave the whole time, despite the security guard grabbing my cart (as provable by the security cameras outside the store, if you believe it’s possible to ever get hold of the footage). The cop had spent the walk over to my car being talked at by the store manager and was further irritated by my refusal to show ID, so started raising his voice as well – I got to listen to two more lectures (one from the cop and another from the manager) about “store policies”, despite my repeatedly stated wish to just leave with the goods I paid for. The manager kept saying I was free to leave, I kept saying that I wanted to leave, and the cop kept demanding that I stay put and listen to it all over again.
So here it is. According to the store manager, “company policy” states that you are required to show your receipt upon leaving the store. I’m no lawyer but the law here is pretty clear – Stores are not allowed to search you or your personal belongings when you leave – they are also not allowed to detain you for refusing the search. In my case they only grabbed the trolley, not me – the latter would probably constitute assault if you really wanted to press the issue. If you value your civil rights I recommend taking a large bag with you if you’re forced to shop at Costco. Place your goods in the bag at the till and just walk out the door – they are not allowed to look in your bag unless you let them, and they’re not allowed to detain you if you choose not to let them look. You’re also not required to show ID if they call the cops – police cannot compel you to show ID unless they have probable cause to believe a crime was committed, and refusing a search doesn’t give them the probable cause they need.
Could I have handled it more calmly? Yeah, dropping the F-bomb in front of an irritated cop probably wasn’t the best idea. Is it possible the store manager wasn’t actually told that I was prevented from leaving? Maybe – it’s possible he thought I just wanted to hang out for a half-hour arguing with people. Did anyone in this situation (even the cops) have the right to search my bag, stop me from leaving, or produce ID? No, they did not.
Know your rights, people – don’t stand for this crap. Sure it’s only Costco, but it’s conditioning people to just blindly accept the erosion of their civil rights, and that’s simply wrong. The 4th amendment is a beautiful thing – in my opinion it’s worth the half-hour of hassle to defend it.
//edit: jandrick pointed out that on page 29 of the costco membership agreement there’s a pretty-much unconditional consent to search. Well I guess I’m breaking that rule – if it’s enough of a problem then Costco can feel free to revoke my membership for doing so. However, they still can’t detain me unless they actually see me commit a crime, and refusing a search (while a possible breach of the member agreement) is not a crime.
AT&T do it right
In an article at the Wall Street Journal about the iPad ICCID breach, AT&T CEO Randall Stephenson said that they will give a new SIM card to anyone who asks. This is absolutely the right thing to do – kudos is due to both Mr Stephenson and to AT&T for their response here. Thankyou – you just gained a fan.
Here’s the thing. When Adobe or Microsoft or Mozilla or any other software company suffers a security problem, the solution to it is a patch. It may take a while to develop and test that patch, and it may require immense bandwidth to deliver that patch, but the cost to deploy that patch is essentially the same no matter how many people were affected. Develop the patch once and it doesn’t matter whether you deliver it to a hundred people or a million people – the cost is essentially the same.
Compare that to the breach of SIM card information, as was the case with AT&T. A SIM card is hardware – it’s an actual thing, with real tangible costs associated with that. Once AT&T figured out how they were going to “patch” (or in this case, how to allow their subscribers to change their IMSIs – no trivial matter) there’s then a non-zero cost per user. A ball-park guess would be $5 for the SIM itself (the physical chip plus the cost of provisioning it in the backend), plus another $5 to cover packaging materials, postage costs, and the inevitable tech-support calls when things don’t go right at the consumers end. $10 per SIM multiplied by 114000 users and you’re at $1.1M to “patch” this vulnerability – I’d wager that’s more expensive than any patch developed by any software company, ever (although fairly small compared to security breaches).
Did AT&T bring this on themselves by associating the ICCID and IMSI like this in the first place? Yes they did, but then so does every other US cellular operator (although it’s apparently rare in Europe) – AT&T were just unlucky enough to get caught out first. They also did this probably 20 years ago or more, and it might even have been a reasonable decision at the time – I really can’t fault them for designing their network this way, although I would argue that it’s long past time to fix it.
The important point here is that AT&T have set a precedent: if your IMSI is compromised by an attacker, you’re entitled to a new SIM card. Fortunately for AT&T (this time) the SIM card is easy to replace on an iPad, but there’s many other devices that aren’t so easy. iPhones are the obvious first mention, but what about all the embedded systems that use GSM for backhaul? Burglar alarm panels, ebook readers, point-of-sale systems – many of these have deliberately inaccessible SIM cards. If these IMSIs were compromised it could require a service engineer to dismantle each device in person to replace the SIM cards, costing hundreds of dollars per subscriber. That gets expensive really quickly.
So again, thank you AT&T and thank you Mr Randall Stephenson. You’ve set an important precedent here, one that will likely end up costing someone a very large sum of money after the next hardware breach. That said, it’s the right thing for the industry and it’s the right thing for your consumers. Good on you.
ICCIDs IMSIs and iPads, Oh My!
A few days ago Apple suffered a security breach – the ICCIDs and email adresses for 114,000 iPad users were hacked, leading to widespread press coverage and speculation. The general consensus seems to be that the ICCID (being the serial number that’s printed onto the SIM card) has no real security consequences to its disclosure, and that the bigger problem is the associated email addresses. The consensus is badly wrong – here’s why.
The ICCID is an identifier for the SIM card, and the SIM card is an identifier for a particular subscriber. GSM has another number to identify a subscriber – it’s called the IMSI, and is generally considered worth protecting. For example, your phone will only ever send out its IMSI when it first starts up – the network will immediately assign the handset a TMSI to replace the IMSI, where the TMSI is a somewhat-random number that bears no direct relationship to the IMSI. The IMSI is a secret, for sure, but not one of the most important ones in GSM (such as Ki).
The ICCID is designed to be non-secret – it’s printed on the outside of the box that your phone came in, and is probably printed on your sales receipt as well. It’s intended that you should be able to figure out what the IMSI is from the ICCID, but only if you have access to the big database that correlates them together (along with a bunch of other information – it’s called the HLR). In theory, disclosure of an ICCID should be useless without access to the HLR, so in theory the masses are correct here.
In practice though, things are a little different. AT&T (as well as T-Mobile and Cingular) made a very bad security decision when they were architecting their networks – their logic was along the lines of the following. In order to translate an ICCID into an IMSI, you need to query the HLR. Not only does that mean giving HLR access to all kinds of places that need to do this (such as retail locations), it also means that there’s more load on the HLR, which is already one of the busier parts of any GSM network. Instead, they figured they could cut out all of that by making the IMSI and ICCID directly correlate – if you know one, you can calculate the other just by understanding how they’re structured and rearranging the digits. This means that the retail locations no longer need HLR access, and they can reduce the load on the HLR by replacing the lookup call with a few lines of C to translate on-the-fly.
I noticed this artifact a little while ago with T-Mobile and hadn’t yet decided what to do with the info – it’s an information disclosure bug at best, and the telco’s don’t tend to have security@ addresses that you can ping the same way you would a software company. I hadn’t even confirmed whether AT&T were vulnerable to the same thing. As it turns out though it’s a known issue – this paper from 2008 describes step-by-step how to calculate the IMSI from an AT&T or T-Mobile ICCID.
So. Now we have 114,000 email addresses and IMSIs leaked. How does that change things? A lot – there’s at least two major attack scenarios that spring to mind.
This presentation on SS7 hackery from Nick DePetrillo and Don Bailey at Source earlier this year describes some of the things you can do if you know someone’s IMSI. Their full name (the unpublished billing name) and the actual phone number are the first things you get, with the ability to track individuals as they roam around the world (down to knowing which tower they’re attached to) and retrieving their voicemail easily obtainable as well (possibly via some clever social trickery).
So now you know who they are, where they are, and maybe their voicemail password – now we get into the active attack scenarios such as IMSI catchers. If we know where they are, all we need is a copy of OpenBootTS that’s configured to look like an AT&T tower, drive to within a couple of miles of their location and we become their cellular network. Every call they make, you get a copy of the audio – you also get a copy of every SMS message they send. Knowing their IMSI makes it a *lot* easier to configure GSM equipment so that they and only they will attach to your fake tower and hand you all of their traffic. I’m actually giving a presentation at Defcon about IMSI catchers and just how effective they are (you just have to spoof a pair of 3-digit numbers and you’re in business); watch for the details to go up here in the next few days.
So yeah, knowing someone’s ICCID can give you their full unpublished billing name, their cellular phone number (and hence their home address), their current location on a realtime basis, their voicemail, and if you’re prepared to follow them around (within a few miles) then you get all their phone calls and SMS messages too.
My recommendations? In the short term, AT&T should replace all 114,000 SIM cards and issue all of these people new cellular identities. In the long term, AT&T and T-Mobile both need to stop translating IMSIs and ICCIDs like this, and opt for either a cryptographic approach (doable) or a more traditional HLR-based approach (better). Leaks like this are going to be happening a whole lot more often; I’d also recommend that the cellular companies start waking up to the fact that they’re now a part of the internet security ecosystem rather than the telecommunications security ecosystem. That’s a big change – it’s going to be an interesting transition.
//edit: iPad is a data-only device, so voice isn’t entirely relevant here. If you have a target device on an IMSI catcher then you are their network so you can also intercept data; I didn’t mention it in the main post because OpenBTS (and therefore OpenBootTS which is based on it) is not data-capable. If you were really desperate there’s places that’ll rent you much more functional GSM gear that’ll happily intercept anything you like if you have a spare $5-10k/month to burn…
//edit2: My friend and colleague Pete Markowsky has posted an excellent blog entry about the exact mechanics of translating an ICCID to an IMSI, and even an online tool that does the translation for you (verified with AT&T SIM cards and OpenBTS). Anyone still want to argue that ICCIDs aren’t a security risk in US cellular networks?
Comcast Business Services
My consulting company just moved into a new office in Redwood City. One of the first tasks for such a move is to establish Internet connectivity; I’ve been reasonably happy with Comcast at home (the occasional glitch but nothing too serious) so I decided to sign up with them again for the office.
I started out in their online chat on Monday, trying to find out why the business plans are so much more expensive than the home plans. After talking to two people in chat and getting no useful answers other than “you have to call this number for businesses, we don’t even have access to the plans”, I called the business folks.
“Mark” from the business sales team was helpful enough although the prices weren’t great – a 22/5 connection is $100/month for a business compared to $53/month for consumer-grade 20/4. I was told that the only major difference between the two is the lack of filtering or bandwidth caps on the business account. The real kicker was the contract – you can get a 1-year contract if you pay a $200 installation fee, 2-year for $100 install, or a 3-year contract for $25 installation, all of which come with a penalty of 75% of the remaining contract fees if you cancel early. So, if you sign a 3-year contract and decide you have a better option in 12 months and want to cancel, it’ll cost you $1800 to get out of the contract. I decided to proceed anyway (on a 1-year contract), and after electronically signing the contract I was told to expect a call back with an installation time the same day.
Monday passed, Tuesday came and went, and eventually I got a call this morning (Wednesday) telling me to expect installation tomorrow. Here’s the thing – I’m planning to use VoIP for all our office calls (we use Asterisk a lot) and that means we need a reliable internet connection. If it takes Comcast 48 hours to get back to me when there’s a sales guy earning commission from the deal, how long is it going to take to get a repair when nobody is getting paid? For a business I can’t afford to take that risk (being without phones or internet for 2 days is a big deal), so I decided to cancel the order and go with another provider (astound.net in this case).
After explaining this to the person who called, I got a call back from Mark just a few minutes later (no surprise that happened quickly), who tried to tell me that he’d confirmed the installation time on Monday. He hadn’t – he’d told me to expect a call on Monday to schedule an installation on probably Wedesday. I’m not sure whether he wrote down incorrect notes or was simply trying to avoid losing his commission, but the end result was a bare-faced lie – I cancelled the order on the spot, whereupon Mark hung up on me.
I’ve had good experiences with Comcast residential services before, so I’m a little surprised that the business side is so different. Excessively high prices (and cancellation penalties that are verging on extortion), slow turnaround times, and outright lies from salesmen – Comcast won’t be getting my business service any time soon. I’ll update once astound.net have done my installation – a 10-minute phone call to their business folks got me an 18/2 connection for $80/month with $100 installation fee on a 12-month contract (they also offer month-to-month for $200 installation), and more importantly they scheduled the installation while I was on the phone. I’ll keep my fingers crossed that the network is as good as their service – the engineer will be coming by on Tuesday.
OpenBTS on Droid
To repeat what I said on Twitter, it’s somewhat pointless but a neat hack nonetheless – running a GSM base station from a CDMA handset. With minimal work it’s possible to get gnuradio and OpenBTS working on the ARMEL architecture used on the Droid, allowing my Droid to act as a base station to which handsets can connect; the Droid then connects calls using an on-board Asterisk server and routes them to the PSTN via SIP over Verizon’s 3G network.
The quick version: I can provide voice and SMS connectivity to local GSM handsets using nothing but a Droid and a USRP.
A quick log of what you’ll need to replicate this. This is from memory so I may have missed something; fortunately there’s an easier way that I’ll come back to.
- Root the Droid and install Sholes Mod.
- Mount your SD card in a desktop machine and create an EXT3 partition. I shrank the FAT32 partition but left it otherwise intact, this is probably a good idea if you want to still take pictures.
- debootstrap into the new ext3 partition, bearing in mind the new architecture (use the two-stage debootstrap with –foreign)
- Put the SD card back in the Droid, and mount the EXT3 partition (you’ll probably need to manually insmod the ext3 and jbd modules)
- “mount -o bind” all of the system filesystems into the mounted EXT3 environment (including /dev, /dev/pts, and /sys)
- Mount usbfs in the mounted filesystem at /proc/bus/usb (if you don’t it won’t find the USRP)
- chroot into the new Debian environment, and debootstrap –second-stage
- Go get dinner – it’ll be a while
- Install all the usual dependancies for building gnuradio (if you can’t figure this out on your own you’re in the wrong place!)
- Configure gnuradio with ./configure –disable-all-components –enable-usrp –enable-omnithread –enable-mblock –enable-pmt
- Patch for 52MHz clock (I highly doubt that Droid can handle the stock 64MHz clock)
- Patch the gnuradio makefiles for ARMEL
- Build gnuradio (again, it’ll be a while)
- Install libosip2-3.3.0 from source (the Debian package is out of date)
- Download and ./configure the openbts source, but don’t build it
- Apply the same makefile patch in Transceiver/ and Transceiver52M/ (or you’ll get the same build error)
- Build OpenBTS
- Install Asterisk (from the debian packages is fine)
- Configure as you wish, then connect the USRP (via a powered hub) in Host mode and have fun!
The easier way that I mentioned before would be for me to just zip up an image of my SD card and slap it on a fileserver somewhere public – I’ll also include some scripts to mount it and start everything up correctly. Give me a few days to clean it up and watch on Twitter for the link, it should be as simple as dropping 2 files on the SD card and then running one of them as root.
I’ll also post video of the Droid connecting a call (that sounds far less cool than it should) at some point, I’m also considering running a workshop on all of this if there’s any interest…?
Credit card “security”
I know I’m supposed to be writing up the OpenBTS thing (it’s coming) but this was a quick thought that I had to get out in the meantime.
I hear a lot of people talking about PCI, discussing whether or not it actually does anything for security, whether it was a move on the part of the card issuers to improve security or simply shift liability, about the strengths and weaknesses of the protections it provides. Almost invariably, these conversations completely miss the far larger issue in credit card security. PCI is nothing but a distraction, a shiny thing to wave in the faces of infosec’ers, execs, and politicians alike, trying to distract them from the bigger issue.
The bigger issue is this – credit cards are broken. The very concept of a “credit card” as it exists today is as fundamentally broken as anything in Infosec has ever been.
Let’s think like infosec professionals for a second here instead of like consumers. Your credit card is a token, one that is used to:
- Prove your identity to the merchant
- Confirm your intent to process a transaction
- Identify your source of funding
We have many protocols that can do all of this and more with a high level of security, it’s trivial to name half a dozen. None of them require you to give your full plaintext credentials to a third-party – although that’s exactly what happens every time you use your credit card. You have to give every merchant a complete list of every bit of information that is required to process transactions against your account – or else they can’t process the transaction. Those credentials remain static for several years, by design being given to several thousand anonymous strangers (known only by their participation in the system) over their lifetime. Multi-year credentials for financial authorization that are, by design, shared with any participant in the system. Does this sound broken yet?
Seriously, why are we still using credit card numbers? Why don’t we have smartcards containing a megabyte of pre-programmed single-use card numbers (that’s a LOT of card numbers!) that we pull up once and throw away? Or some kind of signature algorithm, put a public key on the card and sign the transaction electronically? Or secure tunnels between the card and the processor backend (hell, even between the terminal and the backend)?
Why is it so trivial to spoof our most commonplace payments system when there are such obvious examples of ways to fix it? Why, in short, do we still have credit card fraud?
PCI, no matter what its strengths and weaknesses are, is a band-aid on a festering gangrenous wound. It’s a shiny pink band-aid with a little bit of sparkle to distract us all, but it’s nothing compared to the fundamental brokenness of our credit card infrastructure. We need to stop blaming merchants and consumers for failing to protect a set of data with a process that is inevitably doomed to failure, and instead start blaming the credit card companies for failing to produce a payment vector that is compatible with the security requirements of the 21st century.
We stopped using plaintext protocols for sensitive information decades ago, for good reason. Think about that the next time you swipe your credit card.