autosar: thread safety, MAC services, device offload, key handles, DET

Fixed in the Csm/CryIf/Crypto port:

- Two data races: the MAX_JOBS job table had no lock, so two SW-Cs calling
  Csm_Encrypt() could claim one slot and initialize one Aes twice, and GetKey()
  returned a keystore pointer after dropping the mutex, so a concurrent
  Csm_KeyElementSet() could overwrite the key in use. The table has its own
  mutex and the key is copied out under the lock. ThreadSanitizer: 125 races
  before, none after.
- Key input redirection did not compile at all -- GetKey() used runtime struct
  members as switch case labels -- and redirect_test is gated behind the same
  macro, so nothing built or ran it.
- Cipher jobs take the key length from the keystore, so 128, 192 and 256 bit
  keys all work; csm.c asked every job for 16 bytes and the lookup needed an
  exact match.
- Development errors used a local 0-based enum shadowing Csm.h's values, so
  CSM_E_PARAM_POINTER reached a DET as 0, which the specification assigns to no
  error; it also misspelled CSM_E_UNINIT.
- WOLFSSL_AUTOSAR_DET did not link without the MAC services, the test program
  defining Det_ReportError() only alongside CMAC.
- Crypto_Init() was not safe to re-run although a repeated Csm_Init() is
  supported: re-initialized live mutexes, freed the RNG unlocked, and cleared
  the job table without freeing the contexts in it. Its mutexes are created all
  or nothing now, and the new configuration is published while holding every
  lock its readers use -- jobs_mutex, rngMutex and crypto_mutex, in that order
  -- so a concurrent job cannot recreate the DRBG from the old devId just after
  it was freed, or take one field from each configuration.
- A re-init is refused outright while any job owns a slot or is starting one.
  A job runs its Aes or Cmac context outside the locks, so freeing one under a
  live job trades a leak for a use-after-free; the previous configuration stays
  in force instead, nothing half-applied. Because the service returns void, the
  refusal goes to the DET as CSM_E_INIT_FAILED rather than nowhere. The caller
  FINISHes its jobs, or cancels them -- see Csm_CancelJob() below.
- A START is a sequence, not a step: it copies the key out of the keystore,
  checks it, reads the configured devId and only then claims a slot. Slot
  ownership is what the refusal above looks at, which says nothing about a
  START that has not reached its slot yet, so the whole of Crypto_Init() could
  run inside that window -- wipe the keystore, publish a new heap and devId --
  and leave the job building a context for the newly configured device out of
  the previous configuration's key. A counter makes the window itself visible
  to the refusal; the START paths are factored out so it covers every exit.
- A key label of exactly MAX_KEY_LABEL_LEN characters was rejected, the buffer
  having no room for the terminator; both label buffers are one byte longer so
  the documented maximum fits. That maximum is AES_MAX_LABEL_LEN - 1, 31:
  wolfCrypt's CMAC keeps a label only when it is strictly shorter than
  AES_MAX_LABEL_LEN and silently keeps none at 32, where AES accepts it, so the
  limit the port documents has to be one both back ends carry. A static
  assertion holds the two together.
- A cipher job failing after START kept its slot, and ClaimJobSlot() did not
  check for an existing jobId, so the next START claimed a second slot while
  UPDATE and FINISH ran on the stale first. START restarts the job now.
- CRYPTO_OPERATIONMODE_FINISH on a job never started reported success; the DRBG
  used device ID 0 rather than INVALID_DEVID.
- WOLFSSL_AUTOSAR=yes under CMake defined the macro without compiling the port
  sources, so Csm_* calls compiled and then failed to link. That option also
  rejects a build without AES, or with AES but without AES-CBC, now -- the
  Crypto driver is built around Aes in CBC mode, so the prerequisite belongs to
  the port and not only to its MAC services.
- Key material is wiped with ForceZero(), a failed CMAC init is freed, and the
  port test includes options.h before settings.h.

Added:

