Has Bluetooth Become Secure?

Bluetooth has a bad reputation when it comes to security. Many vulnerabilities have been found over the years in the technology, and many successful attacks have been demonstrated against it. But the Bluetooth specification has also changed much over the years, and each revision of the specification has made substantial changes to the Bluetooth security protocols. Whether the latest protocols are secure is a question open to debate. This question is especially important when Bluetooth is used in emerging medical and Internet-of-Things applications where security flaws have safety implications. But it has also come up recently in the context of the Derived Credentials being standardized by NIST for authentication of Federal employees who use mobile devices.

(This is a continuation of the last two posts, which reported on the recent NIST Workshop on PIV-Related Special Publications. It is also the last of a seven-part series of posts discussing the public comments on Draft SP 800-157: Guidelines for Derived Personal Identity Verification (PIV) Credentials, and the final version of the publication. Links to all the posts in the series can be found here.)

Before tackling the question of whether Bluetooth is secure today, Continue reading “Has Bluetooth Become Secure?”

Highlights of the NIST Worshop on PIV-Related Special Publications

This is Part 5 of a series discussing the public comments on Draft NIST SP 800-157, Guidelines for Derived Personal Identity Verification (PIV) Credentials and the final version of the publication. Links to all the posts in the series can be found here.

On March 3-4, NIST held a Workshop on Upcoming Special Publications Supporting FIPS 201-2. The FIPS 201 standard, Personal Identity Verification (PIV) of Federal Employees and Contractors, leaves out many details to be specified in a large number of Special Publications (SPs). The purpose of the workshop was to discuss SPs being added or revised to achieve alignment with version 2 of the standard, FIPS 201-2, which was issued in September 2013. An agenda with links to the presentations and an archived webcast of the workshop are now available.

I attended the workshop, via webcast, mostly because some of the topics to be discussed were related to derived credentials. In this post I report on some of those topics, plus on three other topics that were quite interesting even though not directly related to derived credentials: (i) the resolution of a controversy on whether to use a pairing code to authenticate a computer or physical access terminal to the PIV card; (ii) the security of methods for physical access control, including new methods to be introduced in the next version of SP 800-116; and (iii) the difficulties caused by having to certify cryptographic modules to FIPS 140. Continue reading “Highlights of the NIST Worshop on PIV-Related Special Publications”

Biometrics and Derived Credentials

This is Part 4 of a series discussing the public comments on Draft NIST SP 800-157, Guidelines for Derived Personal Identity Verification (PIV) Credentials and the final version of the publication. Links to all the posts in the series can be found here.

As reviewed in Part 3, a PIV card carries two fingerprint templates for off-card comparison, and may also carry one or two additional fingerprint templates for on-card comparison, one or two iris images, and an electronic facial image. These biometrics may be used in a variety of ways, by themselves or in combination with cryptographic credentials, for authentication to a Physical Access Control System (PACS) or a local workstation. The fingerprint templates for on-card comparison can also be used to activate private keys used for authentication, email signing, and email decryption.

By contrast, neither the draft version nor the final version of SP 800-157 consider the use of any biometrics analogous to those carried in a PIV card for activation or authentication. Actually, they “implicitly forbid” the storage of such biometrics by the Derived PIV Application that manages the Derived PIV Credential, according to NIST’s response to comment 30 by Precise Biometrics.

But several comments requested or suggested the use of biometrics by the Derived PIV Application. In this post I review those comments, and other comments expressing concern for biometric privacy. Then I draw attention to privacy-preserving biometric techniques that should be considered for possible use in activating derived credentials.
Continue reading “Biometrics and Derived Credentials”

NIST Omits Encryption Requirement for Derived Credentials

This is Part 2 of a series of posts reviewing the public comments received by NIST on Draft SP800-157, Guidelines for Derived Personal Identity Verification (PIV) Credentials, their disposition, and the final version of the document. Links to all the posts in the series can be found here.

