eystein.maloy.stenbergFebruary 28, 2017 at 11:25 PM
OK, thanks for the input. I adjusted the acceptance criteria to never tolerate missing nor invalid public key then.
Maciej BorzeckiFebruary 28, 2017 at 8:19 AM
I agree with , update payload verification failure, for whatever reason, should stop the update from proceeding. Missing/corrupted key is one such reason.
eystein.maloy.stenbergFebruary 24, 2017 at 5:53 PM
In general I would err on the side of security here, and would favor just stopping update if the public key cannot be read for any reason. I can not quite see a common problem why a public key would be there after you did the update (before commit) but then it got removed / corrupted. However I can imagine an attacker being able to make the public key unavailable on storage at a given time (e.g. removable storage, some vulnerability in other software that allows him to change perms to 0000) in order to feed the device any update of his choosing.
perhaps you can chime in?
Kristian AmlieFebruary 24, 2017 at 2:30 PM
So essentially this would require manual intervention to recover from, and I assume not every device will realistically have that option available. I added what I described as the final acceptance criterion, but if you think security should win here, then just remove the final bullet point.
Acceptance criteria:
Public key must be loaded from specified setting in conf file
This key, and only this, must be used to verify the incoming update
If the client cannot access the public key when it needs it or the public key is not valid, the update fails
Any failure during verification, whether it's during header parsing, or right before the final write to the partition, must cause an update failure