Are biometric sensors inside the TOE boundary?

[woodbe]

Multiple times the current draft is written so it seems like the biometric sensor and its data may be included in the boundary of the CMFA product. I'm not saying this isn't possible, but is this our intent?

I could see this as some sort of optional extension (maybe), but I'm not sure.

[n-kai]

@woodbe I just want to clarify the difference between TOE without sensors and TOE with sensors under different operational environment.

A) If sensors are included in the TOE boundary and there is no assumptions in the PPM for preventing the spoofing attacks to sensors:

• Any information about sensors required by the Supporting Document (not sure now but not much information) should be provided to the lab so that any evaluation activities in SD can be done by the lab
• Any test equipment to test sensors should be provided to the lab so that the lab can run spoofing attacks below basic attack potential if it's difficult for lab to prepare such equipment
• If CMFA can no longer meet security requirements in the PPM because easy spoofing attacks (below the basic attack potential) to sensors is published, CC certificate could be withdrawn

B) If sensors are included in the TOE boundary and there is an assumption defined in the PPM for preventing the spoofing attacks to sensors:

• Any information about sensors required by the Supporting Document (not sure now but not much information) should be provided to the lab so that any evaluation activities in SD can be done by the lab
• Lab doesn't need to run spoofing attacks
• Manual needs to include some instructions so that device user can meet the assumption (e.g. user should use the device under the controlled environment to prevent the spoofing attack)

C) If sensors is not included in the TOE boundary:

• Lab doesn't need information about sensors
• Lab doesn't need to run any attacks to the sensors
• Manual doesn't need to include any information about sensors (because it is the responsibility for mobile device vendors (that implement the CMFA into the device) to instruct users to use the CMFA with sensors securely
• some schemes may not be interested in such CMFA evaluation (schemes usually like the TOE scope that include all necessary parts that implements SFRs in the PP)

The current ESR choose B) with some modification.

• Vendor can include only those sensors that can be trusted within the TOE scope. Trusted sensors are ones that are configured into secure execution environment so that untrusted entity can't access to the sensors and its data and if the sensor uses biometric characteristic (e.g. microphone for voice), vendor should provide performance test data.
• Vendor should provide basic data (e.g. device name and manufacturer) about sensors within the TOE scope to the lab
• Vendor should configure a set of sensors that an attacker who possess basic attack potential can't spoof all sensors at once.

But above is my initial idea and any comments would be welcomed.

[woodbe]

@n-kai So I drew the initial boundary actually more as C, not B, so as to limit the scope of the CMFA to the engine itself, and not everything where it is getting data. For example, I wouldn't want to include the timer in the scope, but that should also quality as a trusted source with a secure path for input.

My thinking is more along the lines of this:

The TOE is the engine, management and what we called the signal verification component (which may just be part of the engine). The input that can come into the TOE, is assigned (by the vendor) to have some level of trust, which leads to how it is handled by the engine (or the signal verification component). If I want to use a biometric on the device (built-in) that has a trusted path to the TOE, it should get a higher trust than say a front-facing selfie camera that does not (i.e. a camera with a trusted path should be considered better than one without). If the vendor wants to establish a higher level of trust for the biometric, it should be validated to the BIO-PPM (and ideally include PAD).

How the vendor assigns the trust (or possibly verifies input to assign trust) should be reviewed, and combinations of inputs tested, but the specific inputs, to me, ideally would be out of scope of the CMFA itself.

I would expect an evaluation that encompasses CMFA to also include MDF and BIO-PPM, so you would have a combined TOE with all three, but the scope of the CMFA would not actually cover the biometric.

I am not fixed to this, it is how I see it now.

[gregott]

I agree that the TOE boundary should be limited to the Admin function and the CMFA engine which, the more I think about it, also includes the signal verification component. It is possible that a vendor may have multiple versions (e.g. sizes) of a mobile device with different sensors but the same CFMA engine. Including the sensors in the boundary will multiply the number evaluations needed. How the CMFA engine performs with a given set of inputs is what needs to be evaluated. The levels of trust for the various sensor data coming into the TOE can be specified by the vendor based on the device design.

[woodbe]

@gregott this is exactly what I am thinking (and the verification component is definitely part of the TOE boundary).

[n-kai]

When I talked to Japanese bank implemeting biometric authentication, they said that their main concern was biometric performance and presentation attacks. Bank normally asks IT vendors to evaluate the security of their system, however, there is no such vendors who can test or evaluate biometric performance and presentation attacks. that's why they asked a Japanese mobile biometric vendor to get a CC certificate to test biometric verification functionality.

If the bank considers to introduce the CMFA for their banking service (I don't know when it could happen), the same things could happen (they may concern the spoofing attacks to sensors). Can verification component prevent spoofing attacks so that the bank can explain to the customer that their continuous authenticaion is secure enough? That's my concerns.

[woodbe]

So I think what we need here is to specify two classes of biometrics, and with a trusted and untrusted set available. For example I could use ECG, which is unlikely to be certified anytime soon, as a biometric, but it wouldn't necessarily meet the BIO-PPM, and that is OK, as long as it isn't "trusted" (which is of course a somewhat vague term, but it has been defined in the latest version of the ESR, sort of).

My expectation here is that the PP-Config initially would be MDF+CMFA+BIO if the vendor wants to include a trusted biometric (which would seem to be the expected configuration). If there is no BIO portion, then biometrics could only be used as untrusted.

[woodbe]

I think this can be closed since the CMFA would be evaluated as part of a composed TOE (PP-Config) and if they want the biometric as "trusted" it would need to be included, then this is handled. They are outside the CMFA TOE boundary, but inside the "evaluated device" boundary of the MDFPP (or whatever other allowed composition we allow).

The main thing to remember is that it is only acceptable to use PP-Modules with approved base PPs (and the iTC has a say in what is or is not acceptable), so it isn't like someone can come and take the CMFA and use it in a configuration we haven't already approved. So if we want to say, in the end, that there MUST be a trusted biometric, then we don't provide a PP-Configuration that would allow say only the MDF+CMFA on its own. This would prevent that configuration from being evaluated.