<?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; certification</title>
	<atom:link href="https://javacard.vetilles.com/tag/certification/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>One less flaw in secure USB keys</title>
		<link>https://javacard.vetilles.com/2010/01/09/one-less-flaw-in-secure-usb-keys/</link>
		<comments>https://javacard.vetilles.com/2010/01/09/one-less-flaw-in-secure-usb-keys/#comments</comments>
		<pubDate>Fri, 08 Jan 2010 22:08:53 +0000</pubDate>
		<dc:creator><![CDATA[Eric Vétillard]]></dc:creator>
				<category><![CDATA[News]]></category>
		<category><![CDATA[certification]]></category>
		<category><![CDATA[Security]]></category>

		<guid isPermaLink="false">http://javacard.vetilles.com/?p=521</guid>
		<description><![CDATA[We all know by now that some German testers have broken certified USB keys. Breaking a secure product is not big news. Breaking a certified product is less common, so it makes the news. Now, the reactions are worth analyzing, because it is very hard to figure out what certification is about, in particular when [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>We all know by now that some <a href="http://www.syss.de/index.php?id=108&#038;tx_ttnews[tt_news]=528&#038;tx_ttnews[backPid]=59&#038;cHash=8d16fa63d9" class="liexternal">German testers</a> have <a href="http://www.h-online.com/security/news/item/NIST-certified-USB-Flash-drives-with-hardware-encryption-cracked-895308.html" class="liexternal">broken</a> <a href="http://www.schneier.com/blog/archives/2010/01/fips_140-2_leve.html" class="liexternal">certified</a> USB keys.</p>
<p>Breaking a secure product is not big news. Breaking a certified product is less common, so it makes the news. Now, the reactions are worth analyzing, because it is very hard to figure out what certification is about, in particular when related to security. Certification schemes are not perfect, but they still have plenty of advantages.</p>
<p>I am not going to describe the attack. All we need to know is that (1) the crypto algorithm in the USB drive was not borken, and (2) the authentication has been broken, but not by a brute force attack.</p>
<p>Now, about the certification. We are here talking about a <a href="http://en.wikipedia.org/wiki/FIPS_140-2" rel="nofollow" class="liwikipedia">FIPS 140-2</a>, Level 2 certification. First advantage of the certification, some trace is available on the Web, giving very <a href="http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140crt/140crt932.pdf" class="lipdf">a brief summary</a> of the evaluation results, as well as a <a href="http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp932.pdf" class="lipdf">security policy</a>.</p>
<p>Of course, these documents tell us many things. For instance, that authentication is password-based:</p>
<blockquote><p>Password Only: The module persistently stores the password hashed and AES encrypted in FLASH, which is outside of the cryptographic boundary.</p></blockquote>
<p>Then, it defines the strength of the mechanism:</p>
<blockquote><p>
The probability that a random attempt will succeed or a false acceptance will occur is 1/62^4, which is less than 1/1,000,000. The user is locked out after no more than 100 contiguous login failures, therefore the random success rate for multiple retries is 1/62^4 divided by a customer specified number â‰¤ 1001, which is less than 1/100,000.
</p></blockquote>
<p>OK. The &#8220;62^4&#8243; seems to mean that a 4-character alphanumeric  password is required (26 letters, uppercase + lowercase, + 10 digits, that makes 62 symbols), which represents a bit over 14 million combinations. I don&#8217;t really get the &#8220;customer specified number â‰¤ 1001&#8243; bit, but divided 14 millions by 100 (possible tries) yields a number greater than 100000, so the statement is about right.</p>
<p>Next, we can look at the certificate, which states:</p>
<blockquote><p>Roles, Services, and Authntication: Level 2</p></blockquote>
<p>So, this means that this authentication mechanism has been evaluated, and that it satisfies Level 2. I am not a FIPS140-2 specialist, so I need to look at the certification&#8217;s <a href="http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf" class="lipdf">definition document</a> what that means:</p>
<blockquote><p>For Security Level 2, a cryptographic module shall employ role-based authentication to control access to the module.</p></blockquote>
<p>So far, so good. The roles are here basic, but they are present. Of course, the specification says more than that. Here are the basic requirements for authentication:</p>
<blockquote><p>
The strength of the authentication mechanism shall conform to the following specifications:</p>
<ul>
<li>For each attempt to use the authentication mechanism, the probability shall be less than one in 1,000,000 that a random attempt will succeed or a false acceptance will occur (e.g., guessing a password or PIN, false acceptance error rate of a biometric device, or some combination of authentication methods).</li>
<li>For multiple attempts to use the authentication mechanism during a one-minute period, the probability shall be less than one in 100,000 that a random attempt will succeed or a false acceptance will occur.</li>
<li>Feedback of authentication data to an operator shall be obscured during authentication (e.g., no visible display of characters when entering a password).</li>
<li>Feedback provided to an operator during an attempted authentication shall not weaken the strength of the authentication mechanism.</li>
</ul>
</blockquote>
<p>This definitely reminds us of the security policy, which satisfies all these rules. Now, what is missing? Well, the attack that succeeded is missing. There is no mention of the protection of the authentication mechanism against tampering. The standard only defines the properties of the normal use of the authentication mechanism, but not the properties of its defenses.</p>
<p>This is because FIPS140-2 focuses on cryptography, and not on ancillary functions. Maybe that a <a href="http://en.wikipedia.org/wiki/Common_Criteria" rel="nofollow" class="liwikipedia">Common Criteria</a> (CC) certification would have been better at finding this flaw, because CC looks at all security functions, beyond cryptography, and all labs know that authentication often is the weakest point of the crypto products. Of course, we will never know what CC would have found.</p>
<p>Now, we know one good point about certification: it only took us a few minutes to find the relevant information (security policy, certificate, and FIPS140-2 definition). And a security-literate computer professional would only need a few minutes to understand what features have been analyzed or not. Of course, very few people ever do that kind of analysis.</p>
<p>One of Schneier&#8217;s commenters mentions the fact that these products don&#8217;t really deserve to be blamed because &#8220;to err is human&#8221; and the vendors have acted swiftly after the discovery of the flaw.</p>
<p>Well, this may also be a very good point about certification. When NIST sees headlines about FIPS-certified products getting broken, it is quite likely that they take some action to analyze the problem, and that they get in contact with the vendor. And that&#8217;s a pretty good incentive in favor of action from these vendors. </p>
<p>So, overall, the certification brought some advantages to the customers, even to those who do not understand much about security. And the other good news is that now, their product is likely to be more secure, once they will have applied the corrective actions suggested by the vendors.</p>
]]></content:encoded>
			<wfw:commentRss>https://javacard.vetilles.com/2010/01/09/one-less-flaw-in-secure-usb-keys/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
