[Cfrg] Trusting government certifications of cryptography

"D. J. Bernstein" <djb@cr.yp.to> Fri, 03 October 2014 11:10 UTC

Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 193151A028B for <cfrg@ietfa.amsl.com>; Fri, 3 Oct 2014 04:10:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.101
X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5uxFK4-sZ7V0 for <cfrg@ietfa.amsl.com>; Fri, 3 Oct 2014 04:10:33 -0700 (PDT)
Received: from mace.cs.uic.edu (mace.cs.uic.edu []) by ietfa.amsl.com (Postfix) with SMTP id 0709D1AD038 for <cfrg@irtf.org>; Fri, 3 Oct 2014 04:10:32 -0700 (PDT)
Received: (qmail 5449 invoked by uid 1011); 3 Oct 2014 11:10:30 -0000
Received: from unknown (unknown) by unknown with QMTP; 3 Oct 2014 11:10:30 -0000
Received: (qmail 20326 invoked by uid 1001); 3 Oct 2014 11:10:24 -0000
Date: 3 Oct 2014 11:10:24 -0000
Message-ID: <20141003111024.20324.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: cfrg@irtf.org
Mail-Followup-To: cfrg@irtf.org
In-Reply-To: <54116278.3080901@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/hXwTjUHi_xconBo_6FCApC_PVCQ
Subject: [Cfrg] Trusting government certifications of cryptography
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Oct 2014 11:10:35 -0000

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? 

http://smartfacts.cr.yp.to explains how we factored 184 RSA-1024 keys
from Taiwan's national "Citizen Digital Certificate" database. As you
can see from http://smartfacts.cr.yp.to/cert.html, 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.

http://smartfacts.cr.yp.to/analysis.html 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., https://projectbullrun.org/dual-ec), 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".