[Cscwg-public] Re FIPS tokens supporting RSA 3072

Inigo Barreira Inigo.Barreira at sectigo.com
Fri Mar 26 14:03:30 UTC 2021


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  <mailto:cscwg-public-bounces at cabforum.org>
<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/20210326/3d469aff/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6853 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210326/3d469aff/attachment-0001.p7s>


More information about the Cscwg-public mailing list