feat(core/embed): make pin verification faster on T3W1
What the developer wrote
Authored by Ondřej Vejpustek
feat(core/embed): make pin verification faster on T3W1
What changed, and why it matters
This commit changes how many times a device 'stretches' (repeats and strengthens) the user's PIN before checking it. On T3W1 devices, when a build-time flag called STRETCHED_PIN_COUNT is greater than 1, the code now reduces both Optiga hardware stretching and software PBKDF2 stretching to a single iteration. The stated goal is to make PIN verification faster. Reducing stretching weakens the protection against brute-force attacks if an attacker obtains the stored secrets, but the change is conditional on a build flag and does not by itself create a direct remote exploit. It is a security-relevant hardening reduction rather than an obvious vulnerability.
Treat as a security-relevant hardening change requiring review. Verify whether STRETCHED_PIN_COUNT > 1 on T3W1 is accompanied by equivalent or stronger stretching elsewhere, and confirm the production build does not accidentally enable this fast path. If the reduction is purely for speed without compensating controls, restore a higher iteration count or add a compensating rate-limit/anti-hammering mechanism. Request a security note or changelog entry from the vendor explaining the threat-model justification.
Security signals we found
Reduction of PBKDF2/Optiga PIN stretching iterations to 1 under a build-time condition
Conditional bypass of production iteration count via STRETCHED_PIN_COUNT macro
Change touches security-critical PIN verification and storage code
No explicit security rationale or threat-model discussion in commit message
No CVE, advisory, or researcher attribution present in supplied materials
Evidence from the diff
The patch conditionally lowers PIN stretching iterations. In core/embed/sec/optiga/optiga.c, PIN_STRETCH_ITERATIONS becomes 1 when STRETCHED_PIN_COUNT > 1, otherwise 2. In storage/storage.c, PIN_ITER_COUNT becomes 1 when (STORAGE_INSECURE_TESTING_MODE && !PRODUCTION) OR STRETCHED_PIN_COUNT > 1, otherwise it uses the production PBKDF2 iteration count. The new STRETCHED_PIN_COUNT > 1 branch appears intended for T3W1 builds where PIN stretching is already performed elsewhere (possibly across multiple shares), but the commit message only says ‘make pin verification faster’. The change reduces the computational cost for an offline attacker who extracts storage, and it removes a throttling-like defense in the PIN verification path.
Changed components
core/embed/sec/optiga/optiga.cstorage/storage.cT3W1 device PIN verification flowPIN stretching / PBKDF2 parametersInspect captured patch +5 / −1
diff --git a/core/embed/sec/optiga/optiga.c b/core/embed/sec/optiga/optiga.c
index e211ef5e..8c643882 100644
--- a/core/embed/sec/optiga/optiga.c
+++ b/core/embed/sec/optiga/optiga.c
@@ -62,7 +62,11 @@
#define OID_PIN_ECDH (OPTIGA_OID_ECC_KEY + 3)
// The number of times that PIN stretching is repeated.
+#if STRETCHED_PIN_COUNT > 1
+#define PIN_STRETCH_ITERATIONS 1
+#else
#define PIN_STRETCH_ITERATIONS 2
+#endif
// The throttling delay when the security event counter is at its maximum.
#define OPTIGA_T_MAX_MS 5000
diff --git a/storage/storage.c b/storage/storage.c
index c2f02c80..807484cf 100644
--- a/storage/storage.c
+++ b/storage/storage.c
@@ -106,7 +106,7 @@ const uint32_t V0_PIN_EMPTY = 1;
// up constant storage space.
#define MAX_WIPE_CODE_LEN 50
-#if STORAGE_INSECURE_TESTING_MODE && !PRODUCTION
+#if (STORAGE_INSECURE_TESTING_MODE && !PRODUCTION) || STRETCHED_PIN_COUNT > 1
#define PIN_ITER_COUNT 1
#else
// The total number of iterations to use in PBKDF2.
Why this scored 44/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.