IronKey versus BitLocker-To-Go with smart cards (part 2)

The first post in this series described how the BitLocker-To-Go feature built into Windows can be used in conjunction with smart cards to encrypt removable drives, and offer an alternative to dedicated hardware such as IronKey devices with comparable security. In this second and final part, we continue the comparison focusing on scaling, cost effectiveness and ease of deployment.

From a cost perspective, BL2G wins hands down:

  • BL2G works for any external drive, as well as logical volumes and non-bootable partitions of internal drives. There is no need to acquire new hardware. Existing plain USB drives can be leveraged, avoiding new capital spending.
  • Even when buying new drives,  there is a huge premium for models with built-in encryption.  Data point from March 2013: 16GB model of IronKey Basic S250 retails for around $300. By comparison a plain USB thumb drive at that capacity costs less than $20, or one-fifteenth the price. Not to mention those vanilla drives boast USB 3.0 support, unlike the IronKey stuck with slower USB v2. The price discrepancy only gets worse with increasing capacity– a phenomenon that can only be explained by wide profit margins, considering that the addition of secure element to vanilla drive is fixed overhead.
    • For BL2G there is the additional expense of card and reader. Basic contact-only readers can be had for less than $20. (On the splurge side, even fanciest dual-interface readers with contact and NFC  retail top out around $130.) The cost of the card itself is noise; plastic cards cost around $10 in volume. Alternatively one can opt for USB tokens such as GoldKey that function as combined card-in-reader.
    • It is also worth pointing out that card and reader are not unique to a drive: the same combination can protect any number of drives. Not to mention, enable other useful scenarios including machine logon,  secure email and remote authentication. In short the one-time investment in issuing cards and readers is far more economical than buying dedicated drives.
  • Speaking of space, BL2G scales better to large capacities because it operates on commodity hardware. IronKey comes in different sizes but the largest ones in thumb-drive form factor max out at 64GB currently. Meanwhile plain 256GB drives have reached market, and are starting their inevitable drop in price. Because BL2G effectively implements the “bring-your-own-drive” approach, it is not constrained by any particular manufacturer’s offerings.

From an administration perspective, the MSFT focus on enterprise scenarios leads to a more manageable solution:

  • The IronKey requires yet one more password to remember and does not fit into any existing enterprise authentication infrastructure. (For users with drives, consider the challenge of updating the password on all of them.) By contrast the same smart card used for logon to Active Directory can be used for BL2G encryption if provisioned with a suitable certificate. The user experience is one versatile credential, good for multiple scenarios.
  • Basic IronKey models can not recover from a forgotten PIN, unless the user activated an online account. Not even if the user is willing to lose all data and start from a clean slate with blank drive. (This conveniently translates into more sales for the manufacturer, so there is not exactly a lot of economic incentive to solve the “problem.”)  BL2G volumes have no such constraint. They can be wiped clean and reformatted as plain drives if desired.
  • BL2G can be integrated with Active Directory in managed environments. Group policy can be configured to back up encryption keys to AD, to allow for data recovery by IT administrators in case the primary (smart card) and secondary (printed key) unlock mechanisms both fail.

On the downside, there are deployment challenges to using smart cards:

  • BitLocker remains a Windows-only solution, while IronKey and its brethren have decent cross-platform support. In principle there is no reason why software could not be written to mount such volumes on OS X and Linux. (It is not clear Wine emulation will help. While there is a reader application available downlevel for XP,  recognizing BL2G volumes is part of core system functionality. There is no stand-alone executable to run in emulation mode to get same effect.)
  • BL2G requires smart card and card reader, or equivalent combined form factor as USB token. While plug-and-play support and developments in the Windows smart card stack for recognizing common cards has made this simpler, it is one more piece of hardware to consider for deployment.
  • Cards need to be provisioned with a suitable certificate. BitLocker can use self-signed certificates obviating the need for CA, but that assumes the card can support user-driven provisioning. This is true for GIDS for example, but not PIV which requires administrative privilege for card management and more suitable for enterprise setting.

Finally it is worth pointing out some options that try to integrate removable storage with a smart card reader. For example the @Maxx Prime combines a SIM-sized smart card reader with a slot that can accommodate microSD drives. Typically that SIM slot would be permanently occupied by a small form-factor card with support for certificates and public-key cryptography. Then interchangeable microSD cards can go in the microSD side to provide access to encrypted data, with the entire rig connected to a USB port.

CP

IronKey versus BitLocker-To-Go with smart cards (part 1)

IronKey is one of the better known examples of “secure flash drive,” a category of products targeted at enterprises and security-conscious users for portable storage with hardware encryption. From a certain perspective, this entire category owes its existence to a failure of smart card adoption in the same target market. All of the functionality of dedicated hardware encryption products can be implemented with equal or better security, at much lower cost and greater flexibility using general purpose smart cards and off-the-shelf software.

Case in point: BitLocker-To-Go (“B2LG” for short) available in Windows 7 and later versions, provides full disk encryption for any old USB drive, with keys managed externally. B2LG is closely related to the original Bitlocker feature introduced in Vista, which protected boot volumes with the help of a trusted platform module. The latter is a more difficult proposition, as booting a modern OS involves several stages, each depending on executing code from the encrypted disk. Maintaining integrity of this code loaded during boot is as much of a concern as confidentiality, because altering the operating system can be an avenue of bypass against disk encryption. By contrast B2LG is concerned strictly with reading data after the OS has been already booted into a steady state.

Screenshot of the context menu on a removable drive