In the first post of this series I discussed how NIST failed to address many concerns expressed in the 400+ comments that it received on the guidelines for derived credentials published in March of last year as Draft Special Publication (SP) 800-157, including concerns about insufficient discussion of business need, lack of guidance, narrow scope, lack of attention to embedded solutions, and security issues. But I postponed a discussion of what I think is the most critical security problem in SP800-157: the lack of security of the so-called software tokens, a concern that was raised in comments including 111 by the Treasury, 291, 311 and 318 by ICAMSC, 406 by PrimeKey AB, 413 by NSA, and 424 by Exponent. This post focuses on that problem.

The concept of a software token, or software cryptographic module is defined in Draft NISTIR 7981 (Section 3.2.1) as follows:

Rather than using specialized hardware to store and use PIV keys, this approach stores the keys in flash memory on the mobile device protected by a PIN or password. Authentication operations are done in software provided by the application accessing the IT system, or the mobile OS.

What does it mean for the keys to be “protected by a PIN or password“?
Continue reading “NIST Omits Encryption Requirement for Derived Credentials”

NIST Fails to Address Concerns on Derived Credentials

This is the first of a series of posts reviewing the comments received by NIST on Draft SP800-157, their disposition, and the final version of the document. Links to all the posts in the series can be found here.

In March 2014, NIST released the drafts of two documents on derived credentials, Draft NISTIR 7981 and Draft SP800-157, and requested comments. Last month it announced that it had received more than 400 comments and released a file with comments and their dispositions.

The file is hard to read, because it contains snippets of comments rather than entire comments (and snippets of comments by the same organization are not always consecutive!). But we have made the effort to read it, and the effort was worth it. The file contains snippets from companies, individuals, industry organizations, and many US Federal government organizations, including the Consumer Financial Protection Bureau (CFPB), the Coast Guard, the Department of Justice (DOJ), the Department of the Treasury, the Department of Agriculture Mobility Program Management Office (USDA MPO), the Department of State (DOS) the Social Security Administration (SSA), the National Aeronautics and Space Administration (NASA), the Department of Homeland Security (DHS), the Air Force Public Key Infrastructure System Program Office (AF PKI SPO), the Identity, Credential, and Access Management Subcommittee (ICAMSC), the Centers for Disease Control and Prevention (CDC), the Federal Public Key Infrastructure Certificate Policy Working Group (FPKI CPWG) and the Information Assurance Directorate of the National Security Agency (NSA). Continue reading “NIST Fails to Address Concerns on Derived Credentials”

Virtual Tamper Resistance is the Answer to the HCE Conundrum

Host Card Emulation (HCE) is a technique pioneered by SimplyTapp and integrated by Google into Android as of 4.4 KitKat that allows an Android app running in a mobile device equipped with an NFC controller to emulate the functionality of a contactless smart card. Prior to KitKat the NFC controller routed the NFC interface to a secure element, either a secure element integrated in a carrier-controlled SIM, or a different secure element embedded in the phone itself. This allowed carriers to block the use of Google Wallet, which competes with the carrier-developed NFC payment technology that used to be called ISIS and is now called SoftCard. (I’m not sure if or how they blocked Google Wallet in devices with an embedded secure element.) Using HCE, Google Wallet can run on the host CPU where it cannot be blocked by carriers. (HCE also paves the way to the development of a variety of NFC applications, for payments or other purposes, as Android apps that do not have to be provisioned to a secure element.)

But the advantages of HCE are offset by a serious disadvantage. An HCE application cannot count on a secure element to protect payment credentials if the device is stolen, which is a major concern because more then three million phones where stolen last year in the US alone. If the payment credentials are stored in ordinary persistent storage supplied by Android, a thief who steals the device can obtain the credentials by rooting the device or, with more effort, by opening the device and probing the flash memory.

Last February Visa and MasterCard declared their support for HCE. Continue reading “Virtual Tamper Resistance is the Answer to the HCE Conundrum”

How Apple Pay Uses 3-D Secure for Internet Payments

