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

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.

Posted in Security | Tagged , , | 3 Comments

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.

Posted in Security | Tagged , , | 3 Comments

Apple Pay, EMV and Tokenization

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!)

Posted in Security | Tagged , , | 8 Comments

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.

Posted in Security | Tagged , | 4 Comments

Forthcoming Presentation at the GlobalPlatform TEE Conference

I’m happy to announce that I’ll be making a presentation at the forthcoming GlobalPlatform TEE Conference (September 29-30, Santa Clara, CA). Here are the title and abstract:

Virtual Tamper Resistance for a TEE

Derived credentials are cryptographic credentials carried in a mobile device that are derived from credentials carried in a smartcard. The term was coined by the US National Institute of Standards and Technology (NIST) in connection with US Federal employee credentials, but the concept is generally applicable to use cases encompassing high-security enterprise IDs, payment cards, national identity cards, driver licenses, etc.

The Trusted User Interface feature of a TEE can protect the passcode that activates derived credentials from being phished or intercepted by malware, the user being instructed to only enter the passcode when a Security Indicator shows that the touchscreen is controlled by the Secure OS of the TEE. Besides protecting the passcode, it is also necessary to protect the derived credentials themselves from an adversary who physically captures the device. This requires resistance against tampering. Physical tamper resistance can be provided by a Secure Element accessed from the TEE through the TEE Secure Element API, thus combining protection of the passcode against malware with protection of the credentials against physical capture.

Derived credentials can also be protected against physical capture using cloud-based virtual tamper resistance, which is achieved by encrypting them with a key stored in a secure back-end. The device uses a separate credential derived in part from the activation passcode to authenticate to the back-end and retrieve the encryption key. A novel technique makes it possible to do so without exposing the passcode to an offline guessing attack, so that a short numeric passcode is sufficient to provide strong security.

Physical tamper resistance and virtual tamper resistance have overlapping but distinct security postures, and can be combined, if desired, to maximize security.

Posted in Uncategorized | Leave a comment

Identity-Based Protocol Design Patterns for Machine-to-Machine Secure Channels

Cryptography is an essential tool for addressing the privacy and security issues faced by the Web and the Internet of Things. Sadly, however, there is a chronic technology transfer failure that causes important cryptographic techniques to be underutilized.

An example of an underutilized technique is Identity-Based Cryptography. It is used for secure email, although not broadly. But, to my knowledge, it has never been used to implement secure channel protocols, even though it has the potential to provide great practical advantages over traditional public key infrastructure if put to such usage. We pointed this out in our white paper on TLS. Now we have also shown the benefits of identity-based cryptography for machine-to-machine communications, in a new paper that we will present at the Workshop on Security and Privacy in Machine-to-Machine Communications (M2MSec, San Francisco, October 29, 2014). Machine-to-machine communications fall into many different use cases with very different requirements. So, instead of proposing one particular technique, we propose in the paper four different protocol design patterns that could be used to specify a variety of different protocols.

Update (August 4). I should point out that there is a proposal to use Identity-Based authenticated key exchange in conjunction with MIKEY (Multimedia Internet KEYing), a key management scheme for SRTP (Secure Real-Time Transport Protocol), which itself is used to provide security for audio and video conferencing on the Internet. The proposed authenticated key exchange protocol is called MIKEY-IBAKE and is described in RFC 6267. This is an informational RFC rather than a standards-track RFC, so it’s not clear if the proposed authenticated key exchange method will be eventually deployed. Interestingly, MIKEY-IBAKE uses identity-based encryption rather than identity-based key agreement. This is also what we do in the M2MSec paper, but with a difference. MIKEY-IBAKE uses identity-based encryption to carry ephemeral Elliptic Curve Diffie-Hellman parameters, and thus does not reduce the number of roundtrips. We use identity-based encryption to send a secret from the initiator to the responder, and we eliminate roundtrips by simultaneously sending application data protected with encryption and authentication keys derived from the secret. This gives up replay protection and forward secrecy for the first message; but replay protection, as well as forward secrecy in two of the four patterns, are provided from the second message onward.

