Blog – Page 9

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.

Forthcoming Presentation at the GlobalPlatform TEE Conference

I'm happy to announce that I'll be making a presentation at the forthcoming GlobalPlatform 2014 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.

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.

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.

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.

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:

It can use the derived credentials, by issuing instructions to the software token after it has been activated by the legitimate user.
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.
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.

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,

NISTIR 7981, Mobile, PIV, and Authentication, and
NIST Special Publication 800-157, Guidelines for Derived Personal Identity Verification (PIV) 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:

Federal agencies would have the flexibility to use any mobile devices they want.
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.
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.

It’s Time to Redesign Transport Layer Security

One difficulty faced by privacy-enhancing credentials (such as U-Prove tokens, Idemix anonymous credentials, or credentials based on group signatures), is the fact that they are not supported by TLS. We noticed this when we looked at privacy-enhancing credentials in the context of NSTIC, and we proposed an architecture for the NSTIC ecosystem that included an extension of TLS to accommodate them.

Several other things are wrong with TLS. Performance is poor over satellite links due to the additional roundtrips and the transmission of certificate chains during the handshake. Client and attribute certificates, when used, are sent in the clear. And there has been a long list of TLS vulnerabilities, some of which have not been addressed, while others are addressed in TLS versions and extensions that are not broadly deployed.

The November SSL Pulse reported that only 18.2% of surveyed web sites supported TLS 1.1, which dates back to April 2006, only 20.7% supported TLS 1.2, which dates back to August 2008, and only 30.6% had server-side protection against the BEAST attack, which requires either TLS 1.1 or TLS 1.2. This indicates upgrade fatigue, which may be due to the age of the protocol and the large number of versions and extensions that it has accumulated during its long life. Changing the configuration of a TLS implementation to protect against vulnerabilities without shutting out a large portion of the user base is a complex task that IT personnel is no doubt loath to tackle.

So perhaps it is time to restart from scratch, designing a new transport layer security protocol — actually, two of them, one for connections and the other for datagrams — that will incorporate the lessons learned from TLS — and DTLS — while discarding the heavy baggage of old code and backward compatibility requirements.

We have written a new white paper that recapitulates the drawbacks of TLS and discusses ingredients for a possible replacement.

The paper emphasizes the benefits of redesigning transport layer security for the military, because the military in particular should be very much interested in better transport layer security protocols. The military should be interested in better performance over satellite and radio links, for obvious reasons. It should be interested in increased security, because so much is at stake in the security of military networks. And I would argue that it should also be interested in increased privacy, because what is viewed as privacy on the Internet may be viewed as resistance to traffic analysis in military networks.

Surveillance and Internet Identity

Last week I attended IIW 17, the 17th meeting of the Internet Identity Workshop, which is held twice a year in Mountain View, California. As usual it was a great opportunity to exchange ideas and meet people, with its unconference format, its many sessions, its rotating demos, its wide space for discussions, and its two free dinners with free drinks.

For me, however, it was tinged with sadness, because of what has happened since the first IIW I attended, IIW 12, in May 2011. IIW 12 was the first IIW after the launch of NSTIC. IIW 17 was the first IIW after Snowden.

The NSTIC Strategy Document, released in April 2011 with a preface signed by President Obama, repeatedly emphasized the goal of enhancing privacy as a key element of the "vision" and "guiding principles" of NSTIC. The document explicitly stated that the Identity Ecosystem will use privacy-enhancing technology and policies to inhibit the ability of service providers to link an individual's transactions, thus ensuring that no one service provider can gain a complete picture of an individual's life in cyberspace. At the time, Facebook Connect was threatening to inject Facebook as a middleman in all or most Internet activities, and I was happy to see that the US Government seemingly wanted to prevent such a massive invasion of privacy; I even convened a session at IIW 12 proposing a technique for achieving the privacy goals of NSTIC in the short term. Little did I know that the government was busy building a massive surveillance apparatus that would give the government a complete picture of an individual's life in cyberspace, by means including bulk collection of data from service providers.

The Internet, given to the world by the US Department of Defense, was a world-wide forum for free-flowing, spontaneous exchange of ideas. Now the NSA, part of the same Department of Defense, has taken that away. People know that they are being tracked and identified when they post an anonymous comment. People know that their conversations are being recorded. Therefore people must think twice about they say.

