<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
	xmlns:media="http://search.yahoo.com/mrss/"
>

<channel>
	<title>Payment Systems Blog &#187; ATM</title>
	<atom:link href="http://www.paymentsystemsblog.com/topics/atm/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.paymentsystemsblog.com</link>
	<description>David D. Bergert</description>
	<lastBuildDate>Sat, 10 Apr 2010 13:32:51 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<!-- podcast_generator="podPress/8.8" - maintenance_release="8.8.4" -->
		<copyright>Copyright &#xA9; 2010 Payment Systems Blog </copyright>
		<managingEditor>podcast@paymentsystemsblog.com (Dave Bergert)</managingEditor>
		<webMaster>podcast@paymentsystemsblog.com (Dave Bergert)</webMaster>
		<category>posts</category>
		<ttl>1440</ttl>
		<itunes:keywords>Payment Systems, ISO8583, PABP, PA-DSS, PCI, Security, Credit, Debit</itunes:keywords>
		<itunes:subtitle></itunes:subtitle>
		<itunes:summary>Payment Systems Podcast is a podcast that address the subject of Payments Systems, their operations, development, security and other experiences related to payment processing.</itunes:summary>
		<itunes:author>Dave Bergert</itunes:author>
		<itunes:category text="Technology"/>
<itunes:category text="Business"/>
<itunes:category text="Technology">
	<itunes:category text="Software How-To"/>