Posted in Uncategorized | Leave a comment

Invited Talk at the University of Utah

I’ve been so busy that I haven’t had time to write for more than three months, which is a pity because things have been happening and there is much to report. I’m trying to catch up today.

The first thing to report is that Prof. Gopalakrishnan of the University of Utah invited Karen Lewison and myself to give a joint talk at the University, on May 29. We talked about the need to replace TLS, which I’ve discussed earlier on this blog. The slides can be found at the usual location for papers and presentations at the bottom of each page of this web site.

The University of Utah has a renowned School of Computing and it was quite stimulating to meet with faculty and discuss research after the talk. We were happy to discover common research interests, and we have been exploring the possibility of doing joint research work with Profs. Ganesh Gopalakrishnan, Sneha Kasera, and Tammy Denning; we are thrilled that the prospects look promising.

Other things to report include that we had papers accepted at the forthcoming M2MSec workshop and the forthcoming GlobalPlatform TEE conference. I will report on that in the next two posts.

Posted in Uncategorized | Leave a comment

Patent Illustrates Five Different Problems with Software Patents

I recently looked at a patent issued last January in the area of secure messaging, US 8,625,805. It uses the term “Digital Security Bubble” (the title of the patent) to refer to a concept which, in my opinion, is no different from the concept of digital envelope or enveloped data found in RFC 5652 (Cryptographic Message Syntax) or the earlier RFC 2315 (PKCS #7). I posed a question on Ask Patents, asking what could be done to challenge the patent short of obtaining a Post Grant Review, which would cost $30,000 or more just in USPTO fees (including a $12,000 request fee and a $18,000 post-institution fee for challenging up to 15 claims, plus $250 for each additional claim being challenged beyond 15). Phoenix88 suggested submitting prior art under 37 CFR 1.501 and 35 USC 301, which requires no fee. Following his advice, I studied the patent in detail and I have submitted as prior art PKCS #7 as well as RFC 1422, an RFC related to Privacy Enhanced Mail (PEM) that PKCS #7 relies upon. If the USPTO accepts the submission, it will be entered into the patent file. In the meantime, it can be found online on the Pomcor site.

But the reason I’m writing this post is that US patent 8,625,805 can serve to identify and illustrate five different problems with software patents, some well known, some that may not have been identified before. Here are those five problems.

1. The Vocabulary Problem

Whereas disciplines such as medicine, biology, chemistry and the various branches of engineering have developed mature and well-established vocabularies for their subject matters, software engineers like to invent their own fanciful vocabulary as they go. Think for example of the invention of the term cookie by Netscape to refer to a data item that stores server state in an HTTP client.

Inventing a new term is justified when the term is applied to a new concept, or when existing terminology is inadequate. But it is deplorable when there exists adequate terminology for the same concept.

Creation of unnecessary terminology may be due to ignorance of existing terminology. But in their comments on prior art resources, which can be found in a USPTO web page, Public Knowledge, the Electronic Frontier Foundation and Engine Advocacy have said that “applicants are able to use invented terminology in order to avoid prior art.” Without judicial discovery it is not possible to tell whether the term “digital security bubble” was used in US 8,625,805 instead of “digital envelope” for the purpose of obfuscation, or simply because the inventors were not familiar with standard secure messaging terminology.

The lack of stable and broadly accepted terminology drastically reduces the ability to find relevant documents by keyword search, i.e. it reduces what is known as recall in information retrieval. The patent file of US 8,625,805 includes a Search Strategy entry (SRNT) showing that 13 out of 26 prior art search queries contained the keyword “bubble”; the useless keyword “bubble” thus took up 50% of the time and effort spent by the examiner on keyword search. (The search strategy entry can be found using the Image File Wrapper tab in the Public Patent Application Information Retrieval tool — Public PAIR — of the USPTO.)

Besides poor recall, keyword searches of software literature also suffer from the opposite problem, poor precision. This is due to the fact that some popular words are used for many different purposes. The word token, for example, has a large number of different meanings. The combination of poor recall and poor precision means that keyword search is not well suited to finding prior art relevant to software patent applications.

The USPTO has launched a Glossary Pilot that provides incentives for applicants to include a glossary section in the specification. While a glossary section may be useful for other purposes, it does not prevent or discourage the use of non-standard terminology.

2. The Search Corpus Problem

The second problem with software patents has to do with the databases that examiners use to search for prior art.

Although the Search Notes entry (SRFW) in the patent file of US 8,625,805 indicates that the examiner did some Non-Patent Literature (NPL) searching, all 26 queries documented in the Search Strategy entry (SRNT) were run on patent literature databases. Since few software patents were granted or applied for before the late nineties, documentation of fundamental software inventions such as secure messaging, cannot be found in the patent literature.

3. Lack of “Full, Clear, Concise and Exact” Descriptions

A patent is supposed to embody a quid pro quo: the inventor gets a monopoly on the use of the invention, and in exchange discloses the invention so that the public can use it once the patent has expired. The inventor’s side of the bargain is codified in 35 USC 112(a):

The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.

But too often, software patents make claims without providing a “full, clear, concise and exact description” of what is being claimed. Claim 15 of US 8,625,805 is a good example. Here is the claim:

15. The system of claim 1 wherein the processor is configured to perform the encapsulation at least in part by performing a spreading function.

And here is what the specification has to say on what it means to “perform the encapsulation at least in part by performing a spreading function”:

In some embodiments (e.g., as is shown in FIG. 5), a spreading function is used to spread the encrypted symmetric keys inside the DSB (as shown in region 512), by spreading the bits of the encrypted key in a spreading function generated pattern, with the default function being a sequential block or data. The spreading function also contains the cryptographic hashed representation of the recipient usernames that are used by the server to identify the recipients of the message and to set the message waiting flag for each of them.

I don’t understand this at all, and FIG. 5 does not help. If you understand it and would like to explain it in a comment, I would appreciate it.

Lack of compliance with 35 USC 112(a) seems to be a common problem. Software engineers often complain that software patents are incomprehensible. Sometimes, software engineers do not even understand their own patents, written up by patent attorneys:

Against my better judgement, I sat in a conference room with my co-founders and a couple of patent attorneys and told them what we’d created. They took notes and created nonsensical documents that I still can’t make sense of.

A “person skilled in the art” of software is called a software engineer or a software developer. Hence patents that are incomprehensible to software engineers, by definition, do not comply with 35 USC 112(a). Unfortunately, the USPTO does not seem to be keen on enforcing compliance with 35 USC 112(a). Sometimes I wonder if examiners read the patent specification at all, or only read the claims.

4. The Means-or-Step-Plus-Function Problem for Security Claims

US 8,625,805 also illustrates a tricky problem specific to security claims. Here is claim 16:

16. The system of claim 1 wherein only a designated recipient, having a device with applicable device characteristics, is able to decrypt the message.

I believe this claim is objectionable under 35 USC 112(b) because it does not point out any subject matter. It should have been written in means-plus-function form, e.g. “the system of claim 1, further comprising a means of preventing the decryption of the message other than by a designated recipient having a device with applicable characteristics,” with “means” referring to the following portions of the specification:

At 208, a device identifier (“deviceID”) is created from captured hardware information. Examples of captured hardware information include: hard drive identifiers, motherboard identifiers, CPU identifiers, and MAC addresses for wireless, LAN, Bluetooth, and optical cards. Combinations of information pertaining to device characteristics, such as RAM, CACHE, controller cards, etc., can also be used to uniquely identify the device. Some, or all, of the captured hardware information is run through a cryptographic hash algorithm such as SHA-256, to create a unique deviceID for the device. The captured hardware information can also be used for other purposes, such as to seed cryptographic functions.

FIG. 10 illustrates an example of a process for accessing a message included inside a digital security bubble. In some embodiments, process 1000 is performed on a client device, such as Bob’s client device 114. The process begins at 1002 when a DSB is received. As one example, a DSB is received at 1002 when app 138 contacts platform 102, determines a flag associated with Bob’s account has been set, and downloads the DSB from platform 102. In such circumstances, upon receipt of the DSB, client 114 is configured to decrypt the DSB using Bob’s private key (e.g., generated by Bob at 202 in process 200).

At 1004 (i.e., assuming the decryption was successful), hardware binding parameters are checked. As one example, a determination is made as to whether device information (i.e., collected from device 114) can be used to construct an identical hash to the one included in the received DSB. If the hardware binding parameters fail the check (i.e., an attempt is being made to access Alice’s message using Bob’s keys on a device that is not Bob’s), contents of the DSB will be inaccessible, preventing the decryption of Alice’s message. If the hardware binding parameter check is successful, the device is authorized to decrypt the symmetric key (i.e., using Bob’s private key generated at 202) which can in turn be used to decrypt Alice’s message.

This is very vague, and I don’t think it qualifies as a full, clear, concise, and exact description. But the gist of it seems to be that an encrypted message is accompanied by a hash of hardware parameters of a destination device. When the message is received, an app checks whether the hash matches a hash of the hardware parameters of the device where the app is running. If the check fails, the app refuses to decrypt the message.

The point I really want to make, however, is that this method of “hardware binding” does not work. An adversary who has Bob’s private key is not prevented from decrypting the message on a device other than Bob’s device just because an app on Bob’s device is programmed to check the hash of hardware parameters. The adversary can do anything he or she wants on his or her own device. The adversary can, for example, use an app that behaves the same as the app used by Bob except that it omits the check.

This illustrates an important point, specific to security claims, that I have not seen discussed before. It is practically impossible to verify that a means-or-step-plus-function claim is supported by the specification, if the function being claimed is to achieve a security goal. It may be easy to see that a claim like the above is NOT supported. But establishing that a security claim IS supported would require writing and verifying a mathematical proof that the security goal is achieved based on a mathematical model of the a system described in the specification, something which is theoretically possible but not realistically achievable today. Furthermore the statement of the goal would have to be probabilistic, since security is rarely absolute.

This is important because allowing a security claim supported by a description of a technique that does not work does a lot of damage. Somebody else may later invent a technique that does work. Then the person who has been granted a patent on the security claim based on the technique that does not work will be able not only to prevent the person who has found the technique that works from obtaining a patent, but also to prevent everybody from using the technique that works.

5. A Loophole for Avoiding Third-Party Preissuance Submissions

The America Invents Act (AIA) has introduced Preissuance Submissions of Prior Art, which allow third parties to submit prior art to the examiners, and the USPTO is keen on crowdsourcing access to prior art. This a is good thing. But US 8,625,805 avoided third-party scrutiny because the application underwent a Prioritized, a.k.a. Track I, Examination and, like many Track I applications, was not published until granted. (The fact that US 8,625,805 was a Track I patent was noted by George White in a comment on Ask Patents.)

Prioritized Examination, which requires an additional fee of $2,000 for a small entity, has the effect of shortening the waiting time before an examiner takes up the application from years to a few months. Before AIA this was already an extremely unfair and undemocratic procedure, shortening the process for corporations and rich inventors who could afford it while lengthening it for everybody else. Now, after AIA, it can also be used as a loophole to shield those who can afford the fee from third party submissions of prior art, making it easier for them to obtain low quality and overly broad patents which they can inflict on society.

A second loophole for preventing preissuance submission is simply for the applicant to request non-publication of the application. This loophole costs nothing, but it precludes filing in foreign countries that require publication.

More generally, preissuance submission must take place after pre-grant publication, so there can be no preissuance submission if there is no pre-grant publication. The above loopholes prevent preissuance submission by eliminating pre-grant publication. But pre-grant publication may also fail to take place in the normal course of business. By default, it takes place no earlier than 18 months after the earliest benefit date. If the application does not claim the benefit of any earlier application, in an ideal world the USPTO should be able to examine it in less than 18 months, in which case there would be no pre-grant publication, and hence no possibility of preisssuance submission.

Since the 18 months delay in publication and the non-publication request provision are statutory, allowing preissuance submission for all applications requires a change in the law. Since preissuance submission is essential for improving the quality of software patents, such a change is badly needed. I would suggest introducing a minimum 3-month time period between publication and allowance. A request for non-publication would hold publication in abeyance until the examiner thinks the claims are allowable; but then the application would be published and open to preissuance submission of prior art and comments for three months before actual allowance.

While waiting for legislation to be enacted, the Post-Grant Review fees should be drastically reduced, and the onerous requirements on Post-Grant Review petitions should be simplified so that it is not necessary to hire a patent lawyer to file a petition.

Conclusion

The problem of poor quality software patents is difficult and multi-faceted, and many ideas have been proposed for addressing it. Here I would just like to make a few suggestions related to the above observations.

  • Prioritized Examination should be eliminated.
  • The Post Grant Review request fee should be no greater than the Appeal Forwarding fee for a small entity ($1,000). There should be no post-institution fee and no per-claim fee, and a refund of 50% of the request fee should be given if the request is found to have merit and the review is granted.
  • Examiners of software patents should be instructed to direct at least half of their search efforts towards non-patent literature, and to document the non-patent literature queries that they run. Some searchable sources of non-patent literature have been suggested by others in comments on prior art resources. I would add the collection of IETF RFCs and Internet Drafts, which can be searched by restricting a web search to the site datatracker.ietf.org.
  • In addition to crowdsourcing the search for prior art, the USPTO should accept and encourage comments by persons skilled in the art, such as software engineers in the case of software patents, on whether specifications are comprehensible, provide a full, clear, concise, and exact description of the invention, and support the claims.
  • The specification of every patent application containing one or more means-or-step-plus-function claims should be required to contain a separate section explaining in detail how each claimed function is provided. This will not guarantee that every security goal asserted by a means-or-step-plus-function claim is achieved by the invention, but it will at least help third-party reviewers and examiners to identify unsupported claims.

The USPTO has requested comments on “The Use of Crowdsourcing and Third-Party Preissuance Submissions To Identify Relevant Prior Art,” and more generally on “ways the Office can use crowdsourcing to improve the quality of examination.” They are due by April 25. We are sending ours. Please consider sending yours.

Posted in Patents | Tagged , | 1 Comment

Derived Credentials in a Trusted Execution Environment (TEE)

In the previous post I discussed the storage of derived credentials (Federal credentials carried in a mobile device instead of a PIV/CAC card) in a software token, i.e. in a cryptographic module implemented entirely in software, whose contents are stored in ordinary flash memory. In this post I will discuss the storage of derived credentials in a Trusted Execution Environment (TEE).

Malware Attacks

As discussed in the previous post and in a technical report, it is possible to protect derived credentials stored in ordinary flash storage by encrypting them under a high entropy key-wrapping key kept in a secure back-end, which the mobile device retrieves by authenticating to the back-end with a key pair regenerated from a protocredential and an activation passcode.

This provides effective protection against an adversary who captures the device while the software token is not active, preventing the adversary from extracting or using the credentials. But it does not provide protection against malware running on the device while the legitimate user is using the device. Such malware can carry out the following attacks:

  1. It can use the derived credentials, by issuing instructions to the software token after it has been activated by the legitimate user.
  2. It can read the plaintext derived credentials from the flash storage after the software token has been activated, and transmit them to the adversary responsible for the malware, who can then use them at will on a different machine.
  3. It can capture the activation passcode by phishing or intercepting it. In a phishing attack, malware prompts the user for the passcode while masquerading as legitimate code that needs the passcode, such as token activation code. In an interception attack, malware gets the passcode after it has been obtained from the user by legitimate code.

The first of these attacks may be impossible to prevent once privileged malware is running on the mobile device without the user being aware of it. But the second and third attacks can be prevented using a TEE as we shall see below; and preventing them is important because they are more damaging than the first attack.

The second attack, extracting the credentials and sending them to the adversary, is more damaging than the first because it cannot be stopped by recovering or wiping the stolen device. Use of an authentication or signature private key cannot be stopped until the associated certificate is revoked and relying parties become aware of the revocation. Correspondents should avoid sending messages encrypted under a symmetric key wrapped by a “key management” public key after becoming aware that the key management certificate has been revoked. But there is no time limit for using a key management private key to decrypt earlier messages that the adversary may have previously captured or may capture in the future, e.g. by breaching the security of a MS Exchange server containing older encrypted messages.

The third attack is even more damaging for several reasons. First, it enables the first two attacks, because once it has the passcode, malware can activate the software token and use and extract the plaintext derived credentials. Second, if the adversary captures the device after using malware to obtain the passcode, the adversary can use the device, or install more comprehensive malware that is able to extract the credentials. Third, the passcode may be independently exploitable because it may be used for other purposes.

A TEE has security features that make it possible to prevent the second and third attacks.

Features of a TEE

A TEE is a computing environment provided by a secure OS running on the same processor as a normal OS. One or more trusted applications (TAs) run under the secure OS. A hardware bus architecture ensures that a portion of the flash storage can only be accessed by the secure OS. Both OSes can access the touchscreen, but a security indicator lets the user know when the screen is controlled by the secure OS and the user interface can be trusted. GlobalPlatform is developing TEE specifications, including a Trusted User Interface API specification, which can be downloaded from the GlobalPlatform site. TEEs are provided by ARM Cortex-A processors, where a TEE is also referred to as a TrustZone. A TA running in a TEE can be used to implement a cryptographic module in which derived credentials can be stored and used.

Using a TEE to Protect Derived Credentials

Derived credentials stored and used in a cryptographic module implemented within a TEE can be protected against the second malware attack discussed above by making their private keys unextractable from the cryptographic module. The ability to mark private keys as being unextractable is a typical feature of cryptographic modules. The PKCS #11 cryptographic module API, for example, allows private keys to be made non-extractable by setting the value of their CKA_EXTRACTABLE attribute to CK_FALSE. The forthcoming TEE Functional API, mentioned in the TEE white paper, will no doubt allow private keys stored in a cryptographic module within a TEE to be made non-extractable as well.

Furthermore, derived credentials stored in a cryptographic module within a TEE can be protected against the third malware attack using the Trusted User Interface feature of the TEE. The passcode can be prompted for by the TA that implements the cryptographic module, and the user can be instructed to only enter the passcode when a Security Indicator shows that the touchscreen is controlled by the Secure OS of the TEE. The passcode is then protected against phishing and interception by malware, assuming that all TAs can be trusted and that the secure OS is not infected by malware. The latter assumption is motivated by the fact that the secure OS is simpler than the normal OS and presents a much smaller attack surface.

Virtual Tamper Resistance

Using the same processor and a portion of the same storage for the secure OS as for the normal OS has important benefits. It provides greater performance for the secure OS than would typically achieved by a secondary processor located in a secure element, and it saves the cost of the secure element. On the other hand, it means that a TEE is not expected to provide much, if any, tamper resistance. Indeed, the TEE Secure Element API, available at the GlobalPlatform site, is concerned with using together a TEE and a secure element, with the TEE providing a Trusted User Interface, and the secure element providing tamper resistance.

(BTW, some secure elements do provide serious tamper resistance, but tamper resistance is never absolute. A fascinating description of the elaborate anti-tampering countermeasures in a family of Infineon chips, and how they were defeated by an attacker with no insider knowledge, can be found in an 80-minute video demonstration—broken down into ten eight-minute segments—presented at Black Hat 2010.)

But the lack of tamper resistance in a TEE can be remedied using the same technique that I described in the previous post as a solution to the problem of protecting derived credentials stored in a software token. Encrypting the derived credentials under a high entropy key-wrapping key, kept in a secure back-end and retrieved by authenticating to the back-end with a key pair regenerated from a protocredential and an activation passcode, can be viewed as a form of cloud-based virtual tamper resistance.

Combining such virtual tamper resistance with the TEE Trusted User Interface feature would make it possible to implement a cryptographic module that would protect both the derived credentials and their activation passcode.

Posted in Uncategorized | Leave a comment

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.

Posted in Identity | Tagged , , , , , , , , , | 2 Comments