Tag: Mobile

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.

Security Weaknesses of Apple Pay for In-Store Transactions

In an earlier post I raised concerns about the security of Apple Pay based on the scant information provided in Apple’s press release. In a comment on that post, Brendon Wilson pointed out that Apple Pay must be using standard EMV with Tokenization rather than a new payment protocol, because it works with existing terminals. After looking in some detail at the EMV specifications, I tried to explain in my last post how Apple Pay could be implemented without departing from the specifications. As part of that explanation, I conjectured that an Apple Pay device may be using both a symmetric signature verified by the issuer and an asymmetric signature verified by the merchant’s terminal. That would eliminate one of the security concerns in my original post. In his comment, Brendon also referred to a MacRumors blog post that provided new details on how Apple Pay is used with Apple Watch. In this post I’d like to recap my remaining concerns on the security of Apple Pay for in-store transactions. (I don’t have enough information yet to discuss web transactions.)

Secrecy

The security design of Apple Pay is secret. This is a weakness in and of itself. Submitting security designs to public scrutiny has been a standard best practice for decades. Without public scrutiny, security flaws will not be caught by friendly researchers, but may be found by adversaries who have enough to gain from reverse-engineering the design and exploiting the flaws that they find.

Insecurity of Touch ID

When Apple Pay is used on the iPhone, the user has to authenticate to the phone for each transaction. This is a good thing, but authentication relies on Touch ID, which only provides security against casual attackers.

Shortly after the introduction of Touch ID, it was shown that it is possible to lift a fingerprint from the iPhone itself, use the fingerprint to make fake skin reproducing the fingerprint ridges, place the fake skin on a finger, and use the finger with the fake skin to authenticate with Touch ID. Three different techniques for making the fake skin were reported, two of them here, a third one here.

Relay attacks against Apple Pay on Apple Watch

Apple’s press release touts the security provided by Touch ID, but adds that Apple Pay will also work with Apple Watch without explaining how the customer will authenticate to Apple Watch, which does not have a fingerprint sensor, and can be used with the iPhone 5 and 5c, which do not have fingerprint sensors either.

A MacRumors blog post explains that the user will authenticate with a PIN, and remain authenticated while the watch detects continuing skin contact using sensors on the back of the watch. The user has to reenter the PIN after contact is interrupted.

A PIN is more secure than Touch ID as long as either the watch or a chip within the watch provide sufficient tamper resistance to protect the hash of the PIN which may be used to verify the hash. (If an adversary who captures the watch is able to extract the hash, then he or she can easily crack the PIN by a brute-force offline attack.) But the scheme described by MacRumors is vulnerable to a relay attack.

A relay attack involves two attackers, a first attacker located near a merchant’s contactless terminal, and a second attacker located near an unwitting customer, whom we shall refer to as the victim. The first attacker has an NFC device that interacts with the terminal, and the second attacker has an NFC device that interacts with the victim’s contactless card or mobile device, masquerading as a terminal. The attackers’ devices communicate with each other using a fast link, relaying data between the terminal and the victim’s device. The first attacker can thus make a purchase and have it charged to the victim’s card or device. The attack does not work if a customer has to authenticate by performing some action such as entering a PIN or touching a sensor, but it works if all a customer needs to do is put his or her device within NFC reach of the terminal, as is the case for Apple Pay on Apple Watch.

A relay attack was demonstrated by Gerhard Hancke in 2005, who claimed it was an easy attack against ISO 14443A cards and terminals. More recently, a different kind of relay attack was demonstrated by Michael Roland against Google Wallet. In Roland’s attack, the second attacker was replaced with malware running on the victim’s Android phone. Google countered the attack by restricting access from the main operating system of the phone to the NFC chip containing the payment credentials. (It would be interesting to check if Host Card Emulation happens to reenable the attack.) Google’s countermeasure, however, only prevents the attacker-plus-malware attack, not the two-attacker attack.

Lack of customer ID verification

Tokenization means that merchants will not be able to verify the identity of their customers. This is good for customer privacy, but leaves merchants defenseless against criminals who steal phones and defeat Touch ID, and against relay attacks on Apple Watch. Millions of smart phones are stolen every year in the US alone, and once Touch ID can be used for payments, criminal organizations will no doubt perfect the Touch ID hacking techniques originally developed by researchers.

Apple Pay, EMV and Tokenization

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/09/24). Apple Pay must be using the EMV contactless specifications, which are a substantial departure from the EMV 4.3 specifications. PLEASE SEE THIS MORE RECENT POST.

After reading Apple’s press release on Apple Pay, I naively believed that Apple had invented a new protocol for credit and debit card payments. In my previous post I speculated on how Apple Pay might be using the device account number, one-time unique number and dynamic security code mentioned in the press release. But in a comment, Brendon Wilson pointed out that Apple Pay must be using standard EMV with Tokenization, since it uses existing contactless terminals, as shown in a demonstration that he sent a link to. I agree, and after spending some time looking at the EMV specifications, I believe that the device account number, one-time unique number and dynamic security code of the press release are fanciful names for standard data items in the specifications.

I’ve seen a Bank Innovation blog post that tries to explain how Apple Pay works in terms of EMV and Tokenization. But that post is inconsistent, saying sometimes that the terminal generates a transaction-specific cryptogram, and other times that the cryptogram is already stored in the iPhone when the consumer walks up to a checkout counter.

One way of explaining how EMV-plus-Tokenization works is to consider the evolution from magnetic strip cards to cards with EMV chips and then tokenization.

Magnetic strip transactions

In a magnetic strip transaction, the terminal reads the credit or debit card number (a.k.a. as the Primary Account Number, or PAN) and the expiration date from the card and assembles a transaction authorization request that contains the card number and expiration data in addition to other data, including the transaction amount. The terminal sends the request to the acquiring bank, which forwards it to the issuing bank through a payment network such as VISA or MasterCard. If appropriate, the issuer returns an approval code, which reaches the merchant via the payment network and the acquiring bank.

At the end of the day, the merchant sends a batch of approval codes to the acquiring bank for clearing. The acquiring bank forwards each approval code to the appropriate issuing bank via the payment network and credits the merchant account after the issuing bank accepts the charge and the transaction amount is received by the acquiring bank from the issuing bank.

EMV transactions

When an EMV chip is used instead of a magnetic strip, the transaction process changes as follows. The terminal sends transaction data including the transaction amount to the chip in the card, which returns a response indicating whether the transaction is to be rejected, accepted offline, or processed online by submitting it to the issuer for approval.

(In the context of EMV, an “online transaction” is an in-store transaction that is approved by the issuing bank reached over some network. To avoid confusion, I will use the term “web transaction” or “web payment” to refer to a transaction where the user enters credit card data into a web form.)

