Supply chain security, bogus smart cards and Global Platform

An interesting story from past week was IOActive expose on counterfeit chips. The researchers found that a “secure microprocessor” ordered from an online market place proved to be a lower-end version of the same hardware line, dressed up as the more capable/expensive product in a clear instance of hardware tampering. While in this case the modifications appear to be motivated by cost-saving– selling the lower-end hardware at higher price-point– the authors use the incident as starting point to ask:

If it is so easy to taint the supply chain and introduce fraudulently marked microprocessors, how hard is it to insert less
obvious – more insidious – changes to the chips? For example, what if a batch of ST19XT34 chips had been modified to weaken the DES/triple-DES capabilities of  the chip, or perhaps the random number generator was rigged with a more predictable pseudo random algorithm – such that an organized crime unit or government entity could trivially decode communications or replay transactions?

This is not the first time that the integrity of supply chain has been questioned, but it is notable for involving cryptographic hardware. What  the article does not mention is that many smart cards, embedded secure elements and similar hardware trusted execution environments have additional cryptographic properties that can be used for verifying their authenticity.

To take one example: Global Platform is a standard for managing smart cards and for lack of a better word, “card-like” gadgets such as USB tokens, SIM cards in cell phones and more recently the embedded secure elements on Android devices. Global Platform calls for each card to be provisioned with a unique set of keys used to authenticate the Issuer Security Domain or ISD. (In some instances there can be more than one ISD key– an earlier post about the Android secure element noted PN65N models have 4 key slots.) The keys are injected by the hardware manufacturer at fabrication time, and then transferred over to a Trusted Services Manager or TSM, responsible for managing the contents of the smart card. This can be done either by handing over big list of individual keys, or more commonly using a diversification scheme. In the latter case, manufacturer and TSM share a global seed key which is used to derive individual keys based on the card ID.

When the TSM wants to remotely install an application, there is a mutual authentication process laid out by GP that is carried out between the TSM and smart card. After running through the steps of the protocol, the TSM is assured  that it is talking to a genuine card provisioned with the right ISD keys, and the card is assured that it is receiving commands from an authorized TSM. Outcome is an authenticated and encrypted channel between the two parties who may be separated by a continent; the TSM could be website hosted in the US while the “smart card” is a SIM inside a phone travelling around Africa. With some caveats, GP secure messaging ensures that commands issued by the TSM can not be read or tampered with by any other party with access to the communication channel along the way. For example the TSM can guarantee that an EMV chip & PIN application is being installed on a proper smart card, and sensitive information such as card details used for payment will only be available inside that locked down environment. Garden-variety hardware counterfeiting is ruled out in this scenario. If the supply chain had been poisoned with bogus SIM cards, these cards would not have the correct ISD keys. Without being able to authenticate to the TSM, they would never get as far as receiving the credit card data.

But this is a far cry from saying that GP solves all hardware tampering issues. In particular three classes of problems remain:

  • Hardware already configured for use. If a card arrives from the manufacturer fully configured with no additional TSM involvement or provisioning necessary, Global Platform does not help. This is often the case for hardware tokens delivered to an enterprise: the manufacturer simply ships a batch of cards already configured with all necessary functionality. Customer does not have ISD keys for additional confirmation of card integrity. (Granted having possession of ISD keys can also become a liability, since it allows tampering with card applications. Luckily GP also defines supplementary security domains that can be used to authenticate compliant cards without privileges for modifying them.)
  • More complex counterfeiting, where the bogus chip contains a fully functional instance of the real hardware. This is easier than it looks because the physical form factor of most smart cards are huge in relation to the size of the circuitry inside. Inert plastic or air makes up the bulk of the volume, leaving plenty of room for sneaking in additional circuits. In this case, the counterfeit chip can execute a man-in-the-middle attack on communication with the card. While GP protects provisioning of functionality and data, it does not protect ordinary usage by end user. Credit card details sent encrypted remain safe from eavesdropping because the TSM-card communication takes place over secure messaging sessions. The same is not true of user PIN sent in the clear by the ordinary host application using the card.
  • Actual breach of tamper resistance. If ISD keys could be recovered from the authentic chip, one can create a full-replica with the same keys that is  indistinguishable for Global Platform purposes. But such an attack is far more difficult than merely substituting a look-alike unit. If the card has decent hardware and software security, key extraction will require substantial time, effort and specialized equipment. This makes it impractical to scale the attack to large volume of units.

