Re: [Cfrg] Trusting government certifications of cryptography

David Jacobson <> Fri, 03 October 2014 16:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AF3BC1A19E9 for <>; Fri, 3 Oct 2014 09:19:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B59ambHTb0oJ for <>; Fri, 3 Oct 2014 09:19:26 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 254271A03F9 for <>; Fri, 3 Oct 2014 09:19:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1412353165; bh=BAHn+hMEaaZAfbIn3XquXaYY9Q6oLK6Gp3BWzD99/AI=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:From:Subject; b=LzBELvd/C2TYGZw72yxBlDSyGBLK9gQqk74CombWYzgEmRwyeuvikCID0cBqHjA/KKUjQ0Wq7+33fDWRPt7Vskm21/ZTVv6VKi58ZRewjmcyVO2/es4o+LRNrHGF7fnz8Vp5uey1Xca0Oam9K/WjA4NhlHVv17fh4xWkj5+SIHw=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; b=4mAVGEsj02733cs6ysF/OblNmnPmyXuSkCatnIKhJziYtWYInLYdny8pz0gfbuhWq2pYqSiVR0tvQGonMHXoH9bOf6QthgLRyCZzTto2vq3AjJ+/ekuwJggZXo6JtPtVwCK1YEFC8KVwImQPDWUdd5+BOg2yMAL5gOyBu8ncusg=;
Received: from [] by with NNFMP; 03 Oct 2014 16:19:25 -0000
Received: from [] by with NNFMP; 03 Oct 2014 16:19:25 -0000
Received: from [] by with NNFMP; 03 Oct 2014 16:19:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1412353165; bh=BAHn+hMEaaZAfbIn3XquXaYY9Q6oLK6Gp3BWzD99/AI=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=nSjgP/vpGh3Rm087yhMqV7sOZq6mxy7b/8DRk2n04tZNc0OanjxpJD7N0vckm6TzQ8PPT4JyiZHaW0fY+ZLzYCbKHtUH5WD6JAaHT3vOf0VdYnV9YYbgBgBNCtTFH28FJd5rCw3XLiktyFGnbEdTjv2yYibBGjKEJwUPYR96dUU=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: U3j24d0VM1lD5a0jMUaJYB54Kkrg_kMxbeSIAQP8Hgc8yKR BemRpNC4_Zs6AVH9a3RFmAe3bzJrHuG4.RhmpAaPwzz1VUFgpvRkJyAvbUKy uL2Pm52C8dbPjqcAc2f9ZcLEFTxJwpw.zwZbJS11KDlAIJ8ztXz3VZpAGiCi KpG5l1a1gfZ9qJ_ktUm6iOHImBdopEVU4OKJS_vaeObo8Md9IlZS1RbQhL7N 7bavZ8t3KhotReiJLMnJQ32sOMIeKegrLasruFR_tWaqcJH2uSPAFWfup81q .WU.McwnpMsyX_t66bMFWziNKWSZxMAF7SkH3VLYLdLcmy4oBwUEdxZtKJ2J PeXgnNtWB.SS32IvFfbA4mSzwsXGTqecvcJBV79NPjacF0nffmiThBPihLLw N2O8cEkFKZFOy5pyc5s8uXBE_fVuCJRNeyflZEQlvIxt7ePBsrSoRjs1Untw Dmy_InqS3Y5ylzmaTx0PhuVvpcDYP4JXIiUbjtH.D2_09Cep1HW1o79Bzx1. YG40MryUYx2dJXHg5Amug5ihmPCTkbXHQ9DAgyvRpdgMHS3BMY3Uq8PVxWgN xAzvJCbTCKMH2VYIhWdswddeggAxMSbvyUg2moyjY54LaAqJFrkwrGAsZ7fo mLxjVtrDHg0ZUxAO7Z4thEG.DQuHc0vkogstNXWhVItisZu4s9__MfnPASws a0m3gWyYsz.XEIsehqkkuVDHyJzBV1H0ATUSKeZj9rPZMd2zIeJPLmKxLghU zCNijSzfWobw5M68QvgjSbLC6C85fG8a0.YCo8FtXoRJWcu0wQlK0.J62ekX hRIok
X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g--
Message-ID: <>
Date: Fri, 03 Oct 2014 09:19:24 -0700
From: David Jacobson <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [Cfrg] Trusting government certifications of cryptography
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Oct 2014 16:19:31 -0000

