Appending ECDSA signature to a message

Question

I need to authenticate a message sent to an embedded device (which limits my options in terms of just using an existing convention). I can run ECDH/ECDSA on the device and can use SHA-256 as a hash function but pretty much anything else is beyond the resources of the device. Also I can pre-share a public key on the device.

If I simply create a hash from the message, sign the hash using ECDSA with the private key, then append the signature to the message, send it to the device, then on the device verify the signature on the device using the public key against the message hash, is this secure?

Any traps to be aware of?

Edit:

The resource I was looking for is here Authenticate encryption, but I now realize I don't understand secure communication well enough to know what questions to ask.

As per @fgrieu's suggestion I investigate RSA rather than ECDSA, and found that for a NIST-256 curve signature verification takes 0.740s on the device whereas RSA-1024 signature verification takes 0.230s. Code sizes are about the same (3.5k) but the stack usage for the RSA was too high (3.5k) for the amount of RAM I have available. Going down to secp160r1 EC gets the verification time down to about the same as the RSA.

Answer 1

If the message is small enough to be stored in full with the signature in the embedded device, and the software on the embedded device is trusted to not be altered (including the embedded public key) or worked around (a JTAG port or a clever upset can change PC across a test), this is fine, and an intended usage of ECDSA. Most implementation traps are on the signing side.

I doubt that "pretty much anything else is beyond the resources of the device", though. RSA (or Rabbin) signature verification in software is much simpler (thus uses less code) and much faster (like a factor of 10 for usal key size) than ECDSA signature verification. Reasons to prefer ECDSA in this particular application can only be:

• RAM is horribly limited; but 1k byte (used only during signature verification) is ample for RSA-2048.
• The signature size matters much (it's 256-byte with RSA-2048 versus 56-byte for ECDSA P-224 or ECDSA P-256/secp256r1 or secp256k1) and we can't use RSA signature with message recovery (ISO 9796-2) because
  • the signature must be separate from the message (RSA signature with message recovery embeds part of the message in the signature, e.g. 222 bytes in a 256-byte signature; that part becomes available only as a byproduct of signature verification)
  • or the message is too small (below 200 bytes) for message recovery being a space saver.
• Performance on the signer side is a limiting factor. ECDSA (or better, EdDSA as in Ed25519) has a clear edge there.
• Some regulation/constraint prescribes ECDSA (like there's already an implementation, and there's not one for RSA, and time to market is the essence).
• (Update per comment): code size; but that can only realistically be when there's already some code (ECDH) that already does a large fraction of ECDSA, and uses arithmetic code that for some reason can't be re-purposed for RSA (e.g. it handles fixed-size arguments only; or its modular reduction is specialized for moduli of a certain form); and space is badly missing, as RSA itself can fit under 3kByte including public key (add <1.5kByte for SHA-256).