[Cscwg-public] CSCWG Agenda Apr 15, 2021

Adriano Santoni adriano.santoni at staff.aruba.it
Thu Apr 22 07:05:26 UTC 2021


although the QSCD/SSCD issue may not be germane to this discussion .... 
can you point me to any QSCD device whose CC certification is based on a 
PP other than the one I mentioned? Or put another way, can you explain 
what are the differences between QSCDs and SSCDs? I am asking this 
candidly: I do not know, so I'd love to learn.

Coming back to the "core" issue:

I will give a concrete example of a device which, although it can be 
said (with a lot of poetic license, IMO) that it has a CC certification, 
I believe it does not meet the requirements of §16.3 (as I understand 
them). The "Nitrokey" product mentioned by Tomas some time ago is 
actually a family of devices with very different characteristics from 
each other. One of these, called "Nitrokey Pro", is based on a 
microcontroller (i.e. the HW component) with CC EAL5 + certification 
[1]. AFAIK, it is a very good microchip that has been used a lot, albeit 
now obsolete. Well, that microchip /in itself/ doesn't have any 
functionality to 1) generate RSA or ECC keys, 2) execute signatures with 
those keys, 3) protect those keys. These features are (more or less) 
implemented by the Nitrokey firmware, which has no CC certification 
(please note: I am not saying that such firmware is or is not secure). 
If I am saying something wrong, I'd love to be corrected.

In short, in my opinion that device - although in practice it may be 
used and perhaps works very well - does not comply with §16.3, unless we 
clarify that the CC certification mentioned in §16.3 is to be understood 
as referring to any part of the device, and without reference to any 
particular functionality (if this is the interpretation that the WG 

[1] https://www.commoncriteriaportal.org/files/epfiles/0555a_pdf.pdf


Il 21/04/2021 19:55, Dimitris Zacharopoulos (HARICA) ha scritto:
> 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:
>> * FCS_CKM.1 Cryptographic key generation (page 28)
>> * 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/20210422/e34aff36/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/20210422/e34aff36/attachment-0001.p7s>

More information about the Cscwg-public mailing list