Design Decisions
Frostsnap makes several unconventional choices that differ from
traditional hardware wallets. These decisions are intentional and core
to the security model to provide an unmatched user experience that
enable users to achieve an extremely high level of security.
Keeping your keys accessible to you and your loved ones; whilst
out of reach from attackers.
No PINs
Core constraint: In Bitcoin, you own money through a secret.
Frostsnap's approach is to split up this secret so you can't lose all your money in one place.
You can always protect a secret by adding another secret (passphrases, PINs, passwords) -- the path most Bitcoin security takes. But each additional secret often becomes another point of failure: something else to remember, backup, and pass on.
Problems with PINs:
- • Additional cognitive burden -- another secret to remember, record, backup
- • Complicates inheritance -- Hardware becomes difficult to leverage for a secure inheritance process
- • Recovery risks -- forget the PIN, brick the device
- • Physical security risks -- easily extractable through duress and violence
Frostsnap's Approach:
Physical access to keys is the security boundary -- you need access to a threshold number of keys, whether on devices or recovery cards, in a forgiving threshold of your choosing.
- ❄ Phone's secure element protects device secrets
- ❄ No PINs to remember or write down
- ❄ Simple rule: "you need X keys to access your wallet"
- ❄ Easier to explain and safer to inherit
Why No Secure Elements?
Secure elements generally focus on one particular task: to release a secret upon being presented with a PIN. These tamper-resistant chips are a popular approach for ensuring that only authorized users can use the device.
Common Misconception
Most people think signing operations occur inside the secure element. This is NOT the case with most hardware wallets:
- 1. PIN releases a decryption key
- 2. Key passes to the main chip
- 3. Secret key is decrypted and used in memory on the main MCU
Limitations of Secure Elements:
- Not foolproof: Attacks can still occur on the micocontroller that carries out cryptographic operations.
- Invokes the need for a PIN: Introducing all the problems mentioned above.
- Security through Obscurity: Almost all secure elements are closed source.
- Less battle-tested: Bitcoin secure elements are far less proven than mobile phone secure elements.
Frostsnap's Approach:
Instead of each device protected by a secure chip and requiring a PIN, Frostsnap:
- • Requires threshold to unlock: To use any share, device must receive decryption key from coordinator, but coordinator must connect to threshold number of other devices to generate it
- • Nothing to extract: If one device is compromised, attacker can't access or use its share without compromising the threshold of your setup or the secure element of your phone.
Same security outcome - achieved through decryption keys and cryptographic protocol design.
Powerful Cryptography, Not Airgapping
Frostsnap devices are not airgapped -- they connect to your phone or laptop via USB.
Why?
FROST requires multiple rounds of interactive communication. For a 3-of-5 transaction via QR codes, you'd need 9+ QR scans per transaction. For larger quorums, this becomes incredibly tedious.
Usability degradation leads to security degradation:
When security measures become too cumbersome:
- • People avoid using multisig altogether
- • Users resort to elaborate verification rituals--dice-roll entropy, seed words, xpubs, deterministic nonces--repeated across independent devices
- • Or they skip verification steps entirely
- • Advanced cryptographic protections become too burdensome to use--like verifiable key generation and anti-exfiltration protocols
Why Airgapping Doesn't Actually Solve the Problem
Airgapping attempts to solve two threat models: (1) malicious devices attacking computers to leak seeds to the internet, and (2) malicious apps attacking devices to extract seeds.
The intuition is that airgapping makes these attacks harder. This intuition is wrong.
- For (1), airgapping makes attacks easier: It hinders cryptographic protections since multi-round protocols become too cumbersome over QR codes. DarkSkippy demonstrated that airgapped devices can leak secrets trivially through QR codes.
- For (2), airgapping may increase attack surface: QR codes and SD cards require additional hardware, drivers, and sometimes closed-source binary blobs (e.g., cameras). The real solution is avoiding unsafe languages like C in decoding logic. Frostsnap uses the Rust programming language.
- Data must flow either way: Since covert channels defeat visual inspection, we must eliminate attack surrface through cryptography and memory-safe languages, not perceived isolation.
Simple USB serial communication implemented in memory-safe Rust is actually the most paranoid way to have two untrusted devices communicate.
Offline Coordinator Option
For maximum isolation: Keep your coordinator (phone/laptop) permanently offline. Connect devices to the offline coordinator, then manually transfer signed transactions to an online device for broadcasting. You could even use Tails OS with encrypted persistent storage.
But we recommend that you simply use an online coordinator, devices validate every message independently and never leak secrets.
Either way, the coordinator never holds private keys and devices deserialize and verify messages safely.