1
00:00:03,370 --> 00:00:08,650
I'm sure many of you have chip cards in your pocket which you use for credit and debit card transactions.

2
00:00:08,810 --> 00:00:16,590
These use the EMV standard for communication between the card and the terminal while performing one of these transactions.

3
00:00:17,150 --> 00:00:38,270
EMV is named after the original creators of the standard, Europay, Mastercard and Visa, but since then maintenance of the standard has been taken over by EMVco, who also manage closely related specifications on contactless payments and some other payment standards like the 3D Secure online payment standard.

4
00:00:38,870 --> 00:00:42,630
I've been looking into EMV for about 15 years now.

5
00:00:42,630 --> 00:00:52,170
I've found a variety of vulnerabilities both in the standard and in the implementations, but in this talk I'm not going to be covering these vulnerabilities.

6
00:00:52,170 --> 00:00:55,290
If you're interested I've got other talks and papers about these.

7
00:00:55,370 --> 00:01:01,050
Instead in this talk I'll be looking at some of the low-level details about how EMV works.

8
00:01:01,050 --> 00:01:10,650
I hope this might trigger your interest in looking into EMV in more detail yourself and also perhaps will be useful as part of your work.

9
00:01:10,830 --> 00:01:20,890
Given the billions of pounds and dollars that flow through EMV transactions you'd think that EMV was designed to be a security specification, but it's not really.

10
00:01:20,930 --> 00:01:25,330
Primarily EMV is designed to be a compatibility specification.

11
00:01:25,390 --> 00:01:41,070
It's there to allow cars and terminals to communicate regardless of how old or new the equipment is, regardless of where in the world these are and regardless of the banks that have been used to set up the terminal and the cards.

12
00:01:41,650 --> 00:01:47,570
This is because when people perform EMV transactions they want to buy something.

13
00:01:47,610 --> 00:01:56,730
They are not primarily interested in security and if something went wrong they would rather the transaction went through than not.

14
00:01:56,770 --> 00:02:03,970
And so most of the EMV specification is about ensuring compatibility while also managing the constraints.

15
00:02:03,970 --> 00:02:13,710
For example, cards are very limited in the amount of RAM they have and the amount of processing they have and this has a lot of impact in how the specification is designed.

16
00:02:14,210 --> 00:02:22,530
Another consequence of this desire for compatibility is that cards and terminals try to follow Pestale's law.

17
00:02:22,530 --> 00:02:28,550
So they are conservative in what they generate but liberal in what they expect.

18
00:02:28,570 --> 00:02:40,370
The idea is that if there are some changes to the way that cards and terminals work they'll continue to operate because they will not just reject a transaction because something is unexpected.

19
00:02:40,790 --> 00:02:48,010
This is very desirable for compatibility but has the consequence of creating security risks.

20
00:02:48,010 --> 00:02:59,430
Firstly, if there is data which is not possible to interpret devices will ignore it but maybe that is very security relevant information that they're ignoring.

21
00:02:59,430 --> 00:03:09,830
And secondly, having this backwards and forwards compatibility creates more complexity and from complexity we can get security problems.

22
00:03:09,830 --> 00:03:18,330
One way the EMV standard tries to support compatibility is the TLV standard for encoding data.

23
00:03:18,810 --> 00:03:25,650
In this standard data is encoded as a tag followed by a length followed by a value.

24
00:03:25,650 --> 00:03:32,650
This is a very efficient way of representing hierarchical data structures.

25
00:03:32,790 --> 00:03:37,890
If this was a more modern standard you might see things like JSON or XML.

26
00:03:37,890 --> 00:03:44,450
In the case of JSON and XML they take up a lot of extra space to encode data.

27
00:03:44,610 --> 00:03:48,570
In contrast TLV is much much more efficient.

28
00:03:48,610 --> 00:04:03,510
The downside of TLV is that while with JSON or XML you can look at data and more or less work out what's going on, in the case of TLV data you have to look quite carefully before you can work out what this actually means.

29
00:04:03,930 --> 00:04:15,230
TLV data helps compatibility because it's possible to decode without the decoder understanding all the semantics of the data that's encoded inside.

30
00:04:15,230 --> 00:04:25,670
A decoder can still produce this tree and identify data items that it knows about but it can ignore data items that it doesn't know about.

31
00:04:25,670 --> 00:04:37,370
It also has some other features like allowing data items to be deleted just by filling with zeros rather than having to rewrite the whole string of bytes.

32
00:04:37,370 --> 00:04:44,630
This is convenient for older memory technologies that allowed erasure but not moving around the data.

33
00:04:46,110 --> 00:04:51,250
The TLV standard is also known as ASN1 BER.

