"secure" sensor input SFR

[woodbe]

I was thinking about our SFRs and the changes we are making for the MDF, and one thing that I thought of was that we don't have some sort of secure path between the input sensor and the processing. This would probably be something along the lines of:

The TOE shall prevent the operating system on the device from intercepting biometric input from the user.

This could be a new FPT_BDP_EXT.2 requirement.

The idea would be that the OS must not have access to the path between the sensor and the separate execution environment, and hence be able to possibly copy, modify or replace the data submitted by the user.

I had largely been relying on the concept of the SEE that we had defined to handle this, but now that we have been editing for the MDF and taken that away, I don't see how this trusted path is established/verified, and so I think we may need a new requirement for it.

[n-kai]

The idea would be that the OS must not have access to the path between the sensor and the separate execution environment

I agree with you. I defined FPT_BDP_EXT based on "Android 10 Compatibility Definitiony" 1) and I originally planned to develop evaluation activities referring implementation guidelines 2), however this is the guidelines for android and I am not sure they are also applicable to iOS or other devices.

[C-2-4] MUST have all identifiable data encrypted and cryptographically authenticated such that they cannot be acquired, read or altered outside of the isolated execution environment or a chip with a secure channel to the isolated execution environment as documented in the implementation guidelines on the Android Open Source Project site.

1) https://source.android.com/compatibility/10/android-10-cdd 2) https://source.android.com/security/biometric#hal-implementation

[woodbe]

@n-kai so I know that iOS devices can meet this requirement (they establish encrypted channels between components like the biometric sensor to the Secure Enclave), so as long as we don't get too specific, we should be OK. As for other devices, this is basically what we ran into with the OS integration, that there wasn't an SEE to define to use, so we may be better off here with this new requirement under an expectation of a self-contained sensor (so the sensor and engine are not reliant on the OS itself, like a USB device).

Originally I had expected we could rely on the MDF to take care of this, but clearly the MDF isn't specific enough for this particular issue.

So the question though is how this should be written. What I don't think we want to do is get into defining requirements that will require encryption in such a way that we will have to bring in FCS requirements (unless we think we can rely on the MDF for them, but I'm not sure if that works for iOS or not via the MDF). It may be enough to say that we want the vendor to show how the path is separated from the OS, but we will have to think about this. I would prefer not to need to bring in FCS requirements if at all possible (even in the way of saying that you need to rely on the MDF FCS requirements for this), but we may have to.

[n-kai]

@woodbe Originally I had expected we could rely on the MDF to take care of this, but clearly the MDF isn't specific enough for this particular issue.

I assumed that DSC cPP would extend the MDF PP to cover the SEE or trusted pass (but I am not sure whether or not the vendors are happy to use this cPP) . But if we define SFR and evaluation activities for SEE or trusted pass, there may be some overlap between DSC cPP/SD and our PPM/SD. I am worrying that DSC iTC may complain about this overlap.

[woodbe]

Yeah, DSC would technically take care of it, but I'm not sure it is going to be widely used in the MDF world at this point (it may, but I don't know). I wouldn't worry about a potential conflict unless we are going to expect to use it right now, since we can always add similar adjustments for DSC as we will for MDF if we go there.

[woodbe]

Check the GP TEE PP-Module for Biometric subsystems to get ideas for defining the SEE

Consider FPT_AEX_EXT.4 from MDF as possible solution

Another possible option would be to use FTP_TRP.1 in a refinement from the CC docs directly, and choose the options for the requirements.

[woodbe]

So I forgot to bring up the FTP_TRP.1 on the call (I noted it above after), and that seems to be the best option out of the GP TEE-Bio PPM. I don't like the FDP_ACC.1/FDP_ACF.1 combination as I think that brings in a lot of extra stuff, but I also don't see how that would work in the basic setup we are talking about. That would have to be based on some combination of MDF and Bio, and I'm not sure exactly how to write that.

My other concern with these requirements is they have a TEE to rely on (since this is a PPM to the TEE PP), so they already have the wrapper, so to speak, of the SEE. I do think the Trusted Path though may be the best way forward.