Deep in the weeds (Posts about Commentary)

EMVCo's response

Mike Mattice — Mon, 02 May 2016 15:13:33 GMT

A little more than a month later, I got a response from EMVCo to my request. It's about what I expected. I'm not sure they've read their own specification.

Quick Chip EMV

Mike Mattice — Wed, 20 Apr 2016 02:35:51 GMT

So Google Now cards notified me about Visa's "new" Quick Chip EMV spec today. Apparently I've been profiled as someone interested in EMV. Go figure.

From the Quick Chip EMV Specification:

Note: Using Quick Chip, the insertion, reading, and subsequent removal of the card may occur while the sales transaction is being rung up; i.e., before the final amount is known.

That's super cool! It works much closer to the way a normal mag-stripe transaction would work in our stores. Our customer service people do their thing while the customer does theirs in preparation for the end of the transaction and then the request happens as soon as the CS person is done and the customer verifies the amount. This is much better than waiting for a response from the bank before you can pull your card.

Reading the specification, it seems that the terminal's EMV kernel tells the card "Yep, I can't go online, go ahead and give me stuff for a deferred authentication". This will only work if the terminal is doing "Online" verification, which I'd guess most, if not all US retailers are doing with magstripe auths.

I started to wonder why Visa didn't come up with this years ago for everyone else that does EMV in the world. After reading the spec, it dawned on me. This spec only works for ONLINE transactions. The rest of the world used a lot of offline authentications because they've historically had to pay for individual phone calls and those communications were less reliable than the always online terminals the US has used for so many years.

One of the things that I find interesting is that Visa didn't bother fixing this problem 10 years ago for the UK. Apparently the US consumer can't have anything get in the way of charging up their credit cards.

If we're back to a unidirectional communication from card to issuer, why wouldn't private keys loaded into something like Only Coin work? With some detection built in, it could rotate its magstripe every time it was swiped to the next rolling code, just like NFC based credit cards have done for a few years now. The cards would be more expensive, but maybe not extremely so at scale, and we could all go back to "normal" swipes. Just a thought.

EMVCo Request

Mike Mattice — Thu, 14 Apr 2016 04:01:08 GMT

I sent the following to EMVCo via https://www.emvco.com/PublicComments.aspx on March 28th at about 0200UTC.

Table 35 & 36 refer to ISO/IEC 8825 which is also ITU-T Rec. X.690. The X.690 spec available at https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf

Specifically, the document states "According to ISO/IEC 8825, Table 36 defines the coding rules of the subsequent bytes of a BER-TLV tag when tag numbers ≥ 31 are used (that is, bits b5 - b1 of the first byte equal '11111')."

Please explain how 9F02 follows this? The tag number for 9F02 is 2, which is clearly < 31.

IEC/ISO 8255 states:

8.1.2.2 For tags with a number ranging from zero to 30 (inclusive), the identifier octets shall comprise a single octet encoded as follows: a) bits 8 and 7 shall be encoded to represent the class of the tag as specified in Table 1; b) bit 6 shall be a zero or a one according to the rules of 8.1.2.5; c) bits 5 to 1 shall encode the number of the tag as a binary integer with bit 5 as the most significant bit.

That essentially tells me that every EMV tag that's two bytes with the second byte less than 31 is invalid and not capable of being encoded by BER.

I look forward to your response.

I figure two weeks is plenty of time for them to respond to this simple inquiry. Unfortunately, I got the only the following in response:

*****Please do not reply to this email*****

Dear Mike Mattice,

Thank you for submitting your comment to EMVCo. EMVCo has received your comment and will review and respond as deemed necessary.

Please note that EMVCo does not guarantee a response to public comments. EMVCo has implemented a new subscriber program through its website in order to facilitate dialog and interaction between EMVCo and its subscriber community. For more details, please find the service description in the EMVCo website "Contact Us" section.

For your reference, a copy of your comment is included below.

Thank you.

The EMVCo Communication Secretariat Message ID:1001

-------------------

Comment ID: 12005

-------------------

Perhaps I should start a gofundme to become an EMVCo subscriber so I can get a guaranteed answer.

In other news I sent this to customerservice@iso.org:

Are there repercussions for claiming to follow ISO standards (like 8825) but not actually doing so?

Thanks, Mike

A couple days later I got:

ISO standards are voluntary, and as such, ISO does not carry out any assessment of conformity, nor does it monitor the implementation of its standards.

A number of ISO standards - mainly those concerned with health, safety or the environment - have been adopted in some countries as part of their regulatory framework, or are referred to in legislation for which they serve as the technical basis. However, such adoptions are decisions by the regulatory authorities or governments of the countries concerned. ISO itself does not regulate or legislate.

Cordially,

joseph martinez

Information Expert | marketing and sales services | marketing, communication & information | iso central secretariat | phone: +41 22 749 03 17

So, no repercussions for saying you follow ISO-8825, but not actually doing so.

ASN.1 and EMV

Mike Mattice — Sun, 27 Mar 2016 23:41:16 GMT

I've been tasked with making EMV work for the company I work for and more importantly, for our customers. As I write python most of the time these days, I looked around for a tool to play with ASN.1. A stupidly quick Google landed me on pyasn1. I made a run at using it to manipulate the BER-TLV the EMV 4.3 Book 3 requires. This resulted in some difficulties. I reported a bug via the mailing list.

Thinks have changed in the past two months.

pyasn1 moved to github. I'd built some work arounds and submitted a PR. I ended up splitting the PR into another because that one could break extended tags everywhere. The issues I saw with the EMV tags and how they decoded are in that first PR, and also in emv-asn1, which I wrote with my assumptions I'd codified in bugfix/emv.

I did these things because I was sure EMVCo would surely stick to standards and that they had interpreted the ASN.1 spec correctly. I now know I was wrong.

I've built, and am using, an internal version of pyasn1 and that allows me to encode/decode this EMV stuff 'properly'. I've even made a decoder/encoder pair for our pinpad's odd text based format with these assumptions.

Now, however, I want to burn it all to the ground.

Today I found grizzly_ber, which is the same workaround in Ruby. I realized it wasn't just me that was having trouble with this.

From ASN.1:

8.1.2.2 For tags with a number ranging from zero to 30 (inclusive), the identifier octets shall comprise a single octet encoded as follows:

bits 8 and 7 shall be encoded to represent the class of the tag as specified in Table 1;

bit 6 shall be a zero or a one according to the rules of 8.1.2.5;

bits 5 to 1 shall encode the number of the tag as a binary integer with bit 5 as the most significant bit.

8.1.2.4 For tags with a number greater than or equal to 31, the identifier shall comprise a leading octet followed by one or more subsequent octets.

8.1.2.4.1 The leading octet shall be encoded as follows:

bits 8 and 7 shall be encoded to represent the class of the tag as listed in Table 1;

bit 6 shall be a zero or a one according to the rules of 8.1.2.5;

bits 5 to 1 shall be encoded as 11111.

82 and 9F02 are an example of how EMVCo failed. 9F02 decodes to (80 + 1F) with a tag number of (02); 82 decodes to (80) tagno (02). That 1F is only supposed to be there For tags with a number greater than or equal to 31. The EMV standard even refers to the ASN.1 spec correctly in Book 3 Annex B1.

Table 36 defines the coding rules of the subsequent bytes of a BER-TLV tag when tag numbers ≥ 31 are used (that is, bits b5 - b1 of the first byte equal '11111').

The EMV standard claims to use BER-TLV encoding. It does not. How can we fix this? Is it fixable? What's the right approach?

I personally like to do things "The Right Way". Doing so would require billions of cards to be replaced and many instances of software to be updated. I just don't see that happening any time soon.

I've asked EMVCo how 9F** tags (and the rest of the extended tags) follow the standard they claim to follow. I'm not guaranteed a response without subscribing for $2500. We'll see if I get a response.