34
00:04:51,250 --> 00:05:01,770
So this is from the X208 standard and it's the standard that is also used as the encoding format for HTTPS certificates.

35
00:05:01,770 --> 00:05:08,050
There's been plenty of security vulnerabilities as a result in the HTTPS standards.

36
00:05:08,070 --> 00:05:14,330
In this talk I'm going to show how you can manually decode TLV data.

37
00:05:14,330 --> 00:05:16,450
Now of course there's decoders out there.

38
00:05:16,450 --> 00:05:20,830
I've written some and I'll talk about those at the end of the talk.

39
00:05:20,830 --> 00:05:26,650
But there's sometimes cases where it's helpful to be able to decode these things manually.

40
00:05:26,950 --> 00:05:31,610
So maybe the data you've got is incomplete or corrupt but you still need to make sense of it.

41
00:05:31,930 --> 00:05:37,210
Maybe you have to explain exactly why a particular decoding is the right one.

42
00:05:37,430 --> 00:05:48,830
One of the things I do from time to time is expert witness in a court case and there you not only have to give the answer but also explain the rationale of why you're making the recommendation that you are making.

43
00:05:50,110 --> 00:05:53,610
You might have to write your own decoder although I wouldn't recommend it.

44
00:05:53,610 --> 00:05:55,530
There's lots of places you can go wrong.

45
00:05:56,070 --> 00:06:06,270
And also sometimes doing things yourself shows you where other people might have slipped up and help you identify where else security vulnerabilities might be.

46
00:06:06,950 --> 00:06:19,890
So in this talk I'm going to show these decoding processes and if you want to follow along then these links here will take you to the Jupyter notebook which I've used for doing the decoding.

47
00:06:19,910 --> 00:06:28,210
A document with my notes to show some of the resources that are necessary to understand TLV data in EMV.

48
00:06:28,210 --> 00:06:37,890
And there's also the repository which contains the Python notebook and the source code for the utilities that I've been using.

49
00:06:40,680 --> 00:06:45,160
In this talk I'll be decoding some TLV data structures.

50
00:06:45,160 --> 00:06:48,520
These are represented in hexadecimal.

51
00:06:48,840 --> 00:06:59,620
So to help us decode these I've written some simple Python functions that allow us to manipulate these strings of hexadecimal characters.

52
00:06:59,700 --> 00:07:02,380
These are part of the hexutils package.

53
00:07:02,380 --> 00:07:09,080
You can download it from the repository that I linked to earlier and you can also use this within the Jupyter notebook.

54
00:07:09,980 --> 00:07:20,260
The first function takes a byte represented as a pair of characters, hexadecimal characters, and then converts it to binary.

55
00:07:20,260 --> 00:07:26,700
It always converts it to to eight bits so it'll handle adding reading zeros if necessary.

56
00:07:28,920 --> 00:07:36,500
Sometimes these strings will have spaces around it that's very nice for formatting but can complicate decoding.

57
00:07:36,500 --> 00:07:44,020
So the function stripBytes removes any whitespace before, after, and within the hexadecimal string.

58
00:07:46,750 --> 00:07:50,430
This one adds whitespace back in to make it easier to look at.

59
00:07:50,430 --> 00:07:56,850
It splits the hex string into bytes and then adds a space between each byte.

60
00:07:59,460 --> 00:08:02,580
Sometimes we want to count how long a hex string is.

61
00:08:02,580 --> 00:08:08,200
So this counts how many bytes are in a hex string, removing any whitespace beforehand.

62
00:08:10,970 --> 00:08:15,290
Sometimes the hex bytes include text.

63
00:08:15,290 --> 00:08:18,170
Typically this would be encoded using ASCII.

64
00:08:18,170 --> 00:08:32,450
So this function decodes a hex string into the equivalent string using ISO 8859-1 which is a superset of ASCII.

65
00:08:35,790 --> 00:08:38,810
Now into some slightly more interesting functions.

66
00:08:39,030 --> 00:08:46,410
Quite often we all need to look at the individual bits and at what position bits are set to 1 or 0.

67
00:08:46,410 --> 00:08:57,570
So this function takes in a byte and in the hexadecimal and then shows you which bits are set to 1 and which bits are set to 0.

68
00:08:59,940 --> 00:09:04,240
Sometimes there actually might be multiple fields within a single byte.

69
00:09:04,240 --> 00:09:17,600
So this function takes a specification of how long each field is, converts the hex into binary, and then shows each of these binary digits according to which field it belongs to.

70
00:09:21,650 --> 00:09:26,890
I'm going to be taking sections out of hex strings.

71
00:09:26,890 --> 00:09:29,550
So the take function does this.