The chip’s response includes a cryptogram. Confusingly, the term cryptogram has two different meanings in the EMV specifications. Formally, a cryptogram is a symmetric signature, which takes the form of a message authentication code (MAC) calculated with a key shared between the chip and the issuing bank. (Strictly speaking, each MAC is computed with a different key derived from a permanent shared key and a transaction counter.) But informally, the term cryptogram is also used to refer to a message containing the MAC, such as the response from the chip to the terminal, and a cryptogram is said to be of a particular type, indicated by an acronym such as AAC, TC, ARQC or ARPC, determined by a Cryptogram Information Data byte included in the message.

To indicate that the transaction is to be accepted offline, the chip sends the terminal a Transaction Certificate (TC) cryptogram, while to indicate that an authorization request is to be sent to the issuer, the chip sends the terminal an Authorization Request Cryptogram (ARQC). In both cases the MAC is computed on data that includes the transaction amount and other transaction data as well as terminal and application data. However, the card number and expiration date are not included in the MAC computation.

If it receives an ARQC cryptogram, the terminal sends an authorization request including the cryptogram (i.e. the MAC) to the acquiring bank, which forwards it to the issuing bank via the payment network. The issuer responds with a message that follows the same route back to the merchant and includes an Authorization Response Cryptogram (ARPC), signed with the same key as the ARQC cryptogram. The terminal forwards the ARPC cryptogram to the chip, which sends back a TC cryptogram.

Whether the transaction is authorized offline or online, the merchant includes the TC cryptogram received from the chip in the funding request that it sends to the acquiring bank at clearing time. The TC plays the role played by the approval code in magnetic strip processing. It is forwarded by the acquiring bank to the issuer via the payment network.

Tokenized transactions

Tokenization replaces the credit or debit card number and expiration date with numeric codes of same length, called a payment token and a token expiry date respectively. Separate ranges of numeric codes are allocated so that no payment token can be confused with a card number. A Token Service Provider maintains the mapping between card numbers coupled with their expiration dates and payment tokens coupled with their expiration dates.

Reliance on the token service provider means that tokenization can only be used for online transactions. [Update. As explained in Shaun’s comment, there is no reason why offline transactions cannot use tokenization.] Only the issuer and the payment network see the true card number and expiration date. The acquiring bank, the merchant and the user’s device (which may be a card with a chip, or a mobile device) only see the payment token and expiration date. Back-and-forth translation between card data and token data is effected by the token service provider upon request by the payment network. Translation does not invalidate cryptograms, because cryptograms do not include the card number and expiration date.

At transaction time, the authorization request with the ARQC cryptogram includes token data as it travels from the user’s device to the merchant’s terminal, the acquiring bank, and the payment network. The payment network sends a “de-tokenization” request to the token service provider. The token service provider returns the card data, which the payment network adds to the request before forwarding it to the issuer bank. The response from the issuer bank, which carries the ARPC cryptogram, includes card data but no token data. The response goes first to the payment network, which replaces the card data with token data obtained from the token service provider, before sending the response along to the acquiring bank, the merchant, and the user’s device.

At clearing time, the merchant sends token data along with the TC cryptogram to the acquiring bank, which forwards them to the payment network. The payment network asks the token service provider to de-tokenize the data, then forwards the card data and the TC cryptogram to the issuing bank.

The tokenization spec allows the role of token service provider to be played by the issuing bank, the payment network, or a party that plays no other role in transaction processing. According to the Bank Innovation post, it is the payment network that plays the token service provider role in Apple Pay.

The tokenization spec mentions a token cryptogram. This cryptogram is different from the others, and does not replace any of the others. Its purpose is to help the token service provider decide whether it is OK to respond to a de-tokenization request and reveal card data. It is computed with a symmetric key derived from data shared between the user’s device and the token service provider. It is sent along with a transaction authorization request from the user’s device to the merchant’s terminal, the acquiring bank and the payment network, which includes it in the de-tokenization request to the token service provider.

According to the EMV specs, the token cryptogram may also be forwarded by the payment network to the issuer, which can take it into account when deciding whether to authorize the transaction. However, the issuer cannot verify the authenticity of the token cryptogram, since it is signed with a key that the issuer does not have.

Offline data authentication

Now I need to go back to the pre-tokenization EMV specs and describe the concept of offline data authentication, which refers to the direct authentication by the terminal of data sent by the card, as part of an offline or online transaction. The EMV specifications require cards that can perform offline transactions to support offline data authentication, while such support is optional for cards that only perform online transactions. Offline data authentication takes place when both the card and the terminal support it.

Offline data authentication comes in three flavors, called SDA, DDA, and CDA.

In Static Data Authentication (SDA), the card provides the terminal with an asymmetric signature on static card data. The signature is computed once and for all by the issuer when the card is issued and stored in the card. The issuer has an RSA key pair. The private key is used to compute the signature, and the public key is included in a certificate issued by a certificate authority (CA) to the card-issuing bank . The issuer’s certificate is also stored in the card and sent to the terminal along with the signature. (The issuer’s private key is not stored in the card, of course.) The terminal uses the public key in the certificate to verify the signature, and the public key of the CA, which it is configured with, to verify the CA’s signature in the issuer’s certificate. Notice that the card does not have a key pair.

In Dynamic Data Authentication (DDA), the card has its own key pair, which is stored in the card when the card is issued. (Cryptographic best practice calls for a key pair to be generated within the cryptographic module where it will be used, but card firmware may not have key-pair generation functionality.) The card provides the terminal with an asymmetric signature computed with the card’s private key on data including a transaction-specific random challenge sent by the terminal. The card sends the signature to the terminal together with a certificate for the card’s public key signed by the issuer and backed by the issuer’s certificate, which the card also sends to the terminal.

In Combined DDA / Application Cryptogram Generation (CDA), the data signed by the card additionally includes the cryptogram that the card sends to the terminal.
[Update: The data that is signed also includes transaction data. Transaction data is thus signed twice, with a symmetric signature (the cryptogram) and an asymmetric signature. The CDA asymmetric signature provides non-repudiation, although non-repudiation is not discussed in the EMV specfications.]

Offline data authentication in a tokenized transaction

The tokenization spec does not mention offline data authentication. Recall that tokenized transactions are necessarily online transactions, and the EMV spec does not require cards that only perform online transactions to support offline data authentication.

However, nothing prevents the use of offline data authentication in a tokenized online transaction. In a non-tokenized transaction, the asymmetric signature in any of the three flavors of offline data authentication is computed on data that includes the card number and expiration date. In a tokenized transaction, it will be computed on data that includes instead the payment token and token expiry date.

