This happened last Friday. When I went to go look for the link for this post, I find this on cnn.com.

This is totally reasonable. Put that thing that might kill people _today_ over there on the right, but let's definitely highlight the fact that we haven't heard from the power couple on the left. Good plan.

Everybody on infosec twitter is going back and forth about patchability of the systems in hospitals that got infected. I only have second-hand knowledge of this difficulty, but at some point, this seems like it's a deeper version of left-pad.

Seems like a stretch, right? left-pad was a "Know Your Dependencies" problem. Huge .js packages were turtled all the way down to this lowly 11 lines of code.

The problem was that nobody knew all their dependencies and this one just went poof.

Fundamentally, basing your half-million dollar MRI machine or your patient record system on Windows is the same thing. You can't, as a developer, know what lies beneath until someone shows you. Unfortunately, someone hooked crypto-locker malware up to The Shadow Broker's exploit of MS17-010 and showed the world.

Basing your critical life safety machines on third party software you aren't even being put in a position to understand is risky. Further, telling your customers they get to pay money to get patches for that dependency tested and validated causes those customers to not patch. Worse, these things are sold with (then current) older versions of Windows that aren't supported any more. If patching is hard, upgrading is harder.

Do you want remotely exploitable machines? Because this is how you get REMs.

I truly don't want this to be a FLOSS/closed source battle, and obviously requiring changes to these systems now isn't helpful, but can we all please stop putting infrastructure on things nobody outside of one company can audit? Can we please stop taking that shortcut because it's at hand? If not, keep your software up to date, and validate that it works with patches and new releases proactively, within some reasonable time frame.

"But nobody can afford to do that."

Bull. We're paying for it now. This technical debt has just been deferred until someone else deemed it due. It's debt that nobody made accounting aware of on either side of the customer/vendor relationship. Restoring these systems does nothing to "fix" the problem either. Networks will be partitioned, firewalls and air gaps put into place, but the OS isn't going to get patched.

Hold these vendors accountable for their effectively unpatchable systems. Come up with wage reports for those working this incident to show the cost. Go to the C-suite with these reports in hand even if they're not asked for. If your C levels think they're going to keep an MRI/CAT/etc machine for 5+ years, figure out how you're going to keep the machines that run it patched for that long. Get your vendor's help. If they won't, find someone else. Get their code in escrow in case they go bankrupt. Manage the risk. To do otherwise is terribly short sighted.

Sunday, Microsoft came out with patches for MS17-010 for Windows back to XP. Way to go MS! Unfortunately, this will give people the idea that they can continue to use these old operating systems. Hopefully it'll mitigate any version two breakouts.

I found out from a fellow Techlahoman on the slack that those connectors in my last post are JST-SSH. Luckily, Digikey carries both genders of these connectors. They also carry some SSH jumpers that can be hacked up for our purposes. I ended up soldering a 6 pin header onto the board to match the other JST connectors.

I also prepped a few sets of cables with JST "connector housings" on one end and male header pins on the other end.

In other news, in doing some digging, it appears as though the Cypress CY7C68013 on this board is connected A0-A15 to the flash chip, which has 8 times the address space of the 8051 in the 68013. To that end, they have some GPIO stuck to the highest three bits of the flash.

The EA pin of the 68013 is also tied strongly to ground, which means it's using the internal 16KB of RAM is being used for code and data. I also found that the I2C bus was connected to a 64KB SOIC flash chip. I hot-aired that off the board and wired it up to some ribbon cable with a 10pin IDC connector on it that fits directly into my BusPirate 3.6.

Dumping the chip seems to give me 4 copies of the same 16KB of data. I'm not sure if they've programmed it 4 times or if I have the part number wrong and it's only a 16KB flash chip. In either case, I'll be trying to determine what the code is doing.

In the spirit of other RE people, I've heard that you should always have three of the thing you're tearing apart. One to break, one to RE and one to have a known good to test against.

I also just wanted a few more devices to connect to the KX2-416 eventually anyway, so I'd ordered a couple more D2CIM-DVUSB's. I popped them open and...

Now, these two connectors look exactly like the connector they're using on the end of the board and here's the plug for that.

So now, I just need to figure out what kind of connector this is.

I got a KX2-416 from a popular auction site on the internet a few days ago plus a cheap (seemingly unused to boot) D2CIM-DVUSB from another seller. The DVUSB arrived well before the 416 and I got curious, so I opened it up to see what makes it tick.

After poking at it a bit, I found a few potentially useful doors into the chips and some circuit paths that look interesting.

The chip on the left is a TI CD4053B (triple 2-channel multiplexer) and the one on the right is a Microchip 24LCS22A (2K VESA E_EDID Serial EEPROM).

So, it appears as though something wants to switch the EDID EEPROM between a couple of things.

I traced a couple of connections through to the VGA connector.

It also appears as though the JTAG pins are brought out to unpopulated headers for both the AT90USB646 and the Altera EP2C5.

I'm waiting on some headers from the next state over to attach with some wirewrap wire to those ports.

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.

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.

Response:

Thank you for your query.

There is a slight difference between ISO and EMV tag coding. According to the EMV Book3 requirement, bit7 ~ bit1 of the first byte would not be part of tag number when these bits equals '11111', the tag number begins at the second byte in this case.

As the example tag "9F02", is an valid EMV tag, but not an ISO tag. This also means that you might consider the AIP and Amount, Authorised (numeric) to both have tag number 02; it is not helpful to refer to manage tags in this way, and hence EMV uses the full tag throughout.

Sincerely,

The EMVCo Secretariat

Message ID: 1007

For starters, bit7 ~ bit1? I'd say it's grown a bit, but it's grown two. Perhaps they're confused and referring to the second byte. Who knows.

My response to them (Comment ID 12106):

If there is a slight difference, then that difference should be documented instead of the ISO-8825 spec quoted directly by Annex B1. Repeatedly calling your data transport method BER-TLV, quoting ISO-8825 and mis-implementing ISO-7816 (which clarifies the above better than 8825 and is quite specific to ICCs) when both ISO standards are referred to as 'Normative References' is confusing to implementation teams and is blatantly false.

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

This is an exact quote (barring the inability to reproduce the greater than or equal to) of your spec. "When tag numbers >= 31 are used". That means that 9F02 should have a tag number >= 31. It does not. If you want to go the route that '9F02' is >= 31, then ALL EMV tags are >= 31.

I understand the desire to stick to ones guns about something that affects billions of devices in the field, but this is not assisting anyone trying to implement your broken specification.

Sincerely,

Mike Mattice

I very surprised I got a response at all, but not surprised they continue to misunderstand what they, themselves, have published. They have an internalized idea of what it should communicate, but that doesn't match what's on the paper. Having had to work with other vendors and their broken specs before, I'm not sure why it still surprises me when this happens.

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.

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.

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:

1. bits 8 and 7 shall be encoded to represent the class of the tag as specified in Table 1;
2. bit 6 shall be a zero or a one according to the rules of 8.1.2.5;
3. 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:

1. bits 8 and 7 shall be encoded to represent the class of the tag as listed in Table 1;
2. bit 6 shall be a zero or a one according to the rules of 8.1.2.5;
3. 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.