Role of the NPU complier

To support the encryption of the weights, the NPU compiler provides a specific option ('–-encrypt-weights') which generates the extra code needed to configure the stream engines to fetch the encrypted data and decrypt them on-the-fly for the processing units. Only three or four cycles of latency are added. With this option, all weights/parameters regions are considered encrypted by the NPU compiler. For the software epochs, as the weights cannot be decrypted by the MCU, extra epochs are generated to decrypt the used weights in a specific activation memory region, allowing direct access. This additional activation region is used temporarily during the processing time, increasing the requested memory size.

Role of the application developer

At “installation” time, the integrator or application developer is in charge of encrypting the memory chunks associated with a weights/params region.
At runtime, when performing an inference, one is only responsible for setting the keys on the bus interface before performing the inference.

Important remarks

• The encrypted value depends on the address, this means that other things being equal, encryption may not provide the same result at two different addresses (that is, it is not possible to move encrypted weights around in memory otherwise decryption fails).
• Each parameter (except the address) should be kept as secret as possible. Leaking a parameter could make an attacker’s job easier.
  
• The encryption algorithm is involutive: encrypting with the same parameters twice output the original data. The encryption process is the same as the decryption process.
• In the current implementation of the embedded low-level API, only the key values can be made to vary, other parameters are set to hardcoded values for simplicity

Generate, for encrypted inference

When generating code using encryption the --encrypt-weights option has to be added in the profile used during generation.

$> stedgeai generate -m MYMODEL.tflite --target stm32n6 --st-neural-art my_profile@my_profiles.json

The generation process produces (in the output directory) files that are needed for the encryption step:

• c_info.json file representing some information about code generation done
• *.raw files containing the weights to be programmed on board, unencrypted

Encrypt weights

For this step, it is required to have an STM32N6 board (for example, STM32N6-DK) connected to the computer.

$STEDGEAI_CORE_DIR/scripts/N6_encrypt folder contains:

• A c subfolder including the embedded project used for encryption (delivered as source if ever needed),
• A python folder including the scripts that should be used by users (also delivered as source if ever needed)
  • end_to_end_encrypt.py is the recommended script to use for easy encryption

Launching the tool encrypts a .raw file and replace the original file by the encrypted one (the original plain file is then available in the .unencrypted file created).
The encrypted file can then be used as-is in the next step using the n6_loader.py.

$> python end_to_end_encrypt.py --cubeide C:/ST/STM32CubeIDE_1.17.0/STM32CubeIDE --postprocess C:/stai/st_ai_output/network_c_info.json C:/stai/st_ai_output/network_atonbuf.xSPI2.raw

17:29:40.128 :: cubeIDE_toolbox.py :: INFO     :: Resetting the board
17:29:40.977 :: cubeIDE_toolbox.py :: INFO     :: Starting GDB server
17:29:41.132 :: cubeIDE_toolbox.py :: INFO     :: Starting GDB client
17:29:42.351 :: end_to_end_encrypt.py :: INFO     :: Waiting for the firmware to initialize
17:29:43.352 :: end_to_end_encrypt.py :: INFO     :: Starting encryption script
17:29:43.353 :: encrypt_neural_art.py :: INFO     :: Parsing c_info file
17:29:43.368 :: encrypt_neural_art.py :: INFO     :: Memory pool to encrypt found at address: 0x71000000 -- 20.142 kBytes to encrypt at offset 0
17:29:43.399 :: encrypt_neural_art.py :: INFO     :: Starting encryption
17:29:43.399 :: encrypt_neural_art.py :: INFO     :: Sending encryption params: keys = (MSB:0xaabbccddaabbccdd)(LSB:0xaabbccddaabbccdd) -- nb_rounds = 12
17:29:43.619 :: encrypt_neural_art.py :: INFO     :: Data transfer finished -- Took 0.197 seconds -- size = 20.142kB -- Encryption rate: 102.242kB/s
17:29:43.620 :: encrypt_neural_art.py :: INFO     :: Encrypted data injected into network_atonbuf.xSPI2_encrypted.raw
17:29:43.620 :: encrypt_neural_art.py :: INFO     :: Done
17:29:43.621 :: end_to_end_encrypt.py :: INFO     :: Postprocessing the files
17:29:43.621 :: end_to_end_encrypt.py :: INFO     :: Backup of original unencrypted weights: network_atonbuf.xSPI2.raw -> network_atonbuf.xSPI2.unencrypted
17:29:43.621 :: end_to_end_encrypt.py :: INFO     :: Replacing original file with encrypted weights: network_atonbuf.xSPI2_encrypted.raw -> network_atonbuf.xSPI2.raw
17:29:43.659 :: end_to_end_encrypt.py :: INFO     :: Done

