uno: RsaUnwrap bring-up — OAEP endianness fix + non-CRT RSA private-key import

[radutta99]

Summary

Brings up the RSA paths of RsaUnwrap on the uno HSM firmware. Three changes:

1. OAEP endianness fix — rsa_oaep_decrypt now flips the mod_exp_priv result LE→BE before the RFC 8017 EME-OAEP decode. The uno PKA is little-endian native (LE ciphertext in, LE result out), but the OAEP encoded message 0x00 ‖ maskedSeed ‖ maskedDB is big-endian; the std PAL does the same flip around OpenSSL. Without it, every RsaUnwrap failed with RsaDecryptFailed (0x08700012). This fixes the AES-key unwrap path.

2. Non-CRT RSA private-key import — implements rsa_priv_der_to_vault. Adds a small no_std DER parser (der_tlv, der_int, parse_rsa_priv_der) handling PKCS#8 PrivateKeyInfo and bare PKCS#1 RSAPrivateKey. The PKCS#8 AlgorithmIdentifier is validated to be rsaEncryption (OID 1.2.840.113549.1.1.1 + NULL params), mirroring mcr-hsm's Asn1RsaEncryptionInfo. The parsed n/e/d are assembled into the PKA vault operand [d(k) ‖ n(k) ‖ e(4)] little-endian — matching mcr-hsm's RsaPrivKey::to_pka_bytes and what rsa_priv_pub_key reads back. The stack scratch holding the private exponent is scrubbed with zeroize. CRT import returns UnsupportedCmd (deferred — needs PKA-derived n1q/n2p).

3. OAEP oversized-output error contract — rsa_oaep_decrypt now returns RsaInvalidKeyLength (not InvalidArg) when the recovered message exceeds the caller's output buffer, matching the std PAL. The shared key-unwrap path maps this to RsaUnwrapInvalidKek, so an oversized recovered KEK is now reported correctly.

Testing

Hardware (Manticore EVB):

• rsa_unwrap_generated_key: 12/17 (was 9/17)
• rsa_unwrap_smoke: 3/5 (was 2/5) — oversized_kek_smoke now passes
• get_unwrapping_key: 7/7 (unchanged)

Emu: precheck --nextest --package azihsm_ddi_mbor_types --features emu --filter smoke --profile ci-emu-smoke → 94/94 passed.

fmt / clippy (-D warnings, ms-nightly) / taplo all clean.

Deferred to follow-up PRs

The remaining rsa_unwrap failures each map cleanly to one of:

• CRT RSA import — needs PKA-derived n1q/n2p (mcr-hsm computes these separately).
• uno ECC key import — blocks ecc_key_smoke, ecc_keys_with_key_tag.
• OpenKey-by-tag — a full SDK-wide DDI (op 1015 has no handler); needs a shared PAL-trait + vault change (the uno vault Entry already carries a session_or_tag field).

Base

Stacked on #601 (user/radutta/get-unwrapping-key), which is not yet merged — this PR targets that branch, not main.

[Copilot]

Pull request overview

Brings up RSA unwrap support on uno firmware by aligning RSA-OAEP decode with the PKA’s little-endian behavior, adding non-CRT RSA private-key import from DER into the uno vault layout, and tightening an OAEP error contract to match the std PAL.

Changes:

• Reverse the mod_exp_priv result (LE→BE) before OAEP unpadding to fix RSA-OAEP decrypt on uno.
• Implement rsa_priv_der_to_vault for non-CRT RSA keys via a minimal PKCS#8/PKCS#1 DER parser and vault operand assembly, plus stack scratch scrubbing.
• Return RsaInvalidKeyLength (not InvalidArg) when OAEP plaintext exceeds the caller buffer; add zeroize dependency for firmware PAL.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
fw/plat/uno/fw/pal/src/crypto/rsa.rs	Adds DER parsing + non-CRT RSA private-key import; fixes OAEP endianness and output-length error contract.
fw/plat/uno/fw/pal/Cargo.toml	Adds zeroize as a dependency for the uno PAL crate.
fw/plat/uno/fw/Cargo.toml	Adds zeroize (no-default-features) to the uno firmware workspace dependencies.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

fw/plat/uno/fw/pal/src/crypto/rsa.rs:175

• In the PKCS#8 path, the code descends into the privateKey OCTET STRING but does not verify that the inner RSAPrivateKey SEQUENCE consumes the entire OCTET STRING. Without that check, extra bytes inside the OCTET STRING are silently accepted.

        let (ot, oct_start, _ol, _on) = der_tlv(der, after_alg)?;
        if ot != 0x04 {
            return None;
        }
        let (st, inner_start, _sl, _sn) = der_tlv(der, oct_start)?;

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

fw/plat/uno/fw/pal/src/crypto/rsa.rs:332

• buf[vault_len..].zeroize() scrubs a plain &mut [u8] using the zeroize crate, but this repo has a DMA-specific wipe primitive (DmaBuf::zeroize) that uses per-byte volatile writes + a compiler fence (fw/pal/traits/src/alloc.rs:148-160). For DMA-backed buffers, prefer wiping via DmaBuf::zeroize to match the established secret-scrub pattern.

        buf[vault_len..].zeroize();

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