In a comment on an earlier post on Apple Pay where I was trying to figure out how Apple Pay works over NFC, R Stone suggested looking at the Apple Pay developer documentation (Getting Started with Apple Pay, PassKit Framework Reference and Payment Token Format Reference), guessing that Apple Pay would carry out transactions over the Internet in essentially the same way as over NFC. I followed the suggestion and, although I didn’t find any useful information applicable to NFC payments in the documentation, I did find interesting information that seems worth reporting.

It turns out that Apple Pay relies primarily on the 3-D Secure protocol for Internet payments. EMV may also be used, but merchant support for EMV is optional, whereas support for 3-D Secure is required (see the Discussion under Working with Payments in the documentation of the PKPaymentRequest class). It makes sense to rely primarily on a protocol such as 3-D Secure that was intended specifically for Internet payments rather than on a protocol intended for in-store transactions such as EMV. Merchants that only sell over the Internet should not be burdened with the complexities of EMV. But Apple Pay makes use of 3-D Secure in a way that is very different from how the protocol is traditionally used on the web. In this post I’ll try to explain how the merchant interacts with Apple Pay for both 3-D Secure and EMV transactions over the Internet, then how Apple Pay seems to be using 3-D Secure. I’ll also point out a couple of surprises I found in the documentation. Continue reading “How Apple Pay Uses 3-D Secure for Internet Payments”

Making Sense of the EMV Tokenisation Specification

Apple Pay has brought attention to the concept of tokenization by storing a payment token in the user’s mobile device instead of a card number, a.k.a. a primary account number, or PAN. The Apple Pay announcement was accompanied by an announcement of a token service provided by MasterCard and a similar announcement of another token service provided by Visa.

Tokenization is not a new concept. Token services such as the TransArmor offering of First Data have been commercially available for years. But as I explained in a previous post there are two different kinds of tokenization, an earlier kind and a new kind. The earlier kind of tokenization is a private arrangement between the merchant and a payment processor chosen by the merchant, whereby the processor replaces the PAN with a token in the authorization response, returning the token to the merchant and storing the PAN on the merchant’s behalf. In the new kind of tokenization, used by Apple Pay and provided by MasterCard, Visa, and presumably American Express, the token replaces the PAN within the user’s mobile device, and is forwarded to the acquirer and the payment network in the course of a transaction. The purpose of the earlier kind of tokenization is to allow the merchant to outsource the storage of the PAN to an entity that can store it more securely. The purpose of the new kind of tokenization is to prevent cross-channel fraud or, more specifically, Continue reading “Making Sense of the EMV Tokenisation Specification”

Which Flavor of Tokenization is Used by Apple Pay

I’ve seen a lot of confusion about how Apple Pay uses tokenization. I’ve seen it stated or implied that the token is generated dynamically, that it is merchant-specific or transaction-specific, and that its purpose is to help prevent fraudulent Apple Pay transactions. None of that is true. As the Apple Pay press release says, “a unique Device Account Number is assigned, encrypted and securely stored in the Secure Element on your iPhone or Apple Watch”. That Device Account Number is the token; it is not generated dynamically, and it is not merchant-specific or transaction-specific. And as I explain below, its security purpose is other than to help prevent fraudulent Apple Pay transactions.

Some of the confusion comes from the fact that there are two very different flavors of tokenization. That those two flavors are confused is clear in a blog post by Yoni Heisler that purports to provide “an in-depth look at what’s behind” Apple Pay. Heisler’s post references documents on both flavors, not realizing that they describe different flavors that cannot possibly both be used by Apple Pay.

In the first flavor, described on page 7 of a 2012 First Data white paper referenced in Heisler’s post, the credit card number is replaced with a token in the authorization response. The token is not used until the authorization comes back. Tokenization is the second component of a security solution whose first component is encryption of credit card data from the point of capture, Continue reading “Which Flavor of Tokenization is Used by Apple Pay”

Apple Pay Must Be Using the Mag-Stripe Mode of the EMV Contactless Specifications

