Deep in the weeds (Posts about ASN.1)

EMV should be less confusing for all

Mike Mattice — Wed, 22 Jun 2016 16:38:30 GMT

Excuse me for a moment while I do a happy dance for effecting change. It's a small victory, but...

Mr. Mattice,

Thank you for your comment. We acknowledge that the EMVCo tag definition is not fully ISO compliant. For clarification We will remove the reference to ISO 8825 in the next version of the specifications.

Sincerely, The EMVCo Secretariat (on behalf of L2WG)

I'm glad they've admitted to this. I hope it makes someone else's job easier someday.

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.

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.