fix(core/prodtest): improve nrf re-pairing protection
What the developer wrote
Authored by tychovrahe
fix(core/prodtest): improve nrf re-pairing protection
[no changelog]
What changed, and why it matters
This commit tightens the rules for pairing a Trezor hardware wallet with its Nordic (nRF) wireless chip during factory production testing. Previously, the production-test tool could try to re-derive the pairing secret even after the device's secure secret storage was locked, which could have allowed unauthorized re-pairing or leaking of the pairing secret. Now the tool first checks whether the devices are already paired, and the secret-derivation function refuses to run if the secrets sector is locked. This is a defensive hardening fix in a manufacturing diagnostic tool, not a user-facing wallet bug.
Treat as a security hardening patch for the manufacturing/prodtest stack. Apply to relevant firmware branches and verify that production tooling does not rely on deriving the nRF pairing secret after the secrets sector is locked. No immediate end-user action is required.
Security signals we found
Locked secrets sector now blocks nRF pairing secret derivation
Production-test pairing command checks existing authentication before failing on locked state
Validation path separated from derivation path to keep authentication working while blocking new pairing
No changelog entry suggests internal hardening rather than user-visible feature
Evidence from the diff
The change touches two files. In prodtest_nrf.c, the prodtest_nrf_pair CLI command now calls nrf_authenticate() when secret_is_locked() returns true. If authentication succeeds, it reports ‘Already paired’ and exits successfully; otherwise it still errors out. In secret_keys.c, secret_key_nrf_pairing() now returns secfalse immediately if the secrets sector is locked, preventing derivation of the nRF pairing secret from a locked device. The caller secret_validate_nrf_pairing() is updated to call the lower-level secret_key_derive_sym() directly so validation can still occur even when locked, while pairing derivation is blocked. This closes a path where a locked device might be forced or tricked into re-deriving/revealing the pairing key.
Changed components
core/embed/projects/prodtest/cmd/prodtest_nrf.ccore/embed/sec/secret/stm32u5/secret_keys.cTrezor Core production-test (prodtest) nRF pairing flowSTM32U5 secret key derivation for Nordic pairingInspect captured patch +14 / −1
diff --git a/core/embed/projects/prodtest/cmd/prodtest_nrf.c b/core/embed/projects/prodtest/cmd/prodtest_nrf.c
index c1eddccdc..05b32f6dc 100644
--- a/core/embed/projects/prodtest/cmd/prodtest_nrf.c
+++ b/core/embed/projects/prodtest/cmd/prodtest_nrf.c
@@ -88,6 +88,12 @@ static void prodtest_nrf_pair(cli_t* cli) {
}
if (secfalse != secret_is_locked()) {
+ if (nrf_authenticate()) {
+ cli_trace(cli, "Already paired");
+ cli_ok(cli, "");
+ return;
+ }
+
cli_error(cli, CLI_ERROR,
"Secrets sector is locked. Pairing is not allowed.");
return;
diff --git a/core/embed/sec/secret/stm32u5/secret_keys.c b/core/embed/sec/secret/stm32u5/secret_keys.c
index bd2073d3c..a766f5a95 100644
--- a/core/embed/sec/secret/stm32u5/secret_keys.c
+++ b/core/embed/sec/secret/stm32u5/secret_keys.c
@@ -175,6 +175,11 @@ static secbool secequal(const void *ptr1, const void *ptr2, size_t n) {
secbool secret_key_nrf_pairing(uint8_t dest[NRF_PAIRING_SECRET_SIZE]) {
_Static_assert(NRF_PAIRING_SECRET_SIZE == SHA256_DIGEST_LENGTH);
+
+ if (secfalse != secret_is_locked()) {
+ return secfalse;
+ }
+
return secret_key_derive_sym(SECRET_UNPRIVILEGED_MASTER_KEY_SLOT,
KEY_INDEX_NRF_PAIRING, 0, dest);
}
@@ -184,7 +189,9 @@ secbool secret_validate_nrf_pairing(const uint8_t *message, size_t msg_len,
secbool result = secfalse;
uint8_t key[NRF_PAIRING_SECRET_SIZE] = {0};
- if (sectrue != secret_key_nrf_pairing(key)) {
+
+ if (sectrue != secret_key_derive_sym(SECRET_UNPRIVILEGED_MASTER_KEY_SLOT,
+ KEY_INDEX_NRF_PAIRING, 0, key)) {
return secfalse;
}
Why this scored 59/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.