WEBVTT 00:03.370 --> 00:08.650 I'm sure many of you have chip cards in your pocket which you use for credit and debit card transactions. 00:08.810 --> 00:16.590 These use the EMV standard for communication between the card and the terminal while performing one of these transactions. 00:17.150 --> 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. 00:38.870 --> 00:42.630 I've been looking into EMV for about 15 years now. 00:42.630 --> 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. 00:52.170 --> 00:55.290 If you're interested I've got other talks and papers about these. 00:55.370 --> 01:01.050 Instead in this talk I'll be looking at some of the low-level details about how EMV works. 01:01.050 --> 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. 01:10.830 --> 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. 01:20.930 --> 01:25.330 Primarily EMV is designed to be a compatibility specification. 01:25.390 --> 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. 01:41.650 --> 01:47.570 This is because when people perform EMV transactions they want to buy something. 01:47.610 --> 01:56.730 They are not primarily interested in security and if something went wrong they would rather the transaction went through than not. 01:56.770 --> 02:03.970 And so most of the EMV specification is about ensuring compatibility while also managing the constraints. 02:03.970 --> 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. 02:14.210 --> 02:22.530 Another consequence of this desire for compatibility is that cards and terminals try to follow Pestale's law. 02:22.530 --> 02:28.550 So they are conservative in what they generate but liberal in what they expect. 02:28.570 --> 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. 02:40.790 --> 02:48.010 This is very desirable for compatibility but has the consequence of creating security risks. 02:48.010 --> 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. 02:59.430 --> 03:09.830 And secondly, having this backwards and forwards compatibility creates more complexity and from complexity we can get security problems. 03:09.830 --> 03:18.330 One way the EMV standard tries to support compatibility is the TLV standard for encoding data. 03:18.810 --> 03:25.650 In this standard data is encoded as a tag followed by a length followed by a value. 03:25.650 --> 03:32.650 This is a very efficient way of representing hierarchical data structures. 03:32.790 --> 03:37.890 If this was a more modern standard you might see things like JSON or XML. 03:37.890 --> 03:44.450 In the case of JSON and XML they take up a lot of extra space to encode data. 03:44.610 --> 03:48.570 In contrast TLV is much much more efficient. 03:48.610 --> 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. 04:03.930 --> 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. 04:15.230 --> 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. 04:25.670 --> 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. 04:37.370 --> 04:44.630 This is convenient for older memory technologies that allowed erasure but not moving around the data. 04:46.110 --> 04:51.250 The TLV standard is also known as ASN1 BER. 04:51.250 --> 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. 05:01.770 --> 05:08.050 There's been plenty of security vulnerabilities as a result in the HTTPS standards. 05:08.070 --> 05:14.330 In this talk I'm going to show how you can manually decode TLV data. 05:14.330 --> 05:16.450 Now of course there's decoders out there. 05:16.450 --> 05:20.830 I've written some and I'll talk about those at the end of the talk. 05:20.830 --> 05:26.650 But there's sometimes cases where it's helpful to be able to decode these things manually. 05:26.950 --> 05:31.610 So maybe the data you've got is incomplete or corrupt but you still need to make sense of it. 05:31.930 --> 05:37.210 Maybe you have to explain exactly why a particular decoding is the right one. 05:37.430 --> 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. 05:50.110 --> 05:53.610 You might have to write your own decoder although I wouldn't recommend it. 05:53.610 --> 05:55.530 There's lots of places you can go wrong. 05:56.070 --> 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. 06:06.950 --> 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. 06:19.910 --> 06:28.210 A document with my notes to show some of the resources that are necessary to understand TLV data in EMV. 06:28.210 --> 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. 06:40.680 --> 06:45.160 In this talk I'll be decoding some TLV data structures. 06:45.160 --> 06:48.520 These are represented in hexadecimal. 06:48.840 --> 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. 06:59.700 --> 07:02.380 These are part of the hexutils package. 07:02.380 --> 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. 07:09.980 --> 07:20.260 The first function takes a byte represented as a pair of characters, hexadecimal characters, and then converts it to binary. 07:20.260 --> 07:26.700 It always converts it to to eight bits so it'll handle adding reading zeros if necessary. 07:28.920 --> 07:36.500 Sometimes these strings will have spaces around it that's very nice for formatting but can complicate decoding. 07:36.500 --> 07:44.020 So the function stripBytes removes any whitespace before, after, and within the hexadecimal string. 07:46.750 --> 07:50.430 This one adds whitespace back in to make it easier to look at. 07:50.430 --> 07:56.850 It splits the hex string into bytes and then adds a space between each byte. 07:59.460 --> 08:02.580 Sometimes we want to count how long a hex string is. 08:02.580 --> 08:08.200 So this counts how many bytes are in a hex string, removing any whitespace beforehand. 08:10.970 --> 08:15.290 Sometimes the hex bytes include text. 08:15.290 --> 08:18.170 Typically this would be encoded using ASCII. 08:18.170 --> 08:32.450 So this function decodes a hex string into the equivalent string using ISO 8859-1 which is a superset of ASCII. 08:35.790 --> 08:38.810 Now into some slightly more interesting functions. 08:39.030 --> 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. 08:46.410 --> 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. 08:59.940 --> 09:04.240 Sometimes there actually might be multiple fields within a single byte. 09:04.240 --> 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. 09:21.650 --> 09:26.890 I'm going to be taking sections out of hex strings. 09:26.890 --> 09:29.550 So the take function does this. 09:29.770 --> 09:33.610 In the first format it just takes a certain number of bytes. 09:33.610 --> 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. 09:40.590 --> 09:45.330 And in the second form it takes two bytes but also takes an offset. 09:45.330 --> 09:48.590 So here I'm starting offset 1 counting from zero. 09:48.590 --> 09:52.790 That means I'm skipping the first byte and then taking the next two bytes. 09:56.980 --> 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. 10:06.520 --> 10:11.880 Now don't get too excited, the card's long since expired so you won't be seeing any sensitive information. 10:12.080 --> 10:14.560 But this is a real card. 10:14.920 --> 10:18.440 To actually extract this data I used a tool called CardPeek. 10:18.680 --> 10:20.400 This is really handy. 10:20.400 --> 10:23.260 It can deal with many different types of smart cards. 10:23.260 --> 10:27.180 It can do TLV decoding and other types of decoding by itself. 10:27.180 --> 10:31.300 But the whole point of this talk is to show you how to do this yourself. 10:31.300 --> 10:36.880 So rather than looking at the final output of CardPeek I'm going to look at the log file from this. 10:37.880 --> 10:44.600 One of the stages of getting data off a card is to use the read record command. 10:44.600 --> 10:48.280 To see how this works let's look at the EMV specification. 10:48.500 --> 10:55.600 Rather than giving the whole spec I've taken some selected parts and these are available in the notes. 11:00.740 --> 11:05.920 So here is the specification for the read record command. 11:06.320 --> 11:10.760 EMV commands take two different bytes to specify the command. 11:10.760 --> 11:13.060 There's the class and the instruction. 11:13.060 --> 11:17.680 So for read record class is 00, instruction is B2. 11:17.780 --> 11:22.100 And then it takes two parameters P1 and P2. 11:22.160 --> 11:25.960 These parameters depend on the actual command. 11:25.960 --> 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. 11:35.260 --> 11:37.440 And I'll talk about that a bit later. 11:38.880 --> 11:43.360 We need to specify how long the record is. 11:43.360 --> 11:48.740 We need to specify the length expected, but initially we don't know what this is. 11:48.740 --> 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. 11:57.040 --> 12:02.760 So 6c is an error message and tell you how long the response is actually. 12:02.760 --> 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. 12:10.440 --> 12:15.260 And then the 97 in hexadecimal bytes that you've requested. 12:17.360 --> 12:20.740 So I mentioned that there's a reference control parameter. 12:20.740 --> 12:29.680 This is our first example of one of these fields where you are taking a single byte and splitting up. 12:29.680 --> 12:35.380 So here is the table that shows how one of these bytes is formatted. 12:35.480 --> 12:41.900 The first five bits is the SFI, the short file identifier. 12:41.900 --> 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. 12:53.680 --> 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. 13:04.580 --> 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. 13:23.340 --> 13:31.980 So I mentioned that this is a 97 byte long string that's in hexadecimal. 13:31.980 --> 13:34.960 If we convert that to decimal we get 151. 13:34.960 --> 13:39.780 So the response for record number 2 is 151 bytes. 13:42.840 --> 13:49.420 We're going to now try decoding this and the first step is by putting this into a Python variable. 13:49.420 --> 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. 13:57.180 --> 14:02.040 So let's look at the first byte of this response. 14:02.640 --> 14:07.280 We know that this is a TLV string. 14:07.280 --> 14:11.340 First byte of a TLV string is the tag. 14:11.340 --> 14:13.700 So let's look at what that actually is. 14:13.700 --> 14:16.820 And if we look at that we will see that it is 70. 14:16.820 --> 14:22.540 So now let's go and try to decode this tag 70. 14:24.760 --> 14:27.380 Tags can be multiple bytes long. 14:27.480 --> 14:33.980 So here is the table for decoding the first byte of a tag. 14:35.380 --> 14:39.220 We can see that there are three different fields. 14:39.220 --> 14:44.580 One that's two bits long, one that's one bit long and then the rest is five bits long. 14:46.880 --> 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. 15:02.660 --> 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. 15:14.220 --> 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. 15:27.980 --> 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. 15:39.540 --> 15:44.700 It's up to the producer of the card to define how this actually has meaning. 15:45.400 --> 15:51.860 Anyway this is 01 which is application class which means it's specific to to smart cards. 15:52.540 --> 15:57.560 Now we need to find out what is the contents of this tag. 15:57.560 --> 16:01.350 This could be either primitive or it could be constructed. 16:01.940 --> 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. 16:12.980 --> 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. 16:24.720 --> 16:31.080 And then the last five bits is just a number that encodes which particular tag that is. 16:31.140 --> 16:34.600 This is 1 0 0 0 0. 16:34.860 --> 16:40.020 As long as this is not all ones this is a one byte tag. 16:40.020 --> 16:49.380 So what we know is that tag 70 is a one byte tag containing TLV data items. 16:49.480 --> 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. 17:02.730 --> 17:06.370 Okay so now continuing on we've got the tag. 17:06.370 --> 17:07.250 Tag is 70. 17:07.250 --> 17:10.070 The next bytes are going to be the length. 17:10.190 --> 17:16.430 So let's look at the length and this is hex 81. 17:16.810 --> 17:19.470 You actually have to decode the length to find out what it means. 17:19.470 --> 17:23.050 So let's look at the table for decoding length. 17:24.750 --> 17:31.490 And what this says is that if bit 8 is not set then this is the length. 17:31.490 --> 17:40.410 But if bit 8 is set then this specifies the length of the length and that is going to follow. 17:40.410 --> 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. 17:55.620 --> 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. 18:05.940 --> 18:10.960 Converting that into decibel is 148 bytes. 18:10.960 --> 18:21.280 So within tag 70 there are 148 bytes of further data and these are in the TLV format. 18:24.760 --> 18:27.460 Let's actually check whether this makes sense. 18:27.620 --> 18:31.220 So let's take these 148 bytes. 18:31.220 --> 18:38.460 We get to this by skipping the one byte tag and then the two bytes used for the length. 18:39.900 --> 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. 18:49.500 --> 18:56.020 So this tag 70 contains everything that is part of the read record response. 19:00.860 --> 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. 19:10.920 --> 19:13.260 So let's look at the first part of that. 19:13.260 --> 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. 19:20.960 --> 19:23.920 So let's follow the same decoding pattern. 19:28.010 --> 19:36.230 So we see the first field is context specific so the meaning of this depends where it's actually found. 19:36.230 --> 19:41.370 This is as part of an EMV application so we have to use the EMV specification. 19:42.170 --> 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. 19:53.190 --> 19:54.330 We need to look elsewhere. 19:54.790 --> 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. 20:08.550 --> 20:14.870 So to find the meaning of this we're going to need to look again into the EMV specification. 20:14.870 --> 20:22.730 It has something called a tag dictionary where you can see a list of tags and their meaning and their format. 20:22.970 --> 20:32.450 So this is 8c and then we can see that 8c is the CardRiskManagementDataObjectList1. 20:32.490 --> 20:35.230 I'll go into what data object lists are. 20:35.230 --> 20:39.490 That's important data format within EMV. 20:42.330 --> 20:49.070 But let's look at the contents next and to do that we need to see the length. 20:49.070 --> 20:52.870 The length is 21 in hex. 20:52.870 --> 20:56.410 Now is this a one byte length or a multi-byte length? 20:56.410 --> 20:58.110 We need to decode it. 20:58.250 --> 21:02.770 Bit 8 is zero which means that this is a one byte length. 21:02.770 --> 21:12.990 So the size of this cdol1 record is 21 in hex bytes and then if we decode that we get 33. 21:12.990 --> 21:21.170 So there are going to be 33 bytes following tag 8c which is the cdol1. 21:24.010 --> 21:25.470 So let's get that. 21:25.610 --> 21:27.390 We've got to skip over a few things. 21:27.390 --> 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. 21:41.160 --> 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. 21:52.480 --> 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. 22:04.240 --> 22:14.320 So this is 8d and then this is a one byte tag which is the cdol2. 22:15.080 --> 22:17.420 Then we look at the length. 22:17.420 --> 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. 22:25.580 --> 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. 22:36.080 --> 22:41.440 So we've got both the cdol1 and cdol2 which followed it. 22:44.250 --> 22:49.510 So I mentioned that cdol1 is a doll object. 22:49.510 --> 22:52.970 Dolls are really quite important for EMV. 22:52.970 --> 22:59.130 They come about because EMV assumes that cards are very limited in what they can do. 22:59.130 --> 23:03.050 Maybe they cannot even decode TLV data themselves. 23:03.290 --> 23:09.310 The terminal on the other hand is more powerful so it can do a little bit more than the card. 23:09.310 --> 23:15.190 So when data is sent from the card to the terminal that's often in TLV format. 23:15.570 --> 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. 23:28.370 --> 23:31.130 Instead we use dolls. 23:31.130 --> 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. 23:42.650 --> 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. 23:59.690 --> 24:04.290 So one of these dolls consists of a list of tags and a list of lengths. 24:04.290 --> 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. 24:18.770 --> 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. 24:30.150 --> 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. 24:41.470 --> 24:47.130 If the card agrees to authorize that transaction it gets sent to the bank normally. 24:47.130 --> 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. 24:56.210 --> 25:02.190 The data items that are requested in each of these requests are a little bit different. 25:02.190 --> 25:05.710 That's why there's a cdoll1 and a separate cdoll2. 25:06.710 --> 25:10.370 So now let's go actually into this cdoll1. 25:10.370 --> 25:16.450 It's a list of tags so let's look at the first byte of the cdoll1 and we get 9f. 25:16.450 --> 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. 25:23.930 --> 25:32.270 Here we are and now we can see that the first field is 1 0 so it's context specific. 25:32.270 --> 25:35.310 This is a emv tag. 25:35.790 --> 25:43.410 The next bit is that it is a primitive data object so it's not TLV itself. 25:43.530 --> 25:47.990 And then the rest of the bits are 1 1 1 1 1. 25:47.990 --> 25:53.050 If you haven't seen this before this means 9f is the beginning of a multi-byte tag. 25:53.050 --> 25:55.730 It's not a one byte tag like we've seen before. 25:57.110 --> 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. 26:03.710 --> 26:07.870 To interpret this we need a different table so let's go on to the second table. 26:08.530 --> 26:17.630 This says that if the first bit is zero then that is the last byte of the tag. 26:17.630 --> 26:19.570 If it's one there's going to be more coming. 26:19.570 --> 26:25.890 So here we see that the first bit is zero so this is a two byte tag. 26:25.930 --> 26:28.730 One and two byte tags are quite common. 26:28.730 --> 26:33.710 There's also some three byte tags particularly with the contactless specifications. 26:33.830 --> 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. 26:41.650 --> 26:46.750 After the tag is the length and this is going to be six. 26:46.770 --> 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. 27:04.310 --> 27:11.390 So the card wants to know when it's authorizing a transaction what is the amount it's going to authorize. 27:11.390 --> 27:17.630 So it's quite understandable and the card knows that this is the first field that's going to be sent. 27:17.630 --> 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. 27:33.090 --> 27:35.930 Next let's go back to the response. 27:36.710 --> 27:44.430 At position 78 there is another tag this is two bytes long and it is 5f20. 27:44.430 --> 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. 28:00.710 --> 28:10.650 So after the tag is going to be the length and this is 13 in hex which is 19 in decimal. 28:10.650 --> 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. 28:23.370 --> 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. 28:34.790 --> 28:36.710 Okay let's keep on going. 28:38.050 --> 28:46.090 Next at offset 100 we have another tag this is 5f30 and this is the service code. 28:46.090 --> 28:55.650 The service code is another part of the emv chip data which was originally from the magnetic stripe standard. 28:55.890 --> 28:58.690 Let's go and have a look at what this says. 28:59.630 --> 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. 29:07.710 --> 29:11.390 From the specification we know that this is binary coded decimal. 29:11.390 --> 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. 29:21.450 --> 29:23.650 Let's look at what this actually means. 29:24.030 --> 29:33.290 The first digit is two and this says that this is suitable for international transactions and it has a chip. 29:33.510 --> 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. 29:42.710 --> 29:47.370 That's why if you try that the terminal will say please use chip. 29:47.890 --> 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. 30:03.390 --> 30:10.070 Next let's look at offset 57 where we've got actually tag 57 by coincidence. 30:10.310 --> 30:14.110 This is the track 2 equivalent data. 30:14.110 --> 30:20.410 This is a copy of the track 2 of the magnetic stripe on the back of the card. 30:20.410 --> 30:27.070 It's there to allow the terminal to process a chip transaction as if it is mag stripe. 30:27.070 --> 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. 30:34.950 --> 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. 30:43.610 --> 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. 30:52.650 --> 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. 30:59.070 --> 31:01.630 So we can look what this looks like. 31:02.050 --> 31:11.210 The start sentinel was missed out but then the next is the account number 16 binary coded decimal digits. 31:11.290 --> 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. 31:24.330 --> 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. 31:32.750 --> 31:39.890 Next is the expiry date so this is December 2015 so 1512. 31:40.050 --> 31:43.730 Then there's a service code which we've seen before 201. 31:43.990 --> 31:46.690 And finally there's the discretionary data. 31:46.690 --> 31:53.290 This varies between the issuer but most of them follow a similar process so we can guess what it actually means. 31:53.290 --> 31:58.190 The first five digits is the pin verification value. 31:58.390 --> 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. 32:07.930 --> 32:12.710 This made sense when a lot of ATMs were not connected to any network. 32:12.710 --> 32:16.450 Nowadays it's obviously it's probably not used but it's still there. 32:16.450 --> 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. 32:30.210 --> 32:37.390 After the PVV is the CVV car verification value and this is 927. 32:37.390 --> 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. 32:47.170 --> 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. 32:56.290 --> 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. 33:15.810 --> 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. 33:33.310 --> 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. 33:57.790 --> 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. 34:20.690 --> 34:27.990 So I've tried to give you an overview of some of the issues involved in decoding TLV. 34:27.990 --> 34:31.010 You can see it's not easy to get right. 34:31.010 --> 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. 34:42.190 --> 34:47.110 For example we've seen that tags can be almost indefinite lengths. 34:47.430 --> 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. 35:06.790 --> 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. 35:18.870 --> 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. 35:33.110 --> 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. 35:56.010 --> 35:59.710 So maybe you'd like to try to do this yourself. 35:59.710 --> 36:02.510 It's quite an interesting experience. 36:02.770 --> 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. 36:13.990 --> 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. 36:40.390 --> 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. 36:50.830 --> 36:55.070 Here is the decoding of the data I've been talking about in this talk. 36:55.070 --> 37:00.510 So you can see that the cdol1 and cdol2 are there first. 37:00.510 --> 37:02.590 There's some data I didn't talk about in this talk. 37:02.590 --> 37:11.790 The application version number and the currency code, currency code exponent, and the ddol and the ICC public key. 37:12.310 --> 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. 37:26.750 --> 37:28.430 So that stuff is all there. 37:28.430 --> 37:31.430 This is just one of several records that are stored by the card. 37:31.430 --> 37:32.890 There's a lot more out there. 37:32.890 --> 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. 37:39.530 --> 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.