72
00:09:29,770 --> 00:09:33,610
In the first format it just takes a certain number of bytes.

73
00:09:33,610 --> 00:09:39,350
So in this case you have a hex string and then you ask for two bytes and it gives you these two bytes.

74
00:09:40,590 --> 00:09:45,330
And in the second form it takes two bytes but also takes an offset.

75
00:09:45,330 --> 00:09:48,590
So here I'm starting offset 1 counting from zero.

76
00:09:48,590 --> 00:09:52,790
That means I'm skipping the first byte and then taking the next two bytes.

77
00:09:56,980 --> 00:10:06,520
In this talk I'm going to show how to decode some real EMV data and I took some data off my own credit card.

78
00:10:06,520 --> 00:10:11,880
Now don't get too excited, the card's long since expired so you won't be seeing any sensitive information.

79
00:10:12,080 --> 00:10:14,560
But this is a real card.

80
00:10:14,920 --> 00:10:18,440
To actually extract this data I used a tool called CardPeek.

81
00:10:18,680 --> 00:10:20,400
This is really handy.

82
00:10:20,400 --> 00:10:23,260
It can deal with many different types of smart cards.

83
00:10:23,260 --> 00:10:27,180
It can do TLV decoding and other types of decoding by itself.

84
00:10:27,180 --> 00:10:31,300
But the whole point of this talk is to show you how to do this yourself.

85
00:10:31,300 --> 00:10:36,880
So rather than looking at the final output of CardPeek I'm going to look at the log file from this.

86
00:10:37,880 --> 00:10:44,600
One of the stages of getting data off a card is to use the read record command.

87
00:10:44,600 --> 00:10:48,280
To see how this works let's look at the EMV specification.

88
00:10:48,500 --> 00:10:55,600
Rather than giving the whole spec I've taken some selected parts and these are available in the notes.

89
00:11:00,740 --> 00:11:05,920
So here is the specification for the read record command.

90
00:11:06,320 --> 00:11:10,760
EMV commands take two different bytes to specify the command.

91
00:11:10,760 --> 00:11:13,060
There's the class and the instruction.

92
00:11:13,060 --> 00:11:17,680
So for read record class is 00, instruction is B2.

93
00:11:17,780 --> 00:11:22,100
And then it takes two parameters P1 and P2.

94
00:11:22,160 --> 00:11:25,960
These parameters depend on the actual command.

95
00:11:25,960 --> 00:11:35,260
So if we look up the specification for read record we'll see that P1 is the record number we're going to read, and then P2 is a reference control parameter.

96
00:11:35,260 --> 00:11:37,440
And I'll talk about that a bit later.

97
00:11:38,880 --> 00:11:43,360
We need to specify how long the record is.

98
00:11:43,360 --> 00:11:48,740
We need to specify the length expected, but initially we don't know what this is.

99
00:11:48,740 --> 00:11:57,040
So the way to deal with this is you initially specify 0 as the length and then the card will return an error message.

100
00:11:57,040 --> 00:12:02,760
So 6c is an error message and tell you how long the response is actually.

101
00:12:02,760 --> 00:12:10,440
And then you call the same command again now specifying the correct length and it will return 9000 which means everything is okay.

102
00:12:10,440 --> 00:12:15,260
And then the 97 in hexadecimal bytes that you've requested.

103
00:12:17,360 --> 00:12:20,740
So I mentioned that there's a reference control parameter.

104
00:12:20,740 --> 00:12:29,680
This is our first example of one of these fields where you are taking a single byte and splitting up.

105
00:12:29,680 --> 00:12:35,380
So here is the table that shows how one of these bytes is formatted.

106
00:12:35,480 --> 00:12:41,900
The first five bits is the SFI, the short file identifier.

107
00:12:41,900 --> 00:12:53,140
We found out the short file identifier earlier on when we activated the payment application on this card and we found out that the relevant records are in SFI 2.

108
00:12:53,680 --> 00:13:04,580
So the first five bits get set to 2 and then the last three bits get set to 100 to indicate that P1 is a record number.

109
00:13:04,580 --> 00:13:21,380
So we can show how this works by calling the formatBytes function with a field settings of 5 followed by 3 and we see indeed yes the first field is set to 2 and the second field is set to 100.

110
00:13:23,340 --> 00:13:31,980
So I mentioned that this is a 97 byte long string that's in hexadecimal.

111
00:13:31,980 --> 00:13:34,960
If we convert that to decimal we get 151.

112
00:13:34,960 --> 00:13:39,780
So the response for record number 2 is 151 bytes.

113
00:13:42,840 --> 00:13:49,420
We're going to now try decoding this and the first step is by putting this into a Python variable.

