RFC: Optional Duress Event for Emergency Seed Wipe

[oroderico]

RFC: Duress Event for Emergency Seed Wipe in Krux

Status

Proposal / Discussion

---

Summary

This RFC proposes adding an optional Duress Event to Krux, capable of invalidating (erasing) all locally stored seeds (internal flash and SD card) when a specific, preconfigured trigger is activated.

The goal is to provide extreme protection against physical coercion, assuming the user has reliable physical backups of their seeds, and that the device may be abandoned or confiscated after the event.

---

Motivation

In real-world threat scenarios (physical coercion, extortion, confiscation), denying access to the device or showing errors can increase physical risk to the user.

Some hardware wallets implement duress mechanisms that:

• Neutralize the value of the device
• Maintain plausible device behavior
• Protect the user’s funds via external backups

Krux currently has no equivalent mechanism. This RFC explores if and how such a feature could be implemented without compromising security, clarity, or user trust.

---

Assumptions (Explicit)

This RFC assumes that:

• The user has valid physical backups of all seeds
• Wiping local seeds does not imply permanent loss of funds
• The device may be abandoned after the event
• The feature is opt-in and disabled by default
• The feature targets advanced users who understand the risks

Users without backups must not enable this feature.

---

Threat Model

Threats addressed

• Physical coercion to unlock or use the device
• Device confiscation with expectation of immediate access
• Extortion in hostile environments

Out of scope

• Advanced forensic attacks
• Physical extraction of flash memory
• Malware on the host
• Users without backups
• Remote attacks

This RFC intentionally limits scope to avoid unrealistic guarantees.

---

Invariants (Non-negotiable)

The proposed design must not:

1. Perform destructive actions without explicit opt-in
2. Reuse or overload the semantics of the existing Tamper Check
3. Introduce backdoors or undocumented hidden behavior
4. Display explicit “panic” or “emergency” feedback during execution
5. Break existing validation or security flows

Violation of any invariant should result in rejection.

---

Core Concept

Duress is not a PIN or an alternate Tamper Check, but a deliberate event.

The Duress Event represents an extreme, intentional action, comparable to an emergency wipe, triggered only through a preconfigured mechanism.

---

Duress Event Trigger (Proposal)

Primary model (Preferred)

• A user-defined Duress Code
• Entered in an existing code-entry prompt
• No visual UI changes during execution

Simplified logic:

input_code
 ├─ if input == duress_code:
 │     trigger_duress_event()
 │     continue_flow()
 ├─ else if input == normal_code:
 │     normal_flow()
 └─ else:
       invalid_code()

Trigger properties

• Extremely low chance of accidental activation
• Does not reuse Tamper Check
• Does not introduce new suspicious prompts
• No confirmation required at execution time

---

Duress Event Behavior

When triggered:

1. All locally stored seeds are invalidated
   • Internal flash
   • SD card (best-effort)
2. No warnings, alerts, or confirmations are shown
3. The device enters a plausible post-reset state
4. The UI continues operating normally
5. The device appears to contain no funds

The goal is plausibility, not visible destruction.

---

Wipe Strategy (Technical Considerations)

Internal flash

• Explicitly erase seed storage
• Overwrite where possible
• Ensure atomicity:
  • If power is lost mid-wipe, the process resumes on boot

SD card

• Remove seed files
• Overwrite metadata where possible
• Known limitation: full secure erase on SD cards cannot be guaranteed
• This limitation must be explicitly documented

---

Configuration UX (Where clarity is mandatory)

Duress configuration is not silent.

It must include:

• Explicit irreversibility warning
• Multiple confirmations
• Default: disabled
• (Optional, recommended) Backup proof:
  • e.g., entering specific words from the backup

Once enabled, execution may be silent.

---

Initial Scope (Proposed MVP)

To reduce risk and ease evaluation:

• Single trigger method (Duress Code)
• Guaranteed wipe of internal flash
• SD handled as best-effort
• No QR triggers or multiple methods in v1

Future extensions can be discussed separately.

---

Known Risks

• Potential DoS if the trigger is discovered
• Temporary loss of access until seed restoration
• Complexity of implementing a reliable wipe

These risks are considered acceptable only because the feature is opt-in and explicit.

---

Alternatives Considered

• Second Tamper Check → rejected (incorrect semantics)
• Duress “decoy context” without wipe → safer but out of scope
• Visible “Emergency Wipe” menu → less effective under coercion

---

Conclusion

This RFC proposes an optional, explicit, and extreme Duress Event, aligned with real-world threat models and comparable to mechanisms found in other hardware wallets, adapted to Krux’s design and usage model.

The proposal prioritizes:

• Clarity
• Conscious opt-in
• Limited scope
• Absence of backdoors
• Realistic threat mitigation

Community feedback is essential before any implementation.

---

[tadeubas]

If an attacker doesn’t know what the device is, an inconspicuous startup alone #203 would already mitigate most risk. If the device is seized by authorities, it’s unclear whether erasing the seed provides more or less protection; in that scenario, only a strong encryption key really matters. See these Considerations.

This approach seems better suited to devices that store secrets locally and protect them with a PIN (a weak key), where brute-force attacks are a concern. I’m not convinced this feature would benefit users overall, as it could create a false sense of security, especially if combined with a weak encryption key.

Users can mitigate this risk by not storing secrets on the device, removing the SD card beforehand, or fully wiping the device before traveling.

In the current code, data erasure from the SD card is even more reliable than from internal flash memory; however, we still cannot guarantee that the data is unrecoverable:

src/krux/encryption.py

def del_mnemonic(self, mnemonic_id, sd_card=False):
        """Remove an entry from encrypted mnemonics file"""
        if sd_card:
            self.stored_sd.pop(mnemonic_id)
            with SDHandler() as sd:
                orig_len = len(sd.read(MNEMONICS_FILE))
                contents = json.dumps(self.stored_sd)
                # pad contents to orig_len to avoid abandoned bytes on sdcard
                if len(contents) < orig_len:
                    contents += " " * (orig_len - len(contents))
                sd.write(MNEMONICS_FILE, contents)
        else:
            self.stored.pop(mnemonic_id)
            with open(FLASH_PATH_STR % MNEMONICS_FILE, "w") as f:
                f.write(json.dumps(self.stored))

[tadeubas]

Seems related to #814, since the current implementation of TC Hash at Boot could have influenced the direction of that discussion