Context menu on a removable drive, showing the option to enable BitLocker

BL2G can be configured to use either passwords or smart card for encryption:

Choosing between passphrase and smart card

Choosing between passphrase and smart card, when enabling BitLocker.

The first configuration is susceptible to the usual offline guessing attacks, much like Android disk encryption, because keys are derived from a low-entropy secret chosen by the user. In the second configuration, the bulk-data encryption key is randomly and sealed using a public-key associated with the smart card. Unsealing that to recover the original key can only be done by asking the card to perform a private key operation, which is what smart cards are designed to implement with high security.

PIN dialog during private key operation

PIN dialog during private key operation to unlock a volume protected by BitLocker To Go.

Comparing a USB drive with built-in encryption with B2LG coupled to smart cards card, these solutions achieve similar but not identical, security profiles:

  • In both cases, bulk data encryption key is not derived from user-entered PIN or pass-phrase. A key based on “12345678” is not any more likely than one based on “c8#J2*}ep
  • In both cases there is a limit to online guessing attacks by trying different PIN/password choices. For dedicated drives, the retry count is typically fixed by the manufacturer. For BL2G, it depends on the application installed on the card, translating into more flexibility.
  • BitLocker defaults to AES with 128-bit keys, along with a home-brew diffuser to emulate a wide-block cipher operating on sectors. Dedicated flash drives typically boast slightly more modern cryptography, with 256-bit AES in standardized XTS mode. (Not that any practical attacks exist against 128-bit keys or the custom diffuser. But one can imagine that manufacturers are caught in a marketing arms race: as soon as one declares support for the wider key length and starts throwing around “256” as magic number, everyone else is required to follow suit for the sake of parity.)
  • For those comforted by external validation, there are many smart cards with FIPS 140 level 3 certification (as well as Common Criteria EAL 5+) in much the same way that many of the drives boast FIPS compliance. Again BL2G provides for greater choice here: instead of being stuck with the specific brand of tamper-resistant hardware the drive manufacturer decided to use, an enterprise or end-user can go with their own trusted card/token model.
  • BL2G has better resilience against physical theft: an attacker would have to capture the drive and the card, before they get to worrying about user PIN. If only the drive itself is lost, any data residing there can be rendered useless by destroying the cryptographic keys on the smart card. By contrast a lost IronKey is a permanent liability, just in case the attackers discover the password in the future.
  • Neither approach is resilient against local malware. If the drives are unlocked while attached to a compromised machine, all stored data is at risk. Some smart cards can support external PIN entry, in which case local malware can not observe the PIN by watching keystrokes. But this is little consolation, as malware can request the card to perform any operation while connected. Similarly while the IronKey PIN must be collected on PC and subject to interception, there are other models such as Aegis Secure Key with their own integrated PIN pad.
  • BitLocker has one convenience feature that may result in weaker configuration.  There is an option to automatically unlock drives, implemented by caching the key after successful decryption. Once cached, the smart card is no longer required to access the same drive in the future, because the key is already known. If the user makes an unwise decision to use this feature on a laptop which is stolen (or equivalently, remotely compromised) the persisted key can be used to decrypt the drive. Meanwhile the proprietary software accompanying IronKey does not provide an option to cache passwords. (That said, nothing stops a determined user from saving it to a local file.)

The second part of this post will look at other dimensions, such as performance, cost effectiveness and scaling, where BitLocker & smart card combination enjoys a decisive advantage over dedicated hardware.

CP

Windows smartcard logon with Android secure element and NFC

There are different ways to interpret the notion of “logging into your computer PC using a phone.” While it is increasingly common to see phones provide second-factor for login to websites (by sending SMS challenges or using installed apps to generate one-time passcodes) users still have. In addition these ad hoc schemes are not compatible with how authentication works for typical operating systems– for example in an enterprise environment, that means Kerberos.

Here we consider a different approach where the phone is used as primary credential, replacing a standard smart card in conjunction with a short user PIN. Restricting our attention to PCs running Windows on one side and Android devices on the other, it turns out the bulk of the machinery required for implementing this is already present. Quick recap of these raw ingredients from previous posts:

Putting together all of this, we can implement Windows smart card logon with an Android phone:

  1. Write a minimal PIV application for the eSE. Why PIV? In fairness it is one of two options: support for PIV and GIDS standards is built into the OS starting with Windows 7. More over there is a discovery process to automatically recognize such cards as soon as they are introduced to the system. PIV specification is slightly easier to follow and it turns out smart card logon requires a tiny subset of specified functionality.
    • Strictly speaking the applet is not– and can not be– fully PIV compliant. The standard does not permit using the authentication key over NFC. That key is only meant to be used over contact interface, when the card is inserted into a standard reader. Luckily in this case having a more permissive applet does not change anything; Windows does not differentiate between contact verses contactless readers, and will try to use a discovered PIV card either way.
  2. Install the application on the eSE using standard Global Platform commands.
    • Caveat: this part can not be replicated with off-the-shelf hardware. Card manager keys for the secure element will not be known for standard production devices. Luckily one perk of working on Google Wallet is access to development phones, with keys rotated to default well-known values. (This is different from knowing the keys for a production device– a phone with rotated keys can not run Google Wallet any longer, because its keys are not consistent with the ones TSM expects.)
  3. Setup target machine for smart card logon.
    • For enterprise scenarios where the machine is joined to Active Directory, this is built-in. No further action is required on the client machine. However some configuration is required by IT administrators on the backend to issue suitable certificates (for example by installing Active Directory Certificate Services) or setup trust in third-party CA issuer.
    • For local logon to home machine without AD, eIDAuthenticate is a good third-party solution.
  4. Personalize the PIV applet, by setting a PIN, generating key pairs and installing certificates from the enterprise CA. Specifically smart card logon uses only the PIV authentication certificate; remaining keys and certificates are not required.
    • That said, the OS will query the card for other data objects defined in the standard, such as the CHUID and security object. While these are not relevant to the authentication protocol, returning an error can confuse the driver that expects a compliant PIV applet to be configured properly.

