Month: August 2012

Reading the US passport with Android– basic access control

Following up on the first part of the post, NFC TagInfo can be used to read the contents of a US passport issued after 2007, after inputting the correct keys. This is done by selecting “Setup keys” option from the menu, then scrolling down to the ePassport/MRTD section. Only three fields are required: the nine-digit passport number, date of birth and expiration date on the passport.

This is part of the basic access control mechanism, intended to limit read access to the document. These three fields can be scanned from the fourth page of the passport, where they are printed in an OCR-friendly font and marked by chevrons. The idea is that access over NFC to the electronically stored data is only possible after having physically scanned one of the interior pages– in other words, no easy pick-pocketing by bumping someone with an NFC reader. (There are several design flaws with BAC, causing it to fall short of that goal, including the predictability of these numbers as well as more subtle cryptographic attacks against the protocol.)

After entering this information, it will be necessary to backtrack and re-scan the passport, as the application will not automatically re-scan with new key set. This time the scan will take a couple of seconds due to the amount of data transferred– the potential maximum 424 Kbps bandwidth for NFC is not even approached doing bulk transfers from the type of chips with limited computing power found in the passports. Afterwards the application will be able to display the encoded data, such as the photograph, as well as additional fields not present in the MRTD data such as issue date and country of birth.

[continued]

CP

Reading the US passport using Android — overview

Seems like it was only yesterday that the privacy community was up in arms about the perceived evils of the new US passport, equipped with RFID chip. There was that confrontation at the 2005 Computers, Freedom & Privacy conference in Seattle between a State Dept representative and Barry Steinhardt of the ACLU on the maximum reading range for RFID passports. From the tin-foil wrapper suggestions (having inspired a cottage industry at this point, also thanks to contactless payments) to Hollywood-esque scenarios of explosives rigged to go off when a particular individual walks by with their RFID passport, conspiracy theories carried the day.

Couple of years later with the new passports having become standard, it is possible to experiment directly with the technology. No special gadgets required: any Android phone with an NFC controller will do. That includes a wide-range of models from the purist “Google experience device” Nexus S to Samsung’s flagship Galaxy S3.

While there are many applications for scanning NFC tags, NFC TagInfo from NFC Research Lab stands out fpr having built-in logic for recogizing the data layout for several common types of cards, including passports.

Tapping the passport against the phone will not automatically bring up the application, as it does not contain any NDEF tags that Android applications typically use to configure auto-launch. Instead we have to start NFC TagInfo and then scan the passport. This will bring up an overview of the tag structure:

This screen already tells us a bunch of things:

1. There is an NFC chip in the passport. Near Field Communication is a type of RFID, operating at the 13.56 Mhz frequency. This is the only type of RFID that Android devices support. The more common RFID transponders such as garage door openers and key-fobs operate at a different frequency and can not be detected by the phone, because its radio does not operate at that frequency.

2. More specifically the NFC tag is an ISO 14443 smart-card, which Android also calls IsoDep technology. This is also how identification cards such as US government PIV card or contactless credit cards appear to the system.

3. “MRTD” stands for Machine Readable Travel Document, a reference to the international standard for encoding information about individuals for use in cross-border travel in a smartcard.

Clicking on that gray button is when things getting interesting, because the application will try– and most likely, fail– to access the contents of that MRTD. It will fail because the cryptographic keys required to access the data are initially missing:

This is where one of the properties of the MRTD protocol comes into play: decrypting contents of the passport requires cryptographic keys, which are derived from information printed on the passport itself. By supplying this information to the Android app, it is possible to get past this error. This is exposed via menu / “set up access keys” option.

[continued in part II]

CP

CVV1, CVV2, CVV3: Demystifying credit card data (1/2)

[This is a series of posts dedicated to describing the card-validation code (CVC) or card-validation value (CVV) for credit cards.]

Swiping a credit card through a magnetic stripe reader is perhaps the most common way of using a plastic card for payments. At the implementation view, involves reading the data encoded in the magnetic stripe on the back. In a pinch when there are no point-of-sale terminals present, getting an imprint of the card by pressing a carbon paper over it will do. When the merchant and card-holder are not in the same place,  the purchase is instead conducted by relaying the card number, expiration date, perhaps the billing address and an additional number printed on the card dubbed CVV2. More fashionable recently are contactless payments, where the card is tapped against a reader, as in Mastercard Paypass, Visa PayWave or Discover Zip. Each of these involves a slightly different protocol, relying on different characteristics of the card data to authenticate the card.

Swipe transaction are perhaps easiest to describe. The data encoded on the magnetic stripe is static, formatted according to ISO7813 in three tracks, with the third one typically unused. One of the fields in this track layout is the Card Validation Code (CVC) or CVC1. which serves as a cryptographic integrity check on the track contents. Much like a message authentication code, the CVC simplifies the process of authenticating track data when it is received by the issuing bank. It also prevents easy fabrication of credit cards: while track data is relatively predictable given the card number, expiration date and other fields, CVC1 does not have any predictable pattern that allows derivation from the other pieces.

CVC2 serves a similar purpoes but  is used in conjunction with card-not-present or “CNP” transactions such as ecommerce when the user types card information into a web browser.  While CVC1 is encoded in the magnetic stripe, CVC2 is only printed on the card itself– three-digits on the back under the magnetic stripe for Visa, Mastercard and Discover, and four-digits on the front for American Express. (The extra digit can be viewed as balancing out the fact that AmEx cards have 15 digits, one less than other major brands.) PCI standards impose stringent constraints on handling of CVC2. For example: while card numbers, expiration date and billing address can be saved for future use to simplify later transactions, CVC2 can not be stored by the merchant. It is only intended for authenticating the card owner during the purchase.

CVC2 and CVC1 are by design incompatible. It is not possible to use the CVC1 for making a purchase online, or encode CVC2 into a magnetic stripe for a successful swipe transaction. This has important ramifications on managing risks due to theft of payment information. It effectively creates a “firewall” between virtual and in-store fraud. Suppose a waiter has taken to swiping all customer credit cards through his very own mag-stripe reader to save a copy of the track data. The resulting cache of contraband information can be used to forge additional cards and used to make in-store payments compliments of unsuspecting diners. But unless our enterprising waiter also remembered to write down or photograph the CVC2 from those cards, they can not be used for any online purchase where the merchant validates CVC2. (Surprisingly some leading retailers including Amazon do not require CVC2, so this turns out not to be major impediment for the aspiring criminal.) Going in the other direction, when yet another website processing credit cards experiences a data breach, the spoils from this stunt can be used for additional online/mail-order/phone-order transactions. But they are not useful for minting actual plastic cards with valid magnetic stripe to use at an old-fashioned bricks-and-mortar store, due to the absence of CVC1.

Updated: 12.18.13 to correct CVC1 / CVC2 mix-up in last paragraph

[continued]

CP