<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Chip and skim 2</title>
	<atom:link href="http://www.lightbluetouchpaper.org/2006/06/12/chip-and-skim-2/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.lightbluetouchpaper.org/2006/06/12/chip-and-skim-2/</link>
	<description>Security Research, Computer Laboratory, University of Cambridge</description>
	<lastBuildDate>Sat, 28 Jan 2012 18:43:15 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Steven J. Murdoch</title>
		<link>http://www.lightbluetouchpaper.org/2006/06/12/chip-and-skim-2/comment-page-1/#comment-2151</link>
		<dc:creator>Steven J. Murdoch</dc:creator>
		<pubDate>Tue, 26 Sep 2006 22:25:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/2006/06/12/chip-and-skim-2/#comment-2151</guid>
		<description>@Boris

&lt;blockquote&gt;The CVV on the chip should be CVV3 which is rather different from CVV1.&lt;/blockquote&gt;

Perhaps it should be, but that is not what the banks in the UK have done. All the cards we have looked at use the same CVV on the magstripe as they do in the &quot;Track 2 equivalent data&quot; field on the chip.

The card which the ITV team sucessfully used to withdraw money had a magstripe generated from the original card&#039;s chip data. 

Which banks have you found whose cards have a different CVV on the chip?</description>
		<content:encoded><![CDATA[<p>@Boris</p>
<blockquote><p>The CVV on the chip should be CVV3 which is rather different from CVV1.</p></blockquote>
<p>Perhaps it should be, but that is not what the banks in the UK have done. All the cards we have looked at use the same CVV on the magstripe as they do in the &#8220;Track 2 equivalent data&#8221; field on the chip.</p>
<p>The card which the ITV team sucessfully used to withdraw money had a magstripe generated from the original card&#8217;s chip data. </p>
<p>Which banks have you found whose cards have a different CVV on the chip?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Boris</title>
		<link>http://www.lightbluetouchpaper.org/2006/06/12/chip-and-skim-2/comment-page-1/#comment-2150</link>
		<dc:creator>Boris</dc:creator>
		<pubDate>Tue, 26 Sep 2006 22:16:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/2006/06/12/chip-and-skim-2/#comment-2150</guid>
		<description>&quot;Even the CVV1, the code used to verify that a magstripe is valid, is on the chip (but not the CVV2, which is the 3 digit code printed on the back, used by ecommerce).&quot;

This is not the case. The CVV on the chip should be CVV3 which is rather different from CVV1.

In fact, this is the protection that should be in place in order to prevent one from getting to know the magstripe data (including CVV) just by listening to the communication between the terminal and the chip.</description>
		<content:encoded><![CDATA[<p>&#8220;Even the CVV1, the code used to verify that a magstripe is valid, is on the chip (but not the CVV2, which is the 3 digit code printed on the back, used by ecommerce).&#8221;</p>
<p>This is not the case. The CVV on the chip should be CVV3 which is rather different from CVV1.</p>
<p>In fact, this is the protection that should be in place in order to prevent one from getting to know the magstripe data (including CVV) just by listening to the communication between the terminal and the chip.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: BUSLab&#8217;s Swordfish &#187; Bankovní bezpečnost na Light Blue Touch Paper</title>
		<link>http://www.lightbluetouchpaper.org/2006/06/12/chip-and-skim-2/comment-page-1/#comment-602</link>
		<dc:creator>BUSLab&#8217;s Swordfish &#187; Bankovní bezpečnost na Light Blue Touch Paper</dc:creator>
		<pubDate>Fri, 23 Jun 2006 06:27:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/2006/06/12/chip-and-skim-2/#comment-602</guid>
		<description>[...] Chip and skim 2 – popisuje jakých bezpečnostních slabin může být využito při vykrádání účtů pomocí falešných kreditních karet [...]</description>
		<content:encoded><![CDATA[<p>[...] Chip and skim 2 – popisuje jakých bezpečnostních slabin může být využito při vykrádání účtů pomocí falešných kreditních karet [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: TillMonkey</title>
		<link>http://www.lightbluetouchpaper.org/2006/06/12/chip-and-skim-2/comment-page-1/#comment-595</link>
		<dc:creator>TillMonkey</dc:creator>
		<pubDate>Mon, 19 Jun 2006 15:36:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/2006/06/12/chip-and-skim-2/#comment-595</guid>
		<description>&quot;Communications are
nowadays avaliable, cheap and fast&quot;

Agreed but they are also, crucially, not very reliable unless you pay heavily for it; which retailers are always reluctant to do (especially given the fact that the cost is multiplied by the number of stores they operate)

Add to that the stores which will inevitably be too far away from the exchange for even cheap xDSL connectivity (petrol stations, ironically enough, are the classic example here) and, as Mike says, it becomes very difficult to assume &quot;online&quot; as the default scenario.</description>
		<content:encoded><![CDATA[<p>&#8220;Communications are<br />
nowadays avaliable, cheap and fast&#8221;</p>
<p>Agreed but they are also, crucially, not very reliable unless you pay heavily for it; which retailers are always reluctant to do (especially given the fact that the cost is multiplied by the number of stores they operate)</p>
<p>Add to that the stores which will inevitably be too far away from the exchange for even cheap xDSL connectivity (petrol stations, ironically enough, are the classic example here) and, as Mike says, it becomes very difficult to assume &#8220;online&#8221; as the default scenario.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Bond</title>
		<link>http://www.lightbluetouchpaper.org/2006/06/12/chip-and-skim-2/comment-page-1/#comment-594</link>
		<dc:creator>Mike Bond</dc:creator>
		<pubDate>Mon, 19 Jun 2006 10:35:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/2006/06/12/chip-and-skim-2/#comment-594</guid>
		<description>&lt;b&gt;JR,&lt;/b&gt;

&lt;i&gt;&gt;Not exactly “adversary”.&lt;/i&gt;

Don&#039;t get me wrong, I&#039;m not saying the default relationship between customer and bank is adversarial. But if you happen to be in &lt;b&gt;dispute&lt;/b&gt;, an assumption I explicitly made in the post, I would say that this is by its very nature an adversarial relationship.

&lt;i&gt;&gt;I consider SDA and DDA marginal. Comminications are
&gt;nowadays avaliable, cheap and fast. Go online. &lt;/i&gt;

Yes I agree that in today&#039;s connected world offline should become less and less common. But I think security for offline operation will remain important even if it becomes a rare occurrence, because despite the good connectivity of today, guarantees of availability are hard to come by.

Suppose the authorisation requests from a big department store are routed via the internet to the acquirer (through all sorts of encrypted tunnels and VPNs). Now imagine a DDoS attack gets aimed at their gateway, and they lose their connectivity. That afternoon, a troop of crims with SDA &#039;Yes cards&#039; go in and start ripping the place off. The store would lose even more business if it shut, so it daren&#039;t do that.

Now in that situation there is a clear advantage to DDA. Not saying this is an imminent mode of attack, but just that there is a different between &lt;i&gt;having&lt;/i&gt; connectivity to improve security and &lt;i&gt;assuming&lt;/i&gt; connectivity to improve security.

Mike.</description>
		<content:encoded><![CDATA[<p><b>JR,</b></p>
<p><i>&gt;Not exactly “adversary”.</i></p>
<p>Don&#8217;t get me wrong, I&#8217;m not saying the default relationship between customer and bank is adversarial. But if you happen to be in <b>dispute</b>, an assumption I explicitly made in the post, I would say that this is by its very nature an adversarial relationship.</p>
<p><i>&gt;I consider SDA and DDA marginal. Comminications are<br />
&gt;nowadays avaliable, cheap and fast. Go online. </i></p>
<p>Yes I agree that in today&#8217;s connected world offline should become less and less common. But I think security for offline operation will remain important even if it becomes a rare occurrence, because despite the good connectivity of today, guarantees of availability are hard to come by.</p>
<p>Suppose the authorisation requests from a big department store are routed via the internet to the acquirer (through all sorts of encrypted tunnels and VPNs). Now imagine a DDoS attack gets aimed at their gateway, and they lose their connectivity. That afternoon, a troop of crims with SDA &#8216;Yes cards&#8217; go in and start ripping the place off. The store would lose even more business if it shut, so it daren&#8217;t do that.</p>
<p>Now in that situation there is a clear advantage to DDA. Not saying this is an imminent mode of attack, but just that there is a different between <i>having</i> connectivity to improve security and <i>assuming</i> connectivity to improve security.</p>
<p>Mike.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: JR</title>
		<link>http://www.lightbluetouchpaper.org/2006/06/12/chip-and-skim-2/comment-page-1/#comment-593</link>
		<dc:creator>JR</dc:creator>
		<pubDate>Fri, 16 Jun 2006 12:02:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/2006/06/12/chip-and-skim-2/#comment-593</guid>
		<description>&lt;blockquote cite=&quot;&quot;&gt;
&gt;The Application Cryptogram shows that the genuine card was
&gt;not used. The customer is off the hook. 

Sadly the application cryptogram can only be verified by the bank — it’s symmetric cryptography based and they obviously can’t lend out the key. So this provides no assurance for the customer if it is the bank they are in dispute with — only their adversary can let them off the hook.
&lt;/blockquote&gt; 

Not exactly &quot;adversary&quot;.

The AC is verified by the issuer bank, whereas the money is claimed by the acquirer bank. 

Even when it is the same bank, I find it hard to believe they would actually cheat.

Anyhow, offline transactions are decreasing in number and are in any case limited to relatively small amounts. I consider SDA and DDA marginal. Comminications are nowadays avaliable, cheap and fast. Go online.</description>
		<content:encoded><![CDATA[<blockquote cite=""><p>
&gt;The Application Cryptogram shows that the genuine card was<br />
&gt;not used. The customer is off the hook. </p>
<p>Sadly the application cryptogram can only be verified by the bank — it’s symmetric cryptography based and they obviously can’t lend out the key. So this provides no assurance for the customer if it is the bank they are in dispute with — only their adversary can let them off the hook.
</p></blockquote>
<p>Not exactly &#8220;adversary&#8221;.</p>
<p>The AC is verified by the issuer bank, whereas the money is claimed by the acquirer bank. </p>
<p>Even when it is the same bank, I find it hard to believe they would actually cheat.</p>
<p>Anyhow, offline transactions are decreasing in number and are in any case limited to relatively small amounts. I consider SDA and DDA marginal. Comminications are nowadays avaliable, cheap and fast. Go online.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Bond</title>
		<link>http://www.lightbluetouchpaper.org/2006/06/12/chip-and-skim-2/comment-page-1/#comment-592</link>
		<dc:creator>Mike Bond</dc:creator>
		<pubDate>Fri, 16 Jun 2006 09:39:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/2006/06/12/chip-and-skim-2/#comment-592</guid>
		<description>A couple of thoughts from me...

&lt;b&gt;Steven&lt;/b&gt;, I think forcing multiple PINs is probably untenable long term. Basically at the end of the day, when you consider going across totally heterogeneous systems operated by different parties, there&#039;s no way you can enforce that people use different passwords for each. So why try to have it in banking? It&#039;s a battle you can&#039;t win long term. When Mastercard CAP comes for internet banking, it would be really nice to have a different PIN for that as for POS payment, to get separation between the systems, but then thats a third contender... 

With regards to the relay attack, &lt;b&gt;TillMonkey&lt;/b&gt; and &lt;b&gt;Jon&lt;/b&gt; discuss whether various foreign devices inserted into POS terminals are concealable or practical.

We must consider here, first and foremost the incentives of the involved parties to detect such devices, their possible tacit and explicit collusion, and what rewards or benefits there might be from them doing their part. The standard of concealment actually attainable I believe is a second priority, and I think this is a question where many of us can do little more than speculate.

Steven&#039;s analogy of the children&#039;s magician is maybe a little tame... magicians may be great at making rabbits appear from inside their coats, but a more relevant sleight of hand is that of the shoplifter, who does the same sort of trick, except in reverse.

I think that the relay attack &lt;i&gt;is&lt;/i&gt; doable, it will end up as a real threat; it is the attachable interceptor that we prototyped that will have the limited lifespan. It may well work for a while, but once DDA cards come in and the PIN goes in encrypted form, it will no longer become an economical attack method. By this I don&#039;t mean that POS attacks will stop, just that this specific POS attack vector will become obsolete. Then it will probably be cheaper to use whole counterfeit terminals, maybe. Or maybe go back to double-swiping and hidden camera... after all, that&#039;s proven technology.

&lt;b&gt;Jon&lt;/b&gt;, I think this shows that security evaluation standards are an imperfect tool. Standards have so many problems, especially when many players only buy kit that conforms to a standard because of regulatory body requirements, or suchlike. I have never gone out to buy a fluffly toy for my kid and looked for the &quot;CE&quot; mark on the bottom; the presence of such a mark only comes into play when things go wrong and it&#039;s litigation time. Its such a complicated multi-way relationship between POS terminal manufacturers, till software integrators, merchants, acquiring banks and issuing banks that its very difficult to tell who relies upon a security evaluation, who comissioned the evaluation, and who wrote the standard. The chances of the economic incentives of all these parties being properly aligned is slim, I guess, so problems persist.</description>
		<content:encoded><![CDATA[<p>A couple of thoughts from me&#8230;</p>
<p><b>Steven</b>, I think forcing multiple PINs is probably untenable long term. Basically at the end of the day, when you consider going across totally heterogeneous systems operated by different parties, there&#8217;s no way you can enforce that people use different passwords for each. So why try to have it in banking? It&#8217;s a battle you can&#8217;t win long term. When Mastercard CAP comes for internet banking, it would be really nice to have a different PIN for that as for POS payment, to get separation between the systems, but then thats a third contender&#8230; </p>
<p>With regards to the relay attack, <b>TillMonkey</b> and <b>Jon</b> discuss whether various foreign devices inserted into POS terminals are concealable or practical.</p>
<p>We must consider here, first and foremost the incentives of the involved parties to detect such devices, their possible tacit and explicit collusion, and what rewards or benefits there might be from them doing their part. The standard of concealment actually attainable I believe is a second priority, and I think this is a question where many of us can do little more than speculate.</p>
<p>Steven&#8217;s analogy of the children&#8217;s magician is maybe a little tame&#8230; magicians may be great at making rabbits appear from inside their coats, but a more relevant sleight of hand is that of the shoplifter, who does the same sort of trick, except in reverse.</p>
<p>I think that the relay attack <i>is</i> doable, it will end up as a real threat; it is the attachable interceptor that we prototyped that will have the limited lifespan. It may well work for a while, but once DDA cards come in and the PIN goes in encrypted form, it will no longer become an economical attack method. By this I don&#8217;t mean that POS attacks will stop, just that this specific POS attack vector will become obsolete. Then it will probably be cheaper to use whole counterfeit terminals, maybe. Or maybe go back to double-swiping and hidden camera&#8230; after all, that&#8217;s proven technology.</p>
<p><b>Jon</b>, I think this shows that security evaluation standards are an imperfect tool. Standards have so many problems, especially when many players only buy kit that conforms to a standard because of regulatory body requirements, or suchlike. I have never gone out to buy a fluffly toy for my kid and looked for the &#8220;CE&#8221; mark on the bottom; the presence of such a mark only comes into play when things go wrong and it&#8217;s litigation time. Its such a complicated multi-way relationship between POS terminal manufacturers, till software integrators, merchants, acquiring banks and issuing banks that its very difficult to tell who relies upon a security evaluation, who comissioned the evaluation, and who wrote the standard. The chances of the economic incentives of all these parties being properly aligned is slim, I guess, so problems persist.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jon</title>
		<link>http://www.lightbluetouchpaper.org/2006/06/12/chip-and-skim-2/comment-page-1/#comment-591</link>
		<dc:creator>Jon</dc:creator>
		<pubDate>Fri, 16 Jun 2006 06:42:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/2006/06/12/chip-and-skim-2/#comment-591</guid>
		<description>One of the problems with this story and how it has been reported is that it makes blanket statements with regards to the security of POS terminals. This type of attack has been known for some time and in a well designed POS terminal it is rather difficult to insert an interceptor that would not be visible upon examining the terminal (e.g. by a shop keeper). 

The majority of POS terminals in use must undergo security evaluations, which look for such vulnerabilities. It would be interesting to determine if these evaluations are effective in weeding out badly designed terminals. The recent shell case calls this into question as the trintech terminal was evaluated under Visa PED, ZKA and perhaps “APACS Common Criteria”.

I do however agree that these “issues” are brought to light so that banks cannot claim that chip and pin offers perfect security.</description>
		<content:encoded><![CDATA[<p>One of the problems with this story and how it has been reported is that it makes blanket statements with regards to the security of POS terminals. This type of attack has been known for some time and in a well designed POS terminal it is rather difficult to insert an interceptor that would not be visible upon examining the terminal (e.g. by a shop keeper). </p>
<p>The majority of POS terminals in use must undergo security evaluations, which look for such vulnerabilities. It would be interesting to determine if these evaluations are effective in weeding out badly designed terminals. The recent shell case calls this into question as the trintech terminal was evaluated under Visa PED, ZKA and perhaps “APACS Common Criteria”.</p>
<p>I do however agree that these “issues” are brought to light so that banks cannot claim that chip and pin offers perfect security.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steven J. Murdoch</title>
		<link>http://www.lightbluetouchpaper.org/2006/06/12/chip-and-skim-2/comment-page-1/#comment-587</link>
		<dc:creator>Steven J. Murdoch</dc:creator>
		<pubDate>Thu, 15 Jun 2006 10:02:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/2006/06/12/chip-and-skim-2/#comment-587</guid>
		<description>@TillMonkey

&lt;blockquote&gt;
It sounds like it would actually mean a green plastic “card” covered in soldered contacts with wires leading into bad guys’ pocket being used at the target POS?
&lt;/blockquote&gt;

There are already contactless smartcards available, so producing a wireless relay is clearly technically feasible. The open question is whether it is possible to make with readily available components. Fabricating a special purpose IC is not inconceivable for crooks (e.g. modchips), but might make this attack uneconomical.

Even if wires are needed, in a previous case I heard of, the crook melted fine wires into the body of a real card. Where the card is not handled by the shop staff, I think the sleight of hand required to pull this off is well below the standard of your average children&#039;s party magician. In some places I have seen, the terminal is on the customer’s side of a screen, making it even easier.</description>
		<content:encoded><![CDATA[<p>@TillMonkey</p>
<blockquote><p>
It sounds like it would actually mean a green plastic “card” covered in soldered contacts with wires leading into bad guys’ pocket being used at the target POS?
</p></blockquote>
<p>There are already contactless smartcards available, so producing a wireless relay is clearly technically feasible. The open question is whether it is possible to make with readily available components. Fabricating a special purpose IC is not inconceivable for crooks (e.g. modchips), but might make this attack uneconomical.</p>
<p>Even if wires are needed, in a previous case I heard of, the crook melted fine wires into the body of a real card. Where the card is not handled by the shop staff, I think the sleight of hand required to pull this off is well below the standard of your average children&#8217;s party magician. In some places I have seen, the terminal is on the customer’s side of a screen, making it even easier.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: TillMonkey</title>
		<link>http://www.lightbluetouchpaper.org/2006/06/12/chip-and-skim-2/comment-page-1/#comment-586</link>
		<dc:creator>TillMonkey</dc:creator>
		<pubDate>Thu, 15 Jun 2006 09:33:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/2006/06/12/chip-and-skim-2/#comment-586</guid>
		<description>Sorry, responding to various points from different posts.....

&lt;blockquote&gt;Having different cards or PINs for ATMs, Chip &amp; PIN and use abroad would also improve security.&lt;/blockquote&gt;

A good idea but it&#039;s back to consumer acceptance I&#039;m afraid: it&#039;s been difficult enough to get people to start using PINs at all. Telling them they also need different ones for the same debit/ATM multifunction card would&#039;ve been a marketing non-starter (and, for good or ill, the the marketers will always win.....)

&lt;blockquote&gt;P.S. While we’re talking about DDA, remember real-time relay attacks are still on the cards. &lt;/blockquote&gt;

I may be missing a point but wouldn&#039;t a &quot;real world&quot; relay attack just be practically impossible? It sounds like it would actually mean a green plastic &quot;card&quot; covered in soldered contacts with wires leading into bad guys&#039; pocket being used at the target POS? I know shop staff have cheerfully watched people signing &quot;Donald Duck&quot; for years but this would require a degree of negligence/collusion that would would be impossible to explain away come chargeback time....??</description>
		<content:encoded><![CDATA[<p>Sorry, responding to various points from different posts&#8230;..</p>
<blockquote><p>Having different cards or PINs for ATMs, Chip &amp; PIN and use abroad would also improve security.</p></blockquote>
<p>A good idea but it&#8217;s back to consumer acceptance I&#8217;m afraid: it&#8217;s been difficult enough to get people to start using PINs at all. Telling them they also need different ones for the same debit/ATM multifunction card would&#8217;ve been a marketing non-starter (and, for good or ill, the the marketers will always win&#8230;..)</p>
<blockquote><p>P.S. While we’re talking about DDA, remember real-time relay attacks are still on the cards. </p></blockquote>
<p>I may be missing a point but wouldn&#8217;t a &#8220;real world&#8221; relay attack just be practically impossible? It sounds like it would actually mean a green plastic &#8220;card&#8221; covered in soldered contacts with wires leading into bad guys&#8217; pocket being used at the target POS? I know shop staff have cheerfully watched people signing &#8220;Donald Duck&#8221; for years but this would require a degree of negligence/collusion that would would be impossible to explain away come chargeback time&#8230;.??</p>
]]></content:encoded>
	</item>
</channel>
</rss>