That’s it. Tap the phone against a contactless smart card reader and the familiar smart card logon sequence with PIN entry follows. The video shows this proof-of-concept on an HP Envy Spectre, something of a best-case scenario here because it includes an NFC controller under the palm rest, a rarity for laptops on the market today.

One caveat about the HP Spectre: by default the built-in NFC controller only supports peer-to-peer mode, instead of reader mode required to communicate with an external “card” such as the Android eSE. NXP Semiconductors has the necessary drivers to enable reader mode, with the controller appearing as PC/SC compliant smart card reader that Windows can use.

Also note the proof of concept does not require making any changes to Android OS or even writing an Android app. Recall that the eSE is effectively its own environment. Installation of the PIV applet and its personalization can be done entirely over NFC, without going through the Android side at all. For example the employee can walk up to help desk and tap their phone on a reader there to enroll.

CP

When hashing does not improve privacy

Last week a local Portland station drew attention to Nordstrom piloting a program to track shoppers in-store using unique identifiers from their smart-phone. Intriguing quote from an article on StorefrontBacktalk covering the same story:

“To be precise, the MAC addresses of those shoppers are not being stored by Euclid; instead, a hashed version of those MAC addresses is being stored.”

The subtext of this statement is an article of faith about hashing: replacing sensitive information by its hash can magically assuage privacy concerns associated with the collection of personally identifiable information. In the case of Nordstrom and Euclid, the data in question is the unique hardware identifier of the wireless network adapter present in most smartphones. While exact details of the hashing process are not given in the article or for that matter Euclid website, some very general arguments can be advanced to the effect that hashing MAC addresses is unlikely to help in this case.

Quick detour into cryptography: a cryptographic hash function (hash function for short) is a mathematical abstraction designed to be easy to compute forward but difficult to invert. That is: given some input message M of any size– could be as short as an email address or as large as an MP3 file– we can compute a concise digest of that message quickly by applying a prescribed algorithm. But given such a fingerprint that came out of a computation where we were not privy to the original input, it should be very difficult– in other words, require inordinate amounts of computing power– to run the function backwards and come up with a message that could have been used as starting point to produce that fingerprint. (For completeness, there are additional requirements around pair-wise collision resistance, but these will not come into play.)

Storing hashed version of sensitive information looks like a privacy win. Instead of storing the MAC address of a shopper “00:87:44:D3:50:A4” we run that through a well-known hash function such as SHA1 and store the output: e266b50d6a98dafc962e9b7724092304170a3b8a. That may look like merely replacing one sequence of indecipherable symbols by another, but it hides information present in the original. For example MAC addresses have internal structure, with the first three bytes assigned to the hardware manufacturer. By looking up those digits in a public registry, it is possible to determine that. This alone can help distinguish users by the type of phone they carrying, since all units for a given model usually have the same type of wireless adapter. A good hash function wipes out such information. There is no correlation between the first-three digits of MAC and the output. Such simple mappings have been scrambled. The second benefit is that hashing can make it more difficult to link one observation (“user with hashed MAC address X walked into the store at 2:48PM”) against others involving the same person from other data sources, such as (“user with MAC address 008744D350A4 has Twitter handle of @alice”) by removing the common identifier that ties these records together.

There are two problems with this line of argument:

1. “One-way” is a computational notion. It only means there is no efficient algorithm to invert the function, to go from observed hash back to an input that generated it. This does not preclude very inefficient options, such as hashing all possible inputs to find the right one. Whether that is feasible depends on the number of candidates.

2. To prevent linking across different datasets based on a unique identifier such as MAC address, everyone has to adopt hashing. (Not only that, but use incompatible hash functions on purpose. Otherwise if everyone picked an unmodified function such as SHA1, then “SHA1 of MAC address” becomes the new de facto unique identifier for correlation.) It is not possible for one data owner to unilaterally prevent future linking by hashing their own records.

The Nordstrom scenario is an example of the first problem. If it proves “easy” to recover original MAC addresses from hashed versions, the benefits vanish.

To take an extreme case where hashing clearly does not help: consider health records database with one particularly sensitive column. This column can take two values: zero or one, depending on whether the patient tested negative or positive for performance enhancing substances. Replacing “0” with hash of 0 and “1” with the hash of 1 does absolutely nothing to improve the privacy of these records, for any choice of hash function. There are just too few possibilities: anyone with access to the records and knows the hash function can try both zero and one to uncover the status of any subject. (In fact for such an extreme case one need not even know the hash function– eg mixing a secret key into the process does not help either. If there is any a priori information about expected percent of cheaters, simply looking at the total incidence of two different values will suffice. For example if we assume optimistically that crooks are in the minority, then the hash value that appears less often must be the one corresponding to positive test.)