114
00:13:49,420 --> 00:13:54,660
I'm going to call this response and we'll see this used quite a lot in the rest of the talk.

115
00:13:57,180 --> 00:14:02,040
So let's look at the first byte of this response.

116
00:14:02,640 --> 00:14:07,280
We know that this is a TLV string.

117
00:14:07,280 --> 00:14:11,340
First byte of a TLV string is the tag.

118
00:14:11,340 --> 00:14:13,700
So let's look at what that actually is.

119
00:14:13,700 --> 00:14:16,820
And if we look at that we will see that it is 70.

120
00:14:16,820 --> 00:14:22,540
So now let's go and try to decode this tag 70.

121
00:14:24,760 --> 00:14:27,380
Tags can be multiple bytes long.

122
00:14:27,480 --> 00:14:33,980
So here is the table for decoding the first byte of a tag.

123
00:14:35,380 --> 00:14:39,220
We can see that there are three different fields.

124
00:14:39,220 --> 00:14:44,580
One that's two bits long, one that's one bit long and then the rest is five bits long.

125
00:14:46,880 --> 00:15:02,580
If we now decode this hex 70 following the field specification we see that the first field is 01 and that corresponds to application class.

126
00:15:02,660 --> 00:15:14,220
Tags can be universal which means that every application that handles ESN1 should be able to understand it and it's not one of those.

127
00:15:14,220 --> 00:15:27,980
There's application where it is specific to a particular application so it could be smart card for example but it has the same meaning regardless of where it's used.

128
00:15:27,980 --> 00:15:39,540
It can be context specific which means that the meaning actually depends where this tag is present or it can be private in which case the specification doesn't deal with it.

129
00:15:39,540 --> 00:15:44,700
It's up to the producer of the card to define how this actually has meaning.

130
00:15:45,400 --> 00:15:51,860
Anyway this is 01 which is application class which means it's specific to to smart cards.

131
00:15:52,540 --> 00:15:57,560
Now we need to find out what is the contents of this tag.

132
00:15:57,560 --> 00:16:01,350
This could be either primitive or it could be constructed.

133
00:16:01,940 --> 00:16:12,960
Primitive means that no further decoding is handled as part of TLV and constructed means that the contents is a series of TLV data items.

134
00:16:12,980 --> 00:16:23,320
Here we can see this field is set to one which means that is a constructed data object that means that the contents are going to be more TLV data items.

135
00:16:24,720 --> 00:16:31,080
And then the last five bits is just a number that encodes which particular tag that is.

136
00:16:31,140 --> 00:16:34,600
This is 1 0 0 0 0.

137
00:16:34,860 --> 00:16:40,020
As long as this is not all ones this is a one byte tag.

138
00:16:40,020 --> 00:16:49,380
So what we know is that tag 70 is a one byte tag containing TLV data items.

139
00:16:49,480 --> 00:16:59,880
And if we look this up in the UV specification we'd find out this is a read record response message template which is what we'd expect because we just called read record.

140
00:17:02,730 --> 00:17:06,370
Okay so now continuing on we've got the tag.

141
00:17:06,370 --> 00:17:07,250
Tag is 70.

142
00:17:07,250 --> 00:17:10,070
The next bytes are going to be the length.

143
00:17:10,190 --> 00:17:16,430
So let's look at the length and this is hex 81.

144
00:17:16,810 --> 00:17:19,470
You actually have to decode the length to find out what it means.

145
00:17:19,470 --> 00:17:23,050
So let's look at the table for decoding length.

146
00:17:24,750 --> 00:17:31,490
And what this says is that if bit 8 is not set then this is the length.

147
00:17:31,490 --> 00:17:40,410
But if bit 8 is set then this specifies the length of the length and that is going to follow.

148
00:17:40,410 --> 00:17:53,090
So here we can see that bit 8 is set and the rest of it is 1 which means that there's going to be an additional one byte that contains the actual length of this data item.

149
00:17:55,620 --> 00:18:05,740
So let's look at the next byte and this is hex 94 and that is the actual length of the contents of this response.

150
00:18:05,940 --> 00:18:10,960
Converting that into decibel is 148 bytes.

151
00:18:10,960 --> 00:18:21,280
So within tag 70 there are 148 bytes of further data and these are in the TLV format.

152
00:18:24,760 --> 00:18:27,460
Let's actually check whether this makes sense.

153
00:18:27,620 --> 00:18:31,220
So let's take these 148 bytes.

154
00:18:31,220 --> 00:18:38,460
We get to this by skipping the one byte tag and then the two bytes used for the length.

