Quick primer on the Windows smart-card stack (2/3)

While the original CSP model made it possible to support smart cards, it was neither efficient or scalable. It put a significant burden on both upstream consumers and authors of each CSP. Applications had to know which CSP to load in advance– which is a tall order for smart cards, since they can be introduced at any point. In reality most applications were written on the assumption that a single CSP could service all their requirements, because the model did not permit easily mixing and matching. That meant even dedicated CSPs  had to effectively duplicate all of the functionality in the default CSP, including features that have nothing to do with smart cards. These limitations motivated MSFT to introduce a different model with the ill-fated Vista OS, eventually reaching its full potential with Windows 7.

The new model takes advantage of the fact that there is a significant amount of logic shared across smart-card CSPs– such as prompting for a PIN– can be refactored into a platform component. The new architecture could be depicted in simplified form as follows:

Simplified model of smart-cards and CAPI for Vista and above

Simplified model of smart-cards and CAPI for Vista and above

Some observations about this architecture:

  • CSP layer is still intact, but third-party CSPs are largely deprecated. While existing ones will continue to work, MSFT can at some point discourage publication of new ones due to another legacy of the crypto wars: every CSP must be signed by MSFT itself. In the logic of export restrictions, this would have prevented the bad guys from writing stronger cryptography implementations than they were entitled to according to the framework. Again the original motivation is long gone, but the restriction survived in the architecture. (Tangent: it is trivial for users to override this, with administrative privileges. First approach is to configure the machine for kernel debugging, which permits loading unsigned CSP by design. Another approach, adopted by this blogger for a past project, involves modifying the function in advapi32 responsible for loading new providers. Reverse engineering reveals the location where return value from signature verification is used in a conditional branch. Hot patching that code in memory to with NOOPs allows ignoring failed signature checks. This is best automated with a DLL injected into all processes, using the app-init DLL mechanism for example, such that existing apps can transparently load the unsigned CSP without modification.)
  • There is a single CSP responsible for all smart cards.  One more layer of indirection has been added under that CSP, branching out to individual mini-drivers responsible for a particular card edge. Vendors introducing a proprietary card edge– as opposed to simply shipping new hardware that conforms to an existing standard– are now tasked with writing smart card mini-drivers hooking into the generic smart card CSP instead of writing wholesale CSPs specific to one model of cards.
  • To complicate the picture– Vista also introduced a new cryptographic API called Crypto Next Generation (CNG) with its own abstraction called Key Storage Providers, or KSP for short. Smart cards can also be accessed via this path using the unified smart-card KSP. One convenient property is that drivers can operate as part of either stack, depending on whether the calling application uses CAPI or CNG.
  • Drivers are assumed to communicate via the PC/SC interface to the card itself, and they are invoked only after a connection to the card is established at PC/SC layer. A corollary is that cryptographic hardware that does not appear as a CCID device, such as networked HSMs or USB tokens communicating via home-brew HID interface, either have to stick with writing legacy CSP or create the appearance of a fake smart-card, complete with an associated fake smart-card reader to appease PC/SC, as in the case of virtual smart cards built on top of the TPM.
  • The adjective “mini” is relative. Counting by sheer number of APIs, card drivers have a significantly more complex interface than the corresponding CSP they replaced.
  • Two card edges are built into the OS out of the box: PIV and GIDS. Logically these appear as different card types but in reality they are implemented by a single driver, msclmd.dll. For coping with the terra incognito of card models beyond that, there exists a fairly elaborate discovery mechanisms to map a given smart card to a driver, as well as install new drivers via plug-and-play mechanism when confronted with an unfamiliar “card” such as an Android phone with embedded secure element. This will be the subject of the last post in the series.

[continued]

CP

Quick primer on the Windows smart-card stack (1/3)

Earlier posts considered the idea of using a smartphone as a smartcard replacement for security scenarios such as logical access and encryption. The upshot is that presence of an embedded secure element and support for NFC with card-emulation mode gets surprisingly close without installing any software on either side. A commodity OS such as Windows already recognizes the phone as a smart card when it is tapped against an NFC reader, and attempts to use it for traditional smart card scenarios such as login. This article takes a closer look at exactly what goes on inside Windows when interacting with the phone over NFC, a story best related through a historical perspective on cryptography in Windows.

