However, the revised protocol is still vulnerable to attacks.  In a paper that I presented at Financial Cryptography’10, I described two new attacks on HMQV. The first attack presents a counterexample to invalidate the basic authentication feature in the protocol. The second attack is generally applicable to other key exchange protocols despite that many have formal security proofs.

The first attack on HMQV is particularly concerning since the formal security proofs failed to detect this basic flaw. The HMQV protocol explicitly specifies that the Certificate Authority (CA) doesn’t need to validate the public key except checking it is not zero. (This is one reason why HMQV claims more efficient than MQV). So, the protocol allows the CA to certify a small subgroup element as the user’s “public key”. Then, anyone who knows this “public key” can successfully pass authentication using HMQV (see the paper for details). Note, in this case, a private key doesn’t exit, but the authentication is successful. What is the “authentication” in HMQV based on?

The HMQV author acknowledges this attack but states it has no bad effects. Although I disagree, this will be up to the reader to decide.

Well, some users may use applications they don’t want their friend to know about, like dating or job-search. And they certainly may not want others to know the time they used an application, if this makes it clear that they were playing a game on company time. This isn’t a catastrophic privacy breach, but it will definitely lead to a few embarrassing situations. As I’ve argued before, users should have a basic privacy expectation that if they continue to use a service in a consistent way, data won’t be shared in a new, unexpected manner of which they have no warning or control, and this new feature violates that expectation. The interesting thing is how Facebook is continually caught by surprise when their spiffy new features upset users. They seem equally clueless with their response: allowing developers to opt an application out of appearing on the dashboard. Developers have no incentive to do this, as they want maximum exposure for their apps. A minimally acceptable solution must allow users to opt themselves out.

It’s inexcusable that Facebook doesn’t appear to have a formal privacy testing process to review new features and recommend fixes before they go live. The site is quite complicated, but a small team should be able to identify the issues with something like the new dashboard in a day’s work. It could be effective with with 1% of the manpower of the company’s nudity cops. Notably, Facebook is trying to resolve a class-action lawsuit over their Beacon fiasco by creating an independent privacy foundation, which privacy advocates and users have both objected to. As a better way forward, I’d call for creating an in-house “privacy ombudsmen” team, which has the authority to review new features and publish analysis of them, as a much more direct step to preventing future privacy failures.

One question which has appeared a few times is why we called 3-D Secure (3DS) a single sign-on (SSO) system. 3DS certainly wasn’t designed as a SSO system, but I think it meets the key requirement: it allows one party to authenticate another, without credentials (passwords, keys, etc…) being set up in advance. Just like other SSO systems like OpenID and Windows CardSpace, there is some trusted intermediary which both communication parties have a relationship with, who facilitates the authentication process.

For this reason, I think it is fair to classify 3DS as a special-purpose SSO system. Your card number acts as a pseudonym, and the protocol gives the merchant some assurance that the customer is the legitimate controller of that pseudonym. This is a very similar situation to OpenID, which provides the relying party assurance that the visitor is the legitimate controller of a particular URL. On top of this basic functionality, 3DS also gives the merchant assurance that the customer is able to pay for the goods, and provides a mechanism to transfer funds.

People are permitted to have multiple cards, but this does not prevent 3DS from being a SSO system. In fact, it is generally desirable, for privacy purposes, to allow users to have multiple pseudonyms. Existing SSO systems support this in various ways — OpenID lets you have multiple domain names, and Windows CardSpace uses clever cryptography. Another question which came up was whether 3DS was actually transaction authentication, because the issuer does get a description of the transaction. I would argue not, because the transaction description does not go to the customer, thus the protocol is vulnerable to a man-in-the-middle attack if the customer’s PC is compromised.

A separate point is whether it is useful to categorize 3DS as SSO. I would argue yes, because we can then compare 3DS to other SSO systems. For example, OpenID uses the domain name system to produce a hierarchical name space. In contrast, 3DS has a flat numerical namespace and additional intermediaries in the authentication process. Such architectural comparisons between deployed systems are very useful to future designers. In fact, the most significant result the paper presents is one from security-economics: 3DS is inferior in almost every way to the competition, yet succeeded because incentives were aligned. Specifically, the reward for implementing 3DS is the ability to push fraud costs onto someone else — the merchant to the issuer and the issuer to the customer.