MAC addresses have a lot more than two possible values: roughly 281 trillion.** That may seem intractable but helping the attacker is the surprising efficiency of common hash functions, and how quickly they can run on modern hardware, an evolution driven in large part by research on password cracking. (In fact since passwords are typically stored in salted hashed form, that they can be recovered at all is rebuttal to naïvely equating hashing with privacy.) Using the popular cryptographic hash function SHA1 as an example, a single high-end GPU can grind through one billion hashes per second. Cluster together three dozen such processors, or better yet rent them from Amazon, and every possible MAC can be compared against a given mystery hash. (It should be emphasized that we do not know what hashing algorithm Euclid is using. But this is an example where a perfectly reasonable choice employed in many security applications fails to provide privacy.)

The picture gets worse when considering attacks against large number of users. Spending hours of computing time to recover a single MAC address may not seem economically viable for data mining purposes. But the marginal cost of inverting one more hash drops rapidly, thanks to more efficient cryptographic attacks using time-memory tradeoffs. These call for an upfront, sizable pre-computation phase to build a massive table which can be used later to crack individual hashes much faster than exhaustive search. The algorithm in effect takes up more storage space but reduces the time of each search. Refinements of this idea underlie the  rainbow-table approach used for cracking Windows passwords. In other words, the cost of recovering MAC address does not scale linearly in the number of user. Bulk deanonymization is only slightly more expensive than going after a handful of individuals.

Bottom line: hashing does not magically anonymize personally identifiable information. In this case, there may not be much difference in privacy between storing MAC addresses and storing hashes. Without additional context, there is little reason to take comfort in a blanket statement to the effect that sensitive data is hashed.

CP

** In reality, the hierarchical assignment of MAC ranges to different hardware manufacturers, combined with the fact that only certain models appear in smart phones, greatly reduces the range of possibilities. Here we assume worst case scenario.

The RFID boogeyman, part II: passports

If one could point to a single application responsible for giving RFID its bad reputation, it would have to be passports or machine readable travel documents (MRTD) in the standards parlance. The benefits of using smart card functionality to make passports more difficult to counterfeit are difficult to argue against. On the flip side, it has been equally difficult to articulate the value of having those chips support contactless access over RFID. In the US particularly, it has been a controversial decision pitting the privacy advocacy community against the State Department leading the charge for the new design.

Such vociferous opposition is understandable, as the stakes are  higher compared to use of RFID for payment cards. While it requires something of a  Luddite to completely opt out of the conveniences of credit/debit cards, consumers at least enjoy choice of issuers. The usual market forces are continue to operate: if there is indeed strong reluctance for contactless functionality in payments,  customers will gravitate to banks catering to that demand. (Determined card-holders can even take unilateral action and fry the chip in the card.) By virtue of being government issued, passports offer no such easy opt-out. Crossing national borders usually requires some type of identification, and citizens have little choice but to obtain that ID from their country of their citizenship. More importantly NFC functionality is a critical part of passports– it is not an “optional” feature, unlike credit cards where transactions  can still work the old-fashioned way by swiping the magnetic stripe. (Not to mention that tampering with passports is illegal.) The perception that a privacy infringing technology is being foisted on the populace has fueled many a conspiracy theory and FUD cycles.

That FUD has been non-stop and, quite frequently, wildly inaccurate. One sensationalist article from 2010 claims US passports can be read from 217 feet. Aside from the dubious use of “read” (see earlier post about what it takes to actually recover personal data from a passport) the article also conflates two different technologies. The actual demonstration at BlackHat involved EPC Gen 2 tags, which are RFID tags operating on a different frequency than the NFC chips present in passports. NFC stands for Near Field Communications— emphasis on “near.” While sufficiently powerful transmitters and sensitive antennas will no doubt increase the range significantly, up to several meters, to date there has not been a successful demonstration of reading NFC tags anywhere near distances implied by the article. Granted “attacks always get better” as the saying goes, but the article amounts to arguing that trains are dangerous by citing statistics on horse carriages.

An even more pervasive assumption is that individuals can be tracked simply by virtue of carrying their passport. This is a dubious proposition, at least in the simplistic interpretation of “tracking.” In the manifesto describing seven Laws of Identity— fashionable when  Infocard/CardSpace was all the rage– Cameron posited that the problem with RFID is projecting an omni-directional identity:

Another example involves the proposed usage of RFID technology in passports and student tracking applications. RFID devices currently emit an omni-directional public beacon.

Paraphrased, this is asserting that RFID  tags emit a constant, unique identifier to everyone instead of allowing the owner to project a variable identity based on the observer. While that  holds true for earlier generation of RFID tags, it is demonstrably false for US passports, as anyone can verify with an NFC-capable Android phone. In fact it is required that passports are configured to emit a random identifier, picked anew each time the passport is scanned.

Granted randomizing the identifier emitted at the transport level is a necessary but not sufficient condition to prevent tracking. There could be other constant identifiers lurking in higher level protocols, permitting correlation. Here the picture is more complex. The designers have taken additional steps to avoid obvious pitfalls. For example retrieval of unique chip identifiers (such as the CPLC) is not allowed until the reader is authenticated to the card. That authentication step requires already knowing data from the passport, as explained in previous post. The design translates into a limited tracking capability: at best the reader gets a yes/no answer, learning whether the passport scanned is identical to one where the name, date of birth and expiration are known. By repeating this query, one could check against multiple persons. The time required for issuing these queries increases linearly with each such attempt– and these chips are not exactly blazing fast, given the requirement to be powered by an external field. (There is also an unintentional weakness which permits answering the same yes/no question using only a previously observed exchange with legitimate reader, without knowing the passport data.)