</itunes:category>
		<itunes:owner>
			<itunes:name>Dave Bergert</itunes:name>
			<itunes:email>podcast@paymentsystemsblog.com</itunes:email>
		</itunes:owner>
		<itunes:block>No</itunes:block>
		<itunes:explicit>no</itunes:explicit>
		<itunes:image href="http://www.paymentsystemsblog.com/images/pspodcast.png" />
		<image>
			<url>http://www.paymentsystemsblog.com/images/pspodcast.png</url>
			<title>Payment Systems Blog</title>
			<link>http://www.paymentsystemsblog.com</link>
			<width>144</width>
			<height>144</height>
		</image>
		<item>
		<title>PIN Block Formats &#8211; The Basics</title>
		<link>http://www.paymentsystemsblog.com/2010/03/03/pin-block-formats/</link>
		<comments>http://www.paymentsystemsblog.com/2010/03/03/pin-block-formats/#comments</comments>
		<pubDate>Wed, 03 Mar 2010 16:02:19 +0000</pubDate>
		<dc:creator>db</dc:creator>
				<category><![CDATA[ATM]]></category>
		<category><![CDATA[PIN]]></category>

		<guid isPermaLink="false">http://www.paymentsystemsblog.com/2010/03/03/pin-block-formats/</guid>
		<description><![CDATA[I had a call yesterday about approved TG-3 (Which is now called TR-39 ) ANSI PIN Block Formats.
The TR-39 Audit Procedures state that ISO 9564–1 Format 0 (ISO-0) and Format 3 (ISO-3) are the only approved formats:
4.1.3 X9 Approved PIN Block Formats

Documented procedures exist and are followed that ensure any cleartext PIN-block format combined with [...]]]></description>
			<content:encoded><![CDATA[<p>I had a call yesterday about approved <a href="http://www.x9.org/standards/free/">TG-3</a> (Which is now called TR-39 ) ANSI PIN Block Formats.</p>
<p>The TR-39 Audit Procedures state that ISO 9564–1 Format 0 (ISO-0) and Format 3 (ISO-3) are the only approved formats:</p>
<blockquote><p><em>4.1.3 </em><span style="-webkit-text-decorations-in-effect: underline;"><em>X9 Approved PIN Block Formats</em></span><em><br />
</em></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt;"><em>Documented procedures exist and are followed that ensure any cleartext PIN-block format combined with a PIN encryption process has the characteristic that, for different accounts, encryption of the same PIN value under a given encryption key does not predictably produce the same encrypted result. (Note: any cleartext PIN block, formats 0 and 3 meet this requirement, as specified in X9.8-1).</em></p>
<p><span style="font-size: 10.0pt; font-family: Arial;"><em>Reference X9.8-1 &#8211; Sec. 4(c), Sec. 6.2, Sec. 8.3.1, Sec.8.3.2, and Sec. 8.3.5</em></span><!--EndFragment--></p></blockquote>
<p>In case you are curious here are <a href="http://usa.visa.com/merchants/risk_management/cisp_pin_security.html">Visa&#8217;s PIN Security Requirements</a></p>
<blockquote><p><em>Requirement 3:<br />
</em></p>
<p><em>For online interchange transactions, PINs are only encrypted using ISO 9564–1 PIN block formats 0, 1 or 3. Format 2 must be used for PINs that are submitted from the IC card reader to the IC card. Other ISO approved formats may be used.</em></p></blockquote>
<p>This requirement further states:</p>
<blockquote><p><em>PINs enciphered using ISO format 0 or ISO format 3 must not be translated into any other PIN block format other than ISO format 0 or ISO format 3. PINs enciphered using ISO format 1 may be translated into ISO format 0 or ISO format 3,</em> <strong><em>but must not be translated back into ISO format 1.</em></strong></p></blockquote>
<p>(This last paragraph addresses an attack on Pin Blocks that can be translated in to format 1 on a HSM which would expose the clear PIN)</p>
<p><strong><br />
</strong></p>
<h3><strong>Let&#8217;s take a look at a few Pin Block formats:</strong></h3>
<p>For our examples:</p>
<p>P &#8211; PIN Number</p>
<p>F &#8211; Hex 0xF</p>
<p>A- Last 12 digits of PAN not including check digit</p>
<p>R &#8211; Random Hex Character (0-9, A-F)</p>
<p>Let us use the account number 4111111111111111 and PIN Number 1234 (examples use a PIN Length of 4 but could be 4-12 digits)</p>
<h3><strong>&#8220;Pin Pad&#8221; format or IBM 3624</strong></h3>
<p><em>PPPP FFFF FFFF FFFF</em></p>
<p>our Pin Block</p>
<p>1234 FFFF FFFF FFFF</p>
<p>Notes: Not allowed and is an old legacy method &#8211; not approved to be used.</p>
<h3><strong>ISO-0</strong></h3>
<p><strong><span style="font-weight: normal;"><em>04PP PPFF FFFF FFFF   (0 = ISO-0 Format, 4 = length of PIN)</em></span></strong></p>
<p><em>XOR with<br />
</em></p>
<p><strong><span style="font-weight: normal;"><em>0000 AAAA AAAA AAAA (Formatted PAN)</em></span><br />
</strong></p>
<p>our Pin Block:</p>
<p>0412 34FF FFFF FFFF</p>
<p>XOR</p>
<p>0000 1111 1111 1111</p>
<p>=</p>
<p>0412 25EE EEEE EEEE</p>
<p>Notes: Introduces variability in the PIN block by XOR&#8217;ing with a Formatted PAN &#8211; Best practice is to use ISO-3 instead of ISO-0 as there are attacks against ISO-0</p>
<h3><strong>ISO-1</strong></h3>
<p><strong><span style="font-weight: normal;"><em>1412 34RR RRRR RRRR</em></span> <span style="font-weight: normal;"><em>(1 = ISO-0 Format, 4 = length of PIN)</em></span><br />
</strong></p>
<p>our Pin Block:</p>
<p><strong><span style="font-weight: normal;">1412 348D 665A C5A3</span><br />
</strong></p>
<p><strong><span style="font-weight: normal;">Notes: Introduces variability in the PIN block by using Random padding chars &#8211; Best practice is not to allow HSM&#8217;s to accept or use this PIN Block format. Not allowed by TR-39 but is VISA.</span><br />
</strong></p>
<h3><strong>ISO-3</strong></h3>
<p><em>34PP PPRR RRRR RRRR (3 = ISO-3 Format, 4 = length of PIN)<br />
</em></p>
<p><em>XOR with<br />
</em></p>
<p><strong><span style="font-weight: normal;"><em>0000 AAAA AAAA AAAA (Formatted PAN)</em></span></strong></p>
<p><strong><span style="font-weight: normal;">our Pin Block:</span><br />
</strong></p>
<p>3412 34C8 CBA4 285C</p>
<p>XOR</p>
<p>0000 1111 1111 1111</p>
<p>=</p>
<p>3412 25D9 dAB5 394D</p>
<p>Notes: Introduces variability in the PIN block by using Random padding chars and  by XOR&#8217;ing with a Formatted PAN &#8211; Best practice is to use this format.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.paymentsystemsblog.com/2010/03/03/pin-block-formats/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Consolidated links for 1-20 (Inauguration day)</title>
		<link>http://www.paymentsystemsblog.com/2009/01/20/consolidated-links-for-1-20-inauguration-day/</link>
		<comments>http://www.paymentsystemsblog.com/2009/01/20/consolidated-links-for-1-20-inauguration-day/#comments</comments>
		<pubDate>Tue, 20 Jan 2009 15:36:18 +0000</pubDate>
		<dc:creator>db</dc:creator>
				<category><![CDATA[ATM]]></category>
		<category><![CDATA[Discover]]></category>
		<category><![CDATA[General]]></category>
		<category><![CDATA[Gift Cards]]></category>

		<guid isPermaLink="false">http://www.paymentsystemsblog.com/2009/01/20/consolidated-links-for-1-20-inauguration-day/</guid>
		<description><![CDATA[I don&#8217;t have time this morning to write any detailed blog posts:&#160; So let me share a few links that caught my interest for blogging topics:

Coinstar Machines Turn Change into iTunes Credit &#8211; TibBits &#8211; get gift cards from coin counting machines
Beware: Circuit City Gift Cards &#8211; Payment News &#8211; Use it or lose it, [...]]]></description>
			<content:encoded><![CDATA[<p>I don&#8217;t have time this morning to write any detailed blog posts:&#160; So let me share a few links that caught my interest for blogging topics:</p>
<ul>
<li><a href="http://db.tidbits.com/article/10009">Coinstar Machines Turn Change into iTunes Credit</a> &#8211; <a href="http://www.tidbits.com">TibBits</a> &#8211; get gift cards from coin counting machines</li>
<li><a href="http://www.paymentsnews.com/2009/01/circuit-city-gi.html">Beware: Circuit City Gift Cards</a> &#8211; <a href="http://www.paymentnews.com">Payment News</a> &#8211; Use it or lose it, Retail Gift Cards for struggling retailers are best not to hold on to.</li>
<li>&#160;<a href="http://www.paymentsnews.com/2009/01/discover-to-par.html">Discover To Participate in TARP, Becomes Bank Holding Company</a> &#8211; <a href="http://www.paymentnews.com">Payment News</a> &#8211; DiscoverBank</li>
<li>Discover PCI Levels Defined:&#160; See: <a href="http://treasuryinstitute.org/blog/index.php?itemid=221">Here</a> (<a href="http://treasuryinstitute.org">Treasury Institute</a>), and <a href="http://www.greensheet.com/newswire.php?newswire_id=11006#Discover%20rolls%20out%20PCI%20enhancement%20to%20streamline%20validations%20and%20reports">here</a> (<a href="http://www.greensheet.com/">GreenSheet</a>).&#160; The Short of it is that Discover has aligned their PCI Merchant Levels to that of MC and Visa.</li>
<li><a href="http://www.mckeay.net/2009/01/15/atm-skimmers-are-getting-sneakier/">ATM Skimmers are getting sneakier</a> &#8211; <a href="http://www.mckeay.net">Network Security Blog</a> &#8211; Video of an wireless ATM Card Skimmer</li>
<li><a href="http://www.greensheet.com/newswire.php?newswire_id=11004#MasterCard%20dispels%20myths%2C%20highlights%20benefits%20of%20payment%20networks">MasterCard dispels myths, highlights benefits of payment networks</a> &#8211; (<a href="http://www.greensheet.com/">GreenSheet</a>) &#8211; MC has released a paper &quot;Benefits of Open Payment Systems and the Role of Interchange&quot; with some links to audio and video &#8211; some good basic stuff here on a payment transaction.</li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://www.paymentsystemsblog.com/2009/01/20/consolidated-links-for-1-20-inauguration-day/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>ATM reprogramming arrests.</title>
		<link>http://www.paymentsystemsblog.com/2008/09/24/atm-reprogramming-arrests/</link>
		<comments>http://www.paymentsystemsblog.com/2008/09/24/atm-reprogramming-arrests/#comments</comments>
		<pubDate>Wed, 24 Sep 2008 14:40:33 +0000</pubDate>
		<dc:creator>db</dc:creator>
				<category><![CDATA[ATM]]></category>
		<category><![CDATA[Breach]]></category>
		<category><![CDATA[PCI]]></category>
		<category><![CDATA[security]]></category>

		<guid isPermaLink="false">http://www.paymentsystemsblog.com/2008/09/24/atm-reprogramming-arrests/</guid>
		<description><![CDATA[ I guess it has been almost two years now, that a news story and security researcher blog post, pointed out a vulnerability in certain types of ATM Machines. The vulnerability relates to &#34;PCI requirement #2 &#8211; Do not use vendor-supplied defaults for system passwords and other security parameters&#34; with a few brands of ATM [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://www.paymentsystemsblog.com/wp-content/uploads/2008/09/tranax-1500.jpg"><img style="border-right: 0px; border-top: 0px; margin: 0px 20px 20px 0px; border-left: 0px; border-bottom: 0px" height="260" alt="tranax-1500" src="http://www.paymentsystemsblog.com/wp-content/uploads/2008/09/tranax-1500-thumb.jpg" width="155" align="left" border="0" /></a> I guess it has been almost two years now, that a <a href="http://blog.wired.com/27bstroke6/2006/09/atm_hack_uncove.html?entry_id=1560245">news story</a> and <a href="http://www.matasano.com/log/506/atm-backdoor-why-is-no-one-talking-about-this/">security researcher blog post</a>, pointed out a vulnerability in certain types of ATM Machines. The vulnerability relates to &quot;<strong><em>PCI requirement #2 &#8211; Do not use vendor-supplied defaults for system passwords and other security parameters&quot;</em></strong> with a few brands of ATM machines ( generally the smaller standalone ATM&#8217;s you see in convenience stores and sold by ATM ISO&#8217;s and their agents ) whose service manuals were accessible online, and ATM operators failing to setup the ATM&#8217;s in a secure manner.&#160; I remember googling and finding the default passwords and instructions for these. With the service manual and passwords, a person was able to reprogram the value of the ATM cassettes. telling the ATM Machine that the $5 cassettes had $20&#8217;s and doing a withdrawal</p>
<p>&#160;</p>
<p>Today &#8211; <a href="http://blog.wired.com/27bstroke6/2008/09/two-arrested-in.html">Wired</a> notes that the first bust for ATM Reprogramming Scan netted its first two arrests.</p>
<blockquote><p>It took a high-speed chase and some gunplay, but two men in Lincoln, Nebraska, are the first to face felony charges for using default passcodes to reprogram retail cash machines to dispense free money.</p>
<p>Jordan Eske and Nicolas Foster, both 21, are in Lancaster County Jail pending an October 1st arraignment. They&#8217;re each charged with four counts of theft by deception, and one count of computer fraud, for allegedly pulling cash from privately owned ATMs at four stores in the area. The pair allegedly reprogrammed the machines to believe they were loaded with one-dollar bills instead of tens and twenties. A withdrawal of $20 would thus net $380.</p>
</blockquote>
]]></content:encoded>
			<wfw:commentRss>http://www.paymentsystemsblog.com/2008/09/24/atm-reprogramming-arrests/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>