— Cem

PIV, GIDS, home brew: choosing a smart card standard (2/2)

[continued from part I]

PIV and GIDS are the two smart card standards, or card edges, built into Windows 7. Earlier post in this series covered how the built-in discovery mechanism will try to check for both applications using their well-known AID when encountering an unfamiliar card for the first time. For those looking for a smart card solution with minimum hassle, that sound promising. No drivers or middleware installation required, not even behind the scenes installation from Windows Update. Implicitly one would also assume MSFT has tests their own applications– VPN, BitLocker-To-Go disk encryption, Kerberos smart card logon, TLS client authentication in Internet Explorer– end-to-end for these types of cards. In steady state, once cards have already been configured with the appropriate credentials, this assumption holds. The catch is, using a smart card is only part of the equation. Before reaching that point, the card must be configured with the type of cryptographic keys and credentials for the required scenario. For example VPN usually calls for an RSA key and associated X509 digital certificate.

PIV as defined by NIST SP 800-73 part I has the curious property that key-generation and loading certificates on the card requires the application administrator role, as distinct from card-holder role. While ordinary card operations such as signing a document calls for the user to enter his/her PIN, authenticating as the administrator typically calls for using a special RSA key or set of diversified symmetric keys which belong to the organization handing out the cards. End users typically do not have access to these credentials and can not load new credentials on the card without some help from the IT department. That has important implications for provisioning. For example it rules out the straight-forward enrollment option by visiting a web page that uses HTML keygen tag or the proprietary cenroll ActiveX control for Windows Certificate Server web-enrollment. Similarly the MSDN instructions for creating a self-signed certificate for use with BitLocker will not work on a PIV card.

On the bright side, requiring administrative privileges avoid certain maintenance head-aches. Because users can not muck with the contents of a card once issued, that may translate into fewer help-desk calls to replace/re-issue broken cards. That may have been the motivating factor behind this aspect of PIV design. (But then again, if users are allowed to run arbitrary software against the card, they can still brick it.) Otherwise the security advantages of such restrictions seem minor. Any attack that depends on users replacing the keys/certificates on a card, perhaps to take advantage of some vulnerability in the certificate validation logic somewhere, could also be implemented using bogus cards that do not obey PIV restrictions. One can argue that limiting the functionality of valid PIV cards makes the forgery of such attack cards a little more difficult, since attackers must also replicate the physical appearance of authentic cards.

The other major disadvantage is that properly configuring PIV cards requires separate middleware, usually locked into a particular vendor of cards. In other words, all that functionality built-into Windows for making PIV cards work seamlessly– a major requirement for government and defense customers– only applies to using existing credentials already on the card, not provisioning them in the first place.

That brings us to the second option supported out-of-the-box in Windows: GIDS or Generic Identity Device Specification backed primarily by MSFT and Oberthur. GIDS has functionality similar to PIV at a high-level. GIDS-compliant cards can generate and store multiple key-pairs of common algorithm types (RSA and ECC with standard NIST curves), perform cryptographic operations such as signing and decryption using these keys subject to PIN entry. They can also store auxiliary data including X509 certificates associated with the keys. Big advantage is that GIDS permits provisioning operations to be carried out with user PIN, allowing for self-service models.

At first that sounds like a decisive argument for going with GIDS. Returning to the original question, a user armed with a GIDS card can generate a self-signed certificate suitable for BitLocker by following exactly the steps in that MSDN article. The downsides are:

  • PIV is by far more common. That in itself is not an argument about the merits of either standard, but it does translate into a more competitive market with greater choice of  hardware, including in other form factors such as USB tokens. By contrast few vendors ship GIDS cards. (There are understandable reasons for this: PIV is a US federal standard mandated by the government, and it also predates GIDS by a couple of years.)
  • PIV enjoys better cross-platform support. While OS X and Linux never had very good smart  card support to begin with, the requirements from US government customers has forced vendors to at least implement basic support. There is even an Android application for reading basic information from PIV cards over NFC.
  • A certification model exists for PIV cards, with independent labs testing cards submitted by vendors. NIST maintains list of products certified under FIPS 140 and the security-level they were certified for. (This assumes that a formal certification process helps improve product quality in the long run– a premise some disagree with.)
  • Finally PIV has applications beyond logical access control. For example there is an entire suite of products for controlling building access with badge-readers that speak the PIV standard. No similar ecosystem of hardware and software exists for GIDS yet.