That is still enough for targeted surveillance against a small number of individuals, but not practical for tracking movement of every person with a passport who wanders within range of stealth readers. There is clearly room for improvement, because the expression of user “consent” for getting his/her passport scanned is far from clear. One could imagine alternatives where PIN entry is required (and this PIN can be changed by the user) or even a simple physical switch activated by pressing a touch-sensitive area on the passport. Similar designs have already seen trial deployments for payments. Even better, if NFC convergence takes off and passports are integrated into smart phones some day,  existing mechanisms controlling when NFC functionality is accessible could provide a much better balance of privacy and user control over presenting their identity.

CP

PIV card and mobile devices: NFC as missing link

An article in the Government Computing News titled Are mobile devices already making PIV cards obsolete? draws attention to the incompatibility of US government PIV standard with newfangled mobile devices. The author asks whether the shift to smart-phones and tablets is threatening to render the ID card program obsolete barely after it has gained momentum. With the prevalence of NFC in mobile devices (mostly owing to Android ecosystem, although Nokia, Blackberry predate it) this perceived incompatibility may be increasingly an artifact of  design decisions in the PIV specification rather than any intrinsic limitation of smartcards. After all PIV cards are dual-interface: they have both old-school metal contacts for insertion into traditional card reader, as well as NFC antennas for communicating wirelessly. Since NFC-capable phones can act as card reader, one might expect that using the contactless interface will solve the problem– modulo NFC adoption, which is helped by the fact that the Pentagon favors Android for military applications. But it turns out that deliberate design decisions in PIV protocols frustrate that  expectation.

Traditional contact-based card readers were historically used in conjunction with desktop machines, where having a separate gadget with dangling USB cable going back to the PC was less of a problem because the setup was stationary. Overtime came readers integrated into existing hardware such as keyboards, to better blend in with the existing peripherals.  Laptops posed a slight s carrying yet another gadget quickly becomes a usability problem, even when the gadget in question can be quite tiny. In response manufacturers designed  readers intended for the PC Card and later ExpressCard slot directly such that it can be left permanently fixed in place. (Strangely the move from PC Card to ExpressCard standard made the ergonomics worse. Now part of the reader must just out of the narrower slot in order to match ID-1 card dimensions, instead of being flush against the laptop edge in previous designs.)

Mobile devices however continue to pose a challenge due to the paucity of options. It is not that there are no card readers available– they are just very awkward looking. The generic availability of USB in Android makes it possible to reuse existing USB card readers, as ACR has done. Alternatively some manufacturers designed custom readers for phones, since they are no longer required to follow the USB CCID standard prevalent on Windows. There are a couple of products marketed as mobile CAC readers taking that route on iOS, Blackberry and other mobile operating systems. These gadgets are expensive, almost comparable to the cost of the phone and unwieldy. They combine the problems of one-more-widget-to-carry-around (or forget/lose) when not in use, with the problem of poor ergonomics when needed. Some of them functions as sleeve for the phone– a design that ironically would not fly on Android because it would interfere with NFC, with the card being recognized as NFC tag while also being activated on contact interface. Perhaps the least intrusive design is the baiMobile 3000MP which acts as a sleeve for the card and links up to the phone via Bluetooth.

What about NFC? Considering all card functionality can be accessed equally well over NFC, such kluges to get contact readers playing well with mobile device are no longer necessary for the latest crop of phones. In effect the devices are shipping with built-in contactless readers at no extra cost.

There is a catch. While it is true that communicating to the card works equally well from either interface, it does not follow that applications will respond identically. In fact card environments permit applications to determine what interface they have been invoked from and behave differently. In the extreme case, that could mean declining all requests from one interface. There are good security arguments for such discriminatory behavior. Case in point: payment applications running in a secure element inside a mobile device have reason to be suspicious of access from contact interface. That is where host applications and malware lurk. Contactless access from an NFC reader is the proper path for a legitimate point-of-sale terminal, and the payment application can check this during a transaction.

PIV also mandates similar restrictions, except in the other direction. The standard has a significant bias in favor of the contact interface, forbidding most operations over NFC. A look at the PIV data model in NIST SP 800-73 section 1 shows how bad the situation is.  Appendix A lists up to four active X509 certificates and associated key pairs, identified by their purpose: card authentication, PIV authentication, signature and key management. Of these four, only the card authentication certificate can be used over NFC. Worse, that key does not provide two-factor authentication because there is no PIN entry required. It is primarily intended for low-security physical access scenarios. Employees tap their badge against a reader to open doors. (Even in that scenario, FIPS defines “restricted” and “exclusionary” areas where PIN entry and use of a different card key is required, which is only possible by inserting the card into a contact reader.)

The upshot is PIV cards can be accessed from an NFC-enabled mobile device, but they can not be used for any purpose other than physical access. Other applications such as Kerberos authentication with PKINIT, document signing or encrypted email call for using keys that are disallowed for contactless mode. These restrictions are not without good justification: NFC provides no encryption at the transport layer. This is unlike Bluetooth for example, where the pairing process also negotiates keys for protecting future traffic. If PIV messages between card and phone were carried over the air instead of direct contact, it would create new privacy problems. Most notably the user PIN sent to the card, as well as any decrypted data returned from the card would be susceptible to eavesdropping within NFC range. Future protocol improvements can overcome these limitations, but that will not help already deployed cards.

CP

The RFID boogeyman, part 1: credit cards, HuMn wallet and identity theft