We have been working on multichannel protocols since 2005. Different channels have different advantages and disadvantages and therefore one may build a better security protocol by combining different channels for different messages in the protocol trace. (For example a radio channel like Bluetooth has high bandwidth, low latency and good usability but leaves you in doubt as to whether the message really came from the announced sender; whereas a visual channel in which you acquire a barcode with a scanner or camera has low bandwidth and poorer usability but gives stronger assurance about where the message came from.)

In this new paper we apply the multichannel paradigm to the problem of countering relay attacks. We introduce a family of protocols in which at least one message is sent over a special “unrelayable” channel. The core idea is that one channel connects the verifier to the principal with whom she shares the prearranged secret K, while another channel (the unrelayable one) connects her to the prover who is actually in front of her; and the men in the middle, however much they relay, can’t get it right on both of these channels simultaneously.

We convey this idea with several stories. Don’t take them too literally but they let us illustrate and discuss all the key security points.

This work is exciting for us because it opens up a new field. We look forward to other researchers following it up with implementations of unrelayable channels and with formal tools for the analysis of such protocols.

Frank Stajano, Ford-Long Wong, Bruce Christianson. Multichannel protocols to prevent relay attacks (preliminary; the final revised version of the full paper will be published in Springer LNCS)

In a paper I’m presenting today at Financial Cryptography, Steven Murdoch and I analyse 3D Secure. From the engineering point of view, it does just about everything wrong, and it’s becoming a fat target for phishing. So why did it succeed in the marketplace?

Quite simply, it has strong incentives for adoption. Merchants who use it push liability for fraud back to banks, who in turn push it on to cardholders. Properly designed single sign-on systems, like OpenID and InfoCard, can’t offer anything like this. So this is yet another case where security economics trumps security engineering, but in a predatory way that leaves cardholders less secure. We conclude with a suggestion on what bank regulators might do to fix the problem.

Update (2010-01-27): There has been some follow-up media coverage

• The Register – Verified by Visa bitchslapped by Cambridge researchers
• ZDNet UK – Cambridge researchers knock Verified by Visa
• Heise Security – Researchers criticise 3D Secure credit card authentication and Forscher kritisieren Kreditkartentechnik 3-D Secure
• PCWorld (IDG News Service) – 3D Secure Online Payment System Not Secure, Researchers Say
• V3.co.uk (formerly vnunet) – Researchers slam 3-D Secure as insecure

Update (2010-01-28): The New Scientist also has the story, as has Ars Technica.

The position paper I submitted (one more of the extensive Moore/Clayton canon on phishing) took a step back (though of course we intend to be a step forward), in that it looked at the very rich datasets that we have for phishing and asked whether this meant that we could usefully map or measure that particular criminal speciality?

In practice, we believe, bias in the data and the bias of those who are interpret it means that considerable care is needed to understand what all the data actually means. We give an example from our own work of how failing to understand the bias meant that we initially misunderstood the data, and how various intentional distortions arise because of the self-interest of those who collect the data.

Extrapolating, this all means that getting better data on other types of cybercrime may not prove to be quite as useful as might initially be thought.

As ever, reading the whole paper (it’s only 4 sides!) is highly recommended, but to give a flavour of the problem we’re drawing attention to:

If a phishing gang host their webpages on a thousand fraudulent domains, using fifty stolen credit cards to purchase them from a dozen registrars, and then transfer money out of a hundred customer accounts leading to a monetary loss in six cases: is that a 1000 crimes, or 50, or 12, or 100 or 6 ?

The phishing website removal companies would say that there were 1000 incidents because they need to get 1000 domains suspended. The credit card companies would say there were 50 incidents because 50 cardholders ought to have money reimbursed. Equally they would have 12 registrars to “charge back” because they had accepted fraudulent registrations (there might have been any number of actual credit card money transfer events between 12 and 1000 depending whether the domains were purchased in bulk). The banks will doubtless see the criminality as 100 unauthorised transfers of money out of their customer accounts; but if they claw back almost all of the cash (because it remains within the mainstream banking system) then the six-monthly Financial Fraud Action UK (formerly APACS) report will merely include the monetary losses from the 6 successful thefts.

Clearly, what you count depends on who you are — but crucially, in a world where resources are deployed to meet measurement targets (and your job is at risk if you miss them), deciding what to measure will bias your decisions on what you actually do and hence how effective you are at defeating the criminals.