CP

PIV, GIDS, home brew: choosing a smart card standard (1/2)

“The great thing about standards is that there are so many to choose from.”

Trying to pick a smart card for enterprise deployment recalls to mind this particular aphorism. This may be surprising for a technology that is over 30 years old, boasting large-scale real-world implementations thanks to wireless carriers (SIM cards) and payment networks (EMV chip & PIN.) Sure enough many aspects of the technology are standardized: ISO standard 7810 defines the physical characteristics of cards, while ISO7816 lays down the law when it comes to contacts and electrical properties. JavaCard and .NET Card are popular runtime environments for programming cards with custom applications. Meanwhile It is not only the internals of the card that have inspired thousands of pages of specifications. ISO7816 also defines low-level communication between a card and reader,  Global Platform is de facto standard for managing card contents and more recently ISO 14443 extends this to contactless cards using NFC. Even at the programming layer outside the card, PC/SC API defined by Microsoft in the late 1990s has been ported to Linux and OS X to allow portable way of writing desktop applications to use smart cards.

With all of these acronyms and specifications published by august standardization bodies, one would expect that the technology has now become commoditized to the point that one can just pick up a particular smart card  from any manufacturer and expect to use it for any scenario: login to a computer, sign your email, encrypt documents against theft. It turns out that instead the incompatibility has been successfully moved up the stack to the “last hop,” where there is a gap between the abstraction of a “smart card” that PC applications are written against, and the actual functionality loaded on the cards.

To take an illustrative example: earlier posts discussed the notion of using BitLocker-To-Go with smart cards to encrypt removable media. The question is, what type of smart card? (Side note on terminology: we group USB tokens that appear as combined card + reader such as Goldkey, in the same category, since the form factor does not change the software interoperability story.) Can users walk into a store or better yet order cards from a website that are guaranteed to work with minimal hassle? That turns out to be a surprisingly complex story, that depends not only on the functionality present on the card but the presence of appropriate middleware. The first part may seem obvious– given the way BitLocker works, the card must be capable of storing digital certificates and performing public-key decryption operations in order to unlock protected volumes. The unexpected part is that even cards meeting this criteria may not be usable without additional middleware, or in some cases, not usable at all.

The first observation is that most applications (including the OS component responsible for BitLocker disk encryption) do not deal directly with smart cards. Instead they go through an abstraction layer , described in earlier posts [1, 2 & 3] responsible for presenting a common interface for different types of hardware. This is accomplished by having drivers, corresponding to each type of card, combined with a plug-and-play mechanism for mapping drivers to cards. It follows that a necessary but not sufficient requirement to use a given card for general purpose applications on Windows is that appropriate drivers are installed. Note that “general-purpose” is the operative qualifier here: often times a vendor will provide hardware to be used with one specific application, also vendor-written and tailored to that hardware. In that model anything-goes, as the standard smart card stack is not in the picture. Aside from the obvious problem of vendor lock-in and lack of transparency, that approach will not fly when trying to leverage existing applications such as built-in VPN client, BitLocker or Outlook. In the best case, the drivers can be downloaded from Windows Update automatically when the card is used for the first time, using the ATR or a proprietary discovery applet defined by MSFT. But that requires a manufacturer willing to go to the trouble of getting their driver certified by Windows Hardware Quality Labs (WHQL). More likely the vendor will take the path of least resistance and distribute drivers via a proprietary channel such as their own website instead. That model might scale if the machines where the card will be used is known in advance. It  runs into trouble when the user walks up to a brand new machine that has not been set up in advanced.

All of these edge-cases might warrant going with smart card profiles where the driver is already present in the OS out-of-the-box. Starting with Windows 7, PIV and GIDS drivers are built-in. The second post in this series will look at the arguments for and against these.

[continued]

CP

Not the ideal poster-child for CFAA reform

