fix(hotp): bound Non-Secure key size before copy into K[]

[bmolodan]

Description

register_shared_key() in the HOTP TA copied params[0].memref.size bytes into the
fixed 64-byte secure buffer K[] without bounding the length. That size is supplied
verbatim by the non-secure caller, so any NS caller could overflow a secure .bss
buffer with attacker-controlled data.

This is not covered by the pointer-attribution hardening merged in #250:
nsec_check() proves the source range is Non-Secure resident, which is a different
property from "the source fits in the destination". A legitimate 4 KB Non-Secure
buffer passes that check exactly as designed and is then copied into 64 bytes.

The right bounds check already existed in this file (MIN_KEY_SIZE/MAX_KEY_SIZE in
hmac_sha1()), but on the GET_HOTP path — a later, separate invocation, long after
the corruption. This moves the identical rejection to before the copy. Rejecting rather
than truncating matches apps/aes/ta/aes_ta.c:251 and avoids silently accepting a
shortened HMAC key.

Two smaller defects in the same function are fixed alongside:

• The DMSG traced K with %s — it printed the HMAC shared secret to the
  console, and a key of exactly 64 bytes leaves no NUL for %s to stop at, so it also
  over-read past the array. It now traces only the length.
• get_hotp() called truncate_() without checking res from hmac_sha1(), so a
  failed HMAC truncated uninitialised stack.

Fixes #253

Type of change

• Bug fix (non-breaking change which fixes an issue)

Not a compatibility break: a key outside MIN_KEY_SIZE..MAX_KEY_SIZE already failed at
hmac_sha1() on the subsequent GET_HOTP, so no previously-working flow is rejected.

How Has This Been Tested?

Reproducible QEMU harness, run in a container so the build is deterministic.

• Test A — negative. Invoke TA_HOTP_CMD_REGISTER_SHARED_KEY with a valid
  Non-Secure source buffer at sizes 4096, 65 (sizeof(K)+1) and 4 (< MIN_KEY_SIZE).
  All three now return 0xFFFF0006 (TEE_ERROR_BAD_PARAMETERS).
• Test B — positive. The legitimate 20-byte RFC 4226 key still registers
  (0x00000000) and GET_HOTP still returns the specified vector value 755224.
  This also demonstrates the secure world survived the rejected attempts.

Control run with this patch reverted, same harness and same kernel: the 4096-byte
request returned 0x00000000 (TEE_SUCCESS) and the secure world then stopped
producing output — the remaining checks never executed. So the test genuinely detects
the defect rather than passing vacuously.

The temporary test app used for this is intentionally not included in this PR,
following the precedent of 102d3dc; it can be provided on request.

Test Configuration:

• Firmware version: master @ 102d3dc (mTower v0.6.0)
• Hardware: QEMU mps2-an505 (Cortex-M33); build-only check on numaker_pfm_m2351 (Cortex-M23)
• Toolchain: gcc-arm-none-eabi-8-2018-q4-major (M33), gcc-arm-none-eabi-6-2017-q2-update (M23)
• SDK: n/a

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation — N/A
• My changes generate no new warnings
• I have added tests that prove my fix is effective (temporary harness, not included per 102d3dc precedent)
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules — N/A