The first systematic usage of cryptography in Windows dates back to the 1990s and Clinton administration, when crypto wars were still raging. On one side the US government lobbied for strong export restrictions, arguing that encryption made it easier for criminals to evade surveillance by law enforcement agencies. On the other side an alliance of industry, civil liberatarians, self-described cypherpunks and academics pushed for widespread commercial availability of strong cryptography. Meanwhile the sudden growth of the web and ecommerce gave rise to the first large scale use of crypto for consumers: the Secure Sockets Layer protocol or SSL was the ultimate kitchen sink, mixing all of the basic building blocks: public-key encryption, symmetric ciphers, hash functions, digital certificates. The dependence of ecommerce on SSL translated into a product requirement to have all of those moving pieces implemented.

Eventually the US would back down from its position and the restrictions largely lifted in 2000, but not before they took their toll on the design of Windows cryptography API or CAPI for short. CAPI tried to walk this fine lien of enabling the “permited” use cases such as online banking for good guys while making it difficult for bad guys to implement the “frowned upon” scenarios. Many of the inexplicable design choices reflect these constraints. Case in point: for the longest time it was not possible for users to generate their own keys and provide that to the API for use in an encryption operation. Because users could override export restrictions, and for example use 128-bit keys when they were supposed to be limited to weak ciphers only. (Even when the regulatory constraints went away, the API remained hobbled with the restrictions, with the bizarre exponent-of-one trick to import keys with a dummy RSA operation.)

Still CAPI tried to provide an extensibility mechanism, using the notion of cryptographic service providers or CSPs. Applications did not simply ask to encrypt a message or compute a hash. Instead they firsted pick a CSP, which provided the implementation for set of algorithm and invoked the functionality through a consistent interface. (A similar extensibility mechanism was adopted later by openssl in the notion of engines.) While this made life slightly more cumbersome for consumers of cryptography– even simple tasks such as “hash this message with SHA1” required dozens of lines of code– on paper the model had significant advantages:

  • Support for new algorithms can be added by end users. In other words a third-party could author a CSP and install thiswithout waiting for MSFT to update the OS.
  • Default implementation of existing algorithms could be replaced. If a customer was concerned about side-channel attacks in the built-in RSA implementation, they could in principle write an improved version.
  • System-wide policies could be set on choice of algorithms. One could mandate that all applications that use hashing would pick SHA256 for example.

In reality it did not quite pan-out that way, for reasons beyond the scope of this post. But for our purposes the main feature is how smart cards were incorporated into the framework. Originally support for smart cards and custom cryptographic hardware such as HSMs were viewed as a special case of the second scenario. In this model each smartcard vendor writes a CSP tailored to the precise capabilities of their hardware. Customers would install that CSP on the machines where they planned to use that card.  Magically CAPI ensures that requests from existing applications– web browser, email client, VPN app etc.– are be transparently routed to the new CSP without changing the application. This is what the initial architecture looked like:

Diagram of Windows CSP

Original Windows CAPI architecture for smart-cards

[continued]

CP

Login with Facebook as .NET Passport V2, essentially

(Full disclosure: this blogger worked on Passport and its later incarnation Windows Live ID.)

Facebook is close to accomplishing what Microsoft set out to do with .NET Passport in the late 90s: become an identity provider trusted by the majority of popular websites.While recent usage/adoption statistics are difficult to come by, the increasing number of “login with Facebook” buttons popping up on sites ranging from Remember The Milk  to KickStarter suggests that companies representing all types of business segments are on board.

Facebook login may also the lone success story for identity federation– or to be more precise, federation in the consumer space. The enterprise scenario has received far more attention and enjoys an abundance of commercial solutions designed to solve a well-defined problem: employee Alice working at medium/large enterprise, typically a Windows shop running Active Directory, wants to use some cloud provider such as Salesforce. Main requirement is for Alice to login to that external resources using her existing Windows domain credentials, without managing a different username/password. SAML and its more Redmond-centric counterpart WS-Trust have been used with varying degrees of success to bridge that gap. What has never worked reliably is the consumer equivalent of that scenario: Alice using her Yahoo account to login to Twitter for example. There are isolated cases of interoperability, such as Remember The Milk also accepting login with Google identities, via combination of OpenID and oauth. But these are the happy exceptions. For the most part, each cloud provider stands in its own island of identity, with occasional one-off agreements and forays into federation experiments.