Update (2014-10-19). The discussion of tokenization in this post is based on an interpretation of the EMV Tokenisation specification that I now think is not the intended one. See the white paper Interpreting the EMV Tokenisation Specification for an alternative interpretation.

Update (2014-10-05). See Mark’s comment below, where he says that Apple Pay is already set up to use the EMV mode of the EMV Contactless Specification, in addition to the mag-stripe mode.

I’ve been trying to figure out how Apple Pay works and how secure it is. In an earlier post I assumed, based on the press release on Apple Pay, that Apple had invented a new method for making payments, which did not seem to provide non-repudiation. But a commenter pointed out that Apple Pay must be using standard EMV with tokenization, because it works with existing terminals as shown in a demonstration.

So I looked at the EMV Specifications, more specifically at Books 1-4 of the EMV 4.3 specification, the Common Payment Application Specification addendum, and the Payment Tokenisation Specification. Then I wrote a second blog post briefly describing tokenized EMV transactions. I conjectured that the dynamic security code mentioned in the Apple press release was an asymmetric signature on transaction data and other data, the signature being generated by customer’s device and verified by the terminal as part of what is called CDA Offline Data Authentication. And I concluded that Apple Pay did provide non-repudiation after all.

But commenters corrected me again. Two commenters said that the dynamic security code is likely to be a CVC3 code, a.k.a. CVV3, and provided links to a paper and a blog post that explain how CVC3 is used. I had not seen any mention of CVC3 in the specifications because I had neglected to look at the EMV Contactless Specifications, which include a mag-stripe mode that does not appear in EMV 4.3 and makes use of CVC3. I suppose that, when EMVCo extended the EMV specifications to allow for contactless operation, it added the mag-stripe mode so that contactless cards could be used in the US without requiring major modification of the infrastructure for processing magnetic stripe transactions prevalent in the US.

The EMV contactless specifications

The EMV Contactless Specifications envision an architecture where the merchant has a POS (point-of-sale) set-up comprising a terminal and a reader, which may be separate devices, or may be integrated into a single device. When they are separate devices, the terminal may be equipped to accept traditional EMV contact cards, magnetic stripe cards, or both, while the reader has an NFC antenna through which it communicates with contactless cards, and software for interacting with the cards and the terminal.

The contactless specifications consist of Books A, B, C and D, where Book C specifies the behavior of the kernel, which is software in the reader that is responsible for most of the logical handling of payment transactions. (This kernel has nothing to do with an OS kernel.) Book C comes in seven different versions, books C-1 through C-7. According to Section 5.8.2 of Book A, the specification in book C-1 is followed by some JCB and Visa cards, specification C-2 is followed by MasterCards, C-3 by some Visa cards, C-4 by American Express cards, C-5 by JCB cards, C-6 by Discover cards, and C-7 by UnionPay cards. (Contactless MasterCards have been marketed under then name PayPass, contactless Visa cards under the name payWave, and contactless American Express cards under the name ExpressPay.) Surprisingly, the seven C book versions seem to have been written independently of each other and are very different. Their lengths vary widely, from the 34 pages of C-1 to the 546 pages of C-2.

Each of the seven C books specifies two modes of operation, an EMV mode and the mag-stripe mode that I mentioned above.

A goal of the contactless specifications is to minimize changes to existing payment infrastructures. A contactless EMV mode transaction is similar to a contact EMV transaction, and a contactless mag-stripe transaction is similar to a traditional magnetic card transaction. In both cases, while the functionality of the reader is new, those of the terminal and the issuing bank change minimally, and those of the acquiring bank and the payment network need not change at all.

The mag-stripe mode in MasterCards (book C-2)

I’ve looked in some detail at contactless MasterCard transactions, as specified in the C-2 book. C-2 is the only book in the contactless specifications that mentions CVC3. (The alternative acronym CVV3 is not mentioned anywhere.) I suppose other C books refer to the same concept by a different name, but I haven’t checked.