- --enable-autosar-cmac: Csm_MacGenerate()/Csm_MacVerify() over AES-CMAC. It
  enables wolfCrypt CMAC itself, WOLFSSL_AES_DIRECT included, and refuses at
  compile time a user_settings.h build defining WOLFSSL_AUTOSAR_CMAC without
  them. Verify enforces WOLFSSL_AUTOSAR_MAC_MIN_SZ, default 3 bytes for SecOC
  profile 1 -- below wolfCrypt's WC_CMAC_TAG_MIN_SZ deliberately, raisable.
- devId beside heap in Csm_ConfigType, passed down through CryIf_Init() to
  Crypto_Init() instead of being discarded, so the driver can front an HSM.
  WOLFSSL_AUTOSAR_DEVID is the default for a build with no config to plumb and
  WOLFSSL_CSM_CONFIG_DEFAULT initializes one, so leaving devId alone does not
  select device 0. CryIf_ConfigType and Crypto_ConfigType gained the field too:
  an application built against the older headers must be rebuilt.
- Key handles: a slot can name a key held in a device, so the key never enters
  RAM. wolfSSL_Csm_KeyElementSetId()/...SetLabel() point a slot at it and the
  driver uses wc_AesInit_Id()/wc_AesInit_Label() or the CMAC equivalents. Needs
  WOLF_PRIVATE_KEY_ID and a devId. Cipher jobs additionally need
  WOLFSSL_AES_REQUIRE_KEY_SET, absent on the ports under
  WC_AES_KEY_SET_CHECK_UNSUPPORTED in aes.h, since the empty key schedule is
  only an error while something checks for it; MAC jobs need no equivalent,
  CMAC init rejecting a NULL key once the callback has declined.
- Naming a key slot, because element IDs cannot: the specification scopes them
  per key, so CRYPTO_KE_CIPHER_KEY and CRYPTO_KE_MAC_KEY are both 0x01 and this
  keystore is flat. Resolving by element took the first slot holding 0x01, so a
  MAC job could run under the AES-CBC key and the verifying side would accept
  it. wolfSSL_Csm_{Encrypt,Decrypt,MacGenerate,MacVerify}WithKey() put a slot
  in the job's cryIfKeyId, which is the field AUTOSAR has for this.
- DET reporting shaped after Det_ReportError(), forwarded to it under
  WOLFSSL_AUTOSAR_DET without the port including Det.h -- declared as the
  specification has it, returning Std_ReturnType, with the result discarded
  explicitly, a failed report changing nothing the caller can act on -- plus
  the module
  identity a dependent module checks (WOLFSSL_CSM_MODULE_ID 110, a vendor ID,
  the AR_RELEASE macros), which Csm_GetVersionInfo() reports. Service IDs are
  marked in the header as unconfirmed against the specification's table.

- Csm_CancelJob(), CryIf_CancelJob() having been a stub returning E_NOT_OK. It
  releases the slot of a job that will never send its FINISH -- an abandoned
  stream, or one left by an SW-C that has been restarted. Without it such a
  slot is held until the ECU resets and, now that a re-init is refused while
  one is, reconfiguration could never happen again. Cancel a job from its own
  owner: the driver is not safe against a cancel racing an UPDATE of the same
  job, which is the same reason Csm_Init() refuses rather than tearing down.

Two things that can stop a build or a job that used to work:

- An unnamed job is refused when more than one slot holds element 0x01.
  WOLFSSL_AUTOSAR_ALLOW_AMBIGUOUS_KEY_ELEMENT restores first-match for an ECU
  keeping several keys for one service.
- Redirection with --enable-autosar-cmac is refused at build time: it maps 0x01
  to one slot for every service, leaving nothing to disambiguate. Refusing per
  job instead would leave no unnamed job able to resolve 0x01, so the standard
  entry points would stop working and only the wolfSSL extensions would be
  usable. Key input redirection never separated the two, whatever an earlier
  draft of this port documented.