Explaining the Apple press release terminology

Based on the above, the terms in the Apple press release can be understood as follows:

Device account number. The press release says:

When you add a credit or debit card with Apple Pay, the actual card numbers are not stored on the device nor on Apple servers. Instead, a unique Device Account Number is assigned, encrypted and securely stored in the Secure Element on your iPhone or Apple Watch.

Clearly, the device account number must be what the Tokenization spec calls the payment token.

One-time unique number. The press release also says:

Each transaction is authorized with a one-time unique number using your Device Account Number …

The one-time unique number must be the ARQC cryptogram that is sent to the issuer as part of an authorization request.

Dynamic security code. The press release goes on to say:

… and instead of using the security code from the back of your card, Apple Pay creates a dynamic security code to securely validate each transaction.

This is puzzling, since the card’s security code is not used for in-store transactions, is not encoded in a magnetic strip, and is not stored in an EMV chip. It is only used for payments by phone or web payments. So nothing can be used instead of the security code for in-store transactions.

I conjecture that the term dynamic security code has been invented by an imaginative security-marketing guru to refer to an asymmetric CDA signature sent by the user’s device to the merchant’s terminal. We have seen above that CDA is not precluded by the EMV spec for online transaction. It would make sense for Apple Pay devices to provide CDA to merchant terminals, because that would increase security and could be useful to merchants. A merchant could use a CDA signature as evidence when contesting a chargeback, because an asymmetric signature provides non-repudiation. The signature would be on data including the payment token rather than the card number, but in a repudiation dispute the token service provider could supply the card number.

If Apple Pay devices implement CDA signatures, and if all terminals used with Apple Pay make use of them, then the concerns about the use of symmetric instead of asymmetric signatures that I raised in the previous post are eliminated. But other security concerns remain. In the next post I will restate those remaining concerns, taking into account new information in a MacRumors blog post on Apple Watch that was also referenced by Brendon Wilson in his comment. (Thank you, Brendon!)

On the Security of Apple Pay

Update (2014-9-15). As pointed out in the comments, it seems that Apple Pay is based on existing standards. In my next post I try to explain how it may follow the EMV specifications with Tokenization, and in the following one I update the security concerns taking into account additional information on Apple Watch.

Yesterday’s Apple announcements shed light on a surprising contrast between the attitudes of the company towards product design on one hand, and towards security on the other. Tim Cook took pride not only on the design of the Apple Watch, but also on the process of designing it, the time and effort it took, the attention to detail, and the reliance on a broad range of disciplines ranging from metallurgy to astronomy. The contrast could not be sharper with the lack of attention paid to the security of Apple Pay.

I doubt if any cryptographers were consulted on the design of Apple Pay. If they were, they should have insisted on publishing the design so that it could benefit from the scrutiny of a broad range of security experts. Submission to public scrutiny has been recognized as a best practice in the design of cryptographic protocols for many decades.

The press release on Apple Pay mentions a Device Account Number, a one-time transaction authorization number, and a dynamic security code. Since the security design is secret, it is impossible to tell for sure how these numbers and codes are used. But since no mention is made of public key cryptography, I surmise that the Device Account Number is a shared secret between the device and the credit card issuing bank, and the dynamic security code is a symmetric signature on the transaction record. If so, by using a symmetric signature instead of an asymmetric one, Apple is 36 years behind the state of the art in cryptography. By contrast, asymmetric signatures are used routinely by smartcards for in-store payments in accordance with the EMV specifications. The same techniques could be adapted for in-store or online payments with credentials stored in a mobile device.

Symmetric signatures lack non-repudiation. And if the Device Account Number is used as a symmetric key, then it may be vulnerable to insider attacks and security breaches at the issuing bank, while a private key used for asymmetric signatures would only be stored in the user’s device and would be immune to such vulnerabilities. Worse, for all we know, the Device Account Number may be made available to the merchant’s terminal; the press release says nothing to the contrary. If so, it would be vulnerable to capture by point-of-sale malware, after which it could be used online to commit fraud just like a credit card number.

A surprising aspect of Apple Pay is its dependence on Touch ID, which only provides security against casual attackers. But wait, does Apple Pay security really depend on Touch ID? Although this is not mentioned in the Apple Pay press release, it was stated at the Apple event in Cupertino that payments can be made using an Apple Watch, which itself can be used in conjunction with an iPhone 5 or 5C. Neither the Apple Watch, nor the iPhones 5 and 5C have Touch ID sensors; and use of the Touch ID sensor in an iPhone 5S, 6 or 6+ may not be required when the terminal is tapped by an Apple Watch used in conjunction with those phones. So it seems that Apple Pay does not really require user authentication.

The press release says that, “when you’re using Apple Pay … cashiers will no longer see your name, credit card number or security code, helping to reduce the potential for fraud”. This may reduce the potential for fraud against the customer, but certainly not for fraud against the merchant. And while customers have little if any liability to fraud, at least in the US, merchants are fully liable. Without knowing the customer’s name, merchants cannot verify the customer’s identity and are defenseless against a thief who steals an Apple Watch and its companion iPhone and goes shopping online, or in stores without having to show an ID.

But while Apple Pay puts merchants at risk of financial loss, it puts users at an even greater risk. I don’t like to dramatize, but I don’t know how else to say this. People have been killed by smart phone thieves. Somebody wearing an Apple Watch will be parading a valuable watch, and advertising that a valuable smart phone is being carried along with the watch. Furthermore, a thief who steals the watch and the phone can then go on a shopping spree. The press release says that “if your iPhone is lost or stolen, you can use Find My iPhone to quickly suspend payments from that device”; but this will be a powerful incentive for the thief to kill the victim. If Apple does not find some other way of discouraging theft, wearers of Apple watches will be putting their lives at risk.
Update. I got carried away and didn’t think it through. It’s unlikely that a murderer will risk using the victim’s phone and watch for purchases. Even though the merchant does not know the identity of the owner of the mobile device, a forensic investigation will no doubt be able to link the murder to the shopping and may allow the murderer to be identified by surveillance cameras.

Protecting Derived Credentials without Secure Hardware in Mobile Devices

NIST has recently released drafts of two documents with thoughts and guidelines related to the deployment of derived credentials,

and requested comments on the drafts by April 21. We have just sent our comments and we encourage you to send yours.

Derived credentials are credentials that are derived from those in a Personal Identity Verification (PIV) card or Common Access Card (CAC) and carried in a mobile device instead of the card. (A CAC card is a PIV card issued by the Department of Defense.) The Electronic Authentication Guideline, SP 800-63, defines a derived credential more broadly as:

A credential issued based on proof of possession and control of a token associated with a previously issued credential, so as not to duplicate the identity proofing process.

