<?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/"
	>

<channel>
	<title>On the road to Bandol &#187; Banking</title>
	<atom:link href="https://javacard.vetilles.com/tag/banking/feed/" rel="self" type="application/rss+xml" />
	<link>https://javacard.vetilles.com</link>
	<description>A weblog on Java Card, security, and other things personal</description>
	<lastBuildDate>Mon, 18 Aug 2025 06:48:26 +0000</lastBuildDate>
	<language>en-US</language>
		<sy:updatePeriod>hourly</sy:updatePeriod>
		<sy:updateFrequency>1</sy:updateFrequency>
	<generator>https://wordpress.org/?v=4.0.32</generator>
	<item>
		<title>Smart card security on the radio</title>
		<link>https://javacard.vetilles.com/2010/05/03/smart-card-security-on-the-radio/</link>
		<comments>https://javacard.vetilles.com/2010/05/03/smart-card-security-on-the-radio/#comments</comments>
		<pubDate>Mon, 03 May 2010 20:40:57 +0000</pubDate>
		<dc:creator><![CDATA[Eric Vétillard]]></dc:creator>
				<category><![CDATA[Banking]]></category>
		<category><![CDATA[Discussions]]></category>
		<category><![CDATA[News]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[smart card]]></category>

		<guid isPermaLink="false">http://javacard.vetilles.com/?p=576</guid>
		<description><![CDATA[Smart card security doesn&#8217;t often get on traditional media, so we can all (at least, the French-spaking ones) be happy that France Culture will spend an hour discussing the security of payment cards, trying to provide an answer to the question &#8220;Comment amÃ©liorer la sÃ©curitÃ© des cartes bancaires?&#8220;. Among the speakers, we will have Jean-Louis [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>Smart card security doesn&#8217;t often get on traditional media, so we can all (at least, the French-spaking ones) be happy that France Culture will spend an hour discussing the security of payment cards, trying to provide an answer to the question &#8220;<a href="http://sites.radiofrance.fr/chaines/france-culture2/emissions/science_publique/fiche.php?diffusion_id=83616" class="liexternal">Comment amÃ©liorer la sÃ©curitÃ© des cartes bancaires?</a>&#8220;. Among the speakers, we will have Jean-Louis Lanet, from UniversitÃ© de Limoges, and Pierre Chassigneux, from Cartes Bancaires. This talk show follows the publication of an article about the same topic in the French magazine <a href="http://www.sciencesetavenir.fr/" class="liexternal">Sciences et Avenir</a>.</p>
<p>This sounds interesting, and I will be listening to the show (maybe not live, but I will definitely get the podcast). I listened many times to France Culture&#8217;s science shows, and they are usually serious and interesting. Of course, the question (in English, how to enhance the security of bank cards?) is already a bit aggressive, and I am sure that some people would even challenge that question, claiming that there isn&#8217;t much to be enhanced. Well, we&#8217;ll see on Friday.</p>
]]></content:encoded>
			<wfw:commentRss>https://javacard.vetilles.com/2010/05/03/smart-card-security-on-the-radio/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Chip And PIN Is Broken (A Little)</title>
		<link>https://javacard.vetilles.com/2010/02/16/chip-and-pin-is-broken-a-little/</link>
		<comments>https://javacard.vetilles.com/2010/02/16/chip-and-pin-is-broken-a-little/#comments</comments>
		<pubDate>Tue, 16 Feb 2010 21:30:43 +0000</pubDate>
		<dc:creator><![CDATA[Eric Vétillard]]></dc:creator>
				<category><![CDATA[News]]></category>
		<category><![CDATA[Banking]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[smart card]]></category>

		<guid isPermaLink="false">http://javacard.vetilles.com/?p=543</guid>
		<description><![CDATA[By now, there has been sufficient hype around Ross Anderson&#8217;s latest attack on EMV banking cards. Once again, the Cambridge guys have scored a good one here, as the simplicity of the attack is outright incredible: Intercept the PIN Presentation command, make the terminal believe that the PIN is correct (i.e., return Status Word 9000), [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>By now, there has been sufficient hype around Ross Anderson&#8217;s <a href="http://www.lightbluetouchpaper.org/2010/02/11/chip-and-pin-is-broken/" class="liexternal">latest attack</a> on EMV banking cards. Once again, the Cambridge guys have scored a good one here, as the simplicity of the attack is outright incredible: Intercept the PIN Presentation command, make the terminal believe that the PIN is correct (<em>i.e.</em>, return Status Word 9000), while never sending the APDU to the card. After that, the terminal thinks that the PIN was presented correctly, and the card thinks that no PIN was presented. OK, let&#8217;s stop here for a minute.</p>
<p>Most of us, who don&#8217;t know the <a href="http://www.emvco.com/specifications.aspx" class="liexternal">EMV specs</a> by heart, would believe that the PIN authentication is part of the card applet&#8217;s state machine. After all, Chip and PIN seem to be very tightly connected to each other. Well, it isn&#8217;t the case, and PIN verification is just something that may happen, or not. So, the discrepancy can go unnoticed.</p>
<p>When looking at the EMV protocol in greater details, like they do in the article, we notice that the information is actually present, but that we are missing a method to consolidate the various bits of information. Some items are optional, while some others (the IAD) use proprietary formats, and are not intended to be parsed on the terminal. Basically, there are solutions to counter the attack, but they are not obvious to implement. If you want all the technial details, refer to the <a href="http://www.cl.cam.ac.uk/research/security/banking/nopin/oakland10chipbroken.pdf" class="lipdf">full paper</a>.</p>
<p>Now, what does this attack tell us about the EMV Protocol? Well, it has a vulnerability, like many (all?) other security protocols, at least in the way it is most often implemented in practice. It&#8217;s a rather big one, too, which shows that smart card protocols most likely get less interest than others. It also shows that simple is not only beautiful, but also secure, or at least that the complexity of systems like EMV, with all its options, is becoming a real security issue.</p>
<p>Then, another issue is that the ability to perform over-the-air software updates to fix vulnerabilities is becoming standard, on computers, on phones, and even on some TVs and soud systems, provided that they are connected to Internet. Well, such things remain hard to do on payment terminals, and also on smart cards, even though th security of these devices is critical. Can we really expect card operating systems to become more complex if we aren&#8217;t able to maintain them over their lifetime? Probably not, and that transition is going to be tough.</p>
<p>Another thing that this attack reminds us of is that smart cards are just another security measure, which cannot be perfect. The paper contains the usual attacks against UK banks who, according to the authors, make customers liable as soon as PIN authentication is used on a bad transaction. Here, the problem is not the technology, it is the system around it. Magstripe technology is far more broken, but if the insurance provided by US banks is better, then the consequence is that the customer, in the end, is better off with the lower security, because their insurance provided by their banks is better.</p>
<p>About PIN security itself, it is in fact very easy to guess the number typed by a person on a keypad, even without seeing the keypad. You can make the experience in any European supermarket line: simply try to guess the PIN typed by the people in front of you. You will notice that in many cases, you have the feeling that you got a lot of information about that PIN. Add to that the fact that you are far from being a trained professional, and you can get an idea of the problem: protecting a PIN is difficult. As far as I know, in France, where Chip and PIN has been the rule for many years, it is not too hard to avoid liability even if our PIN has been disclosed. The PIN is not a miracle, and it cannot solve all problems.</p>
<p>Finally, a positive note. We are getting quite a lot of attacks on smart cards these days. The program of <a href="http://cardis2010.xlim.fr/program.html" class="liexternal">Cardis 2010</a> includes 6 papers on attacks, and the published state-of-the-art is getting closer to the laboratories&#8217; state-of-the-art. Some might say that this is dangerous for cards, but some others will say that this is actually a positive evolution, moving away from the &#8220;smart cards are secure&#8221; dogma into a &#8220;smart card can help build good security models&#8221; logic. And if we use that logic to build business models that ultimately benefit final customers, then all of this will have been a step in the right direction.</p>
]]></content:encoded>
			<wfw:commentRss>https://javacard.vetilles.com/2010/02/16/chip-and-pin-is-broken-a-little/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Chip cards for (some) Americans</title>
		<link>https://javacard.vetilles.com/2009/10/10/chip-cards-for-some-americans/</link>
		<comments>https://javacard.vetilles.com/2009/10/10/chip-cards-for-some-americans/#comments</comments>
		<pubDate>Sat, 10 Oct 2009 21:22:29 +0000</pubDate>
		<dc:creator><![CDATA[Eric Vétillard]]></dc:creator>
				<category><![CDATA[Banking]]></category>
		<category><![CDATA[News]]></category>
		<category><![CDATA[smart card]]></category>

		<guid isPermaLink="false">http://javacard.vetilles.com/?p=483</guid>
		<description><![CDATA[It seems that the American plastic cards are getting them in trouble, at least when they travel in Europe. Of course, cards without chips still work perfeectly in restaurants, hotels, and stores. However, things are very different at automated machines. If you are in France and you want to pay for underground parking, for renting [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>It seems that the American plastic cards are <a href="http://www.nytimes.com/2009/10/04/travel/04pracchip.html?_r=4&#038;pagewanted=1&#038;ref=world" class="liexternal">getting them in trouble</a>, at least when they travel in Europe. Of course, cards without chips still work perfeectly in restaurants, hotels, and stores. However, things are very different at automated machines. If you are in France and you want to pay for underground parking, for renting a bike, or for a subway trip, your card better have a chip with which to perform an EMV transaction. Otherwise, you may well be out of luck.</p>
<p>There are a few exceptions to that rule. If you are lucky enough to be in a place that accepts American Express, these cards will be accepted even if they don&#8217;t have a chip (this is quite natural, since even those issued in Europe have no chip). But in many cases, you may well be really out of luck. Consider the subway example, for instance. In many places, it is becoming common to close all tellers at late hours, only to leave automated machines. And if you can&#8217;t get them to work, well, things may get ugly.</p>
<p>Things are only going to get worse, and apparently, some American companies have understood that. According to the NYTimes, Travelex is getting ready to issue prepaid smart cards for its customers in a bout a year from now. That means that, in a while, we should see American tourists with smart cards. And if it works, we are quite likely to start seeing American businessmen with smart cards as well, as corporate cards for international travellers will start having them as well.</p>
<p>Good news for smart cards? Not necessarily. If we consider that only 20% of all Americans have a passport, this also caps the number of Americans with that specific need. Most likely not the killer reason for American banks to switch to smart cards, which are still considered too expensive to manage.</p>
]]></content:encoded>
			<wfw:commentRss>https://javacard.vetilles.com/2009/10/10/chip-cards-for-some-americans/feed/</wfw:commentRss>
		<slash:comments>6</slash:comments>
		</item>
		<item>
		<title>Buying on Internet with fake card numbers</title>
		<link>https://javacard.vetilles.com/2009/06/30/buying-on-internet-with-fake-card-numbers/</link>
		<comments>https://javacard.vetilles.com/2009/06/30/buying-on-internet-with-fake-card-numbers/#comments</comments>
		<pubDate>Tue, 30 Jun 2009 11:24:59 +0000</pubDate>
		<dc:creator><![CDATA[Eric Vétillard]]></dc:creator>
				<category><![CDATA[News]]></category>
		<category><![CDATA[Banking]]></category>
		<category><![CDATA[Security]]></category>

		<guid isPermaLink="false">http://javacard.vetilles.com/?p=386</guid>
		<description><![CDATA[One would think that buying real goods on Internet with fake card numbers is not possible today. After all, there are many countermeasures that are quite hard to defeat, among which: You need to provide a 3/4 digit security code that is written on your card, and that is some kind of digital signature of [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>One would think that buying real goods on Internet with fake card numbers is not possible today. After all, there are many countermeasures that are quite hard to defeat, among which:</p>
<ul>
<li>You need to provide a 3/4 digit security code that is written on your card, and that is some kind of digital signature of the card number and expiration date.</li>
<li>Your goods need to be delivered, which will undoubtedly lead you to major trouble, especially if you repeat your scam several times.</li>
</ul>
<p>Well, things aren&#8217;t that simple. A gang presented as two countryside housewives has managed to steal around 200,000â‚¬ worth of goods before to get caught (here is <a href="http://www.01net.com/editorial/503863/deux-meres-de-famille-passees-expertes-dans-l-escroquerie-en-ligne/" class="liexternal">an article about this</a>, in French). The interesting part is how easy it has been to circumvent the complex security measures organized by online sites:</p>
<ul>
<li>First, avoid an immediate check of your credit card data, by buying items that are not too expensive, and by selecting options like &#8220;Pay in three easy installments&#8221; that will trigger a more complex, but less immediate procedure.</li>
<li>Then, use slight variations of your name and address for the delivery. The idea is to ensure that computers will not match &#8220;John Doe&#8221; with &#8220;Jon Doh&#8221;, but that the postman will perform the same match successfully, and deliver the package.</li>
</ul>
<p>I really love this scam, because it is so low tech. We design sophisticated countermeasures with ultra-secure smart cards, and we end up defeated by typos in names. According to the article, the victims are working on fixing the problem, but this is another endless quest: approximate matching is not that easy, and they will soon discover the joys of false positives. Good luck!</p>
]]></content:encoded>
			<wfw:commentRss>https://javacard.vetilles.com/2009/06/30/buying-on-internet-with-fake-card-numbers/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>A strange device from Switzerland</title>
		<link>https://javacard.vetilles.com/2009/04/23/a-strange-device-from-switzerland/</link>
		<comments>https://javacard.vetilles.com/2009/04/23/a-strange-device-from-switzerland/#comments</comments>
		<pubDate>Thu, 23 Apr 2009 21:04:28 +0000</pubDate>
		<dc:creator><![CDATA[Eric Vétillard]]></dc:creator>
				<category><![CDATA[News]]></category>
		<category><![CDATA[Banking]]></category>
		<category><![CDATA[Security]]></category>

		<guid isPermaLink="false">http://javacard.vetilles.com/?p=299</guid>
		<description><![CDATA[10 years ago, IBM Research used to have a team working on Java Card in Zurich. IBM sold their Java Card activity to NXP, but the team still exists, and it announced last year a strange device, the ZTIC. This is a device for securing banking transactions. In the example they insist on, they focus [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>10 years ago, IBM Research used to have a <a href="http://www.zurich.ibm.com/jcop/" class="liexternal">team working on Java Card</a> in Zurich. IBM sold their Java Card activity to NXP, but the team still exists, and it announced last year a strange device, the <a href="http://www.zurich.ibm.com/ztic/" class="liexternal">ZTIC</a>. This is a device for securing banking transactions.</p>
<p>In the example they insist on, they focus on <a href="http://en.wikipedia.org/wiki/Man_in_the_Browser" rel="nofollow" class="liwikipedia">man-in-the-browser</a> attacks, in which an attacker modifies within the browser itself (after successful authentication) the parameters of a money transfer in order to transfer more money, of course to his own account. With the ZTIC device, the user can review the actual amount and approve it (or not). According to the Wikipedia page above, this looks like the right thing to do for such attacks:</p>
<blockquote><p>
One of the most effective methods in combating a MitB attack is through an Out-of-Band (OOB) Transaction verification process. This overcomes the MitB Trojan by verifying the transaction details, as received by the host (bank), to the user (customer) over a channel other than the browser; typically an automated telephone call.
</p></blockquote>
<p>But then, the next sentence in Wikipedia is not that optimistic for the ZTIC:</p>
<blockquote><p>
OOB Transaction Verification is ideal for mass market use since it leverages devices already in the public domain (e.g. Landline, Cell Phone, etc) and requires no additional hardware devices &#8230;
</p></blockquote>
<p>So, is this device really useful?<br />
<span id="more-299"></span></p>
<p>Using hardware for securing banking transactions is not necessarily a bad idea. There are quite a number of <a href="http://en.wikipedia.org/wiki/One-time_password" rel="nofollow" class="liwikipedia">one-time password</a> (OTP) generators, and <a href="http://en.wikipedia.org/wiki/Chip_Authentication_Program" rel="nofollow" class="liwikipedia">CAP readers</a> are being popular as well.</p>
<p>However, as Wikipedia mentions, it is also possible to do without any specific hardware, leveraging for instance your existing landline or cellphone. On top of it, these devices are often more flexible, and can perform more operations.</p>
<p>Let&#8217;s consider the IBM device, and see what it does:</p>
<ul>
<li>It displays an amount that comes directly from the bank&#8217;s server.</li>
<li>It allows the end-user to accept or refuse the transaction, and transmits directly this response to the bank&#8217;s server.</li>
<li>It does so in an out-of-ban manner. Actually, the end-to-end security is a strong requirement in their case, but mostly because the communication goes through the very PC that may be infected by some malware</li>
</ul>
<p>The exact same thing can be done in many ways, even with low tech:</p>
<ul>
<li>By voice: &#8220;You just requested a money transfer of 20,000â‚¬ to some Russian bank. Press 1 to confirm, and 2 to cancel&#8221;</li>
<li>By SMS: &#8220;You just requested a money transfer of 20,000â‚¬ to some Russian bank. Enter 574567 in your browser to confirm the transaction&#8221;</li>
</ul>
<p>I can of course go more high-tech, with a sleek mobile application that handles the incoming SMS and displays it in a fancy way, but still, this is basically the same. In terms of security, is it very different from the ZTIC? Well, no. The communication may not be encrypted, but this has little influence on the global security level. The security measure in an out-of-band confirmation is the very fact that it is out-of-band, using a phone call/SMS directly from the bank&#8217;s server, to a number that only the server knows.</p>
<p>The other issue for this device is that it is specialized, and quite limited. In particular, it lacks an input device that would allow it to perform some kind of authentication in addition to the out-of-band countermeasure. That would definitely increase its potential use, but as it is, I don&#8217;t really see the advantage for a bank.</p>
<p>Let me conclude in an usually selfish way:</p>
<ul>
<li>First, I must admit that I am a bit biased, since I work for a company that sells security middleware for mobile phones. On the other hand, I truly adhere to our &#8220;Where open meets secure&#8221; motto, which engages us to use the same devices for many things, including security.</li>
<li>Then, I try to promote Java Card 3.0, and I have noticed that the ZTIC device is supposed to contain a card reader. Well, if this card reader can handle a Java Card 3.0 card and open a SSL transaction to such a card, I am sure that I will be able to find some applications that can make good use of the &#8220;secure&#8221; display on the ZTIC. Please, just add a few keys so that I can make it a full secure UI, and I will be happy.</li>
</ul>
]]></content:encoded>
			<wfw:commentRss>https://javacard.vetilles.com/2009/04/23/a-strange-device-from-switzerland/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Hackers want your PIN code</title>
		<link>https://javacard.vetilles.com/2009/04/17/hackers-want-your-pin-code/</link>
		<comments>https://javacard.vetilles.com/2009/04/17/hackers-want-your-pin-code/#comments</comments>
		<pubDate>Fri, 17 Apr 2009 11:03:22 +0000</pubDate>
		<dc:creator><![CDATA[Eric Vétillard]]></dc:creator>
				<category><![CDATA[News]]></category>
		<category><![CDATA[Banking]]></category>
		<category><![CDATA[Security]]></category>

		<guid isPermaLink="false">http://javacard.vetilles.com/?p=280</guid>
		<description><![CDATA[Wired is running a nice story about hackers that may be able to steal PIN codes during ATM transactions. The nice part of the story is of course the way in which these guys steal the codes. Since the story takes place in the USA, there is no smart card involved. The PIN codes are [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>Wired is running a <a href="http://blog.wired.com/27bstroke6/2009/04/pins.html" class="liexternal">nice story</a> about hackers that may be able to steal PIN codes during ATM transactions. The nice part of the story is of course the way in which these guys steal the codes. Since the story takes place in the USA, there is no smart card involved. The PIN codes are encrypted on the ATM, and then sent on the network for verification. The article mentions at some point that the encryption may be broken, which sounds strange, but this is of course not the way it happens.</p>
<p>The idea is here to hack the HSM&#8217;s (<a href="http://en.wikipedia.org/wiki/Hardware_Security_Module" rel="nofollow" class="liwikipedia">Hardware Security Module</a>) through which the PIN code transits. I am not an expert, but by reading the article, it seems that the PIN is first encrypted with a key from the ATM&#8217;s owner; then, it gets to an HSM in which it is decrypted and reencrypted with an interchange key. At some point, it gets to the cardholder&#8217;s bank&#8217;s HSM, where it is finally decrypted and compared to the actual PIN. This sounds quite amazing, since all of this goes very fast. But the main point is not here in the complexity of the process: it is on the HSM&#8217;s. Of course, these specialized computers are highly secure, with a lot of security precautions and all. I have worked on some of these things, and they sure look a lot like big smart cards, complete with a bunch of security features.</p>
<p>So, how can it fail?<br />
<span id="more-280"></span></p>
<p>Like usual, through sloppy programming and administration. If an HSM is poorly configured, if its &#8220;root&#8221; access keys are not well protected, if the development of the applications is outsourced without proper control, then there is a significant risk that hackers will be able to get in these systems. And since the incentives for hackers are very high (having card data is interesting, having card data together with the associated PIN code is much more interesting), I would not be surprised if this happened.</p>
<p>Of course, the solution that I will propose is the same as usual: stay local. Your secrets are better protected if they stay with you at all times. In a smart card transaction, the PIN code is verified directly on the card. The bank&#8217;s servers only verify the cryptogram provided by the card (after you present the proper PIN code). There are plenty of other solutions in which your PIN code does not travel through a maze of potentially unsure computers, including the CAP readers that I mentioned <a href="http://javacard.vetilles.com/2009/03/19/card-readers-for-online-banking/" class="liinternal">recently</a>. As far as I know, as of today, even your mobile phone is quite a safe place (unless of course, it is one of these Symbian phones that somehow seem to get all the attacks of the world). At least, it is under your control, so you have a chance to notice if it is being hacked.</p>
]]></content:encoded>
			<wfw:commentRss>https://javacard.vetilles.com/2009/04/17/hackers-want-your-pin-code/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Secure magstripe?</title>
		<link>https://javacard.vetilles.com/2009/04/09/secure-magstripe/</link>
		<comments>https://javacard.vetilles.com/2009/04/09/secure-magstripe/#comments</comments>
		<pubDate>Thu, 09 Apr 2009 18:39:41 +0000</pubDate>
		<dc:creator><![CDATA[Eric Vétillard]]></dc:creator>
				<category><![CDATA[Banking]]></category>
		<category><![CDATA[News]]></category>
		<category><![CDATA[Security]]></category>

		<guid isPermaLink="false">http://javacard.vetilles.com/?p=267</guid>
		<description><![CDATA[Visa seems to be investigating a new way to use magnetic stripe cards. The article does not give much details, but the basic idea seems to be that the magnetic stripe is scanned with a high definition, which provides a &#8220;unique&#8221; pattern, which Visa compares to the DNA or fingerprint of the card. Of course, [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>Visa seems to be investigating a <a href="http://www.computerworld.com.au/article/296344/visa_pilots_new_payment_card_security_initiatives" class="liexternal">new way</a> to use magnetic stripe cards. The article does not give much details, but the basic idea seems to be that the magnetic stripe is scanned with a high definition, which provides a &#8220;unique&#8221; pattern, which Visa compares to the DNA or fingerprint of the card. Of course, we don&#8217;t know yet how unique this pattern is, and how well it identifies the card. In particular, the pattern will be better if it depends on the physical properties of the magstripe (as it is somehow glued on the card), since this will be hard to forge.</p>
<p>This approach is interesting, because it makes it harder to use forged cards in face-to-face transactions. In this particular context, it reduces the differentiation of smart cards. Nevertheless, such approaches are interesting for security, at least to remind the smart card industry that their solutions are costly, and that there may be other ways to decrease the risk associated to payment (or any other application).</p>
]]></content:encoded>
			<wfw:commentRss>https://javacard.vetilles.com/2009/04/09/secure-magstripe/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Card readers for online banking</title>
		<link>https://javacard.vetilles.com/2009/03/19/card-readers-for-online-banking/</link>
		<comments>https://javacard.vetilles.com/2009/03/19/card-readers-for-online-banking/#comments</comments>
		<pubDate>Thu, 19 Mar 2009 20:22:28 +0000</pubDate>
		<dc:creator><![CDATA[Eric Vétillard]]></dc:creator>
				<category><![CDATA[Discussions]]></category>
		<category><![CDATA[News]]></category>
		<category><![CDATA[Banking]]></category>
		<category><![CDATA[Security]]></category>

		<guid isPermaLink="false">http://javacard.vetilles.com/?p=257</guid>
		<description><![CDATA[A few weeks ago, Cambridge&#8217;s team of security researchers published a paper about the small card readers that are currently being deployed as a way to make online banking more secure. Their article is quite critical, and I would just like to review the vulnerabilities that they mention, because I don&#8217;t think that these products [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>A few weeks ago, Cambridge&#8217;s team of security researchers published a <a href="http://www.lightbluetouchpaper.org/2009/02/26/optimised-to-fail-card-readers-for-online-banking/" class="liexternal">paper</a> about the small card readers that are currently being deployed as a way to make online banking more secure. Their article is quite critical, and I would just like to review the vulnerabilities that they mention, because I don&#8217;t think that these products are as dangerous than they make us believe.<br />
<span id="more-257"></span></p>
<h2>Card theft</h2>
<p>This first argument is a good one. Having a portable PIN-checking device is good news for muggers, who will now be able to check their victim&#8217;s PIN code from the comfort of their (victim&#8217;s) own home. As the authors mention, it would have been much better to let the user know about the &#8220;Wrong PIN&#8221; issue only after validating an online authentication or purchase, as it would have made it more difficult for muggers to get their information.</p>
<p>The bad news is that the readers are out now, and that muggers can freely get their hands on one, or they can order one from Internet.</p>
<p>The argument about wearing of the reader&#8217;s keys doesn&#8217;t seem as good. Keys take a lot of abuse before wearing, and a CAP reader is not a device that one will use 10 times a day every day. In practie, I am not sure that this vulnerability is really significant (this can be tested, though).</p>
<h2>Software implementation</h2>
<p>The CAP application can be implemented on pure software using publicly available documents. This is true, but this threat sounds much less significant to me. Because EMV is protected by copyright and other means, &#8220;official&#8221; software vendors are quite unlikely to include a piece of software that banks and payment associations don&#8217;t want to see. Of course, anybody with some smart card experience could write a program that emulates the CAP reader, but who would be stupid enough to give his PIN to a program written by an unknown developer. In addition, smart cards always faced the problem that PCs aren&#8217;t equipped with readers, and I believe that this is still very common today.</p>
<h2>Middleperson attacks</h2>
<p>Attacks based on a tampered-with terminal definitely can work, but they are very hard to industrialize, because payment networks have become quite good at identifying the source of a card fraud (<em>i.e.</em>, the vendor that has been used by several cards before a given attack). This severely limits the exploitation of this vulnerability.</p>
<h2>Supply-chain infiltration</h2>
<p>Like the previous one, this attack is real, but difficult to implement. The attack requires the attacker to sell modified CAP readers, which are then returned because they are designed to stop working (after recording your card information and PIN code, naturally). How many modified CAP readers can a thief sell on eBay before getting caught? Most likely, not much. In addition, the logistics is quite complicated.</p>
<p>The other idea consists in fitting a GSM module (with a SIM card) in the CAP reader. This vulnerability does not make any economic sense, because a CAP reader is intended for personal use, and the price of a GSM module (with some kind of a subscription) is likely to be greater than the price of buying the card information on the black market.</p>
<h2>Social engineering</h2>
<p>This one is really nice, and a beautiful extension to traditional phishing. Once a victim responds to a phishing e-mail, the next communication will consist in asking for some use of the reader, in order to authorize the transaction. This is of course quite natural; if somebody falls for phishing, this same person will keep going through the authentication process, almost regardless of the process.</p>
<p>I believe that this actually is a weakness of these devices. With a slightly larger screen, it would be possible to display a more detailed message, and therefore to reduce the likelihood of phishing.</p>
<h2>Protocol weaknesses</h2>
<p>These weaknesses seem to be specific to the use of the readers by the banks. All the weaknesses mentioned in the paper are quite trivial, and seem to result from the fact that banks have not been adequately trained about the use of the devices. Hopefully, this will get fixed in the near future.</p>
<p>To conclude on these vulnerabilities, I believe that they are not that easy to exploit, except by muggers (but, as I mentioned, it is too late to stop the muggers now, as they already have bought their CAP reader). </p>
<p>On the other hand, CAP readers are a good security measure, which can make online banking and payment safer. Their exploitation is only starting, and we can hope that it will improve in the coming years. In addition, other two-factor authentication means are becoming available, for instance using mobile phones, which will bring more diversity and hopefully more security to this field.</p>
]]></content:encoded>
			<wfw:commentRss>https://javacard.vetilles.com/2009/03/19/card-readers-for-online-banking/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Cloned debit cards are good for secure EMV cards</title>
		<link>https://javacard.vetilles.com/2009/02/06/cloned-debit-cards-are-good-for-secure-emv-cards/</link>
		<comments>https://javacard.vetilles.com/2009/02/06/cloned-debit-cards-are-good-for-secure-emv-cards/#comments</comments>
		<pubDate>Fri, 06 Feb 2009 18:06:36 +0000</pubDate>
		<dc:creator><![CDATA[Eric Vétillard]]></dc:creator>
				<category><![CDATA[Banking]]></category>
		<category><![CDATA[News]]></category>
		<category><![CDATA[Open issues]]></category>
		<category><![CDATA[Security]]></category>

		<guid isPermaLink="false">http://javacard.vetilles.com/?p=239</guid>
		<description><![CDATA[Reports about cloning debit cards have been all around, for instance here. The combination of cloning cards and making millions with a fraud scheme instantly makes smart card people happy: we told you that your magstripe cards would lead to big problems! OK. But let&#8217;s try to analyze this a bit deeper. First, the attack: [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>Reports about cloning debit cards have been all around, for instance <a href="http://news.cnet.com/8301-1009_3-10158062-83.html" class="liexternal">here</a>. The combination of cloning cards and making millions with a fraud scheme instantly makes smart card people happy: we told you that your magstripe cards would lead to big problems!</p>
<p>OK. But let&#8217;s try to analyze this a bit deeper.<br />
<span id="more-239"></span><br />
First, the attack:</p>
<ul>
<li>It relies on cloning. A good point for smart cards, which claim to be more difficult to clone.</li>
<li>It can interest organized crime. We are talking millions here. If this can be repeated, it is a strong point in favor of good security, because the attackers can invest a few thousand dollars in breaking the card.</li>
</ul>
<p>Again, I told you so! But I also need to bring up a few not so strong points:</p>
<ul>
<li>No authentication issues. Apparently, in these attacks, the attackers know the PIN code, either because they own the original card, or because they stole the PIN code with the card (not that hard, try it while waiting in supermarket of money dispenser lanes).</li>
<li>A key part of the attack consists in hacking a server somewhere, to make a system believe that a card has no limit (or a very high limit). No card involved here, so no good point for a smart card.</li>
</ul>
<p>Of course, I will now tell you that these arguments don&#8217;t hold.</p>
<ul>
<li>Smart card PIN authentication also authenticates the card. When performing an EMV transaction, the PIN is verified by the card, and that fact allows a cryptogram to be generated. When the payment terminal or server verifies its cryptogram, it will know that the user has been authenticated <em>and</em> the original card has been used. That links authentication to cloning, which is good for our case.</li>
<li>About servers, there is nothing to say. There are so many breaches in all kinds of servers worldwide that nobody would rely solely on servers for reaching a good level of security.</li>
</ul>
<p>So, I can now safely conclude that this attack would not work without actually cloning the card, which means that smart cards are better than magstripe, because they are in all cases harder to clone (even on cards with very poor security, there is no command to get the value of the secret; some kind of attack is required to get it). In addition, since the potential revenue is important, such schemes may interest organized crime, which means that they should be able to get the secrets out of at least the weakest available cards.</p>
<p>That leads us to the bleak side of things. A typical smart card in use today has been issued in 2007, by a bank who selected a platform vendor in 2005 after one year of negotiation with a card certified in 2003. And since 2003, a lot of attacks have been invented, and I am quite convinced that at least most <a href="http://en.wikipedia.org/wiki/Common_Criteria" rel="nofollow" class="liwikipedia">CC</a>-approved labs would be able to break these cards.</p>
<p>As a conclusion, I would say that smart cards are a good defense against these attacks, because they significantly raise the cost of preparing for the attack. However, I have no clue of the amount of money that it would cost to break a typical card used today, and this may still be very accessible to your typical mafia guy.</p>
]]></content:encoded>
			<wfw:commentRss>https://javacard.vetilles.com/2009/02/06/cloned-debit-cards-are-good-for-secure-emv-cards/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