Except for Facebook. Starting with Facebook Connect, the service has seen increasing adoption of its identity system, with little under the guise of adding social features to websites. This is a far cry from the response to Passport when MSFT started pitching it around. Conceived from the beginning as an identity provider for the entire Internet– as opposed to merely all Microsoft properties, which would have been ambitious enough–  the service had little adoption. Expedia, originally spun out of MSFT, and eBay were among the few large sites accepting Passport logon along side their own identities. (Expedia would later phase out the service.) It was not for lack of trying either, at least on the Windows front.  For example, the IIS 6.0 web server in Windows Server 2003 had built-in support for Passport authentication at the HTTP level.

What was the difference? Several theories come to mind:

  • Better value proposition for relying parties. Passport provided identity and very little else. Granted there was an associated “profile” of user provided personal information. But there few forcing functions for that profile to be accurate (as opposed to “John Smith” living at zipcode 90210) comparable to the stringent real names requirement of Google Plus or the self-imposed convention followed by most Facebook users to represent their true name. Hailstorm aka .NET MyServices was the one ill-fated attempt by MSFT to attach large amounts of data and broker these to third-parties. That effort soon went up in flames. By contrast Facebook login brings an associated wealth of user-generated content, and even ability to post updates to the user timeline.
  • Fear of outsourcing in general. In this day and age of EC2 instances spun up on demand and sites scrapped together by mashing up third-party data feeds, it’s difficult to imagine a time when everyone insisted on running their own data-center and having full control of every feature in their service. That attitude, combined with an over-confidence that everything could be done better in house, predisposed developers against relying on some other authentication service. (The sheer number of password mishaps would prove them very wrong. It turns out the majority of those sites can better serve their users’ security if they delegate authentication to more competent entities.)
  • Fear of MSFT in particular. With diversified business interests in operating systems, productivity software, servers, gaming and entertainment, it is easy for any given website to consider MSFT a competitor, and shy away from entrusting a critical business function to the one company they are most concerned about.
  • Privacy concerns. Plenty of FUD, culminating with an EPIC complaint to FTC and other privacy advocacy groups did not help the matter. Facebook has arguably displaced MSFT as the great privacy boogeyman of the decade, but this was not true when Facebook Connect debuted in 2008, before the company got embroiled in multiple rounds of controversy around privacy of it own making.
  • Lack of standardization. Passport started out with a proprietary protocol, partly because there were few good options available for a web-based protocol that did not require changes to the web browser. Later Kerberos support was added but the corresponding functionality in browsers lagged behind. In principle Passport service could server as a Kerberos Domain Controller (KDC) compatible with Windows, and users could use Kerberos via the negotiate package supported by IE But the user experience for that would have been very restricted– it is a native dialog from the OS– compared to the full control that an HTML page gives the website for customizing the login experience. In any case WS-Trust and SAML followed soon with browser-aware profiles, and a few years later came the backlash against angle-brackets in the form of OpenID and Oauth. Facebook login is built on Oauth2.
  • Finally, one can’t rule out the passage of time helping out. Federated login was a foreign concept in 2000. It confused users: people had become so accustomed to having different identities at every site that they no longer expected their Hotmail credentials could also get them into their instant messaging client. Web site designers meanwhile had very little incentive to fix that, so they continued to put their own identity system front and center while offering federated login half-heartedly as a hidden option that required jumping through hoops. (Reflecting that lack of confidence, they hedged their bets and often required even federated users to also register a “native” account just in case the external identity system disappears overnight.)

CP

Smartphone as smart card– Android meets Windows

Continuing on the theme of using an Android smartphone as smart card, this post looks at how Windows interacts with smartcards and the moving pieces required to transparently substitute a phone for traditional smart-card scenarios such as login to the machine.

Windows has an elaborate smart card stack, with automatic discovery and installation for “drivers” (in quotes, because these are not kernel-mode device drivers in the traditional sense of mediating hardware access, but user-mode constructs that translate cryptography API features to low-level smart card commands)  This is described in great detail in the smart card mini driver specification on MSDN. For our purposes, there are two quick ways to observe how that stack reacts to an Android device in card emulation mode.

1. Using the GUI. Tapping the phone in card emulation mode against a contactless reader will trigger the driver discovery. This requires that the screen is on because Android ties card emulation state to the display being powered. (The screen does not have to be unlocked, although the built-in timeout that turns off the display after idling on the lock screen can lead to an abrupt disconnect.) This will lead to a sequence of device discovery notifications along the lines of:

DriverInstallInProgress    DeviceDriverNotInstalled

Clicking on the error message for additional details:

DriverInstallDetails

The implication is that the Android phone was recognized as a smart card. Windows 7 unsuccessfully tried to locate an appropriate driver, which includes a cloud check at Windows update, but there were no suitable candidates and the system eventually threw in the towel.

2. From the command line using certutil -scinfo, with the phone tapped against a contactless card reader. (Recall that the screen must be on, because Android ties card-emulation mode to the display being powered on.) Below is an example of what could happen:

UnknownSmartcard_AndroidSE

Parsing the rather verbose diagnostic output here, the takeaways are:

  • Windows treats the tap event as smart card being present in the reader. While the user gesture is different for contactless cards (tapping against the NFC surface instead of pushing the card into the reader slot) the PC/SC API abstracts aways that difference and unifies both under a card present event.
  • It observed an ATR (answer-to-reset) from the card of 3b 8a 80 01 00 31 c1 73  c8 40 00 00 90 00 90. Strictly speaking this is another case of playing loose with terminology: contactless cards do not have an ATR,  they have an answer-to-select or ATS. A quick search suggests this particular value is similar to ATRs returned from other versions of JCOP, consistent with the NXP hardware present on this particular Galaxy Nexus device.
  • Here is where it gets strange: the phone is categorized “Identity Device (NIST SP 800-73 [PIV])”– in other words, a card implementing the US government Personal Identity Verification standard. PIV is a successor to the Common Access Card, going back to a presidential directive from 2004 mandating strong identification requirements for federal employees. PIV is one of two smart card standards recognized out-of-the-box in Windows 7, the alternative being GIDS.
  • Problem is, a stock Android secure element initialized for Google Wallet has nothing to do with PIV. Attempting to treat it as a PIV card will not end well, as this example demonstrates. The error dialog appearing in front of the command prompt states the obvious: the “card” in question does not conform to the expected behavior. Without a PIV applet present, APDUs sent to the secure element will not produce expected outcome, eventually forcing the driver to give up.

This suggests two ways out of the current predicament of mismatched drivers:

  1. Getting the Android device to implement a PIV or GIDS, the two card edges recognized out of the box in Windows 7 without any middleware required. This effectively turns the current incorrect Windows assumption above into reality.
  2. Installing a driver that is specific to the Android device to avoid using the incorrect driver. While this will avoid the error messages, it turns out to be a dead-end. The primary beneficiary of the smart card stack is the cryptography API, which expects the card to have certain capabilities such as managing secret keys and credentials.  Without that functionality present in the secure element, the driver can not translate these requests into appropriate commands issued to the phone.

[continued]

CP

HP Envy Spectre and NFC– features missing in action

[continued from part I]

Not supporting card emulation mode in a laptop is understandable, given the absence of secure element and unwieldy form-factor. While it is possible to host-terminated card emulation without special purpose hardware, where traffic from the reader is routed to a garden-variety application running on Windows and emulating an ISO7816 card,  it’s difficult to imagine a practical use case for this. It’s one thing wielding a smart-phone against a point-of-sale terminal for mobile payments. It’s a completely different, unwieldy experience to recreate the same scenario using a 4-pound 14″ laptop where the antenna is located under the palm-rest.

More puzzling is lack of reader/writer mode. Long before NFC was a gee-whiz concept in consumer hardware, it was a standard feature in contactless smartcards used for high-security enterprise scenarios such as login, VPN and encryption. For example the US government PIV standard defines a subset of functionality accessible over NFC. Reader/writer mode exposed as PC/SC driver is a natural choice for that scenario, exposing PN533 as always present smart-card reader. As things stand, lack of reader mode rules out using an Android phone as smart-card replacement.

As for P2P mode, it can be flaky. This blogger was able to share links from the phone, using the standard Android beam functionality but the stack seems to get “wedged:” it will stop triggering Beam after a few attempts, or the Beam ritual will take place on Android but nothing happens on the laptop side.  Other reviewers noted they had problems with getting the feature working consistently; HP Touch to Share app for Android has more 1-star reviews than 5-star ones. Part of the challenge is that early versions instructed users to use that app for sharing links. But recent vintage  Android permits existing apps to share content via Beam. For example Chrome is designed to share link to the current web page, obviating the need for a special purpose application to transfer links. A recent update to the Windows side clarifies this, using a drop-down to toggle between the 2.3.X Gingerbread (still accounting for over 50% of devices) and more recent vintage 4.X phones:

HP_touch_to_share

Still the transfer works one way only– no way to send a link from the PC to the phone, a la Chrome to Phone— and it is limited to URLs, not contacts or other NDEF formats that Beam supports in principle. P2P is an overkill for such narrowly scoped use case, further restricting the target audience to users with Android NFC devices costing hundreds of dollars, instead of anyone who could get their hands on an NFC tag costing less than a dollar. (HP appears to have reversed course on this, supplying NFC tags with Spectre One.)

Overall one is left with the impression that NFC support in the Envy is scratching the surface. It is optimized for one narrow scenario, which turns out to not be very common and of limited utility, bordering on parlor-trick category. But the underlying hardware is capable of supporting a vast array of enterprise use cases, and while the Spectre is not aimed at that market, it contains hints of the broader potential of integrated NFC hardware.

CP

HP Spectre Envy and the case of hidden NFC

HP Spectre is arguably the first mass-produced laptop with an integrated NFC reader. While Lenova has reportedly experimented with NFC in a small number of their venerable business laptops, HP delivered the first off-the-shelf device for sale in the US. What follows are observations from experiments with this capability. These can be best summed up as a collection of surprises.

The first surprise is the extent that NFC is downplayed by the marketing literature. The product pages dedicated to the Spectre and its close cousin Spectre XT are not shy about their accolades, such as the CES 2012 award. But there is nary a mention of NFC anywhere on the page, not even in the product specifications. Main search results for NFC on the HP website refer to as-yet-unreleased Windows 8 tablet called Envy X2. Only a single support link on the right alludes to troubleshooting NFC for the Spectre. In fact there is more excitement about and references to NFC on external blog posts from January covering the product announcement and later full reviews. (HP has since also announced an all-in-one desktop with integrated NFC called Spectre One, that has been controversial for its iMac-inspired all metal styling.)

The next surprise is that exterior design does not advertise NFC either. It’s not that logos have been banished entirely in the service of some minimalist aesthetic:  there is a back-lit red icon for Beats audio, in case you missed that, and even a self-referential track pad symbol on the track pad. But there is no NFC icon to guide users towards the antenna location– under the palm-rest, immediately to the left of the trackpad as it turns out. This could be a usability problem. The “N” in NFC stands for “near” and for good reason:  tags, cards and smart-phones have to be placed right above the antenna in order to exchange data using that technology. That’s a challenge when users do not know where the antenna is located.

Incidentally the placement of said antenna faces a very strict constraint from physics: metal interferes with the ability to modulate the RF field. That leaves the palm-rest (which is a layer of Gorilla glass on top of plastic) and the capacitive surface of the trackpad as two logical options. The choice for the Spectre makes eminent sense for ergonomic reasons, compared to forcing the trackpad to do double-duty as NFC antenna. User may want to leave a tag/card/phone on top of the reader while continuing to interact with the machine. The same principle also argues against using the keyboard, screen or any other part of the user interface. One can imagine this is going to be challenging for Apple, as Macbooks have a signature all-metal exterior shell, with only two areas are exposed: the Apple logo on outside of the top lid, and the trackpad. Meanwhile MSFT threw in the towel when faced with the same problem, hinting they dropped NFC from the all-magnesium Surface tablet because of metal inteference.

Back to the Spectre: under the hood is the NFC controller PN533, produced by NXP Semiconductors. For comparison the majority of Android devices feature the PN544 from the same family, coupled to an embedded secure element also produced by NXP. Main difference here is there is no hardware SE inside the laptop. (Nor is there another viable candidate such as TPM or SIM card slot in the laptop that could be substituted using single-wire-protocol. )

In terms of the three NFC modes, the existing driver only exposes support for peer-to-peer mode. This is the second surprise, as it constrains usage in crucial ways.

[continued]

CP

Downgrading cookies, functional bit-rot and privacy

Taking a break from the series on Android and NFC to revisit a recurring theme: privacy features in web browsers.