155
00:18:39,900 --> 00:18:49,500
And if we check the size of the whole response and take off those three bytes that we skipped over then indeed there's 148 bytes there.

156
00:18:49,500 --> 00:18:56,020
So this tag 70 contains everything that is part of the read record response.

157
00:19:00,860 --> 00:19:10,920
We know that this is a constructed tag so the contents are going to be a TLV item or one or more TLV items.

158
00:19:10,920 --> 00:19:13,260
So let's look at the first part of that.

159
00:19:13,260 --> 00:19:20,960
So the first byte is 8c and to find out what that actually means as a tag we need to decode it.

160
00:19:20,960 --> 00:19:23,920
So let's follow the same decoding pattern.

161
00:19:28,010 --> 00:19:36,230
So we see the first field is context specific so the meaning of this depends where it's actually found.

162
00:19:36,230 --> 00:19:41,370
This is as part of an EMV application so we have to use the EMV specification.

163
00:19:42,170 --> 00:19:53,190
The next bit is that it is a primitive data object so the ASM1 specification doesn't say anything more about how to decode that.

164
00:19:53,190 --> 00:19:54,330
We need to look elsewhere.

165
00:19:54,790 --> 00:20:08,170
And then the rest of it is not all ones so this is a one byte tag and the bits that are in this final field show us which of the tags it is.

166
00:20:08,550 --> 00:20:14,870
So to find the meaning of this we're going to need to look again into the EMV specification.

167
00:20:14,870 --> 00:20:22,730
It has something called a tag dictionary where you can see a list of tags and their meaning and their format.

168
00:20:22,970 --> 00:20:32,450
So this is 8c and then we can see that 8c is the CardRiskManagementDataObjectList1.

169
00:20:32,490 --> 00:20:35,230
I'll go into what data object lists are.

170
00:20:35,230 --> 00:20:39,490
That's important data format within EMV.

171
00:20:42,330 --> 00:20:49,070
But let's look at the contents next and to do that we need to see the length.

172
00:20:49,070 --> 00:20:52,870
The length is 21 in hex.

173
00:20:52,870 --> 00:20:56,410
Now is this a one byte length or a multi-byte length?

174
00:20:56,410 --> 00:20:58,110
We need to decode it.

175
00:20:58,250 --> 00:21:02,770
Bit 8 is zero which means that this is a one byte length.

176
00:21:02,770 --> 00:21:12,990
So the size of this cdol1 record is 21 in hex bytes and then if we decode that we get 33.

177
00:21:12,990 --> 00:21:21,170
So there are going to be 33 bytes following tag 8c which is the cdol1.

178
00:21:24,010 --> 00:21:25,470
So let's get that.

179
00:21:25,610 --> 00:21:27,390
We've got to skip over a few things.

180
00:21:27,390 --> 00:21:39,070
We've got to skip over tag 70, the two byte length, skip over tag 8c and then one byte length and take 33 bytes and then this is what we actually get.

181
00:21:41,160 --> 00:21:52,480
So we'll save the cdol1 for later but now let's continue and see what is the next item within this response.

182
00:21:52,480 --> 00:22:04,240
So we're going to skip over everything we did before and also skip over the 33 bytes of data which is a cdol1 and then the next thing we get is another tag.

183
00:22:04,240 --> 00:22:14,320
So this is 8d and then this is a one byte tag which is the cdol2.

184
00:22:15,080 --> 00:22:17,420
Then we look at the length.

185
00:22:17,420 --> 00:22:25,580
This is zero c that's a one byte length and then actually now let's get the contents of this tag.

186
00:22:25,580 --> 00:22:36,080
So this is zero c bytes starting at the offset by skipping over everything before and then this is now the cdol2.

187
00:22:36,080 --> 00:22:41,440
So we've got both the cdol1 and cdol2 which followed it.

188
00:22:44,250 --> 00:22:49,510
So I mentioned that cdol1 is a doll object.

189
00:22:49,510 --> 00:22:52,970
Dolls are really quite important for EMV.

190
00:22:52,970 --> 00:22:59,130
They come about because EMV assumes that cards are very limited in what they can do.

191
00:22:59,130 --> 00:23:03,050
Maybe they cannot even decode TLV data themselves.

192
00:23:03,290 --> 00:23:09,310
The terminal on the other hand is more powerful so it can do a little bit more than the card.

193
00:23:09,310 --> 00:23:15,190
So when data is sent from the card to the terminal that's often in TLV format.

194
00:23:15,570 --> 00:23:27,970
But when data is sent from the terminal to the card generally TLV is not used because maybe the doesn't understand how to decode that sort of data item.

195
00:23:28,370 --> 00:23:31,130
Instead we use dolls.