A PIV/CAC card may carry a PIV authentication credential, a digital signature credential, a current key management credential and up to 20 retired key management credentials, each credential consisting of a private key and an associated certificate that contains the corresponding public key. The digital signature private key is used for signing email messages, and the key management keys for decrypting symmetric keys used to encrypt email messages. The retired key management keys are needed to decrypt old messages that have been saved encrypted. The PIV authentication credential is mandatory for all users, while the digital signature credential and the current key management credential are mandatory for users who have government email accounts.

A mobile device may similarly carry an authentication credential, a digital signature credential, and current and retired key management credentials. Although this is not fully spelled out in the NIST documents, the current and retired key management private keys in the mobile device should be able to decrypt the same email messages as those in the card, and therefore should be the same as those in the card, except that we see no need to limit the number of retired key management private keys to 20 in the mobile device. The key management private keys should be downloaded to the mobile device from the escrow server that should already be in use today to recover from the loss of a PIV/CAC card containing those keys. On the other hand the authentication and digital signature key pairs should be generated in the mobile device, and therefore should be different from those in the card.

In a puzzling statement, SP 800-157 insists that only an authentication credential can be considered a “derived PIV credential”:

While the PIV Card may be used as the basis for issuing other types of derived credentials, the issuance of these other credentials is outside the scope of this document. Only derived credentials issued in accordance with this document are considered to be Derived PIV credentials.

Nevertheless, SP 800-157 discusses details related to the storage of digital signature and key management credentials in mobile devices in informative appendix A and normative appendix B.

Software Tokens

The NIST documents provide guidelines regarding the lifecycle of derived credentials, their linkage to the lifecycle of the PIV/CAC card, their certificate policies and cryptographic specifications, and the storage of derived credentials in several kinds of hardware cryptographic modules, which the documents refer to as hardware tokens, including microSD tokens, UICC tokens, USB tokens, and embedded hardware tokens. But the most interesting, and controversial, aspect of the documents concerns the storage of derived credentials in software tokens, i.e. in cryptographic modules implemented entirely in software.

Being able to store derived credentials in software tokens would mean being able to use any mobile device to carry derived credentials. This would have many benefits:

  1. Federal agencies would have the flexibility to use any mobile devices they want.
  2. Federal agencies would be able to use inexpensive devices that would not have to be equipped with special hardware for secure storage of derived credentials. This would save taxpayer money and allow agencies to do more with their IT budgets.
  3. Mobile authentication and secure email solutions used by the Federal Government would be affordable and could be broadly used in the private sector.

The third benefit would have huge implications. Today, the requirement to use PIV/CAC cards means that different IT solutions must be developed for the government and for the private sector. IT solutions specifically developed for the government are expensive, while private sector solutions too often rely on passwords instead of cryptographic credentials. Using the same solutions for the government and the private sector would lower costs and increase security.

Security

But there is a problem. The implementation of software tokens hinted at in the NIST documents is not secure.

NISTIR 7981 describes a software token 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.

And SP 800-157 adds the following:

For software implementations (LOA-3) of Derived PIV Credentials, a password-based mechanism shall be used to perform cryptographic operations with the private key corresponding to the Derived PIV Credential. The password shall meet the requirements of an LOA-2 memorized secret token as specified in Table 6, Token Requirements per Assurance Level, in [SP800-63].

Taken together, these two paragraphs seem to suggest that the derived credentials should be stored in ordinary flash memory storage encrypted under a data encryption key derived from a PIN or password satisfying certain requirements. What requirements would ensure sufficient security?

Smart phones are frequently stolen, therefore we must assume that an adversary will be able to capture the mobile device. After capturing the device the adversary can immediately place it in a metallic box or other Faraday cage to prevent a remote wipe. The contents of the flash memory storage may be protected by the OS, but in many Android devices, the OS can be replaced, or rooted, with instructions for doing so provided by Google or the manufacturer. OS protection may be more effective in some iOS devices, but since a software token does not provide any tamper resistance by definition, we must assume that the adversary will be able to extract the encrypted credentials. Having done so, the adversary can mount an offline password guessing attack, testing each password guess by deriving a data encryption key from the password, decrypting the credentials, and checking if the resulting plaintext contains well-formed credentials. To carry out the password guessing attack, the adversary can use a botnet. Botnets with tens of thousands of computers can be easily rented by the day or by the hour. Botnets are usually programmed to launch DDOS attacks, but can be easily reprogrammed to carry out password cracking attacks instead. The adversary has at least a few hours to run the attack before the authentication and digital signature certificates are revoked and the revocation becomes visible to relying parties; and there is no time limit for decrypting the key management keys and using them to decrypt previously obtained encrypted email messages.

To resist such an attack, the PIN or password would need to have at least 64 bits of entropy. According to Table A.1 of the Electronic Authentication Guideline (SP 800-63), a user-chosen password must have more than 40 characters chosen appropriately from a 94-character alphabet to achieve 64 bits of entropy. Entering such a password on the touchscreen keyboard of a smart phone is clearly unfeasible.

SP 800-157 calls instead for a password that meets the requirements of an LOA-2 memorized secret token as specified in Table 6 of SP 800-63, which are as follows:

The memorized secret may be a randomly generated PIN consisting of 6 or more digits, a user generated string consisting of 8 or more characters chosen from an alphabet of 90 or more characters, or a secret with equivalent entropy.

The equivalent entropy is only 20 bits. Why does Table 6 require so little entropy? Because it is not concerned with resisting an offline guessing attack against a password that is used to derive a data encryption key. It is instead concerned with resisting an online guessing attack against a password that is used for authentication, where password guesses can only be tested by attempting to authenticate to a verifier who throttles the rate of failed authentication attempts. In Table 6, the quoted requirement on the memorized secret token is coupled with the following requirement on the verifier:

The Verifier shall implement a throttling mechanism that effectively limits the number of failed authentication attempts an Attacker can make on the Subscriber’s account to 100 or fewer in any 30-day period.

and the necessity of the coupling is emphasized in Section 8.2.3 as follows:

When using a token that produces low entropy token Authenticators, it is necessary to implement controls at the Verifier to protect against online guessing attacks. An explicit requirement for such tokens is given in Table 6: the Verifier shall effectively limit online Attackers to 100 failed attempts on a single account in any 30 day period.

Twenty bits is not sufficient entropy for encrypting derived credentials, and requiring a password with sufficient entropy is not a feasible proposition.

Solutions

But the problem has solutions. It is possible to provide effective protection for derived credentials in a software token.

