Metadata API: handle malformed keys better

This may be a securesystemslib issue but I’m filing here for visibility:

If a ecdsa key is malformed (e.g. includes raw bytes encoded in hex instead of PEM) we get this:

Traceback (most recent call last):
  File "/home/jku/src/tuf/examples/client_example/./client_example.py", line 136, in <module>
    main()
  File "/home/jku/src/tuf/examples/client_example/./client_example.py", line 129, in main
    download(command_args.target)
  File "/home/jku/src/tuf/examples/client_example/./client_example.py", line 54, in download
    updater = Updater(
  File "/home/jku/src/tuf/tuf/ngclient/updater.py", line 98, in __init__
    self._trusted_set = trusted_metadata_set.TrustedMetadataSet(data)
  File "/home/jku/src/tuf/tuf/ngclient/_internal/trusted_metadata_set.py", line 99, in __init__
    self._load_trusted_root(root_data)
  File "/home/jku/src/tuf/tuf/ngclient/_internal/trusted_metadata_set.py", line 451, in _load_trusted_root
    new_root.verify_delegate(Root.type, new_root)
  File "/home/jku/src/tuf/tuf/api/metadata.py", line 395, in verify_delegate
    key.verify_signature(delegated_metadata, signed_serializer)
  File "/home/jku/src/tuf/tuf/api/metadata.py", line 678, in verify_signature
    if not sslib_keys.verify_signature(
  File "/home/jku/.virtualenvs/tuf/lib/python3.9/site-packages/securesystemslib/keys.py", line 853, in verify_signature
    valid_signature = ecdsa_keys.verify_signature(public, scheme, sig, data)
  File "/home/jku/.virtualenvs/tuf/lib/python3.9/site-packages/securesystemslib/ecdsa_keys.py", line 314, in verify_signature
    ecdsa_key = load_pem_public_key(public_key.encode('utf-8'),
  File "/home/jku/.virtualenvs/tuf/lib/python3.9/site-packages/cryptography/hazmat/primitives/serialization/base.py", line 30, in load_pem_public_key
    return ossl.load_pem_public_key(data)
  File "/home/jku/.virtualenvs/tuf/lib/python3.9/site-packages/cryptography/hazmat/backends/openssl/backend.py", line 853, in load_pem_public_key
    self._handle_key_loading_error()
  File "/home/jku/.virtualenvs/tuf/lib/python3.9/site-packages/cryptography/hazmat/backends/openssl/backend.py", line 1129, in _handle_key_loading_error
    raise ValueError(
ValueError: ('Could not deserialize key data. The data may be in an incorrect format, it may be encrypted with an unsupported algorithm, or it may be an unsupported key type (e.g. EC curves with explicit parameters).', [_OpenSSLErrorWithText(code=151584876, lib=9, reason=108, reason_text=b'error:0909006C:PEM routines:get_name:no start line')])

From Metadata API perspective the problem is that Metadata.verify_delegate() (and below that Key.verify_signature()) does not keep its API promise: it allows ValueError to bubble up.

• Metadata.verify_delegate() case seems clear: The API is correct, we do not want to know about parsing errors here, we just want to know whether verify worked or not.
• for Key.verify_signature() I’d still say the same thing: caller is just interested in a yes or no answer (but we do raise UnisgnedMetadataError so the stack is available to whoever is interested)

So the result is that something in securesystemslib, probably ecdsa_keys.verify_signature() should handle the ValueError coming from cryptography, and raise one of the documented errors, maybe FormatError.

[MVrachev]

The one things we could do in python-tuf is make things debuggable: If I read the code correctly, after your sslib fix, if verify fails because we can’t load the key we get this (verify_delegate()):

except exceptions.UnsignedMetadataError:
    logger.info("Key %s failed to verify %s", keyid, delegated_role)

but it does not say why the verify failed. it’s not trivial to do at this point (since the reason is in the contained error) but maybe we could do that in verify_signature() if there is a sslib error? Can you have a look and see if we can make TUF logging more useful to someone debugging a malformed key issue – this could be a new issue as well

I tried it locally with a malformed key and yea… didn’t get a good message about why the key verification happened. I created an issue about this #1875.

I don’t think there is anything else left for this particular issue and that’s why I am closing. If I am missing something, please feel free to reopen this.

[jku]

The one things we could do in python-tuf is make things debuggable: If I read the code correctly, after your sslib fix, if verify fails because we can’t load the key we get this (verify_delegate()):

except exceptions.UnsignedMetadataError:
    logger.info("Key %s failed to verify %s", keyid, delegated_role)

but it does not say why the verify failed. it’s not trivial to do at this point (since the reason is in the contained error) but maybe we could do that in verify_signature() if there is a sslib error? Can you have a look and see if we can make TUF logging more useful to someone debugging a malformed key issue – this could be a new issue as well