This new PR supercedes #387 due to the number of changes that were made in #380 that coincided with the changes for this topic.
I left this somewhat open to the possibility of there being some sort of API that can be disabled by the admin that could allow for the export of data, and stated that in the required configuration this has to be disabled. I don't know if this is needed, but given the explicit statement of externally transmitted data being out of scope, I thought that it may be necessary to state that along with the expectation that the data would be stored locally (as opposed to remotely). That could be removed, but I was trying to not get too prescriptive here.
The TSFI test is basically limited to testing from the main OS and trying to get data back. This is because I think otherwise we are trusting the SEE to protect access to the TOE, so if you can't get to it from the main OS, you can't get to it because it is protected by the SEE, which is out of testing scope.
We could add in some sort of explicit testing within the SEE (I would still limit it to TSFIs that may allow for exporting data), with the idea that if there is some sort of compromise of the SEE at least plaintext data isn't normally lying around (outside of in the middle of a transaction, anyway, which is not really something we can do anything about). This depends though on the level of protection that is expected in the security provided by the SEE.
This is to close #371.
This new PR supercedes #387 due to the number of changes that were made in #380 that coincided with the changes for this topic.
I left this somewhat open to the possibility of there being some sort of API that can be disabled by the admin that could allow for the export of data, and stated that in the required configuration this has to be disabled. I don't know if this is needed, but given the explicit statement of externally transmitted data being out of scope, I thought that it may be necessary to state that along with the expectation that the data would be stored locally (as opposed to remotely). That could be removed, but I was trying to not get too prescriptive here.
The TSFI test is basically limited to testing from the main OS and trying to get data back. This is because I think otherwise we are trusting the SEE to protect access to the TOE, so if you can't get to it from the main OS, you can't get to it because it is protected by the SEE, which is out of testing scope.
We could add in some sort of explicit testing within the SEE (I would still limit it to TSFIs that may allow for exporting data), with the idea that if there is some sort of compromise of the SEE at least plaintext data isn't normally lying around (outside of in the middle of a transaction, anyway, which is not really something we can do anything about). This depends though on the level of protection that is expected in the security provided by the SEE.