<?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; contactless</title>
	<atom:link href="https://javacard.vetilles.com/tag/contactless/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>Protecting your contactless card</title>
		<link>https://javacard.vetilles.com/2012/02/20/protecting-your-contactless-card/</link>
		<comments>https://javacard.vetilles.com/2012/02/20/protecting-your-contactless-card/#comments</comments>
		<pubDate>Mon, 20 Feb 2012 08:35:11 +0000</pubDate>
		<dc:creator><![CDATA[Eric Vétillard]]></dc:creator>
				<category><![CDATA[Discussions]]></category>
		<category><![CDATA[Mobile Security]]></category>
		<category><![CDATA[News]]></category>
		<category><![CDATA[Research]]></category>
		<category><![CDATA[contactless]]></category>
		<category><![CDATA[Security]]></category>

		<guid isPermaLink="false">http://javacard.vetilles.com/?p=806</guid>
		<description><![CDATA[As I mentioned in NFC Payments 101, current contactless cards aren&#8217;t protected against the simple attack that consists in performing a transaction while your card is in your pocket. Since some models don&#8217;t require anything else than tapping the card, the attack is workable. Well, that may change. researchers for the University of Pittsburgh&#8217;s RFID [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>As I mentioned in <a href="http://javacard.vetilles.com/2012/02/16/nfc-payments-101/" class="liinternal">NFC Payments 101</a>, current contactless cards aren&#8217;t protected against the simple attack that consists in performing a transaction while your card is in your pocket. Since some models don&#8217;t require anything else than tapping the card, the attack is workable.</p>
<p>Well, that may change. researchers for the University of Pittsburgh&#8217;s <a href="http://www.engr2.pitt.edu/SITE/RFID/" class="liexternal">RFID Center for Excellence</a> have invented a on/off switch for cards, that simply requires you to put your finger on a specific spot on a contactless card to allow it to work (see a picture <a href="http://venturebeat.com/2012/02/18/researchers-create-onoff-switch-for-credit-cards-to-prevent-rfid-theft/" class="liexternal">here</a>).</p>
<p>Comment on the various articles around the topic are quite typical, ranging from the &#8220;This is very dumb because it is unpractical&#8221; to the &#8220;You have to give up some practicality for security&#8221;, and all variants in the middle. I would have liked to see the inventors&#8217; arguments, but I haven&#8217;t found a reference to a paper/report.</p>
<p>From previous experience, user experience often wins, in particular when, like with contactless cards, practicality is a selling point of a technology.Also, since the idea is to protect your cards in your wallet, I would think that it is easier for security-conscious to use wallets that include some kind of wire mesh or other wave-blocking technology. Since the on/off switch requires you to actually get the card out of your wallet, it is more or less equivalent, and it only annoys security-conscious people. The other guys will still be able totap their wallet (until, of course, they start having several contactless cards in there, in which case this optimization may not work any more).</p>
<p>This invention does not look flexible enough. The threat of someone performing transactions without you knowing is not significant enough to justify this kind of generalized measure for payment cards. On the other hand, it sounds much better as privacy-protecting technology on ID cards, since an ID card. Ensuring that the data about your identity will not leak from your wallet is interesting, and since an ID card is typically pulled out of the wallet before to be used, the technology is not an annoyance any more. But of course, in research like in politics, the fears associated to credit card theft remain more powerful than those associated to privacy protection (although identity theft is gaining traction).</p>
]]></content:encoded>
			<wfw:commentRss>https://javacard.vetilles.com/2012/02/20/protecting-your-contactless-card/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>The hidden price of smart card security</title>
		<link>https://javacard.vetilles.com/2009/05/25/the-hidden-price-of-smart-card-security/</link>
		<comments>https://javacard.vetilles.com/2009/05/25/the-hidden-price-of-smart-card-security/#comments</comments>
		<pubDate>Mon, 25 May 2009 21:04:15 +0000</pubDate>
		<dc:creator><![CDATA[Eric Vétillard]]></dc:creator>
				<category><![CDATA[News]]></category>
		<category><![CDATA[Research]]></category>
		<category><![CDATA[contactless]]></category>
		<category><![CDATA[Security]]></category>

		<guid isPermaLink="false">http://javacard.vetilles.com/?p=339</guid>
		<description><![CDATA[Our friends from Radboud University made the news again last week, when they got the Best Practical Paper Award at the IEEE Symposium on Security and Privacy. The most interesting part of this is the background, of course. NXP tried to stop the researchers from publishing the results of their work, and they failed, after [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>Our friends from Radboud University made the news again last week, when they got the Best Practical Paper Award at the <a href="http://oakland09.cs.virginia.edu/" class="liexternal">IEEE Symposium on Security and Privacy</a>. The most interesting part of this is the background, of course. NXP tried to stop the researchers from publishing the results of their work, and they failed, after providing them with a great public acknowledgment. The interesting thing is of course to understand how NXP is dealing with the actual publication.</p>
<p>In a paper from <a href="http://www.govtech.com/gt/689811?topic=117671" class="liexternal">Government Technology</a>, we don&#8217;t get a reaction from from NXP directly, but from an industry analyst. Here are two quotes from him:</p>
<blockquote><p>
&#8220;The smart card industry is way ahead of the curve, and they have a new product available right now that is not only secure, but it fully defeats the attack that was done by these researchers,&#8221;</p>
<p>&#8220;MIFARE classic is like running on Windows 95, and we already have Windows Vista available. When are you going to upgrade? What&#8217;s your migration strategy to upgrade to the new system?&#8221;
</p></blockquote>
<p>These two quotes are true, and they are typical of the quotes we get when a smart card encounters a security problem. Naturally, when negotiating a new deployment, this language more or less disappears. Is that really respectful of our customers?<br />
<span id="more-339"></span></p>
<p>Of course, no. Anybody that has been in the smart card industry for a while knows that the level of security of a smart card decreases over time, sometimes rapidly. Some people in certification bodies even say that their certificates are &#8220;deprecated the day they are issued&#8221;, which reminds us that new things may happen all the time.</p>
<p>The issue, of course, is that nobody wants customers to think about the fact that, in a few years from now, these brand new ultra-secure cards will need to be replaced, at a cost that may not be negligible, especially if no provision has been taken for it. This means that vendors don&#8217;t only lie to their customers, they also damage them by not taking the required precautions.</p>
<p>Something interesting is that the cost of replacement is likely to go up with the required level of security. Banking smart cards are often changed every two years, three years in some cases. On the other hand, SIM cards can last for many years (my wife&#8217;s SIM card is getting close to 10 years old, and mine is 7 or 8 years old). I perfectly know that such SIM cards can be easily broken using today&#8217;s attack techniques. However, this doesn&#8217;t happen, so operators don&#8217;t feel the need to change them, and I feel perfectly OK with that.</p>
<p>Another fun thing is that the lifetime of bankinf cards is much more than 2 years, if you think of it. Think of my latest card, issued in 2009. The contract about that card may be a 2-year contract, from 2007, which took one year to negotiate, starting in 2006. Of course, the card product has been developed and evaluated, which took about a year, in 2005. That&#8217;s for the software, because the chip is older than that, and was originally certified in 2004. So, when my card is issued, it is already a 4 year-old product based on a 5 year-old chip, and at the end of its life, 2 years from now, it will be a 6-year old product on a 7 year-old chip. I don&#8217;t know about the coming years, but I can tell you that few 7 year-old products resist to today&#8217;s attacks.</p>
<p>Replacing smart cards brings a lot of interesting questions, for which few answers have been given over the years. Here are  two that I find really interesting:</p>
<ul>
<li>How to know that an issued card needs to be replaced (<em>i.e.</em>, that it doesn&#8217;t satisfy its security requirements)?</li>
<li>How to deal with the data of the applications hosted in the card, especially with multi-application cards and applications from multiple issuers?</li>
</ul>
<p>These questions are very interesting and very complex, because the solutions are not always easy. For instance, think of a signature application, based on keys generated on-card. The fact that the private key never gets out of the card is an important security argument, so how can you transfer it to another card? Should you rather revoke the certificate and issue a new key? Well, there is a question like this for every application, and the solutions are never easy.</p>
<p>However, having a good answer to these questions is necessary in order to be truthful to customers, and to let them know about the total cost of ownership of smart cards over several years. Such questions are often overlooked, and simpler questions, related to the introduction of newer and unproven technology, often get more effort. Not a good thing.</p>
]]></content:encoded>
			<wfw:commentRss>https://javacard.vetilles.com/2009/05/25/the-hidden-price-of-smart-card-security/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Stories remain alive</title>
		<link>https://javacard.vetilles.com/2008/07/10/stories-remain-alive/</link>
		<comments>https://javacard.vetilles.com/2008/07/10/stories-remain-alive/#comments</comments>
		<pubDate>Thu, 10 Jul 2008 09:13:48 +0000</pubDate>
		<dc:creator><![CDATA[Eric Vétillard]]></dc:creator>
				<category><![CDATA[News]]></category>
		<category><![CDATA[contactless]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[voting machine]]></category>

		<guid isPermaLink="false">http://javacard.vetilles.com/2008/07/10/stories-remain-alive/</guid>
		<description><![CDATA[I recently posted about contactless card security and about voting machines. Well, these two items are still in the news. About contactless card, it seems that the researchers from Radboud University Nijmegen are being sued by NXP in an attempt to avoid the full disclosure of their flaw. The article I linked to contains a [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>I recently posted about <a href="http://javacard.vetilles.com/2008/06/26/open-source-smart-card-operating-system/" class="liinternal">contactless card security</a> and about <a href="http://javacard.vetilles.com/2008/07/02/voting-machine-security/" class="liinternal">voting machines</a>. Well, these two items are still in the news.</p>
<p>About contactless card, it seems that the researchers from Radboud University Nijmegen are being <a href="http://news.cnet.com/8301-10784_3-9985886-7.html?tag=nefd.top" class="liexternal">sued by NXP</a> in an attempt to avoid the full disclosure of their flaw. The article I linked to contains a link to a video that shows that this attempt is pointless. The dutch research team was smart enough to identify a flaw in the cryptographic algorithm, but they are not the only capable team of researchers in the world. Suing them will buy a little time, but other teams will get on the topic, and it will be hard to avoid disclosure for very long. I hope that NXP also has other contingency plans to react to this new security issue.</p>
<p>On a completely different topic, a scientific study in France by <a href="http://www.sciences.univ-nantes.fr/info/perso/permanents/enguehard/" class="liexternal">Chantal Enguehard</a> has shown that there were more errors on precincts that use voting machines than on those that don&#8217;t. I must say that I can easily believe in this, as my experience looking at voting machines being used has shown that the use of the machines is often confusing for both staffers and voters. Since confusion leads to errors, the report does not come as a surprise.</p>
<p>I haven&#8217;t found the report itself, just <a href="http://www.01net.com/editorial/385931/la-fiabilite-des-machines-a-voter-de-nouveau-mise-en-cause/?rss" class="liexternal">an article</a> about it. I will get back to the issue, as I am quite happy that the file against the voting machines currently used in France is becoming thicker, and that we can hope to achieve some results there.</p>
]]></content:encoded>
			<wfw:commentRss>https://javacard.vetilles.com/2008/07/10/stories-remain-alive/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