On 10/3/14, 4:10 AM, D. J. Bernstein wrote:
> Torsten Schuetze writes:
>> Smart cards, i.e., its coprocessors and its ECC software
>> implementations, are always certified by Common Criteria, usually with
>> rather high assurance level. Don't you trust this certification in
>> principle?
> explains how we factored 184 RSA-1024 keys
> from Taiwan's national "Citizen Digital Certificate" database. As you
> can see from, these keys were
> generated by government-issued smart cards that advertised all of the
> usual Common Criteria and FIPS certifications from BSI, NIST, and CSE.
> analyzes five contributing
> factors to this security disaster---low-quality hardware RNG, inadequate
> sanity checks, no run-time sanity checks, no postprocessing, and
> inadequate initial response---and the complete failure of certification
> to prevent the disaster from occurring.
> Another interesting example to consider is the FIPS certification for
> branches of OpenSSL starting with openssl-fips-1.1.2.tar.gz (2007). The
> pursuit of FIPS certification was the reason that OpenSSL added support
> for Dual EC with NSA's P and Q. The certification procedure failed to
> catch the fact that OpenSSL's Dual EC implementation didn't work at all:
> As Steve Marquess put it: "Frankly the FIPS 140-2 validation testing
> isn't very useful for catching 'real world' problems."
> After the public learned that Dual EC with this P and Q was an NSA back
> door (see, e.g.,, the slowness of
> recertification stopped openssl-fips from dropping Dual EC support for
> _nine months_:
> It's clear that OpenSSL's certification had various other effects, such
> as diverting quite a bit of OpenSSL funding into InfoGard Laboratories
> Inc. How much positive security impact did this have to outweigh its
> obvious negative impacts? For example, how many of OpenSSL's security
> holes, whether in the FIPS version or generally, were discovered through
> the FIPS validation process?
> Security review is of course important, and I've heard several stories
> of security problems being caught by Common Criteria testing labs. But
> the security problems that _aren't_ caught show that certification is
> not true "assurance" of security---even in relatively simple settings
> such as the Taiwanese Citizen Digital Certificates, never mind the much
> more complex environment of Internet cryptography.
> I understand that words such as "certification" and "validation" and
> "assurance" have an important impact on users in some markets. But for
> experts it should be clear that more skepticism is warranted. You can't
> reasonably ask CFRG to "trust this certification in principle".
> ---Dan
> _______________________________________________
> Cfrg mailing list
I totally agree with Dan.  I've been involved in getting several 
products validated at FIPS 140-2 some at level 3 and some at level 1.  
Here are some examples of unnecessary difficulty and/or weaknesses.  
Some of what I say is based on what our consultant told us, and I 
presume he knew standard better than we.

1.  In one product we were accelerating IPSEC.  In IPSEC the security 
associations in the kernel contain the keys in plaintext. But FIPS 140-2 
level 3 requires that all key material be encrypted as it crosses the 
security boundary. Our consultant advised us to just use a fixed, hard 
coded, AES key on both sides.  Apparently this is allowed.

2.  Random number generators are required to implement a "continuous 
test", which means that they have to check that no two consecutive 
generated random numbers are the same, and if this does occur they must 
enter an error state.   Apparently this requirement was written back in 
the days when RNGs were generated using SHA1 and always had the same 
size.  But this is not the case with, say, CTR_DRBG from SP 800-90A.  
Even if we neglect that, it (sort of) requires saving each output value 
until the next generate operation.  This spoils backtracking 
resistance.  For good backtracking resistance, we want to delete the 
delivered value as soon as possible.  The "sort of" is because we could 
compute the hash of each delivered value, and save that and compare with 
the hash of the next one.  But that adds a lot of extra cycles.  And 
this is a waste, since the NIST-recommeded DRBGs can only get stuck with 
cryptographically small probability. And even if the DRBG did get stuck, 
a better response would be to force an immediate reseed, rather than 
entering an error state.

3.  There is a requirement at level 3 that the "operator" log in using 
"identity-based" credentials.  Well, when the host operating system is 
providing crypto services, sometimes for the OS itself, who is the 
"operator"?  Solution:  The driver for the crypto card is.  We gave the 
driver some credentials.  The validation requirements only apply to the 
interface, and it sees an approved login protocol, so all is well.

4.  One of the onerous things is the self test requirements.  If you 
build the HASH-DRBG in hardware, you would think the running the known 
answer tests at each power-on would be an acceptable way showing the the 
logic hasn't rotted.  This would only require a way for the driver to 
push in a known entropy blob instead of getting entropy from the 
hardware entropy generator.   No.  The HASH-DRBG hardware contains a 
dedicated implementation of SHA-256.  You have to not only do the known 
answer test on the whole HASH-DRBG, but you also have to apply known 
answer tests to the internal dedicated SHA-256.  This adds a lot of 
complexity with no benefit.

Summary,  FIPS-140 is not a system level security assurance.  It is 
showing that a lot of rules are satisfied at and inside the "security 

    --David Jacobson