usage: end_to_end_encrypt.py [-h] [-v] [-k KEYS KEYS] [-r NBROUNDS] [-p COMPORT] --cubeide CUBEIDE [--skip_debug] [--postprocess] [--flash] c_info raw_file

End-To-End encryption tool for weights using Neural Art

positional arguments:
  c_info                json file output of the compilation
  raw_file              memory-initializer file output of the compilation (.raw)

optional arguments:
  -h, --help            show this help message and exit
  -v, --verbose         Increase output verbosity (debug) (default: False)
  -k KEYS KEYS, --keys KEYS KEYS
                        Keys to use (MSB LSB) (default: [12302652059516914909, 12302652059516914909])
  -r NBROUNDS, --nbrounds NBROUNDS
                        Number of rounds (ignored for now) (default: 12)
  -p COMPORT, --comport COMPORT
                        COM-port name to be used for transmitting data to STLink. auto tries to connect to the first "STLink" found. (default: auto)
  --cubeide CUBEIDE     Path to cubeIDE install dir (default: None)
  --skip_debug          Skip loading the encryption tool elf file to the board (default: False)
  --postprocess         Postprocess the files to use them with the n6_loader script (default: False)
  --flash               After postprocessing, flash the encrypted weights to the board (default: False)

Easy case

For most cases (except when dealing with weights stored in flash – see below), doing a data transfer to encrypt a buffer is straightforward.
ll_aton_cipher provides int LL_DmaCypherInit(LL_Cypher_InitTypeDef *cypherInfo) that can be used to do a stream engine transfer to encrypt data.

The argument of this function is of type LL_Cypher_InitTypeDef:

typedef struct {
    uint32_t srcAdd;                       /**< Transfer source address */
    uint32_t dstAdd;                       /**< Transfer destination address */
    uint32_t len;                          /**< Transfer size */
    CypherCacheSourceMask cypherCacheMask; /**< Cache usage mask:
                                            *     0-no cache
                                            *     1-cache source
                                            *     2-cache destination */
    CypherEnableMask cypherEnableMask;     /**< Cyphering channel mask:
                                            *     0-no cypher
                                            *     1-cypher source
                                            *     2-cypher destination */
    uint64_t busIfKeyLsb;                  /**< Bus interface LSB Key */
    uint64_t busIfKeyMsb;                  /**< Bus interface MSB Key */
  } LL_Cypher_InitTypeDef;

• srcAdd, dstAdd and len are used respectively for the source address, the destination address and the transfer size.
  
• cypherEnableMask can be used to activate cyphering: the address used for encrypting weights can be either the source or the destination address depending on the use-case.
  
• cypherCacheMask should not be used for the standard case (not triggering encryption of external-flash-bound weights).

The last two fields contain the bus interface key to use: 2x64-bits = 128 bits. This function returns when the data transfer is over.

Tricky case: Encrypting for external flash

Encrypting to external flash can be tricky because it is not possible for the stream engines to write directly to external flash. Capability to write in an external FLASH through the XSPI interface in memory-mapped mode is not guarantee.

One solution is to store the plaintext to external FLASH at the final address and encrypts it using the source address as a parameter TO a buffer in internal RAM. The resulting buffer stored in RAM could then be written to flash by the CPU, at the final address. The drawback of this solution is that the unencrypted data is stored in the FLASH for a given period.