It has been 10+ years since Internet Explorer introduced the notion of downgrading cookies, as part of P3P-based cookie management introduced with version 6. To recap: HTTP cookies are small identifiers used by websites to track users across multiple visits. In terms of lifetime, cookies come in two flavors. Persistent cookies— so called because the expectation is that they are stored on persistent storage such as disk drive for long term access– have a fixed expiration date specified by the website, which can be as far into the future as the year 2038. By contrast session cookies are intended to be temporary, getting automatically discarded when the user exists their web browser. (Strangely certain usage patterns where the browser is always left running, as in Chromebooks and even incarnations of Chrome on Android, means this “temporary” period can span days or weeks.)

Downgrading is the act of converting a persistent cookie into a session cookie, with one twist: lifetime of the cookie is bounded by the session and original expiration specified by the website, whichever occurs first. This was an explicit design goal to prevent a website from discriminating against users who employ the feature. It is relatively easy to detect when cookies are rejected altogether, and compel the user to modify their settings. If downgraded cookies outlived their stated expiration date, a website could likewise detect that their long-term tracking cookies were not being retained: set a cookie with a very short lifetime on the order of seconds and check if it is still being replayed after that time period elapses. Stopping this also guarantees compatibility: if websites can’t detect whether a cookie was accepted ,or downgraded, even when they go out of their way, using the feature will not break an existing website that was relying on cookies during that browsing session either.

Downgrading is used judiciously in IE default P3P settings, as middle-of-the-road response to unsatisfactory policies, preferable to outright rejecting the cookie which may break the site. Other browsers followed suit with comparable features. For instance Firefox has an option to delete cookies automatically when user exits the browser. Interestingly enough, IE never exposed an option in the UI to downgrade all persistent cookies regardless of P3P policy. (Downgrade option is not offered in the advanced privacy preferences dialog, but it is possible to import custom XML settings to do that. Here is an example ZIP file containing custom settings to downgrade all first & third-party cookies.)

What changed in the intervening 10 years? Main difference is that cookies are no longer the only ubiquitous tracking mechanism. Granted this was never true, even at the height of the great Internet privacy scare over cookies. Many creative ways to abuse other stateful mechanisms for tracking has been discovered, including DNS, visited sites history and page  cache. But these schemes all had limitations limiting their scaling.  Into the void stepped in Flash, with its local shared objects and later HTML5 standardizing similar capabilities with session storage and local storage, complete with the imprimatur of W3C. Both mechanisms present websites with functionality comparable to HTTP cookies. In fact LSOs are dubbed “Flash cookies” informally, and they have the feature/disadvantage (depending on perspective) of functioning across multiple browsers.

More importantly from a privacy perspective, both operate outside the purview of existing cookie controls. For example P3P policy evaluation is not used to limit access to the DOM storage or Flash cookies. Downgrading cookies has no effect when the same tracking identifier is also stored as Flash LSO or in local storage, which outlives the cookie. This is not a theoretical concern: a 2009 study from Berkeley found sites “resurrecting” deleted cookies from Flash counterparts. A follow up study in 2011 showed similar tracking behavior using HTML5 storage and even the HTTP cache.

Privacy features in the browser have not kept up with the new reality. There is no equivalent to downgrade option for converting persistent DOM storage into session storage. Nor is there any option to synchronize the lifetime of Flash LSO to cookies from the same origin, to prevent one from being used to respawn the other. There are crude mechanisms in place for viewing/deleting stored LSOs per website, and blacklisting sites from using Flash storage in the future. But these mechanism are proprietary to Flash, not influenced by existing browser privacy settings that are readily accessible to the user. For example importing custom privacy settings with a blacklist of sites can block them from using cookies, but has no impact on alternative tracking mechanisms. (In fact Flash settings have such haphazard UI, as embedded control inside a web page hosted on a Macromedia website that the authors felt compelled to add this helpful explanation: “The Settings Manager that you see above is not an  image; it is the actual Settings Manager itself.”) There is also the heavy-handed approach to private browsing which discards all state after the session ends– and even that was initially undermined by Flash, until Adobe kindly released an update in 2010.  Neither of these mechanisms permit fine-grained control where scope of tracking is limited based on website policies.

It is a case of bit-rot operating at higher level. Strictly speaking cookie management in IE is still operational in the sense that it works as advertised. Yet it no longer serves the original purpose of protecting users against tracking, because it has not been improved/expanded to cover alternative mechanism for infringing on user privacy.

CP

Your Android phone is also a smartcard

An earlier post discussed the three different modes supported by the NFC controller on Android devices. In this post we look at a surprising consequence of one of these: card emulation.

