[Cscwg-public] Re FIPS tokens supporting RSA 3072

Adriano Santoni adriano.santoni at staff.aruba.it
Fri Mar 26 13:25:37 UTC 2021


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> *On Behalf Of 
> *Adriano Santoni via Cscwg-public
> *Sent:* miércoles, 17 de marzo de 2021 16:08
> *To:* 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/20210326/15ef553e/attachment.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/20210326/15ef553e/attachment.p7s>


More information about the Cscwg-public mailing list