Add tamper input mode with QR/manual options

[oroderico]

krux_tc_input_mode.mp4

What is this PR for?

This PR adds a setting for how Krux asks for the Tamper Check Code when running
TC Flash Hash:

• Manual
• Scan QR
• Ask Every Time

Manual is the default, so existing behavior is preserved.

Notes

This is only meant to reduce typing friction. It does not change the TC threat
model, does not make the TC Code a PIN, and does not add access control.

Changing the TC Code still requires manual input regardless of this setting.

QR input trims surrounding whitespace and rejects empty, malformed, multiline,
unexpected, or cancelled scan results.

Validation

• uv run poe format
• uv run poe lint
• uv run pytest --cache-clear tests/pages/test_tc_code_verification.py tests/pages/test_settings_page.py
• git diff --check

Targeted tests: 30 passed.

Hardware smoke-tested on Maix Cube.

[tadeubas]

The Tamper Check (TC) Code is not intended to defend against attackers or protect confidential data. Its purpose is to make firmware tampering obvious and to prevent casual bypass by normal users, not to provide strong access control. The device is intentionally open to modification and scrutiny.

This PR does not reduce attack friction. It only reduces user friction when entering an already user-known value.

QR input also enables the use of high-entropy TC Codes that may be impractical to type or memorize. This allows users to choose longer, more complex strings without worrying about typing errors, while preserving the same security assumptions and behavior.

I have no objections to this PR; the comments above are only meant to ensure that the author and reviewers share a clear understanding of what is involved.

If the ability to choose between manual input and QR input is being considered as an OPSEC, I already have a related PR #485 that intentionally does not address inconspicuous startup, in order to keep the scope small and improve the chances of an earlier merge has now a small QR code Kapp to address inconspicuous startup. The broader idea there is to later introduce a game or similar mechanism to improve OPSEC.

[oroderico]

The Tamper Check (TC) Code is not intended to defend against attackers or protect confidential data. Its purpose is to make firmware tampering obvious and to prevent casual bypass by normal users, not to provide strong access control. The device is intentionally open to modification and scrutiny.

This PR does not reduce attack friction. It only reduces user friction when entering an already user-known value.

QR input also enables the use of high-entropy TC Codes that may be impractical to type or memorize. This allows users to choose longer, more complex strings without worrying about typing errors, while preserving the same security assumptions and behavior.

I have no objections to this PR; the comments above are only meant to ensure that the author and reviewers share a clear understanding of what is involved.

If the ability to choose between manual input and QR input is being considered as an OPSEC, I already have a related PR #485 that intentionally does not address inconspicuous startup, in order to keep the scope small and improve the chances of an earlier merge. The broader idea there is to later introduce a game or similar mechanism to improve OPSEC.

@tadeubas

Thanks for the clarification — fully aligned.

This PR intentionally avoids framing TC input as a security or OPSEC feature.
The goal is purely to reduce user friction and error rates when entering an already user-known value, especially on constrained input devices.

No changes were made to validation logic, threat model, or startup behavior, and QR input remains strictly optional.

[qlrd]

LGTM while i did some first-round on code-quality aspects (less diff as possible, lints, etc.), so some non-blockable nits:

[qlrd]

Second round :), optional nits

[qlrd]

optional: those numbers are somewhat a guide for coding tests, IMHO no need to remove them (i saw them at first when started too, but then made sense from jeff's and other contributors perspective on long term).

[qlrd]

optional: IMHO no need to remove, it work like a document title. One important aspect of coding tests are the comments (we do not add docstrings for specific reasons but comments are valuable and help understand the context while coding).