RFID is turning into what cookies were circa 2000: a poorly understood but universally reviled privacy infringing technology extraordiniare, synonymous with nefarious plans for consumer tracking by shadowy agencies. (Not to mention supernatural conspiracy theories.)  NFC– Near Field Communications– being a type of RFID operating in the 13.56Mhz frequency, appears to have inherited all of that hysteria and vitriol, as it begins to overtake earlier incarnations of the technology. Case in point: HuMn is a KickStarter funded project to manufacture so-called RFID-safe wallets. Aside from the fact that it does not in fact cover all RFID objects, their marketing language appears to suffer from the same confusions about an ill-defined “identity theft” threat. (What about the US passport? Doesn’t look like the dimensions are compatible. And did they forget NFC-enabled phones? Where is the matching shielded phone cover?)

There is certainly a kernel of truth to the FUD: unauthorized payments can be made by bumping an NFC reader against the unsuspecting victim. Dramatic demonstrations of this abound on the tubes and the topic is rehashed often at conferences. This is not an iron-clad rule that follows necessarily from the technology, but an incidental property of the way cards are configured in the US. PIN entry is not required for credit card payments (not to be confused with debit, which does require it) unlike the chip-and-PIN system in Europe. Without a PIN gating authorization,  mere proximity to the card is sufficient to exercise the payment protocol because the card has no other user-interface to ask for consent. (Mobile incarnations of NFC payments such as Google Wallet are a major improvement in that regard: on Android devices the phone screen must be powered on and users need to have recently entered the PIN to enable payments.)

But jury is out on whether that constitutes “identity theft.” Part of the problem lies in the ambiguity of the phrase, conflating routine credit card fraud with wholesale impersonation of the victim. An enterprising criminal in possession of someone else’s credit– even temporarily by NFC skimming– can spend funds available on that card. But armed with the victim’s full legal name, date of birth and social security number, that same crook can cause a lot more damage with new account fraud. They can get new loans with no intent to pay back or establish lines of credit in the name of the victim– all thanks to the bullet-proof authentication system used for such applications: if you know someone’s social security number, you must be that person. Vanilla card fraud takes place in a closed system, with a single institution implicated, namely the bank that issued this card to the legitimate card-holder. That company has an existing relationship with the consumer and presumably an interest in resolving the matter satisfactorily, in order to retain their business. (Card networks are structured such that that the issuer earns revenue from some portion of the interchange fee from every transaction, not to mention interest on balances.)

Between these two, plain card fraud  is far less dangerous. It is also a problem the industry has “solved” to large extent by creating the appearance of zero liability for consumers, distributing losses between merchants and issuing banks.While dealing with fraud is time-wasting and inconvenient, losses are fully recoverable. By contrast new account fraud takes place in an open ecosystem, where the crook could have ripped off any number of participants with no prior relationship to the victim and not subject to the consumer-friendly liability arrangement of credit cards. It can be more challenging to undo this situation.

Lost in the ambiguity of “identity theft” is that neither SSN or date of birth can be gleamed from a credit card. RFID or not, it is not possible to get this information from a credit card so the risk here is one of plain fraud. for  In fact NFC often provides the least information among all the different modes a payment can be made: while card-holder name is encoded in the magnetic stripe and embossed on the card, it is typically omitted from the equivalent “track data” sent during NFC payments. This is why the case of Barclay’s in UK was a big deal because the cards were personalized with full names.

It is unlikely that gangs of identity thieves are roaming crowded areas and bumping into unsuspecting people with NFC readers (Android phone counts as reader, in case stealth is desired) Such attacks are difficult to scale for three reasons. First skimming requires physical proximity to the victim, limiting the miscreants to a geographical area instead of being able to say target US citizens from the safety of Nigeria. Second the environment is not exactly target rich, with only a small number of banks having issued cards with NFC and even fewer people leveraging that. That makes it easy for fraud-detection systems to pick out anomalies because for most customers any contactless transaction is a red flag. Finally each bump only permits a limited number of transactions because the protocol employs a dynamic CVC3 verification value  unique to each transaction. That is unlike swiping or typing card details into a web browser where the same fixed number is entered for the life of the card. In short, it is a bad proposition for the criminal, combining lots of effort with long odds and limited upside even when successful.

Returning to the original problem: yes it is true that unfettered access over NFC to credit cards allows making unauthorized payments. But then so does handing over the card to a bartender when settling a restaurant tab or holding the card in plain-view in any public setting with other people present– watch out for the person behind you in line wearing Google Glass. (Somehow “visible-light-spectrum-shielding wallet” does not sound as marketable.)

CP

T-Mobile blocking traffic from Android wireless hot-spots

T-Mobile appears to be manipulating network traffic from users accessing the Internet through the wireless hot-spot functionality of their Android device:

IE screenshot showing T-Mobile man-in-the-middle

IE screenshot showing T-Mobile man-in-the-middle against HTTP traffic

For background: ever since carriers began offering data connections to mobile subscribers, consumers have been trying to use these same pipes to get Internet access from other devices they might be carrying, such as their laptop. Over time different options emerged to connect these secondary devices and phones to accomplish this. In the beginning were USB cables, originating the concept of “tethering” with overtones of being tied down. Along came Bluetooth with the Personal Area Networking (PAN) profile, cutting the cable metaphorically. Final step in this evolution was the wireless hotspot, first introduced in Android 2.2 “Froyo” release and eventually taken up by the iPhone. In this model the phone acts as a wireless router, offering a wifi network. Instead of messing with cables or working through the ever-inconsistent implementations of Bluetooth pairing, users connect to this wireless network much like they would at a hotel, and get to access the Internet by tapping the same data connection they have already paid for as part of their cell phone plan.

