search

biometricITC / cPP-biometrics

Contains the development of a Collaborative Protection Profile for biometrics
MIT License
10 stars 2 forks source link

FPT_BDP_EXT.1 EA update #346

Closed woodbe closed 3 years ago

woodbe commented 3 years ago

This is to match FPT_BDP_EXT.1 testing requirements to match the updated SFR.

This will close #340

One thing I am not certain about is how easy (or possible) scanning during the process itself is. I know that many tests using memory dumps cause the system to stop so it can write out the RAM contents to disk, so setting this up may be difficult since you couldn't readily scan memory, then do something and scan it again to check for the changes. I do think this is possible (with engineering builds), but am not certain on all platforms.

The other concern is the timing. It may be difficult to get the scan during the verification step (the period for that should be small, though maybe the vendor could provide a special app to request the verification that would trigger the scan too, I don't know).

@The-Fiona what do you think about this? I had a similar dump process described to me once for Samsung devices, but it has not been used in CC testing before.

Variations could be to just allow the scan to proceed after the transaction to see if anything is left after the process completes.

gfiumara commented 3 years ago

This change seems to switch from checking for files to checking in memory. Shouldn't we do both? It's seemingly now valid to write biometric data to a file (...or did we handle this elsewhere?).

woodbe commented 3 years ago

@gfiumara So this requirement was rewritten such that it now is more about the execution of the process along with making sure that data from the sensor to wherever it is processed is secure. Storage would really be part of FPT_KST_EXT.1 which is part of the MDF, and specifies how to test for plaintext keys (and by our refinement, biometric data) being stored.

Basically what happened is I rewrote the SFR itself based on the changes, but missed editing the evaluations activity, so this is the "fix" for that.

n-kai commented 3 years ago

I don’t have any experience to dump the memory of mobile but had some for mainframe OS. Mainframe provides tools to take a dump through the API (so you can add this API to take a dump at specific timing) or an operator command however it’s hard task to analyze the dump and requires skill and experiment. I believe that all evaluators don’t have such skill and experience, so the developer have to provide a program that check the dump to find the biometric data.

It’s OK for me if it’s easy task for developer to develop such code but we can take another approach. For example evaluation activity for TSS can requires the developer to provide the information in BMD such as:

We can also add Evaluation activity for Tests like below.

I can create a PR based on EA for FPT_AEX_EXT.4 in MDFPP if other members agree with this approach.

woodbe commented 3 years ago

@n-kai so I actually wrote this more like the FCS_CKM testing where it revolves around memory dumps instead of using apps to test things. At least on a Samsung device, it is not easy to add apps to the TEE, this is restricted and generally is handled solely through firmware updates. So things like the apps being stored in the locations you state is OK, those are on the read-only partitions, so the app is trusted when it is loaded (and data is not stored there, only the app). iOS isn't exactly the same, but I don't think they allow loading of apps into the Secure Enclave, either.

I guess I'm not really sure what benefit there is for writing a trusted app to be installed inside the TEE and then to look for it. It is possible for apps inside the TEE to write data outside, the real question is whether the biometric system apps do that, not whether it is possible. Just writing data on its own inside could show that it is possible to not do so, but I'm not sure that provides anything useful (maybe it does, since it would show the default behavior, but I'm not sure how relevant that is).

What I was thinking was something along the lines of (for face, which may be an easier example), to do an authentication event and then see if there is a photo stored in main OS memory. This would show whether the camera dumped the data to the main OS or somewhere else (i.e. the TEE).

n-kai commented 3 years ago

@woodbe Writing a trusted app to be installed inside the TEE is just my idea please forget about it but I don't know how the following activities can be done.

4. The evalautor shall perform a memory scan during the biometric transaction and compare the results to the scan before the biometric transaction 5. The evaluator shall confirm that the changes between the two scans do not show access to the biometric data

Evaluation activities for FCS_CKM.4 in MDFPP is defined as follows.

For these tests the evaluator shall utilize appropriate development environment (e.g. a Virtual Machine) and development tools (debuggers, simulators, etc.) to test that keys are cleared, including all copies of the key that may have been created internally by the TOE during normal cryptographic processing with that key.

Test 1: Applied to each key held as plaintext in volatile memory and subject to destruction by overwrite by the TOE (whether or not the plaintext value is subsequently encrypted for storage in volatile or non-volatile memory). In the case where the only selection made for the destruction method key was removal of power, then this test is unnecessary. The evaluator shall:

1.Record the value of the key in the TOE subject to clearing. 2.Cause the TOE to perform a normal cryptographic processing with the key from Step #1. 3.Cause the TOE to clear the key. 4.Cause the TOE to stop the execution but not exit. 5.Cause the TOE to dump the entire memory of the TOE into a binary file. 6.Search the content of the binary file created in Step #5 for instances of the known key value from Step #1. 7.Break the key value from Step #1 into 3 similar sized pieces and perform a search using each piece.

Steps 1-6 ensure that the complete key does not exist anywhere in volatile memory. If a copy is found, then the test fails.

Step 7 ensures that partial key fragments do not remain in memory. If a fragment is found, there is a minuscule chance that it is not within the context of a key (e.g., some random bits that happen to match). If this is the case the test should be repeated with a different key in Step #1. If a fragment is found the test fails.

Biometric data is not known value and there are lots of memory changed between two memory scans. How can the evaluator confirm that there is no biometric data or biometric data fragments in memory? If we don't have clear idea about how to do that, it's better to delete "2.4.1.7.1. Strategy for ATE_IND"

woodbe commented 3 years ago

I don't have a problem removing this test from ATE_IND. What I could see is that the given the developer would have to provide the tools to perform the test, they could also provide some sort of example of what the biometric scan looks like (i.e. if you could actually see it, you would be looking for a raster image or something), and then you could possibly look for this in the memory dump. What I don't know is how easy it would be to interrupt the processes for the dumps, given how they usually work for the keys (it requires basically killing the device to dump memory, though I have been told it could be done without that, though it could potentially leave a small amount of memory unscanned which is running the process, so you would likely need to run the test a few times to make sure something wasn't missed by the dump process).

n-kai commented 3 years ago

I don't know this works but we can leave as it is for public review (that's why I agree with this PR) and if we can find more clear evaluation activity for ATE_IND during public review, we can add it to BIOSD. If we can't, we should delete "2.4.1.7.1. Strategy for ATE_IND"

woodbe commented 3 years ago

call this out in the public review document