Is it an odd coincidence that all of the milestone, precedent-setting court cases around controversial laws have involved highly unsavory characters in the hot seat, being vigorously defended by organizations with impeccable reputation for taking principled stands? First there was Lori Drew, who  bullied a teen-aged girl into suicide on Facebook on behalf of her daughter, to settle some high-school social scene vendetta. She was prosecuted for terms-of-use (TOU) violation on MySpace– remember that other social network?– and eventually acquitted on appeal. Now there is Andrew Auernheimer, better known by the handle weev,  Internet troll and self-described “hacker,” getting handed down a hefty sentence for his role in the AT&T attack leading to disclosure of private information on iPad owners. In some circles, he has become a cause célèbre already, lionized in the hero-as-outlaw stereotype. EFF quickly jumped into the fray to announce that it would be joining the defense attorneys for the appeal. (With apologies to Godwin’s Law, the whole episode has echoes of the ACLU Skokie controversy from 1977.) For all the parallels that the self-martyrizing Mr. Auernheimer tried to draw between his case and that of Aaron Swartz, there is no comparison: Mr. Swartz was a widely respected and popular figure promoting open access. Auernheimer has an extensive rap sheet that includes intimidation, harassment and denial-of-service attacks.

It’s as if advocacy organizations decided to over-compensate for their failure to help Aaron Swartz by pledging their loyalty at all costs to the next defendant picked out of a hat, and much to their chagrin were handed a second-rate cartoon villain as their figurehead.

On the one hand, schadenfreude is easy when the likes of Ms. Drew and Mr. Auernheimer get their karmic comeuppance. If anything there is a degree of disappointment that Ms. Drew managed to get away with a tarnished reputation only, without any penalties under the law. Her more recent counterpart did not quite walk away scot-free. On the other hand, there is that problem of principle. This case was prosecuted under the Computer Fraud & Abuse Act or CFAA, dubbed “the most outrageous law you’ve never heard of” by Tim Wu in a recent New Yorker article.  Badly decided litigation can establish precedent, and cast a long shadow over future cases, or even deter beneficial security research out of fear of similar lawsuits. Several researchers have hinted that Aurenheimer’s fate will create chilling effects for legitimate research.  But it is difficult to see the events as the downfall of a good-intentioned security researcher punished by an ungrateful, retaliatory vendor.

As many commentators noted, the vulnerability itself was laughably simple: manipulating a URL  gives unauthorized access to other people’s data. Changing numbers using nothing more sophisticated than a web browser and keyboard yielded personal information. AT&T failed at web security 101. But the ease of discovering vulnerability has never been a measure of good intent. The pertinent question is what is done after the discovery of the flaw. There is a long-standing debate over the meaning of “responsible disclosure.” It centers around the question of exactly how researchers can minimize user harm and create right incentives for vendors. Go public immediately, wait as long it is necessary for the vendor to deploy mitigations or give them an ultimatum with fixed deadline? The argument rages on. Auernheimer deserves the benefit of the doubt for his utilitarian argument that shaming AT&T by going public is the most effective way to get averted similar mistakes in the future– nothing impresses the value of security on developers quite as forcefully as living through a public incident. (The vulnerability was already fixed by AT&T before disclosure, and Gawker redacted the data set appropriately in their coverage.)

But a bright line does exist between doing vulnerability/exploit research (the two are intricately linked) verses using the exploits at large scale indiscriminately against bystanders. It is one thing to note that AT&T website has an obvious vulnerability or even running a few examples to verify this. Hosted services being blackboxes with no visibility into their internal structure, discovering such a vulnerability usually requires trying an “exploit” against a live site containing user data, and accidentally stumbling on other people’s information. Call it collateral damage. So far, so good– this is well within the realm of garden-variety web security research. But Mr. Auernheimer crossed the line when he ran an exhaustive search using the vulnerability to extract data for 100K+ iPad users, save all of it (merely counting the number of vulnerable records had a fighting chance of being called “research”) and hand over the entire dump to Gawker. This is difficult to file away under the guise of intellectual curiosity. Many researchers find vulnerabilities on popular software running on millions of computer, without feeling compelled to go find and compromise all of those machines with their exploit. More concretely, exploit writers specializing in IE or Firefox bugs do not , generally speaking, run their exploit against thousands of IE/Firefox users and collect a trophy from each one before disclosing their findings to the press.

There is no question that CFAA is outdated, utterly divorced from the complexities of online security today and plain dangerous. It is an instrument of  selective justice, subject to egregious overreach and prosecutorial bullying in the hands of public officials with creative theories of criminality. The Aaron Swartz case drove that point forcefully. One can only hope that weev’s highly dubious case and incoherent post-hoc rationalizations will not distract from the true arguments for overhauling CFAA.

