Comment on OSP.ENROL

[n-kai]

OSP.ENROL (Original text in the integrated cPP) The TOE shall implement the functionality to enrol users. The TOE shall ensure that enrolment records are of sufficient quality in order to meet the requirements on recognition performance. Start of Enrolment shall only be possible after authorization of an authorized administrator.

(Proposed text for this cPP) The TOE shall enrol users for biometric verification, only after successful authentication of a user. The TOE shall ensure that enrolment templates are of sufficient quality in order to meet the requirements on recognition performance.

Rational In case of mobile, there is no admin. So no authorization by admin isn’t necessary however user should be authenticated with password before stating enrollment.

[nils-tekampe]

Are we sure that there is no admin? In the mobile use case in companies and governments there may be an admin? And it could also be an option to simply keep the administrator but allow the user to perform the role of the admin. That could make it more flexible. Or are we purely focusing on a commercial use case?

[n-kai]

Mobile cPP should cover both cases (enrolled mobile device with MDM admin and unenrolled mobile device with user acting also as admin).

I assume that mobile cPP for use case 1 would be used with MDFPP so I want to avoid any overlap between the two.

My concern is "Start of Enrolment shall only be possible after authorization of an authorized administrator" is already defined in the MDFPP.

MDM admin for enrolled mobile device or user for unenrolled mobile device can enable/disable the use of biometric authentication. This requirement is defined in the MDFPP (FMT_SMF_EXT.1) and should be evaluated during the CC evaluation based on MDFPP. So Mobile cPP for use case 1 does not need to include this admin function.

However the user, defined as "A person who uses a biometric system to get enrolled or verified" in the current bio SPD, need to enter the PIN to authenticate his/herself before starting enrolment. I believe that this requirement is not covered by the current MDFPP.

However such admin function (enable/disable the use of biometric authentication) may need to be included in the Mobile cPP for use case 2 because this use case 2 is not assumed to be evaluated with MDFPP.

I need more time to think about this one and come back to you with new proposal.

[woodbe]

The MDFPP FDP_PBA_EXT.1 requires that the authentication template (biometric template) be protected with a PIN/password. Further, the MDFPP requires a password, regardless of whether or not biometrics will be used. Also, FIA_UAU.1(1) requires the password to be entered before changing any supported authentication mechanism. So to enroll a biometric would mean you are changing the authentication mechanism and hence would require you to enter a password (since the evaluated configuration requires a password).