fw/plat/uno/fw/pal/src/crypto/rsa.rs:199

• parse_rsa_priv_der currently only parses the PKCS#1 version, n, e, d integers and then returns success without confirming that the mandatory remaining PKCS#1 fields (p, q, dp, dq, qinv) are present and that the key SEQUENCE is fully consumed. This makes the parser accept malformed/truncated RSA keys (or extra trailing bytes inside the SEQUENCE) even though the comment says those fields “follow”, and it weakens input validation for untrusted recovered key material.

    // n, e, d in order (p, q, dp, dq, qinv follow but are unused for non-CRT).
    let (ns, nl, after_n) = der_int(der, p)?;
    let (es, el, after_e) = der_int(der, after_n)?;
    let (ds, dl, _after_d) = der_int(der, after_e)?;
    Some(((ns, nl), (es, el), (ds, dl)))

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

fw/plat/uno/fw/pal/src/crypto/rsa.rs:640

• rsa_oaep_decrypt now correctly flips the mod_exp_priv result from wire little-endian to big-endian before interpreting EM (RFC 8017). However, the same mod_exp_priv/mod_exp_pub trait contract is wire little-endian for all RSA primitives (see fw/pal/traits/src/crypto/rsa.rs:214-219), while the Uno implementations of PKCS#1 v1.5 decrypt/verify/sign currently build/validate EM as if the mod-exp inputs/outputs were big-endian (e.g. rsa_pkcs1_decrypt checks em[0] == 0x00 immediately after mod_exp_priv, and rsa_pkcs1_sign constructs EM = 0x00||0x01||... then feeds it directly into mod_exp_priv). If/when those entry points are exercised on Uno, they will fail unless they perform the same LE↔BE reversals around modular exponentiation that OAEP now does.

            // `mod_exp_priv` is little-endian (PKA-native): both the ciphertext
            // operand and the `em` result are LE wire form. The RSA-OAEP decode
            // below (RFC 8017 EME-OAEP) operates on the big-endian encoded
            // message `EM = 0x00 ‖ maskedSeed ‖ maskedDB`, so flip the result
            // LE→BE first (the std PAL does the same flip around OpenSSL).
            em[..k].reverse();

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

fw/plat/uno/fw/pal/src/crypto/rsa.rs:326

• rsa_priv_der_to_vault validates exponent length (el <= 4) but does not reject a zero public exponent. Since this parses untrusted recovered key material, accepting e = 0 would import an invalid RSA key and can lead to incorrect behavior (and a trivially broken public key if re-exported via rsa_priv_pub_key). Consider rejecting an all-zero exponent during the size-validation step.

        if !matches!(modulus_len, 256 | 384 | 512) || el > 4 || dl > modulus_len {
            buf.zeroize();
            return Err(HsmError::InvalidArg);
        }

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

fw/plat/uno/fw/pal/src/crypto/rsa.rs:143

• rsa_der_to_vault_operand accepts PKCS#8 / PKCS#1 keys without checking the version fields. For untrusted recovered key material, it’s better to reject non-zero versions (PKCS#8 PrivateKeyInfo.version must be 0; PKCS#1 RSAPrivateKey.version must be 0 for two-prime keys). Without this, malformed keys with unexpected version values could be accepted despite being non-conformant.

    if let Ok(pki) = RsaPrivateKeyInfo::from_der(der_bytes) {
        if pki.algorithm.algorithm != RSA_ENCRYPTION {
            return None;
        }
        let inner = RsaPrivateKeyDer::from_der(pki.private_key.as_bytes()).ok()?;

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

fw/plat/uno/fw/pal/src/crypto/rsa.rs:84

• This intra-doc link points at super::asn1, but the ASN.1 module is declared at the crate root (crate::asn1). If rustdoc warnings are denied, this will fail doc builds; even without that, the link is broken.

/// [`parse_rsa_private_key`](super::asn1::parse_rsa_private_key).

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

fw/plat/uno/fw/pal/src/crypto/rsa.rs:84

• The intra-doc link for parse_rsa_private_key points to super::asn1::..., but asn1 is a crate-root module (crate::asn1). As written, this link is broken and can trigger rustdoc warnings (or deny-by-lint if enabled).

/// modulus. Structural validation (versions, algorithm OID) is done upstream by
/// [`parse_rsa_private_key`](super::asn1::parse_rsa_private_key).

fw/plat/uno/fw/pal/Cargo.toml:52

• der is the only dependency in this crate pinned with an explicit version instead of using the firmware workspace dependency set (everything else is workspace = true). This makes it easier for crates in the same workspace to drift onto multiple der versions/features and increases maintenance + binary size risk. Consider adding der to fw/plat/uno/fw/Cargo.toml’s [workspace.dependencies] and switching this entry to der = { workspace = true, ... }.

der = { default-features = false, features = [
  "derive",
  "oid",
], version = "0.8" }