Re: [Cfrg] On "non-NIST"

Johannes Merkle <johannes.merkle@secunet.com> Mon, 02 March 2015 15:13 UTC

Return-Path: <Johannes.Merkle@secunet.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328FB1A887B for <cfrg@ietfa.amsl.com>; Mon, 2 Mar 2015 07:13:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYj4XrpgTv7j for <cfrg@ietfa.amsl.com>; Mon, 2 Mar 2015 07:13:32 -0800 (PST)
Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A3C61A88DA for <cfrg@irtf.org>; Mon, 2 Mar 2015 07:04:11 -0800 (PST)
Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 5E2D71A009B; Mon, 2 Mar 2015 16:03:59 +0100 (CET)
X-Virus-Scanned: by secunet
Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 61KYelgC1HnA; Mon, 2 Mar 2015 16:03:53 +0100 (CET)
Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id 7233C1A0093; Mon, 2 Mar 2015 16:03:53 +0100 (CET)
Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 2 Mar 2015 16:04:03 +0100
Message-ID: <54F47BE3.2020906@secunet.com>
Date: Mon, 2 Mar 2015 16:04:03 +0100
From: Johannes Merkle <johannes.merkle@secunet.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Watson Ladd <watsonbladd@gmail.com>, Paul Hoffman <paul.hoffman@vpnc.org>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF91123@uxcn10-5.UoA.auckland.ac.nz> <BE305B0B-80D2-48C6-ACE6-6F6544A04D69@vpnc.org> <CACsn0ckHyRiLBiRe9Vg4TJMUg-+c8vbB2e-QKuHbuZ_NiqC2UA@mail.gmail.com> <B56D6A89-A111-40BB-9AE2-F3EEF512262A@vpnc.org> <CACsn0cmwPZuYBtdGi=2NpXQ+OVC3dZDe1ny00fVLdNn0s7qZ3Q@mail.gmail.com>
In-Reply-To: <CACsn0cmwPZuYBtdGi=2NpXQ+OVC3dZDe1ny00fVLdNn0s7qZ3Q@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.208.1.76]
X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/1SCYc5dnq6PcmYq85r4e8rRbxzQ>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, Peter Gutmann <pgut001@cs.auckland.ac.nz>
Subject: Re: [Cfrg] On "non-NIST"
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: Mon, 02 Mar 2015 15:13:35 -0000

Watson Ladd schrieb am 01.03.2015 um 00:41:
>>>> Not "the", but "an". The reason is that NIST controls what can and cannot be given a FIPS-140 certification, and that certification is considered important both by companies who want to sell to the US Govt and companies that use their certification as a statement that "we did it right". If you make an HSM that uses an algorithm not allowed by NIST, you cannot get it certified in the CMVP regime. Thus, when NIST is slow to keep up with the best practices adopted by the community, it becomes a roadblock to deploying better crypto.
>>>
>>> This is factually untrue: CMVP certified modules are permitted to
>>> implement other algorithms: they just can't be in FIPS mode when those
>>> are used.
>>
>> That sentence assumes a few things: an HSM that has multiple signing algorithms *and* a lab that would allow non-certified signing algorithms to be within the crypto module that gets the Level 2+ certification *and* the CMVP program allowing the lab's evaluations. To the best of my knowledge, this has never happened. (Disclaimer: NIST once paid me to become an expert on the CMVP process and how crypto vendors and labs dealt with it, but I have not kept my day-to-day knowledge of it up to date in recent years.)
>>
>> What you describe is quite common in devices that get Level 1 certifications, but it is not clear that something that normally is expected to have a Level 2+ validation, specifically like HSMs, would be able to do so.
> 
> Safenet's Luna SA Network-attached HSM claims FIPS 140-2 Level 3
> certification and support Brainpool. Granted, I only know about this
> because it's the one Amazon provides and I had occasion to read the
> documentation.
> 

The question is how much assurance of security you get by running the HSM in non-FIPS-Mode. I know of a different vendor
of level 2 certified HSMs that use completely different firmware to support Brainpool curves. This practice makes it
more difficult for customers to accept the HSM running in non-FIPS mode to support Brainpool.

-- 
Johannes