Background: The Iraqi army (among others) has bought for millions of pounds ADE651 devices, which according to the vendor’s website can detect almost any substance of interest to the military (explosives, banknotes, drugs, etc.) even kilometres away. The devices contain no power source (”powered by the user’s static electricity”, no battery), resemble very much a dowsing rod, and generally leave much to be desired regarding a plausible operating principle or performance in repeatable double-blind trials. There are several such military dowsing rods on the market. The ADE651 distinguishes itself by being “programmable” with a plastic card that can be inserted into the unit to select the substance to be detected. Having already established that the card reader end was just an empty box, the BBC team wanted to know whether there is anything inside these programming cards.

They provided me with a few sample cards, which when held against a bright light showed in the centre the outline of what might be a loop antenna, similar to those used in RFID tags designed for short-wave frequencies.

I opened some of these cards by first heating them on a 60 °C hotplate to soften the glue that keeps the two layers of the laminate together and then slowly cut them apart from all sides, parallel to the card surface, using a sharp utility knife. About 16 mm from the centre of the cards, I encountered instead of glue an inserted 32 mm x 32 mm large paper sticker, and the card layers fell apart there easily. This paper sticker looked very much like it was designed to be used as part of an RF electronic article surveillance system, which is attached to goods in high-street shops and raises an alarm at sensors near the exit door if the tag hasn’t been deactivated at the till. Several observations confirmed this:

• The barcode looked very similar to the UPC one used by scanner tills in shops, but it was misaligned, the check digit of the number (048572 020000) was incorrect, the prefix of the number had been chosen such that it was not assigned to any country in UPC, and the barcode didn’t even match the number. All this suggests that the barcode is just carefully designed camouflage, to hide the real purpose of these stickers when used in shops, without the risk of being accidentally recognized at a checkout scanner. A member of the Newsnight team even found in a Currys shop an item with a security tag that had the exact same 8-digit number under the fake barcode.
• I cut away the remaining card plastic and used solvent (white spirit, ~80 °C) to dissolve the glue underneath the sticker. After a short time, the sticker paper with the barcode separated and revealed underneath a laminate of aluminium foil and transparent plastic foil. The aluminium was shaped into a coil. The coil centre had been folded out to form two plates of a capacitor. This was clearly meant to be a simple LC resonator, shaped exactly like the ones that RF electronic article surveillance systems near shop doors detect.
• I first used my fingers to find any hints of a semiconductor chip or other electronic component in the laminate, and could not feel any. To be completely sure that there was no chance of there being any semiconductor chip inside that I might have missed, I left the laminate overnight at room-temperature soaking in white spirit, such the remaining glue dissolved and all layers of the laminate came apart easily and completely. Another careful inspection of all surfaces and the solvent showed again no trace of any form of semiconductor device or other integrated circuit than the capacitor and coil formed by the aluminium foil.

All this left me very confident that the sticker was indeed a security label with fake barcode that had no capacity to be programmed with any other information than being deactivated at a shop till by a strong RF field (which shorts out the capacitor by breaking down the foil dielectric). There is no way in which this device could be programmed to distinguish the many different substances that the ADE651 manufacturer claimed it could, not to mention that any useful interaction with such an LC circuit would require a transmitter antenna, a power source, and lots of other components that the ADE651 appears to lack. And, to state the obvious, there is no way in which an anti-theft RF tag, like I found in these cards, could be able to help in detecting explosive substances such as TNT (as the Arabic letters on the card had claimed). I strongly suspect that these tags have been chosen because they are the cheapest and most easily available items that look vaguely electronic and are flat enough to fit inside a plastic card.

See the BBC News coverage and the BBC2 Newsnight programme on 22 January 2009, 22:30 for the full story.

These cards implement the EMV protocol (the same one used for Chip and PIN in the UK). Here, the card is sent the current date in 3-byte YYMMDD binary-coded decimal (BCD) format, i.e. “100101″ on 1 January 2010. If however this was interpreted as hexadecimal, then the card will think the year is 2016 (in hexadecimal, 1 January 2010 should have actually been “0a0101″). Since the numbers 0–9 are the same in both BCD and hexadecimal, we can see why this problem only occurred in 2010*.

