CMFA Signal verification/PAD

[woodbe]

Going through the sections in the ESR again, I am wondering about the PAD/signal verification portion and comparing it to some of the biometrics.

In the straight BIO-PPM, PAD is optional, since it is something that is difficult and likely would prevent some solutions from being able to pass, even at limited testing (which is hard to define).

But CMFA is pretty much an ongoing PAD check to verify that the person who initially authenticated is still the one in possession of the device. So the question then is whether PAD (or as named for CMFA, signal verification) is actually optional. It doesn't seem like we have any expectation that decisions would be made solely by the CMFA Engine, that most signals would go through some sort of verification (potentially everything could, with the trusted inputs being given a no-check pass to the Engine). So this would imply that the at least the verification part of impersonation would be mandatory, as opposed to optional. Checks during enrolment would seem to actually be optional since it is more about providing providing an ability to "pre-configure" part of the CMFA engine to force enrolment to be done under specific conditions.

So it would seem to me that the Attacker Access needs to be edited to include impersonation during verification through the use of the signal verification step.

[n-kai]

I think that it may be difficult or time consuming for lab to test all sensors to try to spoof them. Instead, PP should require CMFA to use set of sensors that can't be spoofed at the same time by an attacker with basic attack potential (and evaluators verify that it can't be done by basic attack potential referring public available information).

[woodbe]

Points on the call:

• most sensors have a binary yes/no outcome, and so should be simple to check
  • some may have range info (like proximity detection or location data), but that should still be relatively simple
• a question is how exactly to test all this, both due to time but also the aggregation of the data
  • an approach may be to check one sensor at a time, keeping everything else the same and see how the signal verification reports the results and then see how the engine changes the results
  • the expectation here would be to check them individually, and not focus on how multiple changes would change the score, but verifying individual pieces
  • this may not actually be attack detection, but just signal verification (checking that the signal changes do result in output changes) which may be more readily possible vs actual spoofing detection on the sensors
• sensor trust needs to be established in some manner by the vendor so it is understood how the input is checked (or not)

[woodbe]

I think this falls under the trust/reliability of the inputs. I do not think we need to specifically define an ESR for this, but that the definition of trust on an input will provide verification for the underlying components.

Determining current confidence should then handle any requirements needed to specify aggregate score data