ECDSA abstraction and Mbed TLS

[d3zd3z]

I've submitted a change #918 that in a somewhat hacky manner, adds support for Mbed TLS as an implementation for ECDSA P256. I wanted to start a bit of a discussion here to keep track a little better about my thoughts (and others) on these abstractions.

The existing ECDSA abstraction is based on the TinyCrypt and the CC310 HW implementation. The interfaces to these are very similar, and specifically, they both want the same data. It is the responsibility of the caller to decode various ASN.1 structures and pass the underlying values to the signature verification.

Mbed TLS, on the other hand, would like to do most of this decoding itself. It offers enough visibility to manually decode the public key (although this is arguably not the best way to do this in Mbed TLS). In addition, it wants the ASN.1 for the signature, and it makes additional validations of the signature that our manual decoder does not make (specifically, it checks the length). One obvious consequence of this is that the manual approach isn't actually checking the length field when decoding the signature. This is unlikely to be exploitable, but would cause an improper-length signature to be attempted, even if there isn't hope of it working.

As a workaround, I have left the manual decoding of the public key, and have added an extra pair of arguments. The code manually decodes the signature, and passes the decoded signature, as well as the original raw signature. This results in a little bit of extra work in the Mbed TLS case.

Part of the difficulty in the abstraction is that it is done with inline functions in a header, even though this file is only included in a single place. Some proposed ideas to improve this abstraction:

1. Move the abstraction into the C file itself. Then, the tinycrypt and CC310 implementations could call the manual signature decoding directly, whereas the Mbed TLS code would not. We could probably decouple the public key unpacking, and just use the Mbed TLS code for parsing the public key. Since the main reason to use Mbed TLS for this is because the Mbed TLS code is being used for something else (such as X.509 signatures), and since the richer decoder is already present in the code, adding a redundant manual decoder isn't helpful.
2. Leave it as is and pass both decoded and raw signature.
3. Other thoughts?