In one sense, this looks like a foolish error, and should have been caught in testing. However, before criticizing too harshly, one should remember that EMV is almost impossible to implement perfectly. I have written a fairly complete implementation of the protocol and frequently find edge cases which are insufficiently documented, making dealing with them error-prone. Not only is the specification vague, but it is also long — the first public version in 1996 was 201 pages, and it grew to 765 pages by 2008. Moreover, much of the complexity is unnecessary. In this article I will give just one example of this — the fact that there are nine different ways to encode integers.

Compliant implementations must be able to implement all of these encoding forms; the one used in any one place depends on context.

TLV field lengths (< 128)

When data is sent from the card to the terminal, they are encoded in tag-length-value format (TLV), inherited from ASN.1. The tag specifies the type, and the length specifies how many bytes follow in the value. When the length is less than 128 bytes, the single length-byte has the most-significant bit cleared, and bits 7–1 encode the length.

TLV field lengths (≥ 128)

When a TLV field value is 128 bytes or longer, the length is encoded using multiple bytes. The first byte has the most-significant bit set, and bits 7–1 encode the number of length bytes that follow. These are then interpreted as a big-endian integer.

TLV tags (< 31)

EMV tags are also variable length. For tags which are less than 31, a single byte is used with bits 5–1 encoding the tag number (bits 8–7 specifies the namespace of the tag, and bit 6 specifies whether the value is encoded in TLV too).

TLV tags (≥ 31)

When the tag is 31 or greater, bits 5–1 of the first byte are set to “11111″ and the actual tag number is encoded in bits 7–1 of subsequent bytes. The last of these bytes has the most-significant bit cleared, whereas preceding ones have it set.

Compact TLV

Alternatively, data can be sent from the card to the terminal in compact TLV format. Here, both tag and length are combined into a single byte — bits 8–4 (after adding 0×40) becomes the tag, and bits 3–1 specifies the length. This is used for encoding data in the historical bytes of the answer-to-reset.

Numeric

Many data items are encoded as binary-coded decimal, with two digits per byte and left-padded with zeros (e.g. used for dates, amounts of currency, some protocol flags).

Compressed numeric

Some data items are encoded in “compressed” binary-coded decimal, with two digits per byte and right-padded with ‘F’s (e.g. used for account number, copy of track two magstrip data).

Binary

Other data items are big-endian integer encoded (e.g. used for encoding the transaction counter, public key parameters, and some protocol flags). Fields are fixed-length, but not necessarily on byte-boundaries.

ASCII

Some integers are encoded as their corresponding ASCII representation, with one digit per byte (e.g. used for encoding the copy of track one magstrip data) .

Given this wide variety of subtly different encodings (and I have probably missed some), it is not that surprising that a smart card developer could slip up, as has appeared to have occurred with the German EMV cards. Handling variable-length integers is a frequent source of bugs (ASN.1 is a particularly bad offender in this regard). This also makes me wonder whether there are security vulnerabilities in the cards or terminals.

* Actually, while this scenario explains the wide-scale problems occurring in 2010, if the month and day were interpreted as hexadecimal too, then cards which expired in September–December, would have problems in their last year of validity. The wrap-around for the day will cause a problem for cards expiring in September, during 20–30 September, because the BCD for 20 September 2009 is “090920″, which is greater than 31 September 2009 in hexadecimal — “09091f”. Similarly, the month will become a problem for cards expiring in October–December, during 1 October — 31 December, because the BCD for 1 October 2009 is 091001, which is greater than the 31 October/November/December 2009 in hexadecimal — “090a1f”/”090b1f”/”090c1f”). So either these glitches occurred but were attributed to random failure, or there is something special about the handling of the year in the failing Gemalto implementation (perhaps related to a conversion between two and four digit years).

This might seem a little surprising because within the EU a “data retention” regime has been in place since the Spring of 2009. So surely the mobile phone companies have to keep the NAT records of Internet access, even though this will be horribly expensive?

They don’t!

The reason is that instead of the EU Directive (and hence UK and other European laws) saying what was to be achieved — “we want traceability to work” — the bureaucrats decided to say what they wanted done — “we want logs of IP address allocation to be kept”. For most ISPs the two requirements are equivalent. For the mobile companies, with their massive use of NAT, they are not equivalent at all.

The EU Directive (Article 5) requires an ISP to retain for all Internet access events (the mobile call itself will require other info to be retained):