196
00:23:31,130 --> 00:23:42,410
So a data object list is a set of tags and lengths and that tells the terminal how to format data that the card is going to receive.

197
00:23:42,650 --> 00:23:59,170
And then when the card receives this all it needs to do is jump to specific offsets within this set of data to know exactly what is the data item at that particular position without having to go through any more decoding steps.

198
00:23:59,690 --> 00:24:04,290
So one of these dolls consists of a list of tags and a list of lengths.

199
00:24:04,290 --> 00:24:18,770
And that tells the terminal when it's sending data to the card in this particular context all it should do is take this particular data item that the card requests, pad it to a particular size, and then send it to the card.

200
00:24:18,770 --> 00:24:29,550
And then keep on sending these data items of the particular length until all the tags covered in the doll have been sent over to the card.

201
00:24:30,150 --> 00:24:40,890
So the cdoll1 is used as the first step of the authorization process where the card is asked to produce an authorization request.

202
00:24:41,470 --> 00:24:47,130
If the card agrees to authorize that transaction it gets sent to the bank normally.

203
00:24:47,130 --> 00:24:56,210
And then the second stage of actually telling the card that the transaction has succeeded is what the cdoll2 is used for.

204
00:24:56,210 --> 00:25:02,190
The data items that are requested in each of these requests are a little bit different.

205
00:25:02,190 --> 00:25:05,710
That's why there's a cdoll1 and a separate cdoll2.

206
00:25:06,710 --> 00:25:10,370
So now let's go actually into this cdoll1.

207
00:25:10,370 --> 00:25:16,450
It's a list of tags so let's look at the first byte of the cdoll1 and we get 9f.

208
00:25:16,450 --> 00:25:23,850
To find out what this actually means we will need to look at the table for decoding the first bytes of tags.

209
00:25:23,930 --> 00:25:32,270
Here we are and now we can see that the first field is 1 0 so it's context specific.

210
00:25:32,270 --> 00:25:35,310
This is a emv tag.

211
00:25:35,790 --> 00:25:43,410
The next bit is that it is a primitive data object so it's not TLV itself.

212
00:25:43,530 --> 00:25:47,990
And then the rest of the bits are 1 1 1 1 1.

213
00:25:47,990 --> 00:25:53,050
If you haven't seen this before this means 9f is the beginning of a multi-byte tag.

214
00:25:53,050 --> 00:25:55,730
It's not a one byte tag like we've seen before.

215
00:25:57,110 --> 00:26:03,510
So to find out what else is going on in this tag we need to look at the next byte and we get this as 0 2.

216
00:26:03,710 --> 00:26:07,870
To interpret this we need a different table so let's go on to the second table.

217
00:26:08,530 --> 00:26:17,630
This says that if the first bit is zero then that is the last byte of the tag.

218
00:26:17,630 --> 00:26:19,570
If it's one there's going to be more coming.

219
00:26:19,570 --> 00:26:25,890
So here we see that the first bit is zero so this is a two byte tag.

220
00:26:25,930 --> 00:26:28,730
One and two byte tags are quite common.

221
00:26:28,730 --> 00:26:33,710
There's also some three byte tags particularly with the contactless specifications.

222
00:26:33,830 --> 00:26:40,930
In principle you can have tags as long as you might like but I've never seen one that is longer than three bytes.

223
00:26:41,650 --> 00:26:46,750
After the tag is the length and this is going to be six.

224
00:26:46,770 --> 00:27:04,310
So if we now look at the emv specification which shows us what the meaning of each tag is then we can see that 9f02 is the amount authorized in numeric format.

225
00:27:04,310 --> 00:27:11,390
So the card wants to know when it's authorizing a transaction what is the amount it's going to authorize.

226
00:27:11,390 --> 00:27:17,630
So it's quite understandable and the card knows that this is the first field that's going to be sent.

227
00:27:17,630 --> 00:27:30,670
It knows that it's exactly six bytes long and it can then very easily compare this value to any limits that are specified in the card as to whether to authorize a transaction or not.

228
00:27:33,090 --> 00:27:35,930
Next let's go back to the response.

229
00:27:36,710 --> 00:27:44,430
At position 78 there is another tag this is two bytes long and it is 5f20.

230
00:27:44,430 --> 00:27:59,710
If we go and look what this actually means in the emv specification we can see that this is the card holder name and it is in alphanumeric format.

231
00:28:00,710 --> 00:28:10,650
So after the tag is going to be the length and this is 13 in hex which is 19 in decimal.

232
00:28:10,650 --> 00:28:23,090
If we now take these 19 bytes we get this and we can then decode it as ASCII and we get the card holder name.