Mind the MAC length units, which differ between the two services because the
specification has them that way. Csm_MacVerify's macLength is in BITS: the
driver converts to ceil(macLength / 8) bytes, compares the whole bytes and
then the trailing partial byte under a mask, and rejects anything longer than
the 128 bit tag -- which is where a byte count passed by mistake lands. The
floor is applied to the bit count before that rounding, 17 bits being short of
a three byte minimum however they round up.
Csm_MacGenerate's macLengthPtr is in BYTES, and its specified unit is
unverified here. So feeding the length Csm_MacGenerate returned straight into
Csm_MacVerify asks for eight times less than intended: 16 becomes 16 bits, two
bytes, below the floor and refused. wolfSSL_Csm_MacVerifyWithKey() is
byte-based throughout, being a wolfSSL extension, and takes the buffer size
beside the length.

Tests and CI: the port test provisions its key and IV into the slots
redirection points at, so it passes either way, and covers a CMAC known answer,
a devId reaching a crypto callback, a named key producing the same ciphertext
as the key itself, a MAC job whose key never enters RAM, a DET report's IDs, a
cipher and a MAC key provisioned at once, the job slot lifecycle, every AES key
length, the MAC floor and buffer-size refusals, a repeat Csm_Init() refused
while a job is open and accepted once it has been finished, and cancelling an
abandoned one -- the context free observed through the device's free
notifications, a cleared table alone being indistinguishable from the API. One
case is threaded: cipher jobs against a concurrent Csm_Init(), which holds the
invariant that a job that ran to completion ran under the key provisioned, and
is clean under ThreadSanitizer. It does not fail with the START gate removed,
checked by removing it -- that window is a time-of-check race whose accesses
are all still under a lock -- so it is traffic over the window and not a proof
of it.
Each was checked against the unfixed driver to confirm it fails. The new
autosar.yml runs nine configurations, each asserting its feature-gated test
actually ran, since a compiled-out test's silence looks like success; its
negative configure probe runs in tree before the real configure, automake's
VPATH guard otherwise rejecting an already-configured source directory and
logging that instead. --enable-autosar had no CI coverage at all before.

Author: SparkiDev

.github/workflows/autosar.yml

@@ -3817,11 +3817,51 @@ add_option("WOLFSSL_AUTOSAR"
     "Enable AUTOSAR support (default: disabled)"
     "no" "yes;no")
 if(WOLFSSL_AUTOSAR)
+    # The Crypto driver is built around Aes and the AES APIs, and this option
+    # now compiles csm.c/cryif.c/crypto.c rather than only defining a macro,
+    # so AES is a prerequisite of the port itself and not just of its MAC
+    # services. Without this the build reaches C compilation with Aes
+    # unavailable.
+    if(NOT WOLFSSL_AES)
+        message(FATAL_ERROR "WOLFSSL_AUTOSAR requires AES")
+    endif()
+    # The cipher services are AES-CBC specifically: wc_AesCbcEncrypt() and
+    # wc_AesCbcDecrypt() are compiled out with WOLFSSL_AESCBC=no, so AES alone
+    # is not enough to build the driver.
+    if(NOT WOLFSSL_AESCBC)
+        message(FATAL_ERROR "WOLFSSL_AUTOSAR requires AES-CBC")
+    endif()
     list(APPEND WOLFSSL_DEFINITIONS
         "-DWOLFSSL_AUTOSAR"
         )
 endif()
 
+add_option("WOLFSSL_AUTOSAR_CMAC"
+    "Enable AUTOSAR MAC generate/verify services using AES-CMAC, requires WOLFSSL_AUTOSAR (default: disabled)"
+    "no" "yes;no")
+if(WOLFSSL_AUTOSAR_CMAC)
+    if(NOT WOLFSSL_AUTOSAR)
+        message(FATAL_ERROR
+            "WOLFSSL_AUTOSAR_CMAC requires WOLFSSL_AUTOSAR")
+    endif()
+    # AES is checked by the WOLFSSL_AUTOSAR block above, which this option
+    # requires, so there is nothing to repeat here.
+    # The driver calls wc_InitCmac()/wc_CmacUpdate()/wc_CmacFinalNoFree().
+    # The WOLFSSL_CMAC block runs earlier in this file, so turning the option
+    # on here also has to add the definitions it would have added --
+    # WOLFSSL_AES_DIRECT included, since cmac.c compiles out its WC_CMAC_AES
+    # case without it and wc_InitCmac() then fails at runtime.
+    if(NOT WOLFSSL_CMAC)
+        override_cache(WOLFSSL_CMAC "yes")
+        list(APPEND WOLFSSL_DEFINITIONS
+            "-DWOLFSSL_CMAC"
+            "-DWOLFSSL_AES_DIRECT")
+    endif()
+    list(APPEND WOLFSSL_DEFINITIONS
+        "-DWOLFSSL_AUTOSAR_CMAC"
+        )
+endif()
+
 add_option("WOLFSSL_HASHFLAGS"
     "Enable support for hash flags (default: disabled)"
     "no" "yes;no")