I want to point out though, that on mobile devices today (I'm not talking about purpose built or Windows 10 devices that are tablets such as Surface devices running desktop OSes) there really aren't multiple users such as available on desktop or similar systems. The devices generally run as a single user, and in the cases where multiple users are allowed, they are really equal. So there isn't an ability, in general, to force things directly. While an admin can block enrollment by blocking biometric access, they can't force enrollment once it is enabled, but if the user does decide to enroll, they will be subject to the requirements in the MDFPP (forcing a password entry before enrollment).

[nils-tekampe]

As with the other comments: I think that I do not yet have a sufficient understanding of the use case that we are developing for. The use case description does not say anything about being for single user devices only. If this is the case that we want to develop for, I would suggest that we go back to a discussion on the use case.

[nils-tekampe]

From the telco:

• mobile devices have MDM systems that can be seen as admins
• However, MDM systems may still be limited in capabilities and have not the same level of control as e.g. an admin on a Windows server.

[woodbe]

@nils-tekampe I want to point out that while in general mobile devices are single user, they are not always that way. Generally it is tablets that tend to get multi-user capabilities, but the same exists there. There isn't an admin control on the device that can force a user (any user) to enroll the biometric at some specific time. The admin may be able to allow or prevent the biometric being used , but that is it.

So in the end we have to rely on the user to perform the enrollment and generally today we have a requirement that you need to have a PIN (or password, etc) also set before you can enroll a biometric.

[BrJu]

Can we try to cope with both situation by merging "Start of Enrolment shall only be possible after authorization of an authorized administrator" and "only after successful authentication of a user." into the following condition that would cover two options?

only after authorization of an authorized administrator or after prior successful authentication of a user

If there is no admin, the second option is the only possible one. If there is an admin, the possibility to go for the second option will depend on rights assigned by the admin, and thus is a consequence of an authorization by the admin (i.e. the 1st option).

[BrJu]

Checked during today meeting: seems feasible. @nils-tekampe @woodbe please provide your feedbacks

[woodbe]

I can agree to this, but the context explained should be added in a note. Something to the effect that authorization by an admin may be allowing the user to enroll a biometric and not any specific steps of an admin logging into the device to begin a specific enrollment process.

[nils-tekampe]

I agree that this can be the direction to move towards. However, this still does not cover the multi-user approach. Do we rule this out by definition?

[woodbe]

@nils-tekampe what exactly are you expecting to be different in the multi-user (but still limited admin) use case? Are you talking specifically about users having their own, separate biometric templates associated with their own "account" and not a generic "system" account access? I want to be sure I understand exactly what you are expecting in this case.

[nils-tekampe]

@woodbe As far as I understood the explanations before, the approach is that an authenticated user automatically gets the permission to enroll the biometrics. That can make sense in case that only one user is existing. However, in a multi user environment I guess that rules would be needed to make clear that such a user can only enrol a template for themselves. So, I just wanted to understand, whether the multi user system is still under consideration.

[BrJu]

Open discussions:

** Multiple users?

• use case 1: only for 1 user (even if several, they would have the same identity for the MDM system)
• other use cases: to be discussed

** Admin ?

• if MDM system, that makes switching off biometric possible, we need an additional assumption (or a note) that the functionality will be switched on at some point.
• to rename admin as biometric system admin + note on that user = bio system admin for use case 1.

@n-kai : please take them in account for use case 1

[BrJu]

to remain open afterward for use cases 2+

[n-kai]

I added the following text to 2.4 TOE use case. This use case assumes that the mobile devices are configured correctly to enable the biometric verification by the biometric system administrator. The users can act as the biometric system administrator in this use case. It is also assumed that the users enroll themselves correctly at secure environment following the guidance provided by the TOE. Attacks during enrolments are out of scope and FTE is not security relevant performance matrix for this use case.

[stemotre]

After reviewing the entire cPP I would like to highlight a few findings:

• in OSP.Enrol text, the initial proposition from Naruki in this thread to change "templates" to "enrollment templates" is important to provide context in this 2nd sentence.
• in FIA_MBE_EXT.2.1. text, the property of "sufficient quality" is not applied to the template (like required by O.Enrol) but to the samples. So we are suggesting good quality samples are OK to cover requirements of good quality templates, and I do not see this is a property of the TOE described in this cPP (there is no SFR that enforces this).

[n-kai]

OSP.Enrol The TOE shall enroll a user for mobile biometric verification, only after successful authentication of a user. The TOE shall ensure that templates are of sufficient quality in order to meet the relevant error rates for mobile biometric verification.

• latest cPP doesn't differentiate two type of templates (i.e. enrollment template and authentication templates) because all mobile devices may not create authentication templates. "templates" in 2nd sentence means any templates that the TOE creates, including authentication templates.

FIA_MBE_EXT.2 Quality of biometric samples for mobile biometric enrolment FIA_MBE_EXT.2.1 The TSF shall only use samples of sufficient quality to create the templates.

• I would like to change the SFR as follows because the TOE may ensure the quality of template in different way and above SFR may be too specific.

FIA_MBE_EXT.2 Quality of biometric templates for mobile biometric enrolment FIA_MBE_EXT.2.1 The TSF shall create templates of sufficient quality.

FIA_MBE_EXT.2 covers both enrolment and authentication templates. Please see "EA for FIA_MBE_EXT.2" in https://github.com/nils-tekampe/cPP-biometrics/blob/master/input/BS%20SD.md

[BrJu]

Agreed on proposed change. @stemotre To be checked for MDV_ETX2

[stemotre]

(deleting my previous comment as the change proposed by Naruki was not in master yet) With the change proposed by Naruki on FIA_MBE.2, the content would be fine. No need to make any change to MDV_EXT.2 per my understanding.

[BrJu]

Perfect, thanks for confirming. So ready to be closed for the quality aspect. Multiple users will have to be discussed for use case 2+