start	end	text
3370	7550	I'm sure many of you have chip cards in your pocket which you use for credit and debit card
7550	13570	transactions. These use the EMV standard for communication between the card and the terminal
13570	20070	while performing one of these transactions. EMV is named after the original creators of the
20070	25450	standard, Europay, Mastercard and Visa, but since then maintenance of the standard has been taken
25450	32570	over by EMVco, who also manage closely related specifications on contactless payments and
32570	38270	some other payment standards like the 3D Secure online payment standard.
38870	44430	I've been looking into EMV for about 15 years now. I've found a variety of vulnerabilities
45050	50550	both in the standard and in the implementations, but in this talk I'm not going to be covering
50550	55290	these vulnerabilities. If you're interested I've got other talks and papers about these.
55370	61490	Instead in this talk I'll be looking at some of the low-level details about how EMV works. I hope
61490	67810	this might trigger your interest in looking into EMV in more detail yourself and also perhaps will
67810	74930	be useful as part of your work. Given the billions of pounds and dollars that flow through EMV
74930	80890	transactions you'd think that EMV was designed to be a security specification, but it's not really.
80930	87770	Primarily EMV is designed to be a compatibility specification. It's there to allow cars and
87770	94350	terminals to communicate regardless of how old or new the equipment is, regardless of where in the
94350	100030	world these are and regardless of the banks that have been used to set up the terminal and the
100030	107970	cards. This is because when people perform EMV transactions they want to buy something. They are
107970	114410	not primarily interested in security and if something went wrong they would rather the
114410	120990	transaction went through than not. And so most of the EMV specification is about ensuring compatibility
121470	127570	while also managing the constraints. For example, cards are very limited in the amount of RAM they
127570	132210	have and the amount of processing they have and this has a lot of impact in how the specification
132210	140850	is designed. Another consequence of this desire for compatibility is that cards and terminals try
140850	147130	to follow Pestale's law. So they are conservative in what they generate but liberal in what they
147130	153430	expect. The idea is that if there are some changes to the way that cards and terminals work
153430	158690	they'll continue to operate because they will not just reject a transaction because something
158690	165730	is unexpected. This is very desirable for compatibility but has the consequence of
165730	172270	creating security risks. Firstly, if there is data which is not possible to interpret
172850	178410	devices will ignore it but maybe that is very security relevant information that they're
178410	185910	ignoring. And secondly, having this backwards and forwards compatibility creates more complexity
185910	192610	and from complexity we can get security problems. One way the EMV standard tries to support
192610	202730	compatibility is the TLV standard for encoding data. In this standard data is encoded as a tag
202730	211310	followed by a length followed by a value. This is a very efficient way of representing hierarchical
211310	217890	data structures. If this was a more modern standard you might see things like JSON or XML.
217890	227010	In the case of JSON and XML they take up a lot of extra space to encode data. In contrast TLV is
227010	234590	much much more efficient. The downside of TLV is that while with JSON or XML you can look at data
234590	240270	and more or less work out what's going on, in the case of TLV data you have to look quite carefully
240270	248190	before you can work out what this actually means. TLV data helps compatibility because it's possible
248190	255230	to decode without the decoder understanding all the semantics of the data that's encoded inside.
255230	262810	A decoder can still produce this tree and identify data items that it knows about but it can ignore
262810	269690	data items that it doesn't know about. It also has some other features like allowing data items to be
269690	277370	deleted just by filling with zeros rather than having to rewrite the whole string of bytes.
277370	284630	This is convenient for older memory technologies that allowed erasure but not moving around the data.
286110	295590	The TLV standard is also known as ASN1 BER. So this is from the X208 standard and it's the
295590	302690	standard that is also used as the encoding format for HTTPS certificates. There's been plenty of
302690	311070	security vulnerabilities as a result in the HTTPS standards. In this talk I'm going to show how you
311070	318350	can manually decode TLV data. Now of course there's decoders out there. I've written some and I'll
318350	324770	talk about those at the end of the talk. But there's sometimes cases where it's helpful to be
324770	329990	able to decode these things manually. So maybe the data you've got is incomplete or corrupt but you
329990	336410	still need to make sense of it. Maybe you have to explain exactly why a particular decoding is the
336410	341430	right one. One of the things I do from time to time is expert witness in a court case and there
341430	346710	you not only have to give the answer but also explain the rationale of why you're making the
346710	353010	recommendation that you are making. You might have to write your own decoder although I wouldn't
353010	358570	recommend it. There's lots of places you can go wrong. And also sometimes doing things yourself
359090	364570	shows you where other people might have slipped up and help you identify where else security
364570	372110	vulnerabilities might be. So in this talk I'm going to show these decoding processes and if you want
372110	378050	to follow along then these links here will take you to the Jupyter notebook which I've used for
378050	385690	doing the decoding. A document with my notes to show some of the resources that are necessary to
385690	393370	understand TLV data in EMV. And there's also the repository which contains the Python notebook
393370	403400	and the source code for the utilities that I've been using. In this talk I'll be decoding some
403400	411860	TLV data structures. These are represented in hexadecimal. So to help us decode these I've
411860	418560	written some simple Python functions that allow us to manipulate these strings of hexadecimal
418560	424620	characters. These are part of the hexutils package. You can download it from the repository
424620	429080	that I linked to earlier and you can also use this within the Jupyter notebook.
429980	437960	The first function takes a byte represented as a pair of characters, hexadecimal characters,
437960	444960	and then converts it to binary. It always converts it to to eight bits so it'll handle adding reading
444960	453660	zeros if necessary. Sometimes these strings will have spaces around it that's very nice for
453660	459680	formatting but can complicate decoding. So the function stripBytes removes any whitespace
460380	469490	before, after, and within the hexadecimal string. This one adds whitespace back in to make it easier
469490	480060	to look at. It splits the hex string into bytes and then adds a space between each byte. Sometimes
480060	485460	we want to count how long a hex string is. So this counts how many bytes are in a hex string,
485460	495290	removing any whitespace beforehand. Sometimes the hex bytes include text.
495290	501930	Typically this would be encoded using ASCII. So this function decodes a hex string
502440	512450	into the equivalent string using ISO 8859-1 which is a superset of ASCII.
515790	521270	Now into some slightly more interesting functions. Quite often we all need to look at the
521270	529410	individual bits and at what position bits are set to 1 or 0. So this function takes in a byte
529410	537570	and in the hexadecimal and then shows you which bits are set to 1 and which bits are set to 0.
539940	545220	Sometimes there actually might be multiple fields within a single byte. So this function
545220	552880	takes a specification of how long each field is, converts the hex into binary, and then shows
552880	557600	each of these binary digits according to which field it belongs to.
561650	569550	I'm going to be taking sections out of hex strings. So the take function does this.
569770	574770	In the first format it just takes a certain number of bytes. So in this case you have a
574770	579350	hex string and then you ask for two bytes and it gives you these two bytes.
580590	586650	And in the second form it takes two bytes but also takes an offset. So here I'm starting
586650	591310	offset 1 counting from zero. That means I'm skipping the first byte and then taking the
591310	603880	next two bytes. In this talk I'm going to show how to decode some real EMV data and I took some
603880	609140	data off my own credit card. Now don't get too excited, the card's long since expired
609140	614560	so you won't be seeing any sensitive information. But this is a real card.
614920	620700	To actually extract this data I used a tool called CardPeek. This is really handy. It can
620700	626540	deal with many different types of smart cards. It can do TLV decoding and other types of decoding by
626540	632040	itself. But the whole point of this talk is to show you how to do this yourself. So rather than
632040	636880	looking at the final output of CardPeek I'm going to look at the log file from this.
637880	644600	One of the stages of getting data off a card is to use the read record command.
644600	649600	To see how this works let's look at the EMV specification. Rather than giving the whole
649600	655600	spec I've taken some selected parts and these are available in the notes.
660740	665920	So here is the specification for the read record command.
666320	673060	EMV commands take two different bytes to specify the command. There's the class and the instruction.
673060	682100	So for read record class is 00, instruction is B2. And then it takes two parameters P1 and P2.
682160	688340	These parameters depend on the actual command. So if we look up the specification for read record
688340	692100	we'll see that P1 is the record number we're going to read,
692100	697440	and then P2 is a reference control parameter. And I'll talk about that a bit later.
698880	706260	We need to specify how long the record is. We need to specify the length expected,
706260	711920	but initially we don't know what this is. So the way to deal with this is you initially specify
711920	718560	0 as the length and then the card will return an error message. So 6c is an error message
718560	725080	and tell you how long the response is actually. And then you call the same command again now
725080	730440	specifying the correct length and it will return 9000 which means everything is okay.
730440	735260	And then the 97 in hexadecimal bytes that you've requested.
737360	740740	So I mentioned that there's a reference control parameter.
740740	748920	This is our first example of one of these fields where you are taking a single byte and splitting
748920	758120	up. So here is the table that shows how one of these bytes is formatted. The first five bits
758660	765960	is the SFI, the short file identifier. We found out the short file identifier earlier on when we
765960	771640	activated the payment application on this card and we found out that the relevant records are
771640	780200	in SFI 2. So the first five bits get set to 2 and then the last three bits get set to 100
780200	788280	to indicate that P1 is a record number. So we can show how this works by calling the formatBytes
788280	796480	function with a field settings of 5 followed by 3 and we see indeed yes the first field is set to
796480	810080	2 and the second field is set to 100. So I mentioned that this is a 97 byte long string
810820	816960	that's in hexadecimal. If we convert that to decimal we get 151. So the response for record
816960	827900	number 2 is 151 bytes. We're going to now try decoding this and the first step is by putting
827900	832960	this into a Python variable. I'm going to call this response and we'll see this used quite a lot
832960	845060	in the rest of the talk. So let's look at the first byte of this response. We know that this is a TLV
846320	853700	string. First byte of a TLV string is the tag. So let's look at what that actually is.
853700	862540	And if we look at that we will see that it is 70. So now let's go and try to decode this tag 70.
864760	873980	Tags can be multiple bytes long. So here is the table for decoding the first byte of a tag.
875380	881860	We can see that there are three different fields. One that's two bits long, one that's one bit long
881860	894240	and then the rest is five bits long. If we now decode this hex 70 following the field specification
894920	904020	we see that the first field is 01 and that corresponds to application class. Tags can be
904020	911160	universal which means that every application that handles ESN1 should be able to understand it
911780	919940	and it's not one of those. There's application where it is specific to a particular application
919940	927980	so it could be smart card for example but it has the same meaning regardless of where it's used.
927980	935120	It can be context specific which means that the meaning actually depends where this tag is present
935120	939780	or it can be private in which case the specification doesn't deal with it. It's
939780	946460	up to the producer of the card to define how this actually has meaning. Anyway this is 01
946460	953640	which is application class which means it's specific to to smart cards. Now we need to find
953640	961350	out what is the contents of this tag. This could be either primitive or it could be constructed.
961940	968220	Primitive means that no further decoding is handled as part of TLV and constructed means that
968220	975560	the contents is a series of TLV data items. Here we can see this field is set to one which means
975560	983320	that is a constructed data object that means that the contents are going to be more TLV data items.
984720	991080	And then the last five bits is just a number that encodes which particular tag that is.
991140	1002200	This is 1 0 0 0 0. As long as this is not all ones this is a one byte tag. So what we know is that
1002200	1012040	tag 70 is a one byte tag containing TLV data items. And if we look this up in the UV specification
1012040	1017760	we'd find out this is a read record response message template which is what we'd expect
1017760	1027250	because we just called read record. Okay so now continuing on we've got the tag. Tag is 70.
1027250	1036430	The next bytes are going to be the length. So let's look at the length and this is hex 81.
1036810	1040610	You actually have to decode the length to find out what it means. So let's look at the table
1040610	1051490	for decoding length. And what this says is that if bit 8 is not set then this is the length.
1051490	1060410	But if bit 8 is set then this specifies the length of the length and that is going to follow.
1060410	1067210	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
1067210	1076900	an additional one byte that contains the actual length of this data item. So let's look at the
1076900	1085740	next byte and this is hex 94 and that is the actual length of the contents of this response.
1085940	1098080	Converting that into decibel is 148 bytes. So within tag 70 there are 148 bytes of further data
1098080	1107460	and these are in the TLV format. Let's actually check whether this makes sense.
1107620	1116600	So let's take these 148 bytes. We get to this by skipping the one byte tag and then the two
1116600	1124660	bytes used for the length. And if we check the size of the whole response and take off those
1124660	1132100	three bytes that we skipped over then indeed there's 148 bytes there. So this tag 70 contains
1132100	1144180	everything that is part of the read record response. We know that this is a constructed tag
1144180	1152020	so the contents are going to be a TLV item or one or more TLV items. So let's look at the
1152020	1158820	first part of that. So the first byte is 8c and to find out what that actually
1158820	1163920	means as a tag we need to decode it. So let's follow the same decoding pattern.
1168010	1175590	So we see the first field is context specific so the meaning of this depends where it's actually
1175590	1181370	found. This is as part of an EMV application so we have to use the EMV specification.
1182170	1190190	The next bit is that it is a primitive data object so the ASM1 specification
1190850	1194330	doesn't say anything more about how to decode that. We need to look elsewhere.
1194790	1203510	And then the rest of it is not all ones so this is a one byte tag and the bits that are in this
1204170	1211190	final field show us which of the tags it is. So to find the meaning of this we're going to need to
1211370	1217590	look again into the EMV specification. It has something called a tag dictionary where you can
1217590	1227150	see a list of tags and their meaning and their format. So this is 8c and then we can see that
1227150	1235490	8c is the CardRiskManagementDataObjectList1. I'll go into what data object lists are. That's
1236050	1248190	important data format within EMV. But let's look at the contents next and to do that we need to
1248190	1256410	see the length. The length is 21 in hex. Now is this a one byte length or a multi-byte length?
1256410	1264950	We need to decode it. Bit 8 is zero which means that this is a one byte length. So the size of
1264950	1274490	this cdol1 record is 21 in hex bytes and then if we decode that we get 33. So there are going to be
1274490	1287050	33 bytes following tag 8c which is the cdol1. So let's get that. We've got to skip over a few
1287050	1294050	things. We've got to skip over tag 70, the two byte length, skip over tag 8c and then one byte
1294050	1303580	length and take 33 bytes and then this is what we actually get. So we'll save the cdol1
1303580	1313420	for later but now let's continue and see what is the next item within this response. So we're going
1313420	1321100	to skip over everything we did before and also skip over the 33 bytes of data which is a cdol1
1321100	1331880	and then the next thing we get is another tag. So this is 8d and then this is a one byte tag
1331880	1339700	which is the cdol2. Then we look at the length. This is zero c that's a one byte length
1340800	1346840	and then actually now let's get the contents of this tag. So this is
1348300	1355380	zero c bytes starting at the offset by skipping over everything before and then this is now the
1355380	1366170	cdol2. So we've got both the cdol1 and cdol2 which followed it. So I mentioned that cdol1
1366170	1374690	is a doll object. Dolls are really quite important for EMV. They come about because
1375330	1381690	EMV assumes that cards are very limited in what they can do. Maybe they cannot even decode TLV
1381690	1388290	data themselves. The terminal on the other hand is more powerful so it can do a little bit more
1388290	1395190	than the card. So when data is sent from the card to the terminal that's often in TLV format.
1395570	1402950	But when data is sent from the terminal to the card generally TLV is not used because maybe the
1403510	1413190	doesn't understand how to decode that sort of data item. Instead we use dolls. So a data object
1413190	1421010	list is a set of tags and lengths and that tells the terminal how to format data that the card is
1421010	1428110	going to receive. And then when the card receives this all it needs to do is jump to specific
1428110	1435490	offsets within this set of data to know exactly what is the data item at that particular position
1435490	1442350	without having to go through any more decoding steps. So one of these dolls consists of a list
1442350	1447050	of tags and a list of lengths. And that tells the terminal when it's sending data to the card
1447050	1452810	in this particular context all it should do is take this particular data item that the card
1452810	1460150	requests, pad it to a particular size, and then send it to the card. And then keep on sending
1460150	1467970	these data items of the particular length until all the tags covered in the doll have been sent
1467970	1476730	over to the card. So the cdoll1 is used as the first step of the authorization process where the
1476730	1485010	card is asked to produce an authorization request. If the card agrees to authorize that transaction
1485010	1491290	it gets sent to the bank normally. And then the second stage of actually telling the card that the
1491290	1497970	transaction has succeeded is what the cdoll2 is used for. The data items that are requested
1498490	1503410	in each of these requests are a little bit different. That's why there's a cdoll1
1503410	1512090	and a separate cdoll2. So now let's go actually into this cdoll1. It's a list of tags so let's
1512090	1518890	look at the first byte of the cdoll1 and we get 9f. To find out what this actually means we will
1518890	1527790	need to look at the table for decoding the first bytes of tags. Here we are and now we can see
1527790	1537570	that the first field is 1 0 so it's context specific. This is a emv tag. The next bit is
1538090	1545850	that it is a primitive data object so it's not TLV itself. And then the rest of the bits are
1545850	1553050	1 1 1 1 1. If you haven't seen this before this means 9f is the beginning of a multi-byte tag.
1553050	1559970	It's not a one byte tag like we've seen before. So to find out what else is going on in this tag
1559970	1565430	we need to look at the next byte and we get this as 0 2. To interpret this we need a different
1565430	1574970	table so let's go on to the second table. This says that if the first bit is zero then that is
1574970	1580930	the last byte of the tag. If it's one there's going to be more coming. So here we see that the
1580930	1589610	first bit is zero so this is a two byte tag. One and two byte tags are quite common. There's also
1589610	1594630	some three byte tags particularly with the contactless specifications. In principle you
1594630	1600930	can have tags as long as you might like but I've never seen one that is longer than three bytes.
1601650	1609710	After the tag is the length and this is going to be six. So if we now look at the
1609710	1616970	emv specification which shows us what the meaning of each tag is then we can see that
1619210	1626990	9f02 is the amount authorized in numeric format. So the card wants to know when it's authorizing
1627190	1633530	a transaction what is the amount it's going to authorize. So it's quite understandable and
1633530	1639070	the card knows that this is the first field that's going to be sent. It knows that it's exactly six
1639070	1645570	bytes long and it can then very easily compare this value to any limits that are specified
1646110	1654810	in the card as to whether to authorize a transaction or not. Next let's go back to the
1654810	1665530	response. At position 78 there is another tag this is two bytes long and it is 5f20. If we go
1665530	1673590	and look what this actually means in the emv specification we can see that this is the card
1673590	1683630	holder name and it is in alphanumeric format. So after the tag is going to be the length
1684430	1698310	and this is 13 in hex which is 19 in decimal. If we now take these 19 bytes we get this and
1698310	1706090	we can then decode it as ASCII and we get the card holder name. Card holder name is also present on
1706090	1712070	the magnetic stripe and I'll talk about the relationship between the chip data and the
1712070	1721730	magnetic stripe data a bit later. Okay let's keep on going. Next at offset 100 we have another tag
1721730	1730930	this is 5f30 and this is the service code. The service code is another part of the emv chip data
1730930	1737510	which was originally from the magnetic stripe standard. Let's go and have a look at what this
1737510	1746610	says. After the tag is the length this is two and after the length is the two bytes that make up the
1746610	1752830	content. From the specification we know that this is binary coded decimal. We know it is three digits
1752830	1760090	long and with binary coded decimal it's left padded with zero so we ignore the first zero and we get
1760090	1768110	201. Let's look at what this actually means. The first digit is two and this says that this is
1768110	1776210	suitable for international transactions and it has a chip. This service code on the magnetic stripe
1776210	1783230	is how terminals know that this card should have a chip if you swipe the magnetic stripe. That's why
1783230	1790290	if you try that the terminal will say please use chip. Next digit is zero which says that it can
1790290	1796750	be authorized in normal ways and the final digit is one which says that it can be used with or
1796750	1807070	without pin and it can also be used for any type of transaction. Next let's look at offset 57 where
1807070	1815310	we've got actually tag 57 by coincidence. This is the track 2 equivalent data. This is a copy
1815310	1823250	of the track 2 of the magnetic stripe on the back of the card. It's there to allow the terminal to
1823250	1829650	process a chip transaction as if it is mag stripe. Maybe it's because the network isn't able to
1829650	1836270	process chip transaction or maybe the issuer has not yet upgraded their systems. So the terminal
1836270	1842770	has all the information necessary to put together a copy of track 1 and track 2 of the magnetic
1842770	1849290	stripe. For track 1 the terminal needs to take data items like the account number and the card
1849290	1855290	or name and so on and then put that together. For track 2 there's actually a complete copy of track
1855290	1860130	2 in one of these data fields and that's what you're seeing here. So we can look what this
1860130	1869330	looks like. The start sentinel was missed out but then the next is the account number 16 binary
1869330	1875650	coded decimal digits. Here I've masked out the middle of the digits because I've had too many
1875650	1879870	conversations with my bank to say I needed a new card because my card number has been shown on
1879870	1885510	television even though this card actually was cancelled quite a while ago. Then the separator
1885510	1891010	normally this would be equal on track 2 but you can't do equal in binary coded decimal so they
1891010	1901670	use d. Next is the expiry date so this is December 2015 so 1512. Then there's a service code which
1901670	1907910	we've seen before 201. And finally there's the discretionary data. This varies between the
1907910	1914170	issuer but most of them follow a similar process so we can guess what it actually means. The first
1915050	1922670	five digits is the pin verification value. This is used for verifying whether a pin is correct
1922670	1929830	without the card actually talking to the bank which knows the pin. This made sense when a lot
1929830	1934690	of ATMs were not connected to any network. Nowadays it's obviously it's probably not used
1934690	1942430	but it's still there. The first digit one which is the index for the key that is used for
1942430	1949550	encrypting the PVV and then the rest which is 4079 is the PVV itself.
1950210	1959470	After the PVV is the CVV car verification value and this is 927. This was a security feature
1959470	1966730	introduced on magnetic stripe cards to help the bank detect whether a card is fake or not.
1967170	1971290	A type of fraud that was happening quite frequently is people were getting
1971290	1977590	card numbers and expiry dates and creating cloned magnetic stripe cards. The way that this was fixed
1977590	1985350	is the CVV was written onto the magnetic stripe and it allowed the bank to see whether this is
1985810	1992230	a genuine card or whether it was a card created with a copy of the account number and the expiry
1992230	1999310	date that was obtained from a receipt perhaps. Now this actually creates a problem when chip
1999310	2004970	transactions came along because if there was a copy of the CVV on the chip it meant someone who
2004970	2010050	had data from the chip could then create a mag stripe and then completely bypass all the extra
2010050	2017750	security features of the chip transaction. Eventually this got fixed round about in 2008
2018270	2025290	where there was a different CVV that was copied onto the chip compared to the copy of the CVV
2025290	2030310	which was on the mag stripe and that meant that in principle card issuers could tell the difference
2030310	2036510	between a genuine mag stripe transaction and a mag stripe transaction that was made using
2036510	2042630	chip data. Now it turned out that that didn't actually work out as well as hoped because what
2042630	2049410	we've found out from some recent research from Leanne Galloway is that issuers are accepting
2049410	2057070	transactions as mag stripe transactions even though the CVV is incorrect because the CVV
2057070	2062910	was taken from the chip and not actually from the mag stripe. So I've tried to give you an overview
2062910	2071270	of some of the issues involved in decoding TLV. You can see it's not easy to get right. There's
2071270	2077230	different encodings used for different purposes in different contexts and even if you're using
2077230	2083030	the right decoding format then there's lots of ways that things can go wrong. For example we've
2083030	2090450	seen that tags can be almost indefinite lengths. It's very easy to encode extremely long lengths
2090450	2097950	because you can say that I'm now going to send eight further bytes of length and then have
2098590	2104270	massive lengths that are then processed by the TLV decoder and that could cause memory overflow
2104270	2111170	or memory underflow errors. Because of all the ways that things go wrong, mistakes do happen
2111170	2117730	and this not only has problems from mistakes but problems occur from the consequences of those
2117730	2126350	mistakes. What I mean is that issuers who are banks sending out cards know that sometimes things will
2126350	2131290	go wrong because of all these complexities of EMV and they will accept transactions even though
2131290	2137670	something has gone wrong. Now more often than not that's not fraud it's just someone has made a
2137670	2144350	mistake with encoding or decoding some data but sometimes it will be fraud and this complexity
2144350	2150950	leading to mistakes and then leading to being very forgiving about errors actually makes the
2150950	2159070	EMV system more vulnerable to fraud than it would be otherwise. So maybe you'd like to try to do this
2159070	2165530	yourself. It's quite an interesting experience. There might be some specific need why you might
2165530	2171290	have to do this but it's often very instructive to try to do something yourself even though you
2171290	2176770	can get some code out there already. One of my colleagues Mike Bond said the only way to
2176770	2182670	understand the wheel is to reinvent it and when I've been writing TLV decoders and other aspects
2182670	2190150	of the EMV infrastructure that's helped me understand where I've slipped up and if I slipped
2190150	2194730	up then there's a reasonable chance that someone else might slip up and that's been a very fruitful
2194730	2202390	source of vulnerabilities in terms of my research. But if you don't want to do all the decoding
2202390	2210830	yourself I've written a TLV decoder on the emvlab.org website where you can try this out.
2210830	2215070	Here is the decoding of the data I've been talking about in this talk.
2215070	2221670	So you can see that the cdol1 and cdol2 are there first. There's some data I didn't talk
2221670	2228450	about in this talk. The application version number and the currency code, currency code exponent,
2228450	2235490	and the ddol and the ICC public key. But you can also see the track two equivalent data is there,
2235490	2242850	service code, the track one discretionary data which is necessary for formatting track one if
2242850	2248430	you're going to make a magstripe transaction using the chip data. So that stuff is all there.
2248430	2252890	This is just one of several records that are stored by the card. There's a lot more out there.
2252890	2257790	If you want to try for yourself then get a smart card reader, try out Cardpeak and then see what
2257790	2264310	you can find. So there's more information about me and my research on my website and if you're
2264310	2269770	interested in updates from our research group then have a look at our blog on Bentham's Gates.