CMakeLists.txt

@@ -48,6 +48,10 @@
 * Added `--enable-falcon=smallest-mem`, a Falcon signer working in 20*n bytes (12KB peak heap at Falcon-512, 22KB at Falcon-1024). by @Frauschi
 * Added ML-KEM (FIPS 203) key OIDs, SubjectPublicKeyInfo and PKCS#8 encoding, and X.509 certificate support, including issuing an ML-KEM certificate with `wc_MakeCert_ex`. A key initialised with the new `WC_ML_KEM_TYPE_UNSET` takes its parameter set from the DER being decoded. by @Frauschi
 
+## Hardware and Embedded Ports
+
+* AutoSAR: the Csm/CryIf/Crypto port gained the MAC generate and verify services, device offload and key handles, and had its thread safety, key handling and development error reporting fixed. `Csm_MacGenerate()` and `Csm_MacVerify()` use AES-CMAC behind the new `--enable-autosar-cmac` (CMake `WOLFSSL_AUTOSAR_CMAC`), which requires `--enable-autosar` and enables wolfCrypt CMAC (`WOLFSSL_CMAC` and `WOLFSSL_AES_DIRECT`) by itself; the key is read from `CRYPTO_KE_MAC_KEY`, which the specification gives the same value as `CRYPTO_KE_CIPHER_KEY`. This port's keystore is flat, so the element ID alone cannot tell a cipher key from a MAC key and a job that lets the driver resolve its own key takes the first slot holding 0x01, whichever service provisioned it. A build using both services names the slot it means, with the new `wolfSSL_Csm_EncryptWithKey()`, `wolfSSL_Csm_DecryptWithKey()`, `wolfSSL_Csm_MacGenerateWithKey()` and `wolfSSL_Csm_MacVerifyWithKey()` (wolfSSL extensions): `keyId` selects the slot holding the key element, while other elements such as the cipher IV stay resolved by the driver, their IDs being unambiguous. A build with the MAC services refuses a job that did not name its slot when more than one populated slot holds element 0x01, rather than resolving to the first match -- a SW-C written against the standard Csm API would otherwise compute a CMAC under the AES-CBC key and the verifying side, set up the same way, would accept it. One such slot is unambiguous whichever service provisioned it, so a single-key ECU is unaffected, and `WOLFSSL_AUTOSAR_ALLOW_AMBIGUOUS_KEY_ELEMENT` restores the first-match scan for an ECU that keeps several keys for a single service. Key input redirection with `--enable-autosar-cmac` is refused at build time, that combination mapping element 0x01 to one slot for every service with nothing left to disambiguate; `--enable-autosar-cmac` also now requires `WOLFSSL_CMAC` and `WOLFSSL_AES_DIRECT` at compile time rather than failing every MAC job at run time in a `user_settings.h` build that forgot them. Key input redirection does NOT separate them -- it maps an element ID to one slot for every service -- so an earlier draft of this port documented a workaround that could not work. `Csm_MacVerify()`'s `macLength` is in bits, as the specification defines it: the driver converts to `ceil(macLength / 8)` bytes, compares the whole bytes and then the trailing partial byte under a mask, and rejects anything longer than the 128 bit tag -- which is also where a byte count passed by mistake lands. `Csm_MacGenerate()`'s `macLengthPtr` is in bytes and its specified unit is unverified here, so passing the length it returns straight into `Csm_MacVerify()` asks for eight times less than intended; multiply by 8. `wolfSSL_Csm_MacVerifyWithKey()` is byte-based throughout, being a wolfSSL extension, and takes the buffer size beside the length. Verify also enforces a floor, `WOLFSSL_AUTOSAR_MAC_MIN_SZ`, which defaults to the 3 bytes AUTOSAR SecOC profile 1 truncates to -- below wolfCrypt's own `WC_CMAC_TAG_MIN_SZ` deliberately, so that the port does not refuse its own standard's profile, and raisable per build; a 1 or 2 byte tag, forged by guessing, is refused outright. A MAC shorter than the full tag compares against the leading bytes, and a mismatch is reported through `verifyPtr` as `CRYPTO_E_VER_NOT_OK` with an `E_OK` return rather than as a job failure. `Csm_ConfigType` gained a `devId` alongside its `heap` and `Csm_Init()` now passes both down through `CryIf_Init()` to `Crypto_Init()` instead of discarding the config, so the driver can be a front end for an HSM, SHE block or accelerator rather than a software implementation; `Csm_Init(NULL)` still selects the default allocator and software and `WOLFSSL_AUTOSAR_DEVID` sets that default for builds with no runtime configuration to plumb, a repeated `Csm_Init()` is now safe to make: it frees the DRBG built under the previous configuration while holding the RNG lock, publishes the new heap and `devId` while holding every lock their readers use, and creates the driver mutexes once instead of re-initializing them under a thread that may hold one. It is refused outright while any job owns a slot or is starting -- a job runs its wolfCrypt context outside the driver's locks, so freeing one under a live job would be a use-after-free -- and because the service returns void the refusal is reported to the DET as `CSM_E_INIT_FAILED`; `Csm_CancelJob()` (`CryIf_CancelJob()` was a stub) releases the slot of a job that will never send its FINISH, so an abandoned stream cannot wedge reconfiguration for the life of the ECU, and `CryIf_ConfigType` and `Crypto_ConfigType` gained the same field -- applications compiled against the older headers must be rebuilt. A keystore slot can now name a key that lives in a device instead of holding the key material, so the key never enters RAM: `wolfSSL_Csm_KeyElementSetId()` and `wolfSSL_Csm_KeyElementSetLabel()` (wolfSSL extensions, not AUTOSAR 4.4 Csm API, hence the prefix) point a slot at a hardware key and a cipher job is then built with `wc_AesInit_Id()` or `wc_AesInit_Label()` rather than `wc_AesSetKey()`, so a fall-through to software fails instead of encrypting under an all-zero key; needs `WOLF_PRIVATE_KEY_ID` and a configured `devId`, and a job naming a key is refused outright when the port is in software mode or when wolfCrypt's key-is-set check is compiled out (`WOLFSSL_AES_REQUIRE_KEY_SET`, absent on the hardware ports listed under `WC_AES_KEY_SET_CHECK_UNSUPPORTED` in `aes.h`), since without that check the fail-closed guarantee does not hold, and the MAC services can use such a slot as well: wolfCrypt stores the name on the `Cmac`, offers the job to the crypto callback, and rejects a NULL key only once the callback has declined, so a MAC job either runs in the device or fails. Fixed: two data races in the Crypto driver, the `MAX_JOBS` job table having no lock of its own (two SW-Cs calling `Csm_Encrypt()` concurrently could claim one slot and initialize one `Aes` context twice) and `GetKey()` returning a pointer into the keystore after dropping the mutex (a concurrent `Csm_KeyElementSet()` could overwrite the key bytes in use); the key input redirection build, where `GetKey()` used runtime struct members as `switch` case labels, so no build defining `REDIRECTION_CONFIG` compiled and `redirect_test`, gated behind the same macro, never ran; cipher jobs now take the key length from the keystore, so 128, 192 and 256 bit keys set with `Csm_KeyElementSet()` all work, where `csm.c` previously asked every cipher job for a 16 byte key and the driver required an exact match, and a stored key whose length is not a valid AES key length is rejected by the job that tries to use it; development errors now carry the IDs the CSM specification assigns, where a local 0-based enum in `csm.c` shadowed the header's correct values and reported 0 for `CSM_E_PARAM_POINTER`, which the specification assigns to no error at all, and `ReportToDET()` takes the arguments of the AUTOSAR entry point and forwards to `Det_ReportError()` under `WOLFSSL_AUTOSAR_DET`; the dead `WOLFSSL_CSM_E_PROCESSING_MOD` macro is spelled `WOLFSSL_CSM_E_PROCESSING_MODE` as the specification does, and the enum's `CSM_E_UNINT` misspelling of `CSM_E_UNINIT` went with it; the DRBG was initialized with a device ID of 0 rather than `INVALID_DEVID`, which under `WOLF_CRYPTO_CB` could match a registered device by accident; `CRYPTO_OPERATIONMODE_FINISH` naming a job that was never started returns `E_NOT_OK` instead of reporting success; and a cipher job that fails mid-stream now frees its job slot, where it used to leak it and leave a stale context that the next `CRYPTO_OPERATIONMODE_START` for the same `jobId` would keep using while claiming a second slot -- a START on a job that is already active now restarts it instead. `WOLFSSL_AUTOSAR=yes` under CMake defined the macro into `options.h` without compiling `csm.c`, `cryif.c` or `crypto.c`, so an application's `Csm_*` calls compiled against `Csm.h` and then failed to link; the port sources are now part of the CMake build. `Csm.h` gained the module identity AUTOSAR expects (`WOLFSSL_CSM_MODULE_ID` 110, a vendor ID and the `AR_RELEASE` version macros), which `Csm_GetVersionInfo()` now reports. The port test provisions its key and IV into the slots redirection points at so it passes with and without `REDIRECTION_CONFIG`, and gained an AES-CMAC known answer case, a case checking a configured `devId` reaches a registered crypto callback, a case checking a key named rather than stored produces the same ciphertext as the key itself, a case checking a development error arrives with the specified module and error IDs, a case provisioning a cipher key and a MAC key at once and checking each service picks the right one, a case for cancelling a job and for the refusal and DET report a re-init gives while one is open, and a threaded case running cipher jobs against a concurrent `Csm_Init()`; it also no longer trips the `settings.h` header order warning. A new `autosar.yml` workflow runs all nine configurations, including development error reporting without the MAC services -- which did not link, because `csm.c` compiles the `Det_ReportError()` call whenever `WOLFSSL_AUTOSAR_DET` is defined while the test program defined the symbol only alongside CMAC -- each asserting its feature-gated test actually ran, plus a CMake job that links an application against the AUTOSAR API -- `--enable-autosar` previously had no CI coverage at all. Key material in a keystore slot is wiped with `ForceZero()` rather than `XMEMSET()` when the slot is overwritten or the driver re-initialized, a CMAC context whose initialization failed is freed rather than left behind, and the port test gained cases for the job slot lifecycle -- a restart of an active job, a job failing after START not leaking its slot, and every AES key length the keystore can hold. The port README documents the supported services, the compile time `MAX_KEYSTORE` and `MAX_JOBS` limits, the `heap` and `devId` configuration, key handles, the module identity and DET wiring, the `resultLengthPtr` and MAC length deviations from the specification, and what still does not conform if certification is the goal. by @SparkiDev (PR TBD)
+
 ## Bug Fixes
 
 * Fixed `wc_PKCS7_DecodeEnvelopedData()` and `wc_PKCS7_DecodeAuthEnvelopedData()` failing on a message addressed to more than one recipient; AuthEnvelopedData never supported it at all. A message carrying no recipient for the reader now reports `PKCS7_RECIP_E` rather than a parse error. Streaming an AuthEnvelopedData now buffers the whole RecipientInfo set, as the EnvelopedData decoder already did, so peak memory rises by the size of that set. by @Frauschi (PR 11350)

