<?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: Indiana Bank gets Hacked&#8230;Who&#8217;s really to blame?</title>
	<atom:link href="http://www.spylogic.net/2008/06/indiana-bank-gets-hackedwhos-really-to-blame/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.spylogic.net/2008/06/indiana-bank-gets-hackedwhos-really-to-blame/</link>
	<description></description>
	<lastBuildDate>Sun, 18 Sep 2011 21:48:21 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Matt</title>
		<link>http://www.spylogic.net/2008/06/indiana-bank-gets-hackedwhos-really-to-blame/comment-page-1/#comment-65</link>
		<dc:creator>Matt</dc:creator>
		<pubDate>Tue, 08 Jul 2008 00:00:16 +0000</pubDate>
		<guid isPermaLink="false">#comment-65</guid>
		<description>Without some serious bruteforcing compromised track data would not of lead to the PIN being revealed.  Clear text PIN data should never be stored on the card.  I am not aware of any standard that allows this.&lt;br /&gt;
&lt;br /&gt;
The ISO 7813 standard does not require a PIN to be encoded onto the card but it does allow an &quot;Encrypted PIN&quot; to be encoded onto the card.  The &quot;Encrypted PIN&quot; is a 4 digit code that is generated by DES or 3DES encrypting the PIN with the banks PIN Verification Key (PVK).  Then that string of cipher text is run through an algorithm that pulls out the four digits that comprise the Encrypted PIN block.&lt;br /&gt;
&lt;br /&gt;
Given this process an attacker would first need to bruteforce the banks PVK encryption keys.  Next they would need to bruteforce the PIN to figure out which PIN matches up with which Encrypted PIN.  Because the Encrypted PIN is a subset of the cipher text generated you can not simply decrypt the Encrypted PIN to get the original PIN.  Think of it like a hashing function.&lt;br /&gt;
&lt;br /&gt;
Cheers,&lt;br /&gt;
Matt</description>
		<content:encoded><![CDATA[<p>Without some serious bruteforcing compromised track data would not of lead to the PIN being revealed.  Clear text PIN data should never be stored on the card.  I am not aware of any standard that allows this.</p>
<p>The ISO 7813 standard does not require a PIN to be encoded onto the card but it does allow an &quot;Encrypted PIN&quot; to be encoded onto the card.  The &quot;Encrypted PIN&quot; is a 4 digit code that is generated by DES or 3DES encrypting the PIN with the banks PIN Verification Key (PVK).  Then that string of cipher text is run through an algorithm that pulls out the four digits that comprise the Encrypted PIN block.</p>
<p>Given this process an attacker would first need to bruteforce the banks PVK encryption keys.  Next they would need to bruteforce the PIN to figure out which PIN matches up with which Encrypted PIN.  Because the Encrypted PIN is a subset of the cipher text generated you can not simply decrypt the Encrypted PIN to get the original PIN.  Think of it like a hashing function.</p>
<p>Cheers,<br />
Matt</p>
]]></content:encoded>
	</item>
</channel>
</rss>