CP

Sacrificial first login, or coping with sites who fail at SSL

SSL/TLS adoption has received several boosts in the past couple of years. It was almost three years ago that GMail switched its default to SSL, a move soon emulated by other leading email providers, and services such as Facebook and Twitter. Meanwhile the IETF worked to standardize HTTP Strict Transport Security or HSTS, which allows websites to declare that all of their content will use SSL, preempting any attempts to downgrade users to unprotected traffic. In spite of these advances there are still many sites who manage to use SSL incorrectly and jeopardize users.Exhibit A: WordPress, which also happens to be hosting service provider for this blog. WordPress home page contains a login form but is not served over SSL:

WordPress home page, with login form

WordPress home page, with login form served in the clear

One might argue this is acceptable, as long as the password submission itself takes place over SSL. After all, there are two distinct communications with the website for signing in. First the web browser retrieves the login page containing username and password fields. After the user fills in the required information, a second request is made to the website carrying those credentials.  Perhaps all is well as long as that second step takes place over SSL? This was in fact the argument advanced by many financial institutions several years ago, when they had the exact same setup with login pages served in the clear.

But that reasoning is flawed. It ignores the possibility of active attacks. Unlike a passive attack where the bad guys are content to merely watch the traffic fly by, an active attacker can also modify it. If the first page was not sent to the browser over SSL, it is susceptible to such tampering. There is no guarantee that what the web browser is displaying the authentic login page that WordPress intended for them to see. For all we know, a miscreant on the network could have modified it with a backdoor which takes a copy of the password, sneaks it away n the background to a server in Russia, before submitting it to the legitimate site to complete the login process as if nothing was wrong.

This is a useful demonstration of how integrity is as important as confidentiality. SSL is often employed to keep sensitive information from prying eyes, on its way from the user to the website or vice verse. But it is equally important to guarantee that content, such as script implementing sensitive application logic, is not modified along the way.

In practical terms, that leaves users with a quandary. Starting at a login page such as WordPress above, it is not possible to determine if the credentials are  going to be handled properly or if the page has been back-doored with malicious javascript. Obvious solutions such as view-source on the page to verify form submission URL do not work– not that one would reasonably expect users to go to that trouble. Script lurking on the page can alter the form at any point in time or read out the password field as the user is typing. There is no way, short of auditing every single line of Javascript loaded into that page, to know what is going to happen.

Luckily there are two workarounds for dealing with these websites:

1. Try to load the page over SSL, by editing the address bar to add that all-important  letter “S” before the column. (Ideally, book-marking this final URL, to avoid error prone manual URL crafting in the future.) This may not always work, as some websites will redirect their “non-sensitive” pages back to regular HTTP even if they are accessed over SSL. WordPress is an interesting example in this regard. Navigating to https://wordpress.com indeed results in a secure connection. But type https://www.wordpress.com and the site dutifully redirects back to the plain HTTP version subject to man-in-the-middle attack.

Another example is the download location for IronPython, a Python interpreter for Windows. This particular software package is served over HTTP by default. (It also happens to lack any Authenticode signatures–arguably a bigger blunder, since code-signing would have obviated the need for SSL, but that is another story.) Luckily reloading the same page with HTTPS also leads to a download link  for the same package over HTTPS.

2. Enter a bogus username and password. Let’s call these the sacrificial credentials. If the login page is indeed working as intended, these will be submitted over SSL and the website will display an error page informing the user that login failed. That page is likely displayed over SSL and now contains another copy of the login form to retry:

Sign-in error with login form, returned over secure connection.

Sign-in error with login form, returned over secure connection.

Caveat: this behavior is not guaranteed either– websites could choose to redirect the user back to HTTP to render the error page. Fortunately the path of least resistance is to return the error message on the original SSL request. This gives users a fighting chance to inspect the URL and decide if they are on the right page. (After all, in a true attack scenario, the attacker could respond to the bogus credentials with a back-doored error page as well. But at least web browser security indicators such as the address bar will be meaningful when looking at SSL.)