ChangeLog.md

@@ -127,6 +127,7 @@ function(generate_build_flags)
     set(BUILD_INTELASM ${WOLFSSL_INTEL_ASM} PARENT_SCOPE)
     set(BUILD_AFALG ${WOLFSSL_AFALG} PARENT_SCOPE)
     set(BUILD_DEVCRYPTO ${WOLFSSL_DEVCRYPTO} PARENT_SCOPE)
+    set(BUILD_AUTOSAR ${WOLFSSL_AUTOSAR} PARENT_SCOPE)
     if(WOLFSSL_CAMELLIA OR WOLFSSL_USER_SETTINGS)
         set(BUILD_CAMELLIA "yes" PARENT_SCOPE)
     endif()
@@ -1376,6 +1377,16 @@ function(generate_lib_src_list LIB_SOURCES)
             wolfcrypt/src/port/caam/wolfcaam_hmac.c)
     endif()
 
+    # Corresponds to wolfcrypt/src/port/autosar/include.am. Without these the
+    # WOLFSSL_AUTOSAR define still reaches options.h, so an application's Csm_*
+    # calls compile against Csm.h and then fail to link.
+    if(BUILD_AUTOSAR)
+        list(APPEND LIB_SOURCES
+            wolfcrypt/src/port/autosar/csm.c
+            wolfcrypt/src/port/autosar/crypto.c
+            wolfcrypt/src/port/autosar/cryif.c)
+    endif()
+
     if(BUILD_HPKE)
         list(APPEND LIB_SOURCES wolfcrypt/src/hpke.c)
     endif()