One solution is to encrypt the derived credentials under a high-entropy key that is stored in a secure back-end and retrieved when the user activates the software token. The problem then becomes how to retrieve the high-entropy key from the back-end. To do so securely, the mobile device must authenticate to the back-end using a device-authentication credential stored in the mobile device, which seems to bring us back to square one. However, there is a difference between the device-authentication credential and the derived credentials stored in the token: the device-authentication credential is only needed for the specific purpose of authenticating the device to the back-end and retrieving the high-entropy key. This makes it possible to use as device-authentication credential a credential regenerated on demand from a PIN or password supplied by the user to activate the token and a protocredential stored in the device, in a way that deprives an attacker who captures the device of any information that would make it possible to test guesses of the PIN or password offline.

The device-authentication credential can consist, for example, of a DSA key pair whose public key is registered with the back-end, coupled with a handle that refers to a device record where the back-end stores a hash of the registered public key. In that case the protocredential consists of the device record handle, the DSA domain parameters, which are (p,q,g) with the notations of the DSS, and a random high-entropy salt. To regenerate the DSA key pair, a key derivation function is used to compute an intermediate key-pair regeneration key (KPRK) from the activation PIN or password and the salt, then the DSA private and public keys are computed as specified in Appendix B.1.1 of the DSS, substituting the KPRK for the random string returned_bits produced by a random number generator.

To authenticate to the back-end and retrieve the high-entropy key, the mobile device establishes a TLS connection to the back-end, over which it sends the device record handle, the DSA public key, and a signature computed with the DSA private key on a challenge derived from the TLS master secret. (Update—April 24, 2014: The material used to derive the challenge must also include the TLS server certificate of the back-end, due to a recently reported UKS vulnerability of TLS. See footnote 2 of the technical report.) The DSA public and private keys are deleted after authentication, and the back-end keeps the public key confidential. An adversary who is able to capture the device and extract the protocredential has no means of testing guesses of the PIN or password other than regenerating the DSA key pair and attempting online authentication to the back-end, which locks the device record after a small number of consecutive failed authentication attempts that specify the handle of the record.

An example of a derived credentials architecture that uses this solution can be found in a technical report.

Other solutions are possible as well. The device-authentication credential itself could serve as a derived credential, as we proposed earlier; SSO can then be achieved by sharing login sessions, as described in Section 7.5 of a another technical report. And I’m sure others solutions can be found.

Other Topics

There are several other topics related to derived credentials that deserve discussion, including the pros and cons of storing credentials in a Trusted Execution Environment (TEE), whether biometrics should be used for token activation, and whether derived credentials should be used for physical access. I will leave those topics for future posts.

Update (April 10, 2014). A post discussing the storage of derived credentials in a TEE is now available.

Two Methods of Cryptographic Single Sign-On on Mobile Devices

This is the sixth and last post of a series discussing the paper A Comprehensive Approach to Cryptographic and Biometric Authentication from a Mobile Perspective.

To conclude this series I am going to discuss briefly two methods of single sign-on (SSO) described in the paper, one based on data protection, the other on shared login sessions.

SSO Based on Data Protection

Section 5 of the paper explains how the multifactor closed-loop authentication method described in the third and fourth posts of the series provides an effective mechanism for protecting data stored in a mobile device against an adversary who captures the device. The data is encrypted under a data encryption key that is entrusted to a key storage service. To retrieve the key, the user provides a PIN and/or a biometric that are used to regenerate an uncertified key pair, which is used to authenticate to the storage service.

An adversary who captures the device needs the PIN and/or the biometric sample to regenerate the key pair, and cannot mount an offline attack to guess the PIN or to guess a biometric key derived from the biometric sample; so the adversary cannot authenticate to the key storage service, and cannot retrieve the key. For additional security the data encryption key can be cryptographically split in several portions entrusted to different storages services. Furthermore a protokey can be entrusted to those services instead of the data encryption key, the key being then derived from the protokey and the same non-stored secrets that are used to regenerate the authentication key pair as described in Section 5.4.

This data protection mechanism can be used to protect any kind of data. In particular, it can be used to protect credentials used for open-loop authentication or one-factor closed-loop authentication to any number of mobile applications or, more precisely, to the back-ends of those applications, which may be have browser-based or native front-ends. As discussed in Section 5.5, this amounts to single sign-on to those applications because, after the user enters a PIN and/or provides a biometric sample, the data encryption key retrieved from the storage service(s) can be kept in memory for a certain amount of time, making it possible to authenticate to the applications without further user intervention.

SSO Based On Shared Login Sessions

Whereas SSO based on data protection can be used for any collection of applications, SSO based on shared login sessions, described in Section 7.5, is best suited for authenticating to enterprise applications from a mobile device. A dedicated PBB in the mobile device and a VBB in the enterprise cloud are used to that purpose. The PBB contains a single protocredential shared by all the enterprise applications, which is used to regenerate an uncertified key pair, in conjunction with a PIN and/or a biometric sample supplied by the user. The VBB has access to an enterprise database that contains device and user records and where the VBB stores shared session records, as illustrated in Figure 8.

It is not difficult to share login sessions among a group of web-based applications owned by an enterprise, using a mechanism readily available on the web. Once the user has logged in to one of the web-based applications in the group, that application can set in the browser a session cookie whose scope (defined explicitly or implicitly by the domain and path attributes of the cookie) comprises the applications in the group and no others. The browser will send the cookie along with every HTTP request targeting an application in the scope of the cookie, thus authenticating the request without user intervention.

But we want to share login sessions among a group of enterprise applications comprising applications with native front-ends in addition to web-based applications. To that purpose we use the mobile authentication architecture that I discussed in the previous post, modifying it as follows.

Recall that an authentication event in the architecture consists of a cryptographic authentication of the PBB to the VBB, followed by a secondary non-cryptographic authentication using a one-time authentication token, which plays the role of a bearer token, as illustrated in Figure 6 for the case of an application with a native front-end, and in Figure 7 for the case of a web-based application. The authentication token is only used once because of the risk of a Referer leak in the case of a web-based application. However there is no such risk in the case of an application with a native front-end.

To implement shared login sessions we replace the one-time authentication token with a pair of session tokens, a one-time session token and a reusable session token. After successful cryptographic authentication of the PBB to the VBB, the VBB creates a pair of session tokens and a shared session record containing the two tokens, and sends the two tokens to the PBB, which stores them.

A native front-end obtains a reusable session token from the PBB and uses it repeatedly to authenticate to its back-end until the back-end rejects it because the session referenced by the token has expired because an expiration time in the shared session record has been reached or some other reason. Then the native front-end sends the reusable token to the PBB asking for a replacement. If the PBB has a different reusable token, it sends it to the native front-end. If not, it prompts the user for a PIN and/or a biometric sample, regenerates the uncertified key pair, authenticates cryptographically to the VBB, obtains from the VBB a pair of session tokens pertaining to a new session, and sends the new reusable token to the native front-end.