The “right thing” of course is for the site to avoid this vulnerable pattern and display any page containing a login form over SSL. Sites that can afford to serve all of their pages over SSL can go one step further and use HSTS feature to declare that. Because this setting operates at the entire site level, it is not possible to single out specific pages however, ruling out its use for sites who want to keep some content in the clear for capacity reasons.

CP

Jailbreaking and the distorted economics of phone subsidies

Raging against subsidies– farm, oil, coal– is back with a vengeance. To the list of economic distortions caused by funny accounting, add one more example of collateral damage: freedom to jail-break our devices . At the heart of the successful CTIA campaign against renewing the DMCA exemption for jail-breaking devices are the opposing interests of the consumer and those of the mobile carrier.

To get a better picture of this conflict, one needs to appreciate the pecking order in the mobile ecosystem. When a consumer uses an application on their phone that connects to the Internet, there are many players involved making this possible. Some of them are highly visible with brand recognition, others are unsung heroes. There is the handset manufacturer producing the hardware (say Samsung for Galaxy S3) who sources parts from multiple suppliers (ARM processor, baseband radio from Qualcomm, wireless chipset from Broadcom, NFC controller from NXP etc.), the vendor producing the operating system (Google for Android, Apple for iOS), finally the third-party developer who authored the application and last but not least, the wireless carrier or “mobile network operator” providing the pipes for voice and data traffic.

Among these different actors, there is no question that carriers are calling the shots– at least in the US. It is relatively easy to see this by both following the money trail. On average users change phones every 18 months, which might mean about $600 for the handset manufacturer, from which the various component suppliers get bits and scraps. By contrast with the average US cell phone spending hovering north of $100, the carrier will collect $1800 from the same subscriber over that time span. Worse the profits margins for hardware are razor-thin. Carriers on the other hand are monetizing upfront investments in spectrum and infrastructure, with low marginal cost. They can command high prices on low-cost services such as text messaging or ring tones.(As for the per-user revenue accruing to the OS manufacturer or third-party app developers, it would not even register on this scale.) Finally the carriers maintain strong control over the distribution channel. Traditionally most subscribers purchased their phone directly from a retail location affiliated with the carrier. Even when the phone was sold through a third-party such as BestBuy, it often came bundled with a wireless plan. It was the iPhone that managed to pry open this model, by offering devices at sleek Apple Stores, initially still tethered to AT&T but later directly selling unlocked phones at full price, a model also followed by Google for Google Experience Devices.

There are two closely related uses of jail-breaking: First is getting additional privileges on a device, to perform certain operations that are normally not permitted by the operating system. For example on certain Android devices, this includes enabling tethering or running Google Wallet. Second motivation is taking the phone over to a different mobile carrier than the one it was initially bought under, for example by swapping SIM cards. Often this requires the escalated privileges because the software is “locked” down to only accept the original carrier.

In both cases, there is a direct conflict between the user intent and the carrier. The first case can be subtle, as when carriers label certain applications such as Skype as “undesirable,” because they strain network capacity (according to the oft-advanced claim for VoIP) or otherwise work against the carrier profitability. The second case is a more clear-cut instance of creating customer lock-in. Preventing the device from working with a different network raises the costs to the customer of switching: at a minimum they need to spring for a replacement phone– assuming they can even get the same hardware. As the original exclusivity of iPhone to AT&T demonstrates, if the user is wedded to owning a particular model they may not even have the option to purchase it from a competing carrier at any price.

On the one hand, it is easy to get indignant about this. The consumer paid for the device, the argument goes, so they should have the freedom to do anything they please, including novel modifications not envisioned by the manufacturer. Arbitrary restrictions harken back to the conflict between general purpose computers and specialized appliances described eloquently by Jonathan Zittrain in The future of the Internet and how to stop it.

The problem is, the consumer did not pay for the device, at least not initially. Carriers have a legitimate point: in most cases the phone is sold at below cost, with the expectation that monthly charges for service will eventually cover it. This is the basic distortion created by subsidizing the phone with recurring subscription. The mobile network operator does have a legitimate claim on deciding the fate of the device, at least from the start when it is effectively “loaned” to the subscribers with the intention that it will be paid off over time.

