lewyble
commented
4 years ago The intention was never for the vendor to have to provide the lab with the signing keys and the wording has been modified to state that the lab shall attempt to install an update signed with the proper key/certificate, but the lab no longer has to actually be the ones signing it.
While this hasn't been a problem in practice, the tests here state that "the tester shall digitally sign the update" in several places. While it may be possible for the lab to improperly sign something and see it fail, the tests also state the tester should sign it with the proper key, and this is actually nonsensical.
The keys for updating the device software are, but necessity, tightly controlled, and so the idea that the lab would have access to them to sign their own updates makes no sense whatsoever (and if those keys really were generally available, would seem to invalidate the whole point of the protections laid out here).
The tests should be rewritten such that the vendor will provide valid updates to test with. The lab can then take the valid updates and do things to mess with the valid update to see failures, but it should not say that the tester should be signing things with the valid key.
https://github.com/commoncriteria/mobile-device/blob/954ded4330200e30c1e4b35b7b7398b6d6a3598c/input/mobile-device.xml#L7646-L7647
https://github.com/commoncriteria/mobile-device/blob/954ded4330200e30c1e4b35b7b7398b6d6a3598c/input/mobile-device.xml#L7649-L7651
The first one is clear in stating it and it is implied in the second one since the first part says to sign with an invalid certificate and then repeat with a valid certificate (where would the lab get a valid certificate?).