Browse Source

feat: use RAK hardware crypto on advert processing

While working on some sensor code implementations, I ran into
some hard crashes that root-caused to the 4KB loop task stack
being exhausted.

Looking for various optimization schemes resulted in this relatively
low-lift fix. RAK3401 and RAK4631 both support hardware crypto.

Rather than loading in one of the two software crypto libs,
we can just use the onboard hardware. This is faster, should
consume less power, and in testing used a scant up to 700
bytes in the run loop vs 2.5-3KB per advert.

This change **only** affects advert verification processing, which
currently consumes a significant chunk of the 4KB run loop.

I figured such a change should likely be implemented in phases.

After soaking, this hardware crypto verification
process could be implemented across the entire MeshCore
cryptographic function on RAK nodes. Also possible other nodes
have available hardware crypto, however, I have not checked,
so future improvements may also exist there.

Tested on:
  - RAK3401 RAK 1W
  - RAK4631 19001
pull/2824/head
Nick Dunklee 1 month ago
parent
commit
4ac8742ce0
  1. 20
      src/Identity.cpp
  2. 1
      variants/rak3401/platformio.ini
  3. 1
      variants/rak4631/platformio.ini

20
src/Identity.cpp

@ -4,6 +4,11 @@
#include <ed_25519.h> #include <ed_25519.h>
#include <Ed25519.h> #include <Ed25519.h>
#ifdef USE_CC310_ED25519
#include <Adafruit_nRFCrypto.h>
#include "nrf_cc310/include/crys_ec_edw_api.h"
#endif
namespace mesh { namespace mesh {
Identity::Identity() { Identity::Identity() {
@ -15,7 +20,20 @@ Identity::Identity(const char* pub_hex) {
} }
bool Identity::verify(const uint8_t* sig, const uint8_t* message, int msg_len) const { bool Identity::verify(const uint8_t* sig, const uint8_t* message, int msg_len) const {
#if 0 #ifdef USE_CC310_ED25519
// nRF52840 CryptoCell CC310 hardware Ed25519 verification. The software
// implementations need ~3KB of stack (which can overflow the Adafruit core's
// 4KB loop task stack from the advert receive path); the hardware path
// needs much less, around 600-700bytes. The CC310 workspace is static, faster,
// should save power at scale as well.
static CRYS_ECEDW_TempBuff_t cc310_tmp;
nRFCrypto.begin();
CRYSError_t rc = CRYS_ECEDW_Verify((uint8_t*)sig, CRYS_ECEDW_SIGNATURE_BYTES,
(uint8_t*)pub_key, CRYS_ECEDW_MOD_SIZE_IN_BYTES,
(uint8_t*)message, (size_t)msg_len, &cc310_tmp);
nRFCrypto.end();
return rc == CRYS_OK;
#elif 0
// NOTE: memory corruption bug was found in this function!! // NOTE: memory corruption bug was found in this function!!
return ed25519_verify(sig, message, msg_len, pub_key); return ed25519_verify(sig, message, msg_len, pub_key);
#else #else

1
variants/rak3401/platformio.ini

@ -13,6 +13,7 @@ build_flags = ${nrf52_base.build_flags}
-D SX126X_CURRENT_LIMIT=140 -D SX126X_CURRENT_LIMIT=140
-D SX126X_RX_BOOSTED_GAIN=1 -D SX126X_RX_BOOSTED_GAIN=1
-D SX126X_REGISTER_PATCH=1 ; Patch register 0x8B5 for improved RX with SKY66122 FEM -D SX126X_REGISTER_PATCH=1 ; Patch register 0x8B5 for improved RX with SKY66122 FEM
-D USE_CC310_ED25519=1
build_src_filter = ${nrf52_base.build_src_filter} build_src_filter = ${nrf52_base.build_src_filter}
+<../variants/rak3401> +<../variants/rak3401>
+<helpers/sensors> +<helpers/sensors>

1
variants/rak4631/platformio.ini

@ -22,6 +22,7 @@ build_flags = ${nrf52_base.build_flags}
-D LORA_TX_POWER=22 -D LORA_TX_POWER=22
-D SX126X_CURRENT_LIMIT=140 -D SX126X_CURRENT_LIMIT=140
-D SX126X_RX_BOOSTED_GAIN=1 -D SX126X_RX_BOOSTED_GAIN=1
-D USE_CC310_ED25519=1
-D ENV_INCLUDE_RAK12035=1 -D ENV_INCLUDE_RAK12035=1
-UENV_INCLUDE_BME680 -UENV_INCLUDE_BME680
-D ENV_INCLUDE_BME680_BSEC=1 -D ENV_INCLUDE_BME680_BSEC=1

Loading…
Cancel
Save