A web-based application obtains a one-time session token from the PBB and uses it to locate a shared session record and retrieve a reusable session token, which it sets in the browser as the value of a session cookie. After the PBB sends the one-time token to the application, it erases the one-time token from its storage; and after the application uses the one-time token to retrieve the reusable token, it erases the one-time token from the shared session record. The session cookie is used to authenticate HTTP requests sent by the browser to web-based applications in the group, until one of the applications finds that the session referenced by the reusable token contained in the cookie has expired. Then that application sends the reusable token to the PBB and asks for a one-time token. If the PBB has a one-time token paired with a reusable token different from the one sent by the application, it sends the one-time token to the application. Otherwise it authenticates cryptographically to the VBB as in the case of a native front-end, obtaining a pair of fresh tokens and sending the new one-time token to the application.

Pros and Cons of the Two Methods

The method based on data protection is more flexible than the method based on shared sessions. It can be used to implement SSO for any set of applications, whether or not those applications are related to each other. By contrast, the method based on shared sessions can only be used to implement SSO for a group of related applications: the set of web-based applications in the group must be circumscribable by the scope of a cookie; and, as explained in Section 8.2.2, native front-ends of applications in the group must be signed with the same code-signing key pair in Android, or must have the same Team ID in iOS, so that the PBB can refuse requests from applications not in the group.

On the other, the method based on shared login sessions has performance and security advantages, as explained in Section 7.5.3. In the method based on data protection, SSO is accomplished by making cryptographic authentication transparent to the user, whereas in the method based on shared login sessions cryptographic authentication is avoided altogether; hence the performance advantage. In the method based on data protection, the data encryption key must be present in the device while the user interacts with the applications, whereas in the method based on shared login sessions the uncertified key pair is only needed when a new session is created, and can be erased after it is used; hence the security advantage.

Using Cryptographic Authentication without a Cryptographic API on iOS and Android Devices

This is the fifth of a series of posts discussing the paper A Comprehensive Approach to Cryptographic and Biometric Authentication from a Mobile Perspective.

Everybody agrees that passwords provide very poor security for user authentication, being vulnerable to capture by phishing attacks or database breaches, or by being reused at malicious sites. Authentication using public key cryptography does not have any of these vulnerabilities, and yet, after being available for several decades, it is only used in limited contexts. As computing shifts from traditional PCs to mobile devices, everybody agrees that passwords are terribly inconvenient on touchscreen keyboards, in addition to being insecure; and yet I don’t see a rush to adopting cryptographic authentication methods on mobile devices.

What obstacles stand in the way of widespread adoption of cryptographic authentication?

One obstacle is no doubt the complexity of cryptography. Implementing cryptographic functionality is difficult even when cryptographic libraries are available. Using a cryptographic API is no trivial matter, as documented by Martin Georgiev et al. in a recent paper (reference [39] in the paper).

Another obstacle is poor support by web browsers for the deployment and use of cryptographic credentials. In particular, there are no easy-to-use standards generally supported by browser vendors for issuing cryptographic credentials to a browser and requesting the presentation by the browser of particular credentials or credentials asserting particular attributes.

In Section 7 the paper proposes an architecture for cryptographic authentication on mobile devices that addresses these two obstacles. It does that by encapsulating cryptographic authentication of a mobile device to an application back-end inside a Prover Black Box (PBB) located in the device and a Verifier Black Box (VBB) located in the cloud, as shown in figures 6 (page 48) and 7 (page 54).

The PBB may contain one or more protocredentials for multifactor closed-loop authentication, or credentials for single factor closed-loop or open-loop authentication; and it takes care of proving possession of credentials to the VBB. After a cryptographic authentication event in which the PBB proves possession of one or more credentials, the VBB creates an authentication object that records the event and contains authentication data such as the hash of a public key or attributes asserted by a public key certificate, a U-Prove token, or an Idemix anonymous credential. The authentication object is retrievable by a one-time authentication token, which the VBB passes to the PBB and the PBB passes to the application back-end via a native front-end or via the web browser. The authentication token plays the role of a bearer token in a secondary non-cryptographic authentication of the native front-end or web browser to the back-end, and allows the application back-end to retrieve the authentication data.

In Figure 6 the native front-end of a mobile application receives the authentication token from the PBB and uses it to authenticate to the back-end of the same application, which presents it to the VBB to retrieve the authentication data.

In Figure 7, the PBB sends the token via the browser to the back-end of a web-based application, thus authenticating the browser to the back-end, which again uses the token to retrieve the authentication data from the VBB. (As a matter of terminology, we view a web-based application as having a back-end and a front-end, the back-end being its cloud portion, while the front-end consists of web pages and client-side code running in the browser.)

This architecture circumvents the two obstacles identified above to the adoption of cryptographic authentication.

The browser obstacle is avoided in Figure 6 because no browser is involved, and in Figure 7 because the browser is not involved in storing or presenting credentials, and no modification of standard browser functionality is required.

The obstacle presented by the complexity of cryptography is avoided by the encapsulation of cryptographic functionality in the PBB and the VBB and by making the PBB and the VBB accessible through non-cryptographic APIs in a manner familiar to native and web-based application developers.

In Figure 6, arrows (1) and (4) represent messages sent via the operating system of the mobile device using inter-application communication mechanisms available in iOS and Android; each message is a URL having a custom scheme, with message parameters embedded as usual in the query portion of the URL. Arrow (6) represents an HTTP POST request, and arrow (7) the corresponding response. Arrow (5) is internal to the application and can be implemented as part of a standard web API through which the native front-end accesses its back-end.

In Figure 7, arrow (1) represents an HTTP response that redirects the browser to a custom scheme that targets the PBB, with parameters included in the query portion of the URL; when the browser receives the response, it forwards it to the PBB as a message, using the inter-application communication mechanism provided by the operating system. Arrow (4) represents a message sent by the PBB using the same mechanism, with scheme https; the operating system delivers it to the browser, which forwards it as an HTTP GET request to the application back-end. Arrow (5) represents an HTTP POST request, and arrow (6) the corresponding response.

The architecture is very flexible. It covers a wide variety of use cases, some of which are sketched out in Section 7.1.

A PBB-VBB pair may be used for returning-user authentication to one particular application. In that case the PBB contains a single credential (for one-factor authentication) or protocredential (for multifactor authentication).

Alternatively, a general purpose PBB may be made available to any mobile application that has a native front-end on the device or is accessed from the device through a browser, each application having its own VBB. In that case the PBB may contain any number of credentials or protocredentials used for closed-loop authentication, as well as credentials used for open-loop authentication.