More troubling, this bargain is never spelled out transparently, and subscribers are rarely offered a meaningful chance to negotiate. Long after the mandatory 12 or 24 month period of the contract runs out (and one assumes, the hardware is already paid off and then some) the user does not earn the privilege to unlock their device. Often there is not even an option to pay full price at the outset, in exchange for greater freedom– which would count as a fair deal. While gray-market unlocked phones were always available, it is only in recent history that this avenue of distribution has been legitimized. The result is the current mess: restrictions against user freedom and heavy-handed attempts to enforce these fundamentally unenforceable restrictions with legislation mismatched to the task. DMCA is putatively concerned with copyright. Regardless of one’s opinion on its suitability for that job, there is little room for debate that it was never intended as a tool for protecting carrier revenue streams from disruption.

One hopeful sign is the growth of alternative distribution channels, emphasizing the hardware over the carrier. This is something that HTC, Samsung, LG etc. would welcome, as an opportunity for devices to finally compete on their own merits– both in features and price– instead of carrier affiliation or extent of subsidies hiding the true costs from consumers.

CP

CNet NFC wishlist and status quo

Jessica Dolcourt over at CNet has recently published a wishlist called 6 things I want to do with NFC. Here is quick look at the list and how far existing incarnations of the technology are from getting there:

1. Transfer photos, video and music from any device. Android users might reply with “already there.” Android Beam was first introduced in ICS and later expanded to support larger file transfers by using the initial NFC tap to bootstrap a Bluetooth connection. (Because NFC bandwidth is lower and requires keeping the devices in close contact, Bluetooth or 802.11 wireless are preferable for transmitting large amounts of data.) But the author is asking for more widespread adoption for Beam-style transfer, including on cameras and laptops. As covered in this blog, HP Envy Spectre laptops boast an NFC controller configured in peer-to-peer mode compatible with Android Beam. But the feature can be flaky, which CNet has also noted.

2. Control a car with NFC. The description of this scenario is vague, but can be interpreted as variations on the peer-to-peer transfer capability: transferring contacts, using the car speakers for audio playback or sending an address to the onboard navigation system. (Assuming those will still be around– it’s difficult to justify their price considering driving directions are included for free on Android and iOS now.)

3. Replacing the ATM card. Not to be confused with replacing a credit card— already doable with Google Wallet— this one refers to ATM withdrawals for cash. Chip & PIN cards used in Europe for ATM withdrawals are currently based on contact technology. In principle the same protocol can run over NFC, but a few tweaks would be required to avoid pitfalls of direct translation, such as sending PIN over NFC without encryption. Also depending on the form factor of the NFC device, different user experiences are possible. If the “card” happens to be a full-fledged smartphone there is no need for external PIN entry; that can be handled on the phone itself. As a side-effect that could frustrate certain ATM skimming attacks, which rely on capturing user PIN with a camera or keypad overlay.

4. Help with shopping:

In a supermarket, sporting goods store, or DIY home improvement store, NFC could pop up a mobile site that helps you locate items by aisle, track down a salesperson, and surface coupons or deals.

Perhaps but such location-based services can also be handled based on GPS and indoor mapping technologies. Why require explicit user action at the store– also asking for a roll-out of NFC tags by merchants– if the phone can already determine where the user is and display helpful, contextual information?

5. Check-in for events:

It’d be wonderful to use those details to check yourself into appointments at hospitals, sporting events, concerts, the DMV, and airport kiosks.

Also eminently doable today, considering that many festivals including Outside Lands already use NFC tags for passes. Main challenge with extending this to more sensitive scenarios such as DMV and airport check-in would be the security level achievable with a mobile device only. NFC combined with a secure element could take the phone out of the security equation, and offer high degree of assurance against mobile malware. That said, boarding passes can already be delivered as PDF files in email for display on smart phones, all without the benefit of any specialized hardware. As long as additional checks are present– showing government issued ID and inevitable TSA checkpoints, in the case of transportation– merely starting the process with NFC tap is not necessarily more risky.

6. “Stay on the side of convenience.” Another vague requirement, this appears to be a call for interoperability and avoiding specialized mobile apps for standard functionality such as sharing. This could be a dig at HP for publishing a custom Android application for their version of touch-to-share. In fairness, that was mainly an artifact of supporting Gingerbread, where Android did not have a flexible mechanism for third-party developers to use peer-to-peer mode. Starting with ICS the platform makes it much easier for applications to opt into Beam, and content from built-in apps can be shared in an intuitive manner: for example Chrome will share current URL, Contacts will transfer the contact details and YouTube will send a link to the video.

CP

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