At least that is the theory. The above screenshot is what happened in a recent session when attempting to navigate to  www.youtube.com from a laptop connected to the wireless hotspot of a Galaxy Nexus running JellyBean. As the screenshot demonstrates, this is not exactly what the legitimate YouTube website looks like.

This is not exactly new. Carriers have been frequently at odds with their own users over tethering. Most recently Verizon got a shellacking from the FTC in a recent settlement ruling that the carrier can not keep customers from downloading tethering apps. AT&T meanwhile has resorted to stalking users with SMS when they start tethering on jail-broken iPhones. T-Mobile seems to have taken matters into its own hands by actively manipulating and blocking traffic. The carrier is using an explicit redirect, as the address bar shows a T-Mobile URL instead of the original location. This is accomplished by returning an intermediate response to the request for YouTube, redirecting the browser to the T-Mobile site instead. (With more nefarious transparent interception, T-Mobile could have returned the same bogus response while impersonating the original site the user expected to visit.)

Two consistent features of this based on initial observations:

  • Traffic manipulation does not commence immediately on connecting to the hot-spot, but only after some time has elapsed, or equivalent some bandwidth consumed. After that point all subsequent requests are tampered with, returning the above page. For what it’s worth, a quick check on Android settings shows the total data used before reaching this point was ~100MB:
Mobile data usage statistics

Mobile data usage statistics

It is not clear what heuristics T-Mobile is using for detection. One article claims carriers rely on the TTL (time-to-live) field in IP packets, which is different for packets taking an extra hop through the phone a”router” verses directly originating from the phone itself. At least TTL is part of the packet header. A more disturbing possibility would be deep-packet inspection, where carriers are looking at content of packets. There are plenty of signals inside an HTTP request that permit easy identification of tethering scenarios. For example, if the HTTP user-agent header indicates the browser is IE9 running on Windows 7, chances are this is not coming from an Android phone.

  • Blocking is not attempted for pages accessed over SSL– in other words URLs starting with https. This is not surprising, as the SSL protocol carefully verifies the identity of the destination website using digital certificates. Any attempt by T-Mobile or other aspiring censors to masquerade as the legitimate site will result in a certificate error from major web browsers. Increasingly the UI for such errors is designed to be very difficult for even the unsuspecting user to ignore or bypass. It appears that T-Mobile made a conscious trade-off in condoning SSL usage and only tampering with unprotected HTTP traffic to display their advertising/upsell message. (Score another victory for HTTP Strict Transport Security or HSTS; websites such as GMail which can be configured to be always accessed over SSL are not affected because the web browser will use the HTTPS version even when a plain HTTP link is given.)

CP

Time to revisit X509 name and path-length constraints?

Recalling the Leslie Lamport quote about the essence of a distributed system:

“You know you have a distributed system when the crash of a computer you’ve never heard of stops you from getting any work done.”

Substitute certification authority for “computer” and trust established for “work done,” and we have a good description of current PKI infrastructure. The fragility of this model, which has inspired critics such as Peter Guttman for over a decade now, was demonstrated again in the latest TurkTrust debacle. Here are the salient facts:

  • TurkTrust is a certification authority, present in Windows and NSS trusted root stores.  Virtually all web browsers recognize this organization as valid issuer of SSL certificates used for secure connections on the web.
  • TurkTrust issued two leaf certificates to websites with the “CA” property set to true. In other words, the lucky recipients became intermediate certification authorities themselves, inheriting all the privileges afforded  TurkTrust by web browsers to mint the equivalent of identity papers for any website in the world.
  • The intermediate CAs were used to issue fraudulent certificates, which were then used to falsely impersonate legitimate websites and intercept user traffic.
  • The problem was not discovered internally by TurkTrust during audits. Instead it was caught by Google, thanks to the Chrome certificate pinning feature.

There are a number of details lacking satisfactory explanation, in spite of a decent attempt at postmortem by TurkTrust. Leaving aside those questions, there are two fundamental questions around why the mistake was possible:

  • Why is TurkTrust– a CA based in Turkey and doing the majority of its business with companies Turkey– entrusted with issuing certificates for any company based anywhere in the world? This speaks to a profound breakdown of compartmentalization in X509, of any semblance of containing the failure of one component in the system from spreading to all others.
  • Why does a single mistake in using the wrong certificate template result in random website owners getting unfettered CA privileges, with no other checks and balances?

It turns out  the X509 standard already has provisions to help out with both. Not surprisingly, these features have not been used properly in the PKI system that emerged over the years.

The solution to the first problem is name constraints. If the CA certificate contains this particular property, it can only issue for websites with name matching the specified pattern. The natural restriction for TurkTrust would be requiring that the site name ends in “.TR”, indicating the top-level country domain for Turkey. Design of these constraints allow specifying both permitted and disallowed names. For example if some subdomain of TR was particularly sensitive, it can be further protected against TurkTrust errors by excluding that pattern. Incidentally, name constraints are propagated down the chain. Even if a bumbling CA accidentally creates a subordinate CA lacking any name constraints, the restrictions specified in the root still apply.

The solution to the second problem is path-length constraints. Any CA certificate can express a requirement to the effect certificate chains leading up to that point will be no longer than some fixed number of hops. Setting the limit to 1 hop prevents any “accidental” intermediate CA from being operational. Leaf certificates issued from that unintended intermediary would have an additional hop to the root CA, violating the path-length constraint.