An application may ask a general purpose PBB to prove possession of an uncertified key pair to the application’s VBB for returning-user authentication, or to the VBB of an identity/attribute provider or a social network for third-party closed-loop authentication or social login. The VBB of an identity/attribute provider delivers the user’s identity or attributes to the application back-end as authentication data upon presentation of the authentication token. The VBB of a social network may instead deliver an access token that provides limited access to the user’s account, thus allowing the application to obtain the user’s identity and attributes from the user’s profile, to issue social updates on behalf of the user, and more generally to provide an alternative user interface to the social network.

An application may also ask a general purpose PBB to demonstrate that the user has certain attributes by presenting public key certificates, U-Prove tokens or Idemix anonymous credentials to the application’s VBB in open-loop authentication.

For enterprise use, a PBB-VBB pair may be shared by a group of enterprise applications, including web-based applications and applications with native front-ends, with single sign-on based on shared login sessions. I will discuss this functionality in the next post.

A security analysis of the architecture is provided in Section 8. Among other security considerations, it discusses protection against leaks through so-called Referer headers, protection against misuse of an authentication token by its recipient to impersonate the user, a countermeasure against a form of Login CSRF, identification of the application that requests presentation of one or more credentials kept by a general purpose browser, and countermeasures against a malicious application masquerading as a different application or as the system browser.

Strong Authentication with a Low-Entropy Biometric Key

This is the fourth of a series of posts discussing the paper A Comprehensive Approach to Cryptographic and Biometric Authentication from a Mobile Perspective.

Biometrics are a strong form of authentication when there is assurance of liveness, i.e. assurance that the biometric sample submitted for authentication belongs to the individual seeking authentication. Assurance of liveness may be relatively easy to achieve when a biometric sample is submitted to a reader in the presence of human operator, if the reader and the operator are trusted by the party to which the user is authenticating; but it is practically impossible to achieve for remote authentication with a reader controlled by the authenticating user. When there is no assurance of liveness, security must rely on the relative secrecy of biometric features, which is never absolute, and may be non-existent. Fingerprints, in particular, cannot be considered a secret, since you leave fingerprints on most surfaces you touch. Using a fingerprint as a login password would mean leaving sticky notes with your password everywhere you go.

In addition to these security caveats, biometric authentication raises acute privacy concerns. Online transactions authenticated with biometric features would be linkable not only to other online transactions, but also to offline activities of the user. And both online and offline transactions would become linked to the user’s identity if a biometric sample or template pertaining to the user became public knowledge or were acquired by an adversary.

Yet, in Section 3, the paper proposes a method of using biometrics for user authentication on a mobile device to an application back-end. The method addresses the above security and privacy concerns as follows:

  1. First, biometrics is not used by itself, but rather as one factor in multifactor authentication, another required factor being possession of a protocredential stored in the user’s device, and another optional factor being knowledge of a passcode such as a PIN.
  2. Second, the paper suggests using an iris scan, which provides more secrecy than fingerprints. (The scan could be taken by a camera on the user’s mobile device. The paper cites the work of Hao, Anderson, and Daugman at the University of Cambridge, which achieved good results with iris scans using a near-infrared camera. I have just been told that phone cameras filter our near-infrared light, so a special camera may be needed. The Wikipedia article on iris recognition discusses the use of near-infrared vs. visible light for iris scanning.)
  3. Third, no biometric-related data is sent by the user’s device to the application back-end, neither at authentication time nor at enrollment time. The biometric sample is used to regenerate a key pair on the device, and the key pair is used to authenticate the device to the back-end.
  4. Fourth, neither a biometric sample nor a biometric template are stored in the user’s device. Instead, the paper proposes to use one of several methods described in the literature, cited in Section 3.2, for consistently producing a biometric key from auxiliary data and genuine but varying biometric samples. Only the auxiliary data is stored in the device, and it is deemed unfeasible to recover any biometric information from the auxiliary data.

The resulting security and privacy posture is discussed in Section 4.4 of the paper.

As shown in Figure 3 (in page 22 of the paper), we combine the biometric key generation process with the key pair regeneration process of our protocredential-based authentication method. The biometric sample (the iris image in the figure) is a non-stored secret (the only one in this case), and the auxiliary data is kept in the protocredential as a non-stored-secret related parameter. The auxiliary data and the biometric sample are combined to produce the biometric key. A randomized hash of the biometric key is computed using a salt which is also kept in the protocredential, as a second non-stored-secret related parameter. The randomized hash of the biometric key is used to regenerate the key pair, in conjunction with the key-pair related parameters. The key pair regeneration process produces a DSA, ECDSA or RSA key pair as described in sections 2.6.2, 2.6.3 and 2.6.4 respectively. The public key is sent to the application back-end, and the private key is used to demonstrate possession of the credential by signing a challenge. Figure 4 (in page 23 of the paper) adds a PIN as a second non-stored secret for three-factor authentication; in that case the auxiliary data is kept encrypted in the protocredential, and decrypted by x-oring the ciphertext with a randomized hash of the PIN.

The combination of biometric key generation with our protocredential-based authentication method represents a significant improvement on biometric authentication methodology. There is an intrinsic trade-off between the consistency of a biometric key across genuine biometric samples and the entropy of the key, because the need to accommodate large enough variations among genuine biometric samples reduces the entropy of the key. In the above mentioned paper by Hao et al., the authors are apologetic about the fact that their biometric key has only 44 bits of entropy when the auxiliary data is known. But this is not a problem in our authentication framework, for two reasons:

  1. The auxiliary data is not public. An adversary must capture the user’s device to obtain it.
  2. An adversary who captures the user’s device and obtains the auxiliary data cannot mount an offline guessing attack against the biometric key. All biometric keys produce well-formed DSA or ECDSA key pairs, and most biometric keys produce well-formed RSA key pairs. To determine if a guessed biometric key is valid, the adversary must therefore use it to generate a key pair, and use the key pair to authenticate online against the application back-end, which will limit the number of guesses to a small number. Forty-four bits of entropy is plenty if the adversary can only make, say, 10 guesses.

Therefore our authentication method makes it possible to use low-entropy biometric keys without compromising security. This may enable the use of biometric modalities or techniques that otherwise would not provide sufficient security.

Nevertheless we do not advocate the routine use of biometrics for authentication. As pointed out in Section 10, while malware running on the user’s device after an adversary has captured it cannot obtain biometric data, malware running on the device while the user is using it could obtain a biometric sample by prompting the user for the sample. A biometric authentication factor should only be used when exceptional security requirements demand it and exceptional security precautions are in place to protect the confidentiality of the user’s biometric features.

