[Cscwg-public] CSCWG Agenda Apr 15, 2021
Adriano Santoni
adriano.santoni at staff.aruba.it
Wed Apr 21 13:07:34 UTC 2021
Hi Dimitris,
I am certainly /not/ a Common Criteria expert. However I believe it is
appropriate for my role to try and get acquainted with at least the
basics of such matter, also in order to be able to provide satisfactory
answers to auditors :)
On the other hand, similar questions may also arise with regard to the
HSMs used for signing certificates (and timestamps): the standards (both
CABF and ETSI) require the CA/TSA to use an HSM with either FIPS o CC
security certification, but when it comes to CC not all certifications
are equivalent, so a minimum of analysis and discernment is required by
those who select those HSMs. Therefore, I expect that in every
responsible CA organization there is at least one person who knows "just
enough" about this subject (without necessarily being an expert), namely
FIPS 140-2 and CC certifications, to be able to make or suggest a
sensible choice, and one that is tenable in front of an auditor.
Coming to your questions and comments:
* I like the idea of a guidance web page, like the one you mentioned.
* I disagree that a QSCD is more secure than an SSCD; my understanding
is that QSCD is essentially a new name for an old thing (the SSCD), and
in fact the devices referred to as QSCD on
https://esignature.ec.europa.eu/efda/notification-tool/#/screen/browse/list/QSCD_SSCD
are often "in SSCD configuration" as shown by the relevant STs (see for
example
https://www.ssi.gouv.fr/uploads/2020/08/anssi-cible-cc-2020_73en. pdf,
but there are many others) and their STs refer to the old, obsolete but
still used "Protection Profiles for Secure Signature Creation Device"
(see for example
https://www.sogis.eu/documents/cc/pp/sc/sscd/obsolete/pp0059a.pdf)
> Is there some document/rule that SSCD/QSCD devices must meet the three
> security features you listed?
No, and I have not said that there exists any.
What I am proposing is that CAs make sure the crypto modules used by
their Subscribers (for Code Signing purposes) have a CC certification
(unless they have a proper FIPS 140-2 certification) whose Security
Target includes those three security features. These latter may not be
expressed with exactly the same words that I used, because there is no
such requirement for a ST (AFAIK). So, yes, it's up to the CA to figure
out (or have someone figure out for them) if the ST of some crypto
module includes those three security features. It's not always
straightforward, but some guidance can be provided.
For example, regarding QSCDs/SSCDs, their CC certifications are usually
based on STs claiming conformance to the "Protection profiles for secure
signature creation device - Part 2: Device with key generation"
(https://www.commoncriteriaportal.org/files/ppfiles/pp0059b_pdf.pdf).
This PP mandates the following security functions:
* 10.2.2.1 FCS_CKM.1 Cryptographic key generation (page 28)
* 10.2.2.3 FCS_COP.1 Cryptographic operation (page 28)
* 10.2.3 User data protection (FDP) (page 29 and on)
Note that I am not suggesting that we should recommend QSCDs/SSCDs, it's
just one of a number of alternatives.
Another example can be made for Java Card -based devices, whose ST
usually claims conformance to the Java Card Protection Profile
(https://www.commoncriteriaportal.org/files/ppfiles/ANSSI-CC-profil_PP-2010-03en.pdf).
This PP mandates the following security functions:
* FCS_CKM.1 Cryptographic key generation (page 71)
* FCS_COP.1 Cryptographic operation (page 72)
* FCS_CKM.3 Cryptographic key access (page 71) => refers to the Java
Card API that imply PIN-based user authentication
Again, I want to emphasize that I am no expert, not trying to propose
myself as one, and these are just proposals, based on my own
comprehension of the matter, and any discussion on them is more than
welcome.
Adriano
Il 21/04/2021 10:31, Dimitris Zacharopoulos (HARICA) via Cscwg-public ha
scritto:
>
> Hi Adriano,
>
> See answers inline.
>
> On 21/4/2021 10:34 π.μ., Adriano Santoni via Cscwg-public wrote:
>>
>> Hi Dimitris,
>>
>> to avoid misunderstandings: I am not at all suggesting to impose
>> "additional"requirements on crypto modules for Code Signing (by the
>> Subscriber), but only to consider those devices that include the
>> thhree security functions I have listed, which after all are quite
>> common.
>>
>
> Perhaps I wrote it in an unclear way. I agree that most probably these
> are not "additional" requirements but more "specific" requirements
> that should already be fulfilled by existing certified crypto modules.
> My concern is how auditors/CAs will find supporting evidence that
> describes that these "specific" requirements are met.
>
> Does that make sense?
>
>
>> For most cases it seems a relatively simple task to me. I'd prefer
>> not to name products, however, if not absolutely necessary. I will
>> try and provide some hints below. If this is not enough to clarify, I
>> will provide some specific links.
>>
>> First of all, it is useful to remember that a complete list of
>> devices such as smart cards that have a CC certification can be found
>> on the website https://www.commoncriteriaportal.org/products/, and
>> for each of them there is a link to download the Security Target.
>>
>
> As you know, reviewing the Security Target is a very challenging task.
> Most of these documents are quite long (more than 100 pages). Even the
> certifications themselves are often 10-30 pages long.
>
>> That said, many of the devices listed here are (or are based on) Java
>> Cards platforms conforming to the relevant Oracle specifications [1],
>> and in that case we already know that the three security functions
>> that I have listed are certainly implemented (as they are part of
>> those specifications). For example, devices based on the NXP's "JCOP"
>> platform fall into this category. The same applies to devices based
>> on Thales' (formerly Gemalto) "MultiApp" platform, G&D's SmartCafé
>> platform and several others.
>>
>
>> However, there also are "native" (non Java Card-based) Card Operating
>> Systems, such as e.g. Atos' (formerly Siemens) "CardOS", also
>> featuring those three security functions, as it can be easily
>> inferred from the related STs.
>>
>
> I understand that there are experts like yourself that are familiar
> with these terms but I'm afraid without the proper guidance from the
> CSBRs or the Code Signing WG, CAs and auditors will certainly have
> difficulties proving that certain devices meet these *more specific*
> requirements of the security target. Perhaps the WG could write an
> article like https://cabforum.org/guidance-ip-addresses-certificates/
> or https://cabforum.org/internal-names/ about how a CA or an auditor
> can find the proper evidence to support the specific requirements of
> the newly proposed section 16.3.
>
>> Another simple rule of thumb for understanding which devices are
>> eligible is to consider devices that are certified as "secure
>> signature devices" according to EU regulations (eIDAS), i.e. as SSCD
>> / QSCD devices, because this implies (let me simplify the reasoning)
>> having the three security features I have listed.
>>
>
> Is there some document/rule that SSCD/QSCD devices must meet the three
> security features you listed?
>
>> A list of devices already selected according to this criterion can be
>> found at
>> https://esignature.ec.europa.eu/efda/notification-tool/#/screen/browse/list/QSCD_SSCD,
>> . For the reasons above, I would consider all the smartcard-type
>> devices listed therein as (potentially) suitable Subscriber devices
>> for Code Signing
>>
>
> I support adding a normative rule that CAs MAY consider that devices
> listed as Qualified Signature Creation Devices (QSCDs) as defined in
> point 23 of Article 2 of Regulation (EU) 910/2014, meet the technical
> specifications and requirements of section 16.3. Then they can use the
> list you provided to simplify the evidence proof.
>
> I would rule out SSCDs as they are no longer considered as secure as
> the QSCDs. Most of them have expired certifications.
>
>> Of course, having considered some devices based on the above
>> criteria, it remains to be verified if they do support RSA keys up to
>> 3072 bits or at least ECC P256 keys, which is not true for all of
>> them, and if they are accompanied by suitable drivers (i.e. PKCS#11
>> and CSP/Minidriver). But these are not matters for the WG to discuss.
>>
>
> I agree.
>
>> Let me know if this answers your question.
>>
>
> This is an interesting discussion and I think we can make some good
> progress and improve this section.
>
>
> Dimitris.
>
>> [1]
>> https://www.oracle.com/java/technologies/javacard-specs-downloads.html
>>
>> Regards,
>>
>> Adriano
>>
>>
>> Il 20/04/2021 13:26, Dimitris Zacharopoulos (HARICA) via Cscwg-public
>> ha scritto:
>>>
>>> Adriano,
>>>
>>> Can you please share some examples of public certifications of
>>> equipment (HSMs and/or crypto-tokens) that contain this additional
>>> TOE security requirements information? This will be helpful for CAs
>>> and subscribers when deciding what equipment to purchase, but also
>>> auditors that will check that this equipment meets the compliance
>>> requirements.
>>>
>>>
>>> Thank you,
>>> Dimitris.
>>>
>>> On 19/4/2021 4:31 μ.μ., Adriano Santoni via Cscwg-public wrote:
>>>>
>>>> All,
>>>>
>>>> as agreed during the last CSWG call, I am attaching to this post a
>>>> first attempt to revise CSBR §16.3 aimed at clarifyng what kind
of
>>>> CC certifications can reasonably be considered acceptable of a
>>>> hardware crypto module for code signing (by the Subscriber).
>>>>
>>>> I cannot help but observe, however, that the third option (bullet)
>>>> in §16.3, although later on is "not recommended", is still allowed
>>>> although antithetical to the second. Basically, this is saying:
>>>> "you must use a certified device, but not necessarily". From a
>>>> logical point of view, it seems to me that it makes no sense. I
>>>> suppose there is a rationale, probably discussed a long time ago ...
>>>>
>>>> Regards
>>>>
>>>> Adriano
>>>>
>>>>
>>>> Il 14/04/2021 22:08, Bruce Morton via Cscwg-public ha scritto:
>>>>>
>>>>> MINUTE TAKER: *??*
>>>>>
>>>>> 1. Roll Call
>>>>> 2. Antitrust statement
>>>>> 3. Approval of prior meeting minutes (8 April 2021)
>>>>> 4. Cross-sign Roots (Corey)
>>>>> 5. Certificate Policy OID for Time-stamping (Bruce)
>>>>> 6. Common Criteria requirement – update required for CSBRs?
>>>>> 7. CSCWG-6 ballot - status/questions (Ian)
>>>>> 8. Clean-up ballot – status (Bruce) – SAN, CRL, FIPS 140-*2*,
>>>>> Root/SubCA Key size, Cross-certificate, TS SHA-1,
>>>>> Interoperability verification
>>>>> 9. Any other business
>>>>> 10. Next Meeting Apr 22^nd
>>>>>
>>>>> **
>>>>>
>>>>> *Bruce.*
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Cscwg-public mailing list
>>>>> Cscwg-public at cabforum.org
>>>>> https://lists.cabforum.org/mailman/listinfo/cscwg-public
>>>>
>>>> _______________________________________________
>>>> Cscwg-public mailing list
>>>> Cscwg-public at cabforum.org
>>>> https://lists.cabforum.org/mailman/listinfo/cscwg-public
>>>
>>>
>>> _______________________________________________
>>> Cscwg-public mailing list
>>> Cscwg-public at cabforum.org
>>> https://lists.cabforum.org/mailman/listinfo/cscwg-public
>>
>> _______________________________________________
>> Cscwg-public mailing list
>> Cscwg-public at cabforum.org
>> https://lists.cabforum.org/mailman/listinfo/cscwg-public
>
>
> _______________________________________________
> Cscwg-public mailing list
> Cscwg-public at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/cscwg-public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210421/69821533/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/20210421/69821533/attachment-0001.p7s>
More information about the Cscwg-public
mailing list