iTC Meeting Minutes 2025 07 22 - biometricITC/cPP-biometrics GitHub Wiki
Call started at 10:02am EDT
The call started with a quick review of the task list. There were no updates.
The call then moved to BIOSD AP Table changes. The main discussion here was focused on the table showing the attack potential and relationship to the AVA_VAN levels. The concern is that the standard way of handling AVA_VAN under CC will be a problem for biometric testing. Traditional CC testing for AVA_VAN can be somewhat open-ended, leading to problems in terms of actually getting reasonable timeframes for completion on biometric testing, which is known for some scenarios to take many months anyway given the number of subjects/samples involved.
Kevin’s proposal in ISO sort of divorces the AVA_VAN from the attacks, with them instead being defined with time periods to be able to perform the testing in, trying to map the levels to what is being proposed in the EU for the various systems requiring biometrics there. The problem is that this isn’t exactly CC, and still doesn’t provide an easy way to classify the attacks for use.
Brian proposed that we keep the CC version of the mappings, but provide justifications as to why something more like Kevin’s evaluation proposal is acceptable for each of the PAD levels. Doing this could lead to questions, but an extensive justification would be more likely to be accepted as a valid approach.
Part of the thinking here may be to rely on FiTCEM methodology a little bit when defining how to do the testing. It was noted that while technically CC may allow for unlimited time, the realities of how evaluations are done mean that there are always limits, the question is more about how to utilize that in a formal evaluation to provide boundaries that can be seen as acceptable.
Brian proposed that the method may be to not focus on time but to use something more like the FIDO method which provides that a specific number of tests must be performed, and that once those are done, no more are added. This could be done, or provide a little more flexibility to the lab to choose the set from the whole list for each level, specifying the minimal number at each level and then leaving the lab to document and justify their selections. Doing it this way means not having to specify a time limit for the testing, but utilizes the number of possible tests to limit the time by specifying that this should be a representative set for any individual system under evaluation. This does provide a little more variability in the outcomes from a purely direct comparison, but probably not sufficient to discount the idea off hand.
The smart card PP (whatever has the AP table defined for EuroSmart) should have some ideas for the justification needed for changing the table and may also be useful in pointing how to deal with the attacks themselves, how many to test, etc.
Brian pointed out the other issue we have here is that you can’t mix AVA_VAN levels in the document, at least not the way anyone is doing it now. Under CC:2022, it is accepted that you can add a higher SAR value over a lower one using a PP-Module, so that means we will need to create at least 2 more PP-Modules, one for AVA_VAN.2 and another for AVA_VAN.3 corresponding to PAD L2 and L3 respectively. The smart card group is working on this now, but Brian wasn’t sure if they had a draft published yet, he was checking on the side, but didn’t remember off hand.
Related to this is that if the PP-Module is tied to an EU PP then it will be AVA_VAN.2 by default, and it probably can’t defined AVA_VAN.1 for the fingerprint part, meaning that any device using this PP-Module with an EU PP would probably have to test PAD (if they test PAD) and Substantial, or AVA_VAN.2.
The call ended at 10:49am EDT.