C-2 makes a distinction between contactless transactions involving a card and contactless transactions involving a mobile phone, both in EMV mode and in mag-stripe mode. Section 3.8 specifies what I would call a “mobile phone profile” of the specification. The profile supports the ability of the mobile phone to authenticate the customer, e.g. by requiring entry of a PIN; it allows the mobile phone to report to the POS that the customer has been authenticated; and it allows for a different (presumably higher) contactless transaction amount limit to be configured for transactions where the phone has authenticated the customer.

Mobile phone mag-stripe mode transactions according to book C-2

The following is my understanding of how mag-stripe mode transactions work according to C-2 when a mobile phone is used.

When the customer taps the reader with the phone, a preliminary exchange of several messages takes place between the phone and the POS, before an authorization request is sent to the issuer. This is of course a major departure from a traditional magnetic stripe transaction, where data from the magnetic stripe is read by the POS but no other data is transferred back and forth between the card and the terminal.

(I’m not sure what happens according to the specification when the customer is required to authenticate with a PIN into the mobile phone for a mag-stripe mode transaction, since the mobile phone has to leave the NFC field while the customer enters the PIN. The specification talks about a second tap, but in a different context. Apple Pay uses authentication with a fingerprint instead of a PIN, and seems to require the customer to have the finger on the fingerprint sensor as the card is in the NFC field, which presumably allows biometric authentication to take place during the preliminary exchange of messages.)

One of the messages in the preliminary exchange is a GET PROCESSING OPTIONS command, sent by the POS to the mobile phone. This command is part of the EMV 4.3 specification and typically includes the transaction amount as a command argument (presumably because the requested processing options depend on the transaction amount). Thus the mobile phone learns the transaction amount before the transaction takes place.

The POS also sends the phone a COMPUTE CRYPTOGRAPHIC CHECKSUM command, which includes an unpredictable number, i.e. a random nonce, as an argument. The phone computes CVC3 from the unpredictable number, a transaction count kept by the phone, and a secret shared between the phone and the issuing bank. Thus the CVC3 is a symmetric signature on the unpredictable number and the transaction count, a signature that is verified by the issuer to authorize the transaction.

After the tap, the POS sends an authorization request that travels to the issuing bank via the acquiring bank and the payment network, just as in a traditional magnetic stripe transaction. The request carries track data, where the CVC1 code of the magnetic stripe is replaced with CVC3. The unpredictable number and the transaction count are added as discretionary track data fields, so that the issuer can verify that the CVC3 code is a signature on those data items. The POS ensures that the unpredictable number in the track data is the one that it sent to the phone. The issuer presumably keeps its own transaction count and checks that it agrees with the one in the track data before authorizing the transaction. Transaction approval travels back to the POS via the payment network and the acquiring bank. Clearing takes place at the end of the day as for a traditional magnetic stripe transaction.

Notice that transaction approval cannot be reported to the phone, since the phone may no longer be in the NFC field when the approval is received by the POS. As noted in the first comment on the second post, the demonstration shows that the phone logs the transaction and shows the amount to the customer afer the transaction takes place. Since the phone is not told the result of the transaction, the log entry must be based on the data sent by the POS to the phone in the preliminary exchange of messages, and a transaction decline will not be reflected in the blog.

Tokenized contactless transactions

Tokenization is not mentioned in the contactless specifications. It is described instead in the separate Payment Tokenisation specification. There should be no difference between tokenization in contact and contactless transactions. As I explained in the second post, a payment token and expiration date are used as aliases for the credit card number (known as the primary account number, or PAN) and expiration date. The customer’s device, the POS, and the acquiring bank see the aliases, while the issuing bank sees the real PAN and expiration date. Translation is effected as needed by a token service provider upon request by the payment network (e.g. MasterCard or Visa). In the case of Apple Pay the role of token service provider is played by the payment network itself, according to a Bank Innovation blog post.

Implications for Apple Pay

