<?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"
	>
<channel>
	<title>Comments on: Justice, in one case at least</title>
	<atom:link href="http://www.lightbluetouchpaper.org/2008/01/31/justice-in-one-case-at-least/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.lightbluetouchpaper.org/2008/01/31/justice-in-one-case-at-least/</link>
	<description>Security Research, Computer Laboratory, University of Cambridge</description>
	<pubDate>Sat, 17 May 2008 18:18:09 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: bingham</title>
		<link>http://www.lightbluetouchpaper.org/2008/01/31/justice-in-one-case-at-least/#comment-28998</link>
		<dc:creator>bingham</dc:creator>
		<pubDate>Tue, 15 Apr 2008 14:11:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/2008/01/31/justice-in-one-case-at-least/#comment-28998</guid>
		<description>Following on from the Natiowinde thread, we have two members of our family who have had 1800 each taken from their accounts
in the last month.
Having had numerous conversations with the branch it would appear they just pass the ball to their 'special investigation' units and hope that they do the necessary.  It would be interesting to learn how much their exposure to this is at the moment.</description>
		<content:encoded><![CDATA[<p>Following on from the Natiowinde thread, we have two members of our family who have had 1800 each taken from their accounts<br />
in the last month.<br />
Having had numerous conversations with the branch it would appear they just pass the ball to their &#8217;special investigation&#8217; units and hope that they do the necessary.  It would be interesting to learn how much their exposure to this is at the moment.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: O B</title>
		<link>http://www.lightbluetouchpaper.org/2008/01/31/justice-in-one-case-at-least/#comment-28764</link>
		<dc:creator>O B</dc:creator>
		<pubDate>Fri, 04 Apr 2008 20:29:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/2008/01/31/justice-in-one-case-at-least/#comment-28764</guid>
		<description>This is the link to the whole story:

http://forums.moneysavingexpert.com/showthread.html?t=839107</description>
		<content:encoded><![CDATA[<p>This is the link to the whole story:</p>
<p><a href="http://forums.moneysavingexpert.com/showthread.html?t=839107" rel="nofollow">http://forums.moneysavingexpert.com/showthread.html?t=839107</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: O B</title>
		<link>http://www.lightbluetouchpaper.org/2008/01/31/justice-in-one-case-at-least/#comment-28763</link>
		<dc:creator>O B</dc:creator>
		<pubDate>Fri, 04 Apr 2008 20:25:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/2008/01/31/justice-in-one-case-at-least/#comment-28763</guid>
		<description>FOund this blog when looking for information on CVV Transaction Data. I am helping a friend to sort out a ATM discrepancy. The bank has produced a number of copies from their investigation, but they have little meaning to us. IF someone here is intersted in this, or think you could be of some help, please contact me (email address provided).

I would also be interested in talking with Pete Austin to posted above as this is the same bank (Nationwide), which although I find very forthcoming in its branch, has not really produced results on this particular investigation we are looking in right now.
Read more in the URL (or if that does not work, I will copy the post to here - if allowed)</description>
		<content:encoded><![CDATA[<p>FOund this blog when looking for information on CVV Transaction Data. I am helping a friend to sort out a ATM discrepancy. The bank has produced a number of copies from their investigation, but they have little meaning to us. IF someone here is intersted in this, or think you could be of some help, please contact me (email address provided).</p>
<p>I would also be interested in talking with Pete Austin to posted above as this is the same bank (Nationwide), which although I find very forthcoming in its branch, has not really produced results on this particular investigation we are looking in right now.<br />
Read more in the URL (or if that does not work, I will copy the post to here - if allowed)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pete Austin</title>
		<link>http://www.lightbluetouchpaper.org/2008/01/31/justice-in-one-case-at-least/#comment-28614</link>
		<dc:creator>Pete Austin</dc:creator>
		<pubDate>Sun, 30 Mar 2008 16:48:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/2008/01/31/justice-in-one-case-at-least/#comment-28614</guid>
		<description>&#62;&#62; February 6th, 2008 at 20:01 UTC
Follow-up to my comment. Between 28-30 March 2008 I've lost about £1,100 to ATM fraud. I'm paranoid about security, only ever using two specific ATMs, only during daylight hours, so I would expect to notice any skimmer. I still have my card. My PIN has never been written down. Either someone guessed my account+pin, or the the Link database has a leak, or there's something like an invisible "in-slot" skimmer out there. I wonder whether Nationwide will admit one of these unlikely-sounding scenarios, or just claim I'm a fraudster.</description>
		<content:encoded><![CDATA[<p>&gt;&gt; February 6th, 2008 at 20:01 UTC<br />
Follow-up to my comment. Between 28-30 March 2008 I&#8217;ve lost about £1,100 to ATM fraud. I&#8217;m paranoid about security, only ever using two specific ATMs, only during daylight hours, so I would expect to notice any skimmer. I still have my card. My PIN has never been written down. Either someone guessed my account+pin, or the the Link database has a leak, or there&#8217;s something like an invisible &#8220;in-slot&#8221; skimmer out there. I wonder whether Nationwide will admit one of these unlikely-sounding scenarios, or just claim I&#8217;m a fraudster.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ian</title>
		<link>http://www.lightbluetouchpaper.org/2008/01/31/justice-in-one-case-at-least/#comment-28014</link>
		<dc:creator>Ian</dc:creator>
		<pubDate>Fri, 15 Feb 2008 14:24:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/2008/01/31/justice-in-one-case-at-least/#comment-28014</guid>
		<description>Correction to the above, in the second paragraph, I meant to say "where the card was initially read using the magstripe".</description>
		<content:encoded><![CDATA[<p>Correction to the above, in the second paragraph, I meant to say &#8220;where the card was initially read using the magstripe&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ian</title>
		<link>http://www.lightbluetouchpaper.org/2008/01/31/justice-in-one-case-at-least/#comment-28013</link>
		<dc:creator>Ian</dc:creator>
		<pubDate>Fri, 15 Feb 2008 14:22:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/2008/01/31/justice-in-one-case-at-least/#comment-28013</guid>
		<description>EFT message protocols use the PAN Entry Mode field to distinguish between different ways of capturing the card number and other details.  If the magstripe was read and all of its data is available in the transaction message, the PAN entry mode field (defining how the card was read) is set to '90'.  This means something like 'magstripe - CVV data reliable' and indicates that the CVV data in the magstripe can be checked by the bank. It does not indicate that the CVV has been checked - the message hasn't reached the bank yet and the terminal can't check the CVV.

Some transaction messages might not contain reliable CVV data, e.g. if they came via a network that did not transmit the full magstripe data, or perhaps (I'm guessing a bit here) for a recurring payment where the card was initially read manually, but the CVV part of the magstripe was not stored for security reasons.  Systems like this might then 'fake' the CVV part of the magstripe and indicate a mode of '02', defined as 'magstripe read, CVV data unreliable'. It doesn't mean that the CVV failed validation.

By analogy with this, 05 means the chip was read, and the CVV data that the message contains was not faked by the network, i.e. it can be checked by the bank. It doesn't mean the CVV has been checked.  For a chip transaction, other transaction data in the message will indicate whether the PIN was entered correctly and so on.

By further analogy there is sometimes a PAN entry mode of '95' defined to mean 'chip read, CVV data unreliable'. I don't know if this value is ever used. Maybe on networks that only have partial support for chip and PIN.</description>
		<content:encoded><![CDATA[<p>EFT message protocols use the PAN Entry Mode field to distinguish between different ways of capturing the card number and other details.  If the magstripe was read and all of its data is available in the transaction message, the PAN entry mode field (defining how the card was read) is set to &#8216;90&#8242;.  This means something like &#8216;magstripe - CVV data reliable&#8217; and indicates that the CVV data in the magstripe can be checked by the bank. It does not indicate that the CVV has been checked - the message hasn&#8217;t reached the bank yet and the terminal can&#8217;t check the CVV.</p>
<p>Some transaction messages might not contain reliable CVV data, e.g. if they came via a network that did not transmit the full magstripe data, or perhaps (I&#8217;m guessing a bit here) for a recurring payment where the card was initially read manually, but the CVV part of the magstripe was not stored for security reasons.  Systems like this might then &#8216;fake&#8217; the CVV part of the magstripe and indicate a mode of &#8216;02&#8242;, defined as &#8216;magstripe read, CVV data unreliable&#8217;. It doesn&#8217;t mean that the CVV failed validation.</p>
<p>By analogy with this, 05 means the chip was read, and the CVV data that the message contains was not faked by the network, i.e. it can be checked by the bank. It doesn&#8217;t mean the CVV has been checked.  For a chip transaction, other transaction data in the message will indicate whether the PIN was entered correctly and so on.</p>
<p>By further analogy there is sometimes a PAN entry mode of &#8216;95&#8242; defined to mean &#8216;chip read, CVV data unreliable&#8217;. I don&#8217;t know if this value is ever used. Maybe on networks that only have partial support for chip and PIN.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob</title>
		<link>http://www.lightbluetouchpaper.org/2008/01/31/justice-in-one-case-at-least/#comment-27895</link>
		<dc:creator>Rob</dc:creator>
		<pubDate>Thu, 07 Feb 2008 14:28:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/2008/01/31/justice-in-one-case-at-least/#comment-27895</guid>
		<description>It seems that there may be a parallel with car theft and supposedly "theft proof" transponders. I stumbled across this story via /.

http://www.wired.com/wired/archive/14.08/carkey.html

But the transponder system was intact. The car could have been shifted and steered, the investigator concluded, but the engine couldn’t have been turned on. “Since you reportedly can account for all the vehicle keys, the forensic information suggests that the loss did not occur as reported,” the company wrote to Wassef, denying his claim. The barely hidden subtext: Wassef was lying.</description>
		<content:encoded><![CDATA[<p>It seems that there may be a parallel with car theft and supposedly &#8220;theft proof&#8221; transponders. I stumbled across this story via /.</p>
<p><a href="http://www.wired.com/wired/archive/14.08/carkey.html" rel="nofollow">http://www.wired.com/wired/archive/14.08/carkey.html</a></p>
<p>But the transponder system was intact. The car could have been shifted and steered, the investigator concluded, but the engine couldn’t have been turned on. “Since you reportedly can account for all the vehicle keys, the forensic information suggests that the loss did not occur as reported,” the company wrote to Wassef, denying his claim. The barely hidden subtext: Wassef was lying.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pete Austin</title>
		<link>http://www.lightbluetouchpaper.org/2008/01/31/justice-in-one-case-at-least/#comment-27889</link>
		<dc:creator>Pete Austin</dc:creator>
		<pubDate>Wed, 06 Feb 2008 20:01:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/2008/01/31/justice-in-one-case-at-least/#comment-27889</guid>
		<description>In "Integrated Circuit Card read", the word "read" is ambiguous.

I often read the dictionary on my desk, but I have not read it. That would take far too long. 

Similarly an ATM might read a chip without reading the data it contains. For example because of errors.</description>
		<content:encoded><![CDATA[<p>In &#8220;Integrated Circuit Card read&#8221;, the word &#8220;read&#8221; is ambiguous.</p>
<p>I often read the dictionary on my desk, but I have not read it. That would take far too long. </p>
<p>Similarly an ATM might read a chip without reading the data it contains. For example because of errors.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Barry</title>
		<link>http://www.lightbluetouchpaper.org/2008/01/31/justice-in-one-case-at-least/#comment-27861</link>
		<dc:creator>Barry</dc:creator>
		<pubDate>Mon, 04 Feb 2008 11:42:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/2008/01/31/justice-in-one-case-at-least/#comment-27861</guid>
		<description>I have followed the Munden case since way back and told many people about it (including EC officials when I worked there) but this case is worrying because it shows that almost nothing has happened to protect card holders from banks' inefficiencies and plain old saving money in their security 'system'
Although it ended well it appears it was only because Egg couldn't or didn't want to produce the data, not because, as in the Munden case, they were ordered to, and didn't. The distinction is important, the precedent is still set that a bank is not required to support their contention that the client is perpetrating a fraud.</description>
		<content:encoded><![CDATA[<p>I have followed the Munden case since way back and told many people about it (including EC officials when I worked there) but this case is worrying because it shows that almost nothing has happened to protect card holders from banks&#8217; inefficiencies and plain old saving money in their security &#8217;system&#8217;<br />
Although it ended well it appears it was only because Egg couldn&#8217;t or didn&#8217;t want to produce the data, not because, as in the Munden case, they were ordered to, and didn&#8217;t. The distinction is important, the precedent is still set that a bank is not required to support their contention that the client is perpetrating a fraud.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: listening banker</title>
		<link>http://www.lightbluetouchpaper.org/2008/01/31/justice-in-one-case-at-least/#comment-27851</link>
		<dc:creator>listening banker</dc:creator>
		<pubDate>Sat, 02 Feb 2008 13:47:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightbluetouchpaper.org/2008/01/31/justice-in-one-case-at-least/#comment-27851</guid>
		<description>More egg in the news:
http://news.bbc.co.uk/1/hi/business/7222336.stm

J.A.B.:  At least you've got an envelope!</description>
		<content:encoded><![CDATA[<p>More egg in the news:<br />
<a href="http://news.bbc.co.uk/1/hi/business/7222336.stm" rel="nofollow">http://news.bbc.co.uk/1/hi/business/7222336.stm</a></p>
<p>J.A.B.:  At least you&#8217;ve got an envelope!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
