PADv2 integration

[woodbe]

1. FIA_MBV_EXT.3.1 The TSF shall prevent use of artificial presentation attack instruments utilizing [selection: PADv1, PADv2] for the biometric modality.

FIA_MBV_EXT.3.2 The TSF shall provide a biometric verification mechanism with the IAPAR not exceeding [assignment: value equal to or less than 15% (15:100)] to prevent use of artificial presentation attack instruments from being successfully verified.

2. Create a new SFR (based on the above FIA_MBV_EXT.3.1) that has a selection with [PADv1, PADv2, none] that is mandatory, and forces the selection.

The FIA_MBV_EXT.3 SFR becomes selection-based instead of optional

3. FIA_PAD_EXT.1.1 The TSF shall prevent use of artificial presentation attack instruments utilizing [selection: PADv1, PADv2, no PAD] for the biometric modality for verification and [selection: enrolment, no other times].

4. first select whether PAD is being done for verification, enrolment or none second, if not none, then bring in PAD requirement as selection PAD level can then be part of PAD requirement

FIA_PAD_EXT.1.1 The TSF shall prevent use of artificial presentation attack instruments for the biometric modality for [selection: verification, enrolment, no PAD].

[woodbe]

To make PADv1 mandatory:

FIA_MBV_EXT.1.1 The TSF shall provide a biometric verification mechanism using [selection:

• eye;
• face with FIA_MBV_EXT.3;
• fingerprint with FIA_MBV_EXT.3;
• vein ].

Using something like the first option from first comment.

[woodbe]

First thought, keep PAD optional for now, so use this:

FIA_MBV_EXT.3.1 The TSF shall prevent use of artificial presentation attack instruments utilizing [selection: PAD-L1, PAD-L2] for the biometric modality.

FIA_MBV_EXT.3.2 The TSF shall provide a biometric verification mechanism with the IAPAR not exceeding [selection: PAD-L1 [assignment: [with a value equal to or less than 15% (15:100)]], PAD-L2 [assignment: [with a value equal to or less than 10% (10:100)]]] to prevent use of artificial presentation attack instruments from being successfully verified.

This then also increases the IAPAR requirements as the PAD level increases.

Then when making PAD-L1 mandatory, use something like from https://github.com/biometricITC/cPP-biometrics/issues/416#issuecomment-1688351788

[woodbe]

Add new section in the PPM 2.3.1.3 that talks about PAD and levels based on the AP. Make it generic, not specific to L1/L2 so that future updates would not require changes.

Seems to be minimal changes otherwise, even in the SD (probably).

Most changes will be incorporated in the toolbox docs.

[woodbe]

Integration should consider that both enrolment and verification should have the same PAD level for a modality (while it may be acceptable to have L2 at enrolment and L1 for verification, this seems to be an edge case that isn't really needed). As such the FIA_PAD_EXT.1 (or similar) SFR should mandate the PAD level for both at the same time.

The SFR should be written using a table like in the Crypto WG stuff that shows the available options for PAD and the modalities so the selection doesn't get really complicated.

It isn't clear if the SFR should be mandatory or optional. @woodbe would prefer mandatory, but the question there is how to write it such that the requirement makes sense when selecting there is no PAD.

FIA_MBV_EXT.3.2 should still have the selection based on the PAD as the IAPAR needs to be adjusted based on the PAD level.

@woodbe will try to create a pull request before the next non-PAD call with the SFR changes.

[n-kai]

I think that we have following options about how to use the PAD-L2.

1) Modify SFRs in the PPM so that uses can select PAD-L1 or PAD-L2, as Brian proposes in PR #419 2) Create a separete standalone protection profile for PAD-L2 3) Create a Multi-Assurance PP configuration for PAD-L2 that specify the Base PP as MDFPP and the biometric PPM at diffrent assurance level (this may be a risky option because there is no Multi-Assurance PP configuration that has been certified by the schemes)

If the main target of PAD-L2 is EU market (i.e., eIDAS2), I think that we should wait until the requirement of eIDAS become clear. We should select a best option to fit the needs of eIDAS.