Clearly, Apple Pay must following the EMV contactless specifications of books C-2, C-3 and C-4 for MasterCard, Visa and American Express transactions respectively. More specifically, it must be following what I called above the “mobile phone profile” of the contactless specifications. It must be implementing the contactless mag-stripe mode, since magnetic stripe infrastructure is still prevalent in the US. It may or may not be implementing contactless EMV mode today, but will probably implement it in the future as the infrastructure for supporting payments with contact cards is phased in over the next year in the US.

The Apple press release is too vague to know with certainty what the terms it uses refer to. The device account number is no doubt the payment token. In mag-stripe mode the dynamic security code is no doubt the CVC3 code, as suggested in the comments on the second post. In EMV mode, if implemented by Apple Pay, the dynamic security code could refer to the CDA signature as I conjectured in that post, but it could also refer to the ARQC cryptogram sent to the issuer in an authorization request. (I’ve seen that cryptogram referred to as a dynamic code elsewhere.) It is not clear what the “one-time unique number” refers to in either mode.

If Apple Pay is only implementing mag-stripe mode, one of the points I made in my first post regarding the use of symmetric instead of asymmetric signatures is valid after all. In mag-stripe mode, only a symmetric signature is made by the phone. In theory, that may allow the customer to repudiate a transaction, whereas an asymmetric signature could provide non-repudiation. On the other hand, two other points related the use of a symmetric signature that I made in the first post are not valid. A merchant is not able to use data obtained during the transaction to impersonate the customer. This is not because the merchant sees the payment token instead of the PAN, but because the merchant does not have the secret needed to compute the CVC3, which is only shared between the phone and the issuer. And an adversary who breaches the security of the issuer and obtains the shared secret is not able to impersonate the customer, assuming that the adversary does not know the payment token.

None of this alleviates the broader security weaknesses that I discussed in my third post on Apple Pay: the secrecy of the security design, the insecurity of Touch ID, the vulnerability of Apple Pay on Apple Watch to relay attacks, and the impossibility for merchants to verify the identity of the customer.

Remark: a security miscue in the EMV Payment Tokenisation specification

I said above that “an adversary who breaches the security of the issuer and obtains the shared secret is not able to impersonate the customer, assuming that the adversary does not know the payment token“. The caveat reminds me that the tokenization specification suggests, as an option, forwarding the payment token, token expiry date, and token cryptogram to the issuer. The motivation is to allow the issuer to take them into account when deciding whether to authorize the transaction. However, this decreases security instead of increasing it. As I pointed out in the the second post when discussing tokenization, the issuer is not able to verify the token cryptogram because the phone signs the token cryptogram with a key that it shares with the token service provider, but not with the issuer; therefore the issuer should not trust token-related data. And forwarding the token-related data to the issuer may allow an adversary who breaches the confidentiality of the data kept by the issuer to obtain all the data needed to impersonate the customer, thus missing an opportunity to strengthen security by not storing all such data in the same place.

Update (2014-09-21). There is a small loose end above. If the customer loads the same card into several devices that run Apple Pay, there will be a separate transaction count for the card in each device where it has been loaded. Thus the issuer must maintain a separate transaction count for each instance of the card loaded into a device (plus another one for the physical card if it is a contactless card), to verify that its own count agrees with the count in the authorization request. Therefore the issuer must be told which card instance each authorization request is coming from. This could be done in one of two ways: (1) the card instance could be identified by a PAN Sequence Number, which is a data item otherwise used to distinguish multiple cards that have the same card number, and carried, I believe, in discretionary track data; or (2) each card instance could use a different payment token as an alias for the card number. Neither option fits perfectly with published info. Option (2) would require the token service provider to map the same card number to different payment tokens, based perhaps on the PAN sequence number; but the EMV Tokenization Specification does not mention the PAN sequence number. Option (1) would mean that the same payment token is used on different devices, which goes counter to the statement in the Apple Press release that there is a Device Unique Number; perhaps the combination of the payment token and the PAN sequence number could be viewed as the Device Unique Number. Option (2) provides more security, so I assume that’s the one used in Apple Pay.