[Cscwg-public] Re FIPS tokens supporting RSA 3072

Wed Mar 31 06:52:09 UTC 2021

All,

after examining several FIPS PUB 140-2 certifications and considering 
the meaning of the term "crypto module" in that context, I would say 
that the requirement in §16.3 item 2 cannot but refer to the crypto 
device _as a whole_ (HW + FW + SW), regardless of which of its internal 
components are (or are not) individually certified. It also seems to me 
that, in the light of the recent WG call, this is the most shared 
interpretation.

Therefore, a device such as the one that Tomas has mentioned as an 
example, obviously does not meet the certification requirement in §16.3 

item 2 , as it is a device that - as a whole - does not possess any type 
of certification (nor FIPS nor CC). I hope we all agree on this. If not, 
then my take is that §16.3 item 2 must be rewritten (after establishing 

what the intended requirement is).

I'd love to get feedbacks.

Adriano

Il 26/03/2021 15:03, Inigo Barreira ha scritto:
>
> Correct Adriano. The ones I´ve listed in the other email are CC or/and 
> FIPS certified and in the features some list the certification of the 
> hardware and the software and not all are on the same level or only 
> one of the two. But it´s true, that we´d need to clarify what kind of 
> certification we´re looking for. We could stick to the point that the 

> device, that is the hardware itself, is listed as CC or FIPS and show 
> auditors the certificates. Or just the OS. If we´re going to the point 
> to distinguish what part is certified and require it then it would be 
> a problem if we have to differentiate from hardw and softw, which one 
> is best, or remove some possible suppliers from the list, so I´d leave 
> it as much open possible but clearly indicating what we require.
>
> *From:*Adriano Santoni <adriano.santoni at staff.aruba.it>
> *Sent:* viernes, 26 de marzo de 2021 14:26
> *To:* Inigo Barreira <Inigo.Barreira at sectigo.com>; 
> cscwg-public at cabforum.org
> *Subject:* Re: [Cscwg-public] Re FIPS tokens supporting RSA 3072
>
> Hi Inigo,
>
> I also am aware of 4-5 suppliers of USB crypto tokens supporting RSA 
> 3072, regardless of FIPS or CC. That is not the problem I raised.
>
> My concern is that §16.3, point 2, of the CSBR is ambiguous (to me) as 
> to what is supposed to be "certified" (either FIPS or CC):
>
>     A hardware crypto module with a unit design form factor certified
>     as conforming to at least FIPS 140 Level 2, Common Criteria EAL
>     4+, or equivalent.
>
> This is likely my fault, but I am not clear what "unit design form 
> factor" exactly means, and I would appreciate very much anybody 
> pointing me to any FIPS or CC certification reports wherein this term 
> is used.
>
> As far as I know, a "form factor" is the particular design, shape, 
> assembly and wiring of a functionally self-contained electronic 
> component, such as a PCB including microchip(s) and other auxiliary 
> components.
>
> A crypto device is like an onion, being comprised of:
>
>   * *hardware platform*(a microcontroller, tipically including a
>     crypto co-processor);
>   * *card operating system*(COS), which can either be either mono- or
>     multi-application (e.g. Javacard);
>   * where applicable, an *applet*. If the COS is multi-application, a
>     suitable PKI application (mostly referred to as "applet") must be
>     installed into the chip at the production plant, for the device to
>     be usable. A multi-app COS, such as the Javacard platform, does
>     not expose by itself any crypto and key management functionalities
>     in a way that's usable by the host: a suitable Java applet is
>     needed, supporting specific commands (APDUs), a specific file
>     system, specific PKCS11/CSP object attributes, enforcing a
>     specific set of security principles, etc.
>   * a case with I/O and power supply contacts
>
> Where the device is Javacard based, the security of the whole device 
> critically depends on the design of the PKI applet, that's why 
> Javacard-based devices designed for specific usages (e..g. digital 
> signatures) always require this applet to be certified as well (not 
> just the COS). Would we be happy to use a Javacard-based device 
> running an applet that nobody has ever verified to be actually secure? 
> Of course we may, if that's what the WG believes to be the way to go.
>
> But what does it mean for the "hardware crypto module" to be either 
> FIPS or CC certified ? Does it mean that at least the hardware 
> platform (the microchip) must be certified? In this case we have 
> plenty microchips on the market meeting this requirement. Does it mean 
> that the COS must (also) be certified? In this case we have a lesser 
> number of suitable choices, but still comfortable. Or, does it mean 
> that the applet must (also) be certified? In this case, we have a very 
> small choice, to date.
>
> My understanding from the last CSWG call, is that some of the WG 
> members believe it to be sufficient that the COS be certified (or even 
> just the HW?). IMO, this is not clear from the current CSBR language. 
> I would suggest to drop the "unit design form factor" term, and 
> specify instead that the hardware crypto module must be based on a 
> FIPS or CC certified COS (if this is the desired interpretation). Let 
> me clarify that I would not object to this choice, if the WG believes 
> is the right one.
>
> I am not trying to play the "purist", just trying to raise attention 
> and get explanations on some aspects that are not clear to me at this 
> time.
>
> How about adding to the CSBR the definitions of these two terms in 
> section 4 ?
>
>   * hardware crypto module
>   * unit design form factor
>
> Adriano
>
> Il 26/03/2021 12:37, Inigo Barreira ha scritto:
>
>     Hi Adriano,
>
>     Sorry for jumping late here but I´m restarting with the CABF
>     issues and am still in the process L
>
>     Regarding your question, we can differentiate between those
>     USB&smartcards and the HSMs. So, for the first, we´ve found some
>     others, but it´s true that there are not many but we´re aware of
>     3-4 additional providers. In the HSM space, I see no problems.
>
>     Regards
>
>     *From:*Cscwg-public <cscwg-public-bounces at cabforum.org>
>     <mailto:cscwg-public-bounces at cabforum.org> *On Behalf Of *Adriano
>     Santoni via Cscwg-public
>     *Sent:* miércoles, 17 de marzo de 2021 16:08
>     *To:* cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org>
>     *Subject:* [Cscwg-public] Re FIPS tokens supporting RSA 3072
>
>     CAUTION: This email originated from outside of the organization.
>     Do not click links or open attachments unless you recognize the
>     sender and know the content is safe.
>
>     I already posted this question yesterday, but apparently it did
>     not get through.
>
>     I was asking: is the SafeNet eToken 5110 CC the only FIPS token
>     supporting RSA 3072 available on the market?
>
>     I am investigating this matter myself, and although I am not
>     finished it seems there aren't many... possibly just one.
>
>     If so, it would be a rather unfortunate situation competition-wise.
>
>     Adriano
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210331/2b4d8a01/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4557 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210331/2b4d8a01/attachment-0001.p7s>