Do we need precise verification error codes?

[athoelke]

The v0.7 API defines a set of API-specific error codes that are documented to be used with the psa_fwu_install() function, and psa_fwu_set_manifest(), that report specific verification failure conditions. The separately reported errors are as follows (see psa_fwu_install() and psa_fwu_set_manifest()):

Error	Reason
PSA_ERROR_NOT_PERMITTED	The image/manifest is too old to be installed. If the image metadata contains a timestamp, and it has expired, then this error is also returned.
PSA_ERROR_WRONG_DEVICE	The image/manifest is not intended for this device.
PSA_ERROR_INVALID_SIGNATURE	The image/manifest signature is not valid.
PSA_ERROR_DATA_CORRUPT	The image is corrupt.
PSA_ERROR_INSUFFICIENT_DATA	The image is smaller than expected.
PSA_ERROR_DECRYPTION_FAILURE	The key used to decrypt the data is unknown or decryption failed.
PSA_ERROR_ALREADY_INSTALLED	The storage item associated with image ID has already been installed.
PSA_ERROR_DEPENDENCY_NEEDED	A different manifest/image is needed first.
PSA_SUCCESS_DEPENDENCY_NEEDED	Another image needs to be installed to finish installation.

• ALREADY_INSTALLED seems to be a very specific instance of 'too old' (NOT_PERMITTED), when the image being installed is the current version.
• DATA_CORRUPT and INSUFFICIENT_DATA are very specific verification failures. There are others that are not covered - image is unrecognisable, image is encoded in an unsupported version of an enclosure format, image has unexpected length.
• When an encrypted image does not decrypt correctly, it is not normal that this is detected as a specifically decryption problem. It is hard to determine when DECRYPTION_FAILURE will be used, unless it only signifies a key mismatch.
• WRONG_DEVICE is very unique to this API, it is not clear why providing a special error code will help diagnose an in-field problem if this situation arises.
• Do we really need both PSA_ERROR_DEPENDENCY_NEEDED and PSA_SUCCESS_DEPENDENCY_NEEDED? There is no detailed description of the difference between these status codes - and psa_fwu_install() could return either. Although the latter assumes that installation is successful - it depends on the caller actually installing the dependency. What happens if the caller does not do this? - what state is the firmware in?

Proposal

• Remove ALREADY_INSTALLED.
  • Allow NOT_PERMITTED to indicate any kind of update policy failure (e.g. image version <= current version, image expired, etc.)
• Remove DATA_CORRUPT and INSUFFICIENT_DATA.
  • Use INVALID_SIGNATURE to indicate any kind of integrity or authentication check failure (hash/MAC/signature does not match or signature does not correspond to a trusted key)
  • Use INVALID_ARGUMENT to indicate any other kind of image or manifest format/structure issue (wrong number of bytes, not recognisable)
• Remove DECRYPTION FAILURE
  • Use INVALID_ARGUMENT if the decryption key specified in the image/manifest is not recognised by the device
  • Use INVALID_SIGNATURE if the decrypted image fails an integrity check
  • Use INVALID_ARGUMENT if the decrypted image is not valid
• Remove WRONG_DEVICE
  • Use INVALID_ARGUMENT if the image or manifest is targeting a different device.
• Remove SUCCESS_DEPENDENCY_NEEDED
  • If a dependency is missing, always return ERROR_DEPENDENCY_NEEDED.

[d3zd3z]

I'm a little worried about the possibility of having too much detail about why an image fails (invalid signature vs some of the other data) and that being able to be used for an oracle attack. In other words, I like the idea of simplifying the error messages, and to collapse most down to invalid signature). We would want to make sure there isn't any advantage given to an attacker from being able to distinguish INVALID_SIGNATURE from INVALID_ARGUMENT.

[athoelke]

I have the same concern - the historical precedent being providing a distinction between invalid padding and invalid content. I am not sure that this extends to INVALID_SIGNATURE vs INVALID_ARGUMENT. We could tighten up the use of these. For example:

• If an integrity check or signature is required, but none is found (e.g. the metadata format is wrong), or the verification fails the implementation MUST return INVALID_SIGNATURE
• Otherwise, if the image is not valid, then return INVALID_ARGUMENT

This way, until an image passes the integrity check the call will only return INVALID_SIGNATURE. We assume that the signature/integrity check is cryptographically hard enough.

If the Update Service is a secure implementation (inside a Root of Trust), then reducing the information in the failure code reduces the benefit to an attacker - but makes diagnostic of a problem much harder. I would expect this kind of implementation to have some kind of secure audit log that might record the update attempt and failure?

If the implementation is purely a HAL, then it is unlikely to diagnose different failure conditions - it expects that the Client is responsible for most of that.