cmake/functions.cmake

@@ -577,6 +577,9 @@ extern "C" {
 #cmakedefine WOLF_C89
 #undef WOLFSSL_AUTOSAR
 #cmakedefine WOLFSSL_AUTOSAR
+
+#undef WOLFSSL_AUTOSAR_CMAC
+#cmakedefine WOLFSSL_AUTOSAR_CMAC
 #undef WOLFSSL_HASH_FLAGS
 #cmakedefine WOLFSSL_HASH_FLAGS
 #undef WOLFSSL_XILINX

cmake/options.h.in

@@ -12336,6 +12336,31 @@ then
 fi
 
 
+# Support for the autosar MAC services (AES-CMAC), an add-on to --enable-autosar
+AC_ARG_ENABLE([autosar-cmac],
+    [AS_HELP_STRING([--enable-autosar-cmac],[Enable AutoSAR MAC generate/verify services using AES-CMAC, requires --enable-autosar (default: disabled)])],
+    [ ENABLED_AUTOSAR_CMAC=$enableval ],
+    [ ENABLED_AUTOSAR_CMAC=no ]
+    )
+
+if test "$ENABLED_AUTOSAR_CMAC" = "yes"
+then
+    if test "$ENABLED_AUTOSAR" != "yes"
+    then
+        AC_MSG_ERROR([--enable-autosar-cmac requires --enable-autosar])
+    fi
+
+    # The driver calls wc_InitCmac()/wc_CmacUpdate()/wc_CmacFinalNoFree().
+    # WOLFSSL_AES_DIRECT comes with it: the WC_CMAC_AES case in cmac.c is
+    # compiled out without it, so wc_InitCmac() would fail at runtime.
+    AS_IF([test "$ENABLED_CMAC" != "yes"],
+          [ENABLED_CMAC="yes"
+           AM_CFLAGS="$AM_CFLAGS -DWOLFSSL_CMAC -DWOLFSSL_AES_DIRECT"])
+
+    AM_CFLAGS="$AM_CFLAGS -DWOLFSSL_AUTOSAR_CMAC"
+fi
+
+
 # Session Export
 AC_ARG_ENABLE([sessionexport],
     [AS_HELP_STRING([--enable-sessionexport],[Enable export and import of sessions (default: disabled)])],
@@ -14910,6 +14935,7 @@ echo "   * rwlock:                     $ENABLED_RWLOCK"
 echo "   * keylog export:              $ENABLED_KEYLOG_EXPORT"
 echo "   * TLS receive read-ahead:     $ENABLED_READAHEAD"
 echo "   * AutoSAR :                   $ENABLED_AUTOSAR"
+echo "   * AutoSAR CMAC :              $ENABLED_AUTOSAR_CMAC"
 echo "   * ML-KEM  standalone:         $ENABLED_MLKEM_STANDALONE"
 echo "   * PQ/T hybrids:               $ENABLED_PQC_HYBRIDS"
 echo "   * Extra PQ/T hybrids:         $ENABLED_EXTRA_PQC_HYBRIDS"