233
00:28:23,370 --> 00:28:34,390
Card holder name is also present on the magnetic stripe and I'll talk about the relationship between the chip data and the magnetic stripe data a bit later.

234
00:28:34,790 --> 00:28:36,710
Okay let's keep on going.

235
00:28:38,050 --> 00:28:46,090
Next at offset 100 we have another tag this is 5f30 and this is the service code.

236
00:28:46,090 --> 00:28:55,650
The service code is another part of the emv chip data which was originally from the magnetic stripe standard.

237
00:28:55,890 --> 00:28:58,690
Let's go and have a look at what this says.

238
00:28:59,630 --> 00:29:07,430
After the tag is the length this is two and after the length is the two bytes that make up the content.

239
00:29:07,710 --> 00:29:11,390
From the specification we know that this is binary coded decimal.

240
00:29:11,390 --> 00:29:21,190
We know it is three digits long and with binary coded decimal it's left padded with zero so we ignore the first zero and we get 201.

241
00:29:21,450 --> 00:29:23,650
Let's look at what this actually means.

242
00:29:24,030 --> 00:29:33,290
The first digit is two and this says that this is suitable for international transactions and it has a chip.

243
00:29:33,510 --> 00:29:42,710
This service code on the magnetic stripe is how terminals know that this card should have a chip if you swipe the magnetic stripe.

244
00:29:42,710 --> 00:29:47,370
That's why if you try that the terminal will say please use chip.

245
00:29:47,890 --> 00:30:01,390
Next digit is zero which says that it can be authorized in normal ways and the final digit is one which says that it can be used with or without pin and it can also be used for any type of transaction.

246
00:30:03,390 --> 00:30:10,070
Next let's look at offset 57 where we've got actually tag 57 by coincidence.

247
00:30:10,310 --> 00:30:14,110
This is the track 2 equivalent data.

248
00:30:14,110 --> 00:30:20,410
This is a copy of the track 2 of the magnetic stripe on the back of the card.

249
00:30:20,410 --> 00:30:27,070
It's there to allow the terminal to process a chip transaction as if it is mag stripe.

250
00:30:27,070 --> 00:30:34,950
Maybe it's because the network isn't able to process chip transaction or maybe the issuer has not yet upgraded their systems.

251
00:30:34,950 --> 00:30:43,610
So the terminal has all the information necessary to put together a copy of track 1 and track 2 of the magnetic stripe.

252
00:30:43,610 --> 00:30:52,530
For track 1 the terminal needs to take data items like the account number and the card or name and so on and then put that together.

253
00:30:52,650 --> 00:30:58,890
For track 2 there's actually a complete copy of track 2 in one of these data fields and that's what you're seeing here.

254
00:30:59,070 --> 00:31:01,630
So we can look what this looks like.

255
00:31:02,050 --> 00:31:11,210
The start sentinel was missed out but then the next is the account number 16 binary coded decimal digits.

256
00:31:11,290 --> 00:31:23,790
Here I've masked out the middle of the digits because I've had too many conversations with my bank to say I needed a new card because my card number has been shown on television even though this card actually was cancelled quite a while ago.

257
00:31:24,330 --> 00:31:32,110
Then the separator normally this would be equal on track 2 but you can't do equal in binary coded decimal so they use d.

258
00:31:32,750 --> 00:31:39,890
Next is the expiry date so this is December 2015 so 1512.

259
00:31:40,050 --> 00:31:43,730
Then there's a service code which we've seen before 201.

260
00:31:43,990 --> 00:31:46,690
And finally there's the discretionary data.

261
00:31:46,690 --> 00:31:53,290
This varies between the issuer but most of them follow a similar process so we can guess what it actually means.

262
00:31:53,290 --> 00:31:58,190
The first five digits is the pin verification value.

263
00:31:58,390 --> 00:32:07,930
This is used for verifying whether a pin is correct without the card actually talking to the bank which knows the pin.

264
00:32:07,930 --> 00:32:12,710
This made sense when a lot of ATMs were not connected to any network.

265
00:32:12,710 --> 00:32:16,450
Nowadays it's obviously it's probably not used but it's still there.

266
00:32:16,450 --> 00:32:29,550
The first digit one which is the index for the key that is used for encrypting the PVV and then the rest which is 4079 is the PVV itself.

267
00:32:30,210 --> 00:32:37,390
After the PVV is the CVV car verification value and this is 927.

268
00:32:37,390 --> 00:32:46,730
This was a security feature introduced on magnetic stripe cards to help the bank detect whether a card is fake or not.

269
00:32:47,170 --> 00:32:56,290
A type of fraud that was happening quite frequently is people were getting card numbers and expiry dates and creating cloned magnetic stripe cards.