(a)(i) the user ID(s) allocated;
(a)(iii) the name and address of the subscriber or registered user to whom an Internet Protocol (IP) address, user ID or telephone number was allocated at the time of the communication;
(c)(i) the date and time of the log-in and log-off of the Internet access service, based on a certain time zone, together with the IP address, whether dynamic or static, allocated by the Internet access service provider to a communication, and the user ID of the subscriber or registered user;
(e)(ii) the digital subscriber line (DSL) or other end point of the originator of the communication;

That is, the company must record which IP address was given to the user, but there is no requirement to record the source port number. As discussed in this series of articles, this makes traceability extremely problematic.

It’s also somewhat unclear (but then much more of the Directive is technically unclear) whether recording the “internal” IP address allocated to the user is sufficient, or whether the NAT records (without the port numbers) need to be kept as well. Fortunately, in the UK, the Regulations that implement the Directive make it clear that the rules only apply once a notice has been served on an ISP, and that notice must say to what extent the rules apply. So in principle, all should be clear to the mobile telcos!

By the way … this bureaucratic insistence on saying what is to be done, rather than what is to be achieved, can also be found in the Digital Economy Bill which is currently before the House of Lords. It keeps on mentioning “IP addresses” being required, with no mention of source port numbers.

But perhaps that particular problem will turn out OK? Apple will not let anyone with an iPhone download music without permission!

Having talked in detail about this with one of the UK’s major mobile phone companies, I can now further describe some practical issues (Caveat: other companies may differ in how they’ve implemented their details, but all of them are doing something very similar).

The good news, first, is that things are not as bad as they might be!

By design, NAT systems provide a constant mapping to a single IP address for any given user (at least until they next disconnect). This means that, for example, a website that is tracking visitors by IP address will not serve the wrong content; and their log analysis program will see constant IP addresses when the user changes page or fetches an image, so that audience measurements will remain valid. From a security point of view, it means that provided you have at least one logging record with IP address + port number + timestamp, then you will have sufficient data to be able to seek to make an identification.

As a quick aside, you may be thinking that you could do an “inference attack” to identify someone without using a source port number. Suppose that you can link several bad events together over a period of time, but only have the IP address of each. Despite the telco having several hundred people using each IP address at each relevant instant, only one user might be implicated on every occasion. Viewers of the wire will recall a similar scheme being used to identify Stringer Bell’s second SIM card number!

Although this inference approach would work fine in theory, the telco I spoke with does not keep its records in a suitable form for this to be at all efficient. So, even supposing that one could draft the appropriate legal request (a s22 notice, as prescribed by the UK’s Regulation of Investigatory Powers Act), the cost of doing the searches and collating the results (and those costs are borne by the investigators), would be prohibitive.

But now it’s time for the bad news.

Traditional ISP IP address usage records (in RADIUS or similar systems) have both a “start” and “stop” record. The consistency of these records within the logging system gives considerable assurance that the data is valid and complete. The NAT logging only records an event when the source port starts to be used — so if records go missing (and classical syslog systems can lose records when network errors occur), then there is no consistency check to show that the wrong account has been identified.

The logging records that show which customer was using which IP address (and source port) are extremely large — dozens of records can be generated by viewing just one web page. They also provide sensitive information about customer habits, and so if they are retained at all, it will only be for a short period of time. This means that if you want traceability then you need to get a move on. ISPs typically keep logs of IP address usage for a few weeks. At the mobile companies (because of the volume) you will in practice have to consult the records within just a few days.

Furthermore, even when the company intends to hold the data for a short period, it turns out that under heavy load the NAT equipment struggles to do what it’s supposed to be doing, leave alone generate gigabytes of logging. So the logging is often turned off for long periods for service protection reasons.

Clearly there’s a reputational risk to not having any records at all. For an example which does not have anything to do with policing: not being able to track down the sources of email spam would demean the mobile company in the eyes of other ISPs (which in practice will be seen by ever more aggressive filtering of all of their email). However, that risk is rather long-term; keeping the system running “now” is rather more important; and there is a lot that a mobile company can do to block and detect spam within their own networks — they don’t need to rely on being able to process external abuse reports.

In the third and final article of this little series I will consider the question of “data retention”. Surely the mobile phone company has a legal duty to keep traceability records? It turns out that the regulators screwed it up — and they don’t!