Realistically neither extension has been used in practice for existing trust anchor. Few carry any name or path-length constraints, with the exception of subordinate CAs issued to companies such as Microsoft to issue their own certificates for their own domains. Understandably it is not in the interest of the CA to impose restrictions on itself– what if TurkTrust later wanted to expand its business into another country or create additional subordinate CAs? A less draconian requirement is that all leaf-certificates must be issued from an intermediate CA that has a path-length constraint of one. Since the key used to sign leaf certificates must be online, in the sense of being available in the normal course of business, it is at highest risk of “accidents.” While the path constraint does not prevent issuing mistakes, such incidents will be isolated to a small number of sites each time. (Granted when that site is Microsoft or Google, the mistake can have large repercussions.) One could also envision separate intermediaries for different top-level domains, but this is unlikely to reduce overall risk. Most likely all of them will run on same infrastructure with same operational profile, having exactly the same vulnerabilities.

Given that the economics do not favor CAs to exercise self-discipline, the next best option is self-defense for users. Unfortunately that involves changes to certificate verification logic to artificially simulate the constraints. Windows cryptography API has some flexibility in limiting trust associated with root anchors, for example to remove ability to issue certificates for specific purpose such as code signing.

Using the management console

Editing properties using the management console

But that mechanism does not allow for introducing additional path or name constrains into an existing certification. (There is always the nuclear option of blacklisting a CA by putting them the Untrusted Certificates store but that goes well beyond the objective of “compartmentalizing” risk from CA failures.)

CP

Using the secure element on Android devices (3/3)

(Continued from part I and part II)

As discussed in earlier posts, the embedded secure element on Android devices is a generic computing environment, with its own processor, RAM and persistent storage, however modest those may be in comparison to the phone itself. This platform supports running multiple applications, developed in Javacard. Javacard is a very restricted subset of Java optimized for resource-constrained environments. It’s worth emphasizing that while Android SE is programmed in Javacard, not all smart cards are. Some accept native code applications– “native” to their underlying bare-metal architecture. Not to be outdone by Sun, there is also .NET Card supported by Microsoft as a scaled down version of its .NET platform for Redmond-sanctioned smartcard development. The Android SE is also Global Platform compliant. This grandiose-sounding standard sets down a uniform model for card management, independent of form factor and internal architecture. GP can manage SIM cards over-the-air for GSM networks, as well as chip-and-PIN credits card inserted into an ATM. It can install Javacard applets just as well as deliver native code or C# applications.

Our starting point for this discussion was: what functionality does Android SE expose out of the box? It turns out the answer is, very little. Global Platform only mandates a card manager. The card manager is not the analog for an operating system per se. It is more akin to a trusted installer service that provides the only way to add/remove applications from the card. Unlike other smart cards that have a single dedicated purpose such as transit and no provisions for being enhanced in the field, the Android SE starts out with a blank slate. There is no TPM-style functionality, password manager or EMV-payment capability exposed to the outside world when the chip rolls off the assembly line. The underlying hardware and operating environment are very much designed to support all of these scenarios. In fact between the certified tamper resistance, hardware acceleration for cryptography and rich library of primitives in Javacard, the SE makes for an ideal platform for such security-critical functionality. It takes an application (“applet” in preferred Javacard terminology) to package those raw capabilities and offer them up in a way accessible externally.  For example, when Google Wallet is installed and set up with cards/offers, then appropriate applets are installed that collectively implement the Paypass protocol for contactless payments over NFC.

Global Platform spells out how code is delivered (INSTALL for load and LOAD) and instantiated (confusingly named INSTALL for install.) By analogy to the PC, the first one installs new software while the second starts a new process from an executable image on the machine. GP also provides mechanisms for listing applications, deleting them, creating new security domains (similar to “users”) and managing the life-cycle of the card. For instance, locking the card if the issuer wants to suspend usage temporarily, or terminating it in an irreversible manner.

The catch is card management operations require authentication, specifically as the owner of the Issuer Security Domain. Global Platform defines this protocol, based on symmetric cryptography and clearly showing its age with a heavy reliance on DES– specifically triple-DES configured with two independent keys as 2TDEA. Each SE internally has a unique set of secret keys, called ISD keys or colloquially card manager keys. Possession of these keys is required for successful authentication, which in turn is a prerequisite for privileged operations like applet installation. GP envisions ISD keys being guarded by a trusted services manager (TSM), responsible for remotely managing the card without relinquishing keys to intermediate systems. This model strives for end-to-end security from TSM to the card, by avoiding security dependencies on other entities existing along the path. That includes the Android device, which is one of the final hops on the way. Card management commands are received from the cloud and funneled over to the SE. Rooting or jail-breaking the host operating system affords no special privileges because the local device does not have ISD keys.

Returning to the original question then: installing new functionality on the embedded secure element is possible on devices where:

  • The publisher of the application  has card manager keys, or
  • Existing TSM in possession of such keys can perform the installation

CP

** For completeness: there can be more than one set of ISD keys. All of them have equivalent privileges, including the ability to change other ISD keys. For example the embedded SE in PN65N from NXP Semiconductors features four key slots, theoretically allowing up to four different parties to manage the card at once. (That chip and its successor power virtually all NFC-enabled Android handsets. Only the recent Nexus 4 phone and Nexus 10 tablet have different hardware.) This is akin to having multiple cooks in the kitchen. Global Platform spec version 2.2 — which is not supported– adds even more flexibility with delegated management. ISD keys can be used to create supplementary security domains (SSD) which are capable of installing/removing applets on their own, but not interfere with code installed into other SSDs. That gives rise to an unbounded number of participants with ability to deploy applets in parallel.