I don't know if Congress will be able to rein in the NSA. It should be clear that spying on US citizens is unconstitutional, but some politicians think that it is the NSA's job to spy on everybody else in the planet. They don't seem to consider or care that, if the US Government insists on a God-given right to spy on everybody else, other countries or regions may develop their own national or regional networks, separated from the US Internet by an air gap.

Fortunately, the technical community has reacted strongly against the NSA's attacks on Internet privacy. And thanks to Snowden's revelations, many of the attack techniques are known. It may therefore be possible to protect Internet privacy by technical means.

Coming back to the subject of the workshop, Internet Identity, I would argue that the first thing to do to protect Internet privacy is to get rid of the pernicious technology variously known as third-party login, social login or federated login. To be precise, I am referring to authentication techniques where the user authenticates to a third-party identity provider, which then provides identity and/or attribute information to a relying party, using a protocol such as OAuth or OpenID Connect. (These are the techniques in Group 2 of the taxonomy proposed in the paper Privacy Postures of Authentication Technologies.)

The only intrinsic advantage of federated login is that it allows the identity provider to collect vast amounts of information about the user, since the identity provider learns not only the user's identity and/or attributes, but also what relying parties the user logs in to. The identity provider uses the information to sell ads that target the user accurately. We now know that the information is also shared with the government, which makes it available to thousands of analysts and IT personnel who use it for legal or illegal government or personal purposes.

There are no other intrinsic advantages to federated login.

The government and the identity providers argue that federated login is more secure than direct authentication to the relying party with username and password, but the opposite is true.

Security is supposedly increased because federated login reduces password reuse. But password reuse will not be substantially reduced unless a large majority of world-wide web sites force their users to use federated login with one of a small number of global identity providers such as Google or Facebook, something that will hopefully not come to pass.

Security is also supposedly increased because a large identity provider supposedly does a better job of protecting the user's password. But I don't know why a large identity provider would provide better protection against hackers, since large companies are not known to provide great security. And I do know that a password entrusted to a large identity provider may become available to thousands of employees of the government, of government contractors, and of the identity provider.. And the capture of a password used at an identity provider, which provides access to multiple web sites, is more damaging to the user than the capture of a password used at a single web site.

There is an alternative to authenticating to a web site with username and password that provides both security and privacy: namely, authentication with a cryptographic key pair automatically generated on the user's machine when the user registers with the site. The site stores the hash of the public key component of the key pair in its database, and uses it to locate the user's account when the user visits the site again and demonstrates knowledge of the private key component.

Another claimed advantage of federated login is that the user can register at a new site with a single click if logged in to the identity provider, any personal data required by the site being provided by the identity provider. This is a real advantage, but not an intrinsic one. The same benefit could be easily obtained by storing the personal data in the browser, and specifying a protocol by which the browser would supply selected personal data items to a web site upon demand by the site and approval by the user. Such a protocol would be much simpler than any of the federated login protocols and would provide more security and more privacy.

Yet another claimed advantage of federated login is that the identity provider could provide the relying party with a user's identity and/or attributes verified by an identity proofing procedure; however, such verified identity and/or attributes could equally well be provided by a certificate authority using a public key certificate (or by multiple authorities providing a combination of a certificate binding a public key to an identity and one or more certificates binding the identity to various attributes), without the certificate authority having to be informed of what relying parties the certificate is submitted to.

It is sometimes argued (cf. the NSTIC 101 session at last week's IIW) that using public key cryptography for authentication would be expensive and would require the user to carry a separate dongle or smartcard for every credential. This is not true. There is no need for special hardware to store a cryptographic credential, and if special hardware is desired for some reason, there is no need to use different pieces of hardware for different credentials.

Two sessions at IIW 17 gave me hope that Internet privacy is not a lost cause.

One of them was convened by Tim Bray of Google to report on the comments he received in response to a blog post arguing to developers that they should use federated login rather than login with username and password. The comments, which he referred to as a "bloodbath," showed that neither developers nor end-users like federated login. I hope that such pushback will eventually force companies like Google to give up on federated login.

The other one was convened by Kazue Sako of NEC to discuss anonymous credentials and their possible uses. The room was overflowing and the level of engagement of the audience was high, showing that technical people are interested in privacy-enhancing authentication technologies even if large companies are not.