[Cscwg-public] CSCWG Agenda Apr 15, 2021

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Wed Apr 21 17:55:28 UTC 2021



On 21/4/2021 4:07 μ.μ., Adriano Santoni via Cscwg-public wrote:
>
> 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)
>

This is not my understanding at all. Some chips/components may be the 
same, but the certification is new. It's not a re-certification.

>> 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.
>

I will let others chime in and provide feedback if they expect this type 
of information to be clear and unambiguous for a CA and an auditor that 
has to examine certifications and security target documents for specific 
crypto devices.

My opinion is that without the proper guidance from this group, this is 
too complicated and will cause mistakes and confusion.


Dimitris.

> 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
>
> _______________________________________________
> 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/4331e264/attachment-0001.html>


More information about the Cscwg-public mailing list