Add WISeKey/SealSQ VaultIC secure element port

[dgarske]

Summary

Adds an in-tree wolfSSL port for the WISeKey/SealSQ VaultIC secure element (for example the VaultIC 408). It offloads TLS ECC P-256 sign, verify, keygen, and ECDH to the chip through wolfSSL's PK callbacks and loads the device and CA certificates stored on the chip, so the TLS private key never leaves the secure element. Only the glue is in-tree; it calls the external SealSQ VaultIC-TLS SDK.

What it adds

• wolfcrypt/src/port/sealsq/vaultic.c + wolfssl/wolfcrypt/port/sealsq/vaultic.h:
  • WOLFSSL_VAULTIC_EccSignCb / EccVerifyCb / EccKeyGenCb / EccSharedSecretCb - P-256 ops on the device
  • WOLFSSL_VAULTIC_LoadCertificates - read device + CA certs off the chip
  • WOLFSSL_VAULTIC_SetupPkCallbacks / SetupPkCallbackCtx - register the callbacks
• wolfcrypt/src/port/sealsq/README.md - build, usage, and provisioning notes.
• Gated behind --enable-vaultic (defines WOLFSSL_VAULTIC, auto-enables PK callbacks); wiring mirrors the iotsafe port. Compiles to nothing when off.

./configure --enable-vaultic \
    CFLAGS="-I/path/to/VaultIC-TLS/vaultic_tls-4xx/src" LIBS="-lvaultic_tls_408"

Testing

• Option-off full build unchanged (port guarded out); --enable-vaultic configures and compiles cleanly against the vendor SDK header.
• Validated on hardware (Raspberry Pi 5 + VaultIC 408): full TLS 1.2 (ECDHE_ECDSA / SECP256R1) and TLS 1.3 (SecP256r1MLKEM768) handshakes complete, with sign, verify, keygen, and ECDH dispatched to the chip and certificates loaded off the device.

[Copilot]

Pull request overview

Note

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Adds an in-tree wolfSSL port that offloads P-256 ECC operations and certificate loading to the WISeKey/SealSQ VaultIC secure element via PK callbacks, with build-system wiring for autotools/CMake.

Changes:

• Added VaultIC PK callback implementations (sign/verify/keygen/ECDH) and certificate-loading helper.
• Exposed a public header and port README with build/usage/provisioning notes.
• Added --enable-vaultic autotools option and a corresponding CMake option; wired sources/headers into build.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 8 comments.

Show a summary per file

File	Description
wolfssl/wolfcrypt/port/sealsq/vaultic.h	Declares the VaultIC PK callback + certificate-loading API exported by the port.
wolfssl/wolfcrypt/include.am	Installs the new public VaultIC header when BUILD_VAULTIC is enabled.
wolfcrypt/src/port/sealsq/vaultic.c	Implements ECC callbacks and certificate loading using the external VaultIC-TLS SDK.
wolfcrypt/src/port/sealsq/README.md	Documents dependencies, build flags, usage, and devkit/provisioning notes.
wolfcrypt/src/include.am	Adds the VaultIC port source to libwolfssl when BUILD_VAULTIC is enabled and distributes the README.
configure.ac	Adds --enable-vaultic, defines WOLFSSL_VAULTIC, and enables PK callbacks for autotools builds.
CMakeLists.txt	Adds a WOLFSSL_VAULTIC option and excludes the sealsq port directory from header processing.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

MemBrowse Memory Report

No memory changes detected for:

• gcc-arm-cortex-m0plus
• gcc-arm-cortex-m3
• gcc-arm-cortex-m4
• gcc-arm-cortex-m4-baremetal
• gcc-arm-cortex-m4-crypto-only
• gcc-arm-cortex-m4-dtls13
• gcc-arm-cortex-m4-min-ecc
• gcc-arm-cortex-m4-openssl-compat
• gcc-arm-cortex-m4-pkcs7
• gcc-arm-cortex-m4-pq
• gcc-arm-cortex-m4-rsa-only
• gcc-arm-cortex-m4-sp-math
• gcc-arm-cortex-m4-tls12
• gcc-arm-cortex-m4-tls13
• gcc-arm-cortex-m7
• gcc-arm-cortex-m7-pq
• gcc-arm-cortex-m7-tls13
• linuxkm-pie
• linuxkm-standard
• stm32-sim-stm32h753

[Copilot]

Pull request overview

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

Suppressed comments (5)

wolfcrypt/src/port/sealsq/vaultic.c:207

• In the PK verify callback, returning NOT_COMPILED_IN when the certificate public key isn’t P-256 will cause verification to fail outright (wolfSSL won’t retry in software once a verify callback is registered). Since verify doesn’t use a private key, it’s safe and more interoperable to fall back to wc_ecc_verify_hash() for non-P-256 keys.

    /* Check requested curve */
    if (key->dp->id != ECC_SECP256R1) {
        WOLFSSL_MSG("id != ECC_SECP256R1");
        err = NOT_COMPILED_IN;
        goto free_key;
    }

wolfcrypt/src/port/sealsq/vaultic.c:287

• WOLFSSL_VAULTIC_EccSharedSecretCb dereferences otherPubKey->dp without checking for NULL, and also doesn’t validate pubKeyDer/pubKeySz/out/outlen. A malformed call path or error propagation could crash here instead of returning BAD_FUNC_ARG.

    /* check requested curve */
    if (otherPubKey->dp->id != ECC_SECP256R1) {
        WOLFSSL_MSG("id != ECC_SECP256R1");
        return NOT_COMPILED_IN;
    }

wolfcrypt/src/port/sealsq/vaultic.c:401

• WOLFSSL_VAULTIC_LoadCertificates() doesn’t validate ctx before using it. Passing a NULL ctx will currently crash inside wolfSSL_CTX_* calls; other ports typically return BAD_FUNC_ARG for this.

int WOLFSSL_VAULTIC_LoadCertificates(WOLFSSL_CTX* ctx)
{
    int ret = WOLFSSL_FATAL_ERROR;

    /* CA certificate */

wolfssl/wolfcrypt/port/sealsq/vaultic.h:61

• The public header uses unsigned int* for pubKeySz/outlen in WOLFSSL_VAULTIC_EccSharedSecretCb, but wolfSSL’s CallbackEccSharedSecret typedef uses word32*. On WC_16BIT_CPU builds word32 is unsigned long, so this becomes an incompatible function-pointer type and can break compilation or call ABI.

WOLFSSL_API int WOLFSSL_VAULTIC_EccSharedSecretCb(WOLFSSL* ssl,
    ecc_key* otherKey,
    unsigned char* pubKeyDer, unsigned int* pubKeySz,
    unsigned char* out, unsigned int* outlen,
    int side, void* ctx);

wolfcrypt/src/port/sealsq/README.md:145

• The README claims wolfSSL will “fall back to software” when PK callbacks return NOT_COMPILED_IN for non-P-256 curves. wolfSSL’s PK callback paths don’t do this fallback; if callbacks are registered, NOT_COMPILED_IN aborts the handshake. Either document this as a hard requirement (P-256-only handshake) or implement software fallback inside the callbacks (as IoT-Safe does).

The port offloads P-256 (SECP256R1) only. The VaultIC 408 silicon supports
P-384, but the vendor `vlt_tls` API exposes P-256 entry points only, so
P-384 would require vendor `vlt_tls_*_P384` functions. For any other curve
the crypto callback returns `CRYPTOCB_UNAVAILABLE` and the PK callbacks
return `NOT_COMPILED_IN`, so wolfSSL falls back to software.

[dgarske]

Jenkins retest this please

[dgarske]

Jenkins retest this please