Defense in Depth of Cryptographic Credentials on a Mobile Device

This is the third of a series of posts discussing the paper A Comprehensive Approach to Cryptographic and Biometric Authentication from a Mobile Perspective.

Credentials based on public key cryptography provide much stronger security than ordinary passwords or one-time passwords. But a mobile device can be lost or stolen. How can a credential kept in a mobile device be protected if the user’s device is captured by an adversary? Two methods are traditionally used:

  1. Private key encryption. The private key is encoded as specified by PKCS #8, together with cryptographic parameters that typically include the public key or a public key certificate, and the resulting encoded string is encrypted under a symmetric data-encryption key derived from a passcode. This method is used, for example to protect SSH credentials used to manage cloud-hosted virtual servers. But as explained in Section 4.3.1 of the paper this method requires a high-entropy password, which is exceedingly difficult to type on the touchscreen keyboard of a smart phone.
  2. Tamper resistance. This is relied upon, for example to protect credentials in smart cards such as PIV or CAC cards. But few mobile devices have tamper resistant modules.

On an iPhone or an iPad one could think of relying on the data protection method introduced in iOS 4, which encrypts data in a locked device under a key derived from the passcode that the user enters to unlock the device and a key embedded in a hardware encryption chip. But, as explained in section 5.1 of the paper, that method has not proved to be effective.

Instead, Section 2 of the paper proposes a method for using an uncertified key pair for multifactor closed-loop authentication that makes it possible to protect the key pair without relying on any special hardware. The method is generally applicable, but is particularly useful for authentication on a mobile device. The idea is to store in the device cryptographic parameters obtained during initial credential generation, at least one of them being a secret, and later, at authentication time, to regenerate the credential from the stored cryptographic parameters and non-stored secrets supplied by the user such as a PIN and/or a biometric sample. (The non-stored secrets could be supplied by a physical uncloneable function, a PUF, in the case of an autonomous device; but the paper is not concerned with autonomous devices.) We refer to the stored parameters as a protocredential. Possession of the protocredential counts as one authentication factor, while the non-stored secrets play the role of additional authentication factors.

The paper distinguishes between parameters related to the key pair and parameters related to the non-stored secrets. In the case where a PIN is the only non-stored secret, illustrated in Figure 2, there is one non-stored-secret related parameter, a salt used to compute a randomized hash of the PIN. (Two-factor authentication with a biometric sample and three-factor authentication with a PIN and a biometric sample are discussed in Figures 3 and 4. I will discuss biometric authentication in the next blog post.) The key-pair related parameters depend on the public key cryptosystem being used. In the case of DSA and ECDSA, the key-pair related parameters are the domain parameters specified in the Digital Signature Standard. In the case of RSA, there is one key-pair related parameter, the least common multiple &#x03BB of p-1 and q-1, where p and q are the prime factors of the modulus. The key pair regeneration procedures for DSA, ECDSA and RSA are described in sections 2.6.2, 2.6.3 and 2.6.4 respectively.

In a mobile device, once the key pair has been regenerated, it is used by the device to authenticate to a mobile application with which the device has been previously registered. The application may have a native front-end or use a web browser as its front-end. The application back-end has a database that contains a record for the device, identified by a device record handle (a database primary key). To authenticate, the device sends the device record handle and the public key to the application back-end and demonstrates knowledge of the private key by signing a challenge. The back-end verifies the signature, uses the device record handle to locate the device record, computes a cryptographic hash of the public key, and verifies that the hash coincides with a hash stored in the device record. (A mobile authentication architecture that allows application developers to implement the authentication process without using a cryptographic API is described in Section 7; I will discuss it in another post later in this series.)

An adversary who captures the device and is able to read the protocredential needs the non-stored secrets to be able to regenerate the credential and authenticate. The adversary can try to guess the non-stored secrets. If a PIN is the only non-stored secret and the user chooses a 4-digit PIN, the adversary only has to try 10,000 PINs. If the adversary can test each PIN offline, it is trivial to go through all 10,000 PINs. But all PINs (in the case of DSA and ECDSA) or most PINs (in the case of RSA) produce well-formed key pairs. If the adversary does not know the public key (nor a hash of the public key), the only way to test a PIN is to try to use the key pair that it produces to authenticate online against the application back-end; and the back-end can limit the number of guesses to a very small number, such as 3 or 5 or 10. A 4-digit PIN can then be deemed to provide sufficient security, just as 4-digit PIN is usually considered secure enough for withdrawing cash from an ATM, which also limits the number of PIN guesses.

To ensure that the adversary does not know the public key, the public key should be treated as a shared secret between the device and the application back-end. Treating a public key as a secret is an unconventional and paradoxical use of public key cryptography. Section 4.1 explains that a shared symmetric secret could be used instead of a key pair but would result in a weaker security posture.

To prevent a man-in-the-middle attack, the device connects to the back-end using TLS (or some other kind of secure connection). Furthermore, the challenge signed by the device to demonstrate knowledge of the private key includes the TLS server certificate of the application back-end. Section 2.1 explains how this prevents a man-in-the-middle attack even if the adversary is able to spoof the TLS server certificate of the back-end.

All this results in a very strong defense-in-depth security posture. As discussed in Section 4.2 and summarized in Table 1, authentication is secure even against an adversary who is able to:

  1. Capture the user’s device and read the protocredential from the device storage; or
  2. Breach the security of the database back-end and obtain the hash of the public key. The adversary cannot mount an offline attack against a PIN used as single non-stored secret because the adversary does not have the protocredential, which contains at least one secret parameter. Compare this to the effect of a breach of database security when the database contains hashes of passwords, all of which become vulnerable to offline dictionary attacks; or
  3. Breach network security and read the traffic from the device to the back-end (e.g. after the TLS connection has been terminated at a reverse proxy, in a misconfigured infrastructure-as-a-service cloud). Again, the adversary cannot mount an offline attack against the PIN; or
  4. Spoof the TLS server certificate of the application back-end, as discussed above.

Also, in use cases demanding exceptionally high security, by using a high-entropy set of non-stored secrets, it is possible to achieve security even against an adversary who breaches database or communication security and then captures the device and obtains the protocredential.

We have seen how to protect an uncertified key pair used for closed-loop authentication. How about other types of credentials? Section 5 shows how the multifactor closed-loop authentication method discussed above can be used to provide effective protection for data stored in a mobile device, and in particular to provide protection for any kind of credentials, including credentials used for open-loop authentication, such as such as public key certificates, U-Prove tokens or Idemix anonymous credentials.

In the next post I will discuss the use of a biometric sample as a non-stored secret, and explain how it can achieve strong security without putting at risk the confidentiality of the user’s biometric features.