To recap: in card emulation mode, the NFC controller is directly attached to the embedded secure element on the device. Traffic is routed directly between SE and external NFC receiver– such as point of sale terminal, in the case of mobile payments with Google Wallet– without traversing the host operating system at all. In other words, Android is not in the picture for shuttling these bits, except for the supervisory actions of enabling/disabling card emulation mode.

As the name implies, in this state the phone looks like a traditional smartcard. An easy way to demonstrate this is using the built-in smartcard support in Windows for logon. Ingredients for this demo:

  • Recent vintage Windows PC running Vista or higher version of the operating system. Virtual machines are fine for this purpose.
  • Machine joined to an Active Directory domain (** It is also possible to do this using stand-alone PC but that requires installing third-party software.)
  • Contactless or dual-interface smartcard reader
  • Android phone running Google Wallet

When  smart-card reader is attached to a recent vintage Windows machine (Vista and later) joined to a domain networks, it presents the option to logon using a smartcard instead of a password:

Logon screen with password and smartcard options.

Clicking on the smart-card option, we are prompted to insert a smartcard:

Windows logon screen, requesting smart-card

At this point, turning the screen on and tapping it against the  contactless smart card reader leads to a flurry of activity, with the message “reading smartcard” briefly flashed under the tile, quickly followed by an error:

Error message showing no certificates found, during Windows logon

This is what might be called a succesful failure. Here is the sequence of events that transpired:

  1. Turning the screen on enables card-emulation mode on Android devices by default. (Note it is not necessary to unlock the screen, similar to how payments can be executed by tapping the point-of-sale terminal.)
  2. When the phone is introduced to the NFC field of the smartcard reader in this state, Windows smart-card service registers it as a card-present event.
  3. Appearance of a new card triggers a discovery process, to determine what type of card the user has introduced. End goal is picking a suitable smart-card driver. Because applications using smart-card operate in terms of higher level of abstractions such as certificates and cryptographic keys, drivers are required to translate these into low-level commands that each type of card understands.
  4. During the discovery process, the PC will exchange traffic over NFC with the secure element, to query its features.
  5. Driver discovery fails. This is not surprising– the “card” in question is used for contactless payments. It does not implement any of the standard card edges built into Windows 7/8 (PIV and GIDS) and neither does the answer-to-reset (ATR) identifier returned by the secure element
  6. Because no driver is located, the higher level application– in this case Windows logon– also fails in its attempt to locate credentials on the card, displaying the error in the last screenshot.

In the next post, we will look at another way to interact with an Android phone as smart-card, before posing the question: what if the emedded secure element did implement one of the recognized profiles such as PIV?

[continued]

CP

Why encryption would not have saved General Petraeus (part II)

[Second post in a series on why encryption is not the silver bullet for the case of General Petraeus and Paula Broadwell]

2. Encryption does not hide traffic patterns

The first half of this discussion centered on usability challenges of encrypting email with common cloud-based email providers, and how their web interfaces did not exactly help in this endeavor. It turns out that even for the very patient users willing to invest the extra effort and incur the overhead of setting up encryption, it would have made no difference against the type of surveillance FBI is believed to have conducted in this case.

First the threats sent by Ms. Broadwell to Ms. Kelley had to be readable by the recipient. Even if they were encrypted, Ms. Kelley would have voluntarily revealed their contents to law enforcement since it was at her urging that the FBI began investigating the source of these communications.  NBC coverage suggests that FBI only relied on location history for that account (IP addresses and timestamps) to determine the owner. In fact since it is described as an “anonymous” account, it is possible that Ms. Broadwell limited its use to sending those warning shots, never corresponding with other persons that could link the account to her true identity. In other words, the investigators had to rely on metadata for unmasking the sender.

Once Ms. Broadwell’s identity was established– presumably by obtaining access to other accounts accessed from the same IP addresses– law enforcement had access to correspondence sent from these additional accounts. Let’s suspend disbelief and assume that 100% of communications to/from that account were encrypted. This would not have prevented  obtaining metadata about other email addresses observed to be frequently communicating with Ms. Broadwell and performing similar analysis to establish the link to General Petraeus.

As several commentators pointed out, using an anonymizing proxy such as Tor— even when limited to the one-off email account– could have helped with obscuring IP addresses.

3. Encryption would have drawn more attention to the sender

In reality of course not all of the correspondence discovered in Ms. Broadwell’s account would be encrypted. Most of it is routine chatter with friends and associates that does not warrant the extra hassle of using cryptography. When only a few senders in the address book are using encryption, these contacts immediately stand out. Given Ms. Broadwell’s level of security clearance and access to the inner circle of national security leadership, it would have been an alarming discovery that she is corresponding with unknown individuals from a personal email account using strong cryptography.

It’s a murky picture around the question of whether individuals can be legally compelled to decrypt their own communications to aid an investigation. But once investigators had uncovered a frequent pattern of encrypted traffic between General Petraeus and a suspect in an investigation under suspicion of mishandling classified information, either or both sides of that exchange would come under enormorous pressure to come clean by revealing cleartext version of their correspondence– irrespective of whether they can be forced to, as matter of due process.

CP

Why encryption would not have saved General Petraeus (part I)

The resignation of General Petraeus in the aftermath of details emerging of his correspondence with Paula Broadwell has reinvigorated the debate around privacy of data entrusted to cloud service providers. EFF provided a good summary of discrepancies in existing law, where there are seemingly haphazard exceptions carved for communications stored for more than 180 days or already-opened messages– exceptions that may have made it easier for FBI to obtain access to email exchanges between the general and Ms. Broadwell.

A knee-jerk reaction here is to argue they should have been using encryption all along. But this calls to mind a statement variously attributed to Peter Neumann or Roger Needham: “If you think cryptography is the solution to your problem, you either don’t understand cryptography or you don’t understand your problem.” There are three reasons why encryption is particularly fraught with problems for this use case.

1. Usability challenges. Web email providers for the most part have little or no integration with client-side encryption schemes, such as S/MIME or PGP. The average user of these services has no way to compose an email that is not going to be readable by both the sender and recipient services. This limitation is not to be confused with encryption of content to/from the user to the service. Protecting those links with SSL is standard practice today. (Although that in itself is a relatively new phenomenon– GMail lead the way among major providers by switching on SSL by default in 2010 in the aftermath of the China incident, although niche services such as Hushmail supported SSL going much earlier.)

Part of the fault lies with web browsers: they do not make it easy to exercise the cryptographic capabilities of the underlying OS in a platform-independent way. Speaking of Hushmail, that was an example of an attempt at overcoming the browser limitations using a custom Java-based solution itself authored by Hushmail and later implementing cryptographer server side. In the end it only proved the limitations of the model: because encryption code was provided by Hushmail itself (as opposed to being part of software locally installed on end user machine) at the behest of law enforcement it could be replaced by a Trojaned version that surrendered key material.

It is possible to indirectly use S/MIME or PGP by having a native client installed on the local machine. (Also called “rich client” in come circles, casting aspersions at the quality of web based user-interfaces) Examples of these are Outlook, Mozilla Thunderbird and Eudora. These applications either have built-in support or define an extension mechanism for third-parties to implement strong cryptography. They can also be configured to work with popular cloud providers such as Yahoo or GMail for sending/receiving email.

In this model, the email provider becomes glorified storage box for encrypted content. It has zero visibility into the content of messages exchanged, only seeing an opaque stream of unintelligible ciphertext. The privacy goal is achieved, but at what cost? Encrypted messages can only be sent from machines where email clients are setup and cryptographic keys available. The first limitation means that it is not possible to point any old web browser at mail.google.com to read email. Encrypted messages will appear with blank contents, with the actual ciphertext in an attachment that the service provider can not make sense of. Search over email contents will not work– since original message is not available, it can not be indexed. (Neither will ad targetting, but that is arguably a problem the user cares less about.)

There is also the problem of key management but in this regard General Petraeus and Ms. Broadwell were fortunate. As defense employees, they would be in possession of PIV cards, which are smart-cards that can store cryptographic keys for different purposes: authentication, digital signatures, encryption and even physical access with badge readers. Moreover the widespread use of PIV card for logical access has motivated different vendors to make sure their platform makes it easy to use the cards. Case in point: PIV support is built into Windows 7 with no additional middleware required. In the most likely scenario of two users running Outlook on a recent vintage Windows machine, signing or decrypting a message would be as easy as inserting the card into the reader and typing in the PIN. For two random users without the benefit of a government issued smartcard or an ecosystem shaped by market pressures to support that card, it would be a different magnitude of difficulty trying to decrypt messages on another machine.

[continued]

CP