270
00:32:56,290 --> 00:33:15,330
The way that this was fixed is the CVV was written onto the magnetic stripe and it allowed the bank to see whether this is a genuine card or whether it was a card created with a copy of the account number and the expiry date that was obtained from a receipt perhaps.

271
00:33:15,810 --> 00:33:33,090
Now this actually creates a problem when chip transactions came along because if there was a copy of the CVV on the chip it meant someone who had data from the chip could then create a mag stripe and then completely bypass all the extra security features of the chip transaction.

272
00:33:33,310 --> 00:33:57,770
Eventually this got fixed round about in 2008 where there was a different CVV that was copied onto the chip compared to the copy of the CVV which was on the mag stripe and that meant that in principle card issuers could tell the difference between a genuine mag stripe transaction and a mag stripe transaction that was made using chip data.

273
00:33:57,790 --> 00:34:20,530
Now it turned out that that didn't actually work out as well as hoped because what we've found out from some recent research from Leanne Galloway is that issuers are accepting transactions as mag stripe transactions even though the CVV is incorrect because the CVV was taken from the chip and not actually from the mag stripe.

274
00:34:20,690 --> 00:34:27,990
So I've tried to give you an overview of some of the issues involved in decoding TLV.

275
00:34:27,990 --> 00:34:31,010
You can see it's not easy to get right.

276
00:34:31,010 --> 00:34:42,190
There's different encodings used for different purposes in different contexts and even if you're using the right decoding format then there's lots of ways that things can go wrong.

277
00:34:42,190 --> 00:34:47,110
For example we've seen that tags can be almost indefinite lengths.

278
00:34:47,430 --> 00:35:06,550
It's very easy to encode extremely long lengths because you can say that I'm now going to send eight further bytes of length and then have massive lengths that are then processed by the TLV decoder and that could cause memory overflow or memory underflow errors.

279
00:35:06,790 --> 00:35:18,870
Because of all the ways that things go wrong, mistakes do happen and this not only has problems from mistakes but problems occur from the consequences of those mistakes.

280
00:35:18,870 --> 00:35:33,110
What I mean is that issuers who are banks sending out cards know that sometimes things will go wrong because of all these complexities of EMV and they will accept transactions even though something has gone wrong.

281
00:35:33,110 --> 00:35:54,890
Now more often than not that's not fraud it's just someone has made a mistake with encoding or decoding some data but sometimes it will be fraud and this complexity leading to mistakes and then leading to being very forgiving about errors actually makes the EMV system more vulnerable to fraud than it would be otherwise.

282
00:35:56,010 --> 00:35:59,710
So maybe you'd like to try to do this yourself.

283
00:35:59,710 --> 00:36:02,510
It's quite an interesting experience.

284
00:36:02,770 --> 00:36:13,650
There might be some specific need why you might have to do this but it's often very instructive to try to do something yourself even though you can get some code out there already.

285
00:36:13,990 --> 00:36:39,510
One of my colleagues Mike Bond said the only way to understand the wheel is to reinvent it and when I've been writing TLV decoders and other aspects of the EMV infrastructure that's helped me understand where I've slipped up and if I slipped up then there's a reasonable chance that someone else might slip up and that's been a very fruitful source of vulnerabilities in terms of my research.

286
00:36:40,390 --> 00:36:50,830
But if you don't want to do all the decoding yourself I've written a TLV decoder on the emvlab.org website where you can try this out.

287
00:36:50,830 --> 00:36:55,070
Here is the decoding of the data I've been talking about in this talk.

288
00:36:55,070 --> 00:37:00,510
So you can see that the cdol1 and cdol2 are there first.

289
00:37:00,510 --> 00:37:02,590
There's some data I didn't talk about in this talk.

290
00:37:02,590 --> 00:37:11,790
The application version number and the currency code, currency code exponent, and the ddol and the ICC public key.

291
00:37:12,310 --> 00:37:26,750
But you can also see the track two equivalent data is there, service code, the track one discretionary data which is necessary for formatting track one if you're going to make a magstripe transaction using the chip data.

292
00:37:26,750 --> 00:37:28,430
So that stuff is all there.

293
00:37:28,430 --> 00:37:31,430
This is just one of several records that are stored by the card.

294
00:37:31,430 --> 00:37:32,890
There's a lot more out there.

295
00:37:32,890 --> 00:37:38,710
If you want to try for yourself then get a smart card reader, try out Cardpeak and then see what you can find.

296
00:37:39,530 --> 00:37:49,770
So there's more information about me and my research on my website and if you're interested in updates from our research group then have a look at our blog on Bentham's Gates.