Know what the keys do.
And what they don’t.
The details behind signing, recovery and device sync. This is a developer-reported research implementation, not an independently audited security specification.
Signing happens on the card.
Each supported YubiKey generates a secp256k1 private key inside its OpenPGP applet. The host requests an ECDSA signature; it does not receive the private key. Three enrolled card keys form a native SegWit 2-of-3 vault. The keys can be presented sequentially, so one USB port is enough.
The configured touch policy is fixed. Changing that policy requires resetting the relevant key material, which destroys the signing key. The app asks for the card’s PIN and physical touch. Hardware enforcement of touch is separate from the trustworthiness of the transaction shown on the host.
Addresses and derived keys
The current site describes fresh deposit and change addresses using host-side multiplicative derivation. A chain code in the recovery record determines a different child of each card public key. The app adjusts the requested digest and returned signature so a card signs for that child without performing key derivation itself. This custom construction deserves independent cryptographic review.
Older vaults use a fixed address and retain that behaviour. Do not treat the early fixed-key descriptor as a complete description of every newer vault. Export the recovery record for the actual vault version.
Separate theft from a compromised host.
A lost device or a stolen key
A copy of the app’s disk storage does not contain the on-card signing keys. A single stolen card cannot meet a 2-of-3 policy, even with its PIN. The app’s records are encrypted at rest; their protection depends on the device, key storage, configuration and implementation.
The public implementation description uses the platform key store and enrolled hardware keys to protect the records-encryption key. Locking or sleeping a device is intended to remove the open key from memory. An unlocked app is a different threat model.
Malware while you use the wallet
A screenless key cannot check the destination. Malware can show one transaction and request a signature for another. A PIN and touch constrain signing access, but they do not authenticate the intent displayed by a compromised host. Do not read “requires your touch” as “cannot be tricked into spending.”
Malware can also observe a PIN, screen, clipboard, temporary attachments or open records, subject to the operating system’s isolation. Encryption at rest does not protect information after a legitimate app decrypts it.
Adding a screened signer
A mixed vault can enrol a screened device from its key file or QR and exchange signing data by QR or PSBT file. A mixed SeedSigner vault is part of the developer-reported evidence. Other combinations need individual testing.
Two security keys plus one screened signer at 2-of-3 do not require the screen. The screen helps when that signer participates and the user verifies the correct wallet, destination, amount, fee and change. The other two keys can still sign without it. Requiring a screened signer needs a spending policy that actually enforces its participation.
Screen capture
The current implementation reports capture restrictions for private profiles on macOS and Android. Those are not guarantees against a compromised operating system. On iOS, screenshots remain possible, and a recording/mirroring curtain is not implemented according to the current public description. Work and fiction profiles are deliberately capturable.
Recovery restores the record.
The recovery record contains the public information needed to reconstruct the vault, including its keys, threshold and applicable derivation information. Shamir sharing splits that record at the vault’s threshold. It does not split or export the cards’ private signing keys.
Seal every key
Once the vault is enrolled, each key is presented again with the required PINs. A share is stored in the card’s certificate object, encrypted under a secret protected by a PIN-gated card slot. The app reads back the write before marking the key sealed. All three must be sealed for every possible surviving pair to work.
Any two correctly sealed cards with their PINs can reconstruct the public record using compatible software. Moving coins still needs the corresponding signatures and touches. Two cards without their PINs are not a recovery plan. Fewer than two surviving signing keys cannot spend under this policy.
The recovery sheet
An exported sheet, QR or PDF preserves the public vault information independently. It can help with unsealed keys or compatible external software, but it cannot replace missing signing keys or forgotten PINs. The sheet reveals wallet information, so keep it separate from PIN records.
Independent formats and tools
- Published seal format
- Standalone Python recovery tool
- Bitcoin Core can import supported descriptors, build spends and finalise signed transactions. Test the exported format for your vault version.
- The current site reports that Sparrow and Electrum cannot import the early fixed-key multisig descriptor as a signing wallet. Watching an address or broadcasting a finished transaction is not equivalent to full recovery support.
A mixed vault with a seed-based signer introduces that signer’s own backup requirements. Do not assume the three-security-key sealed-share recovery model applies unchanged.
Capability is not compatibility.
The documented baseline is the non-FIPS YubiKey 5 series on firmware 5.2.3 or later. The reported physical tests include firmware 5.4 and 5.8. Supported series models listed publicly are 5 NFC, 5C NFC, 5C, 5Ci, 5 Nano and 5C Nano.
YubiKey Bio, Security Key series, 5 FIPS and YubiKey 4 or earlier are not supported for the documented on-card secp256k1 signing setup. FIDO2 and PIV capabilities alone do not establish Bitcoin-signing support.
One Nitrokey 3C NFC on firmware 1.9.1 has been tested end to end: on-card key generation with fixed touch, signing, sealing, and a firmware update performed by the app itself. That is one key, not a test matrix for every Nitrokey model. Token2 integration still requires confirmation for the exact model and firmware. Curve support, touch policy and recovery behaviour all matter.
USB and platforms
The public site describes USB-connected operation on macOS, iPhone 15 or later, USB-C iPad and Android. NFC is not used by the documented signing flow. Confirm your connector, operating system and build before testing.
Setup and PINs
The app describes an integrated setup flow: inspect the card, choose and record the required PINs, generate the signing key, fix the touch policy, and verify an initial signature. It also disables Yubico OTP keyboard output to avoid unwanted typing on a casual touch. That changes existing key behaviour; inspect current uses before proceeding.
PIN retry limits can lock card functions. Understand the exact firmware’s retry, unblock and reset behaviour before setup. Resetting key material can permanently remove access to a signing key. Start with spare hardware and signet.
Records can follow you.
Optional sync covers vault records, labels, notes, contacts, places and attachments. The device encrypts records before upload to a compatible Versioned Storage Service host. The current app uses a mineracks host by default and allows another compatible host.
An enrolled key can carry PIN-protected profile join material. Joining a synced profile with one key is distinct from the two-key spending policy and two-share vault recovery. Receiving profile data does not confer the signatures needed to spend.
The host still sees metadata such as sizes, timing and network addresses. “Encrypted” is not the same as anonymous. The current implementation reports that object names do not directly reveal the vault, but no independent privacy audit is claimed.
Changes and deletions propagate between devices. Sync is not a substitute for independent backups. A replacement profile-encryption key does not erase information a lost device already had. Real-device key-rotation testing is listed as incomplete.
If the host disappears, existing local records remain exportable. Cross-device sync and recovery of hosted records still require an available compatible service and the encrypted data. This is separate from recovering the on-chain vault record from sealed keys.
Know what leaves the device.
The current public description lists addresses and transactions sent to a Bitcoin server, exchange-rate requests, and optional encrypted sync. Optional Places features use search and map services. The app reports no account requirement, telemetry or its own crash reporting.
Photos are normally decoded and re-saved to remove camera metadata, unless the user chooses to preserve the original file. Places can record an approximate location and consult local city data; searches and map tile requests still disclose information to their service. Those privacy properties depend on the implementation and server operation.
Read the existing privacy notice for the named services, data and retention statements. The app’s privacy practices are distinct from this informational website.
Evidence, with its limits attached.
The current public site reports one developer, one set of keys and a handful of transactions. The following are implementation claims, not independent attestations:
- On-card key generation, fixed touch and integrated setup.
- Two-card SegWit spends on Mac, iPhone 15 Pro Max and Pixel 9 Pro Fold running GrapheneOS.
- A mainnet vault forgotten and restored from two sealed cards and their PINs.
- Encrypted records, labels and attachments restored on another device.
- Optional sync between a Mac and two phones, including photos.
- Signature attribution and node inclusion-proof checks.
- A mixed vault with a SeedSigner exchanging signing data by QR.
A published small transaction
The site reports a 5,000-sat spend with a 190-sat fee, using two YubiKeys. The identifier below is provided as reported evidence, not an endorsement or proof that the implementation is safe.
bcd3fb3da2e6abd3381b2dd5cde0b3cc0357c0eb999bcba5027eec2786a391e1
Work still open
- Independent review and a security audit.
- Broader device, firmware, recovery and transaction testing.
- Mixed-vault registration on Coldcard and fee bumping from this wallet.
- Improved phone layouts and physical-device profile-key rotation tests.
- Reproducible builds. The Mac build is signed and notarised and published with its SHA-256; nothing is reproducible yet.
Version 0.1.0 is free and open source (MIT, github.com/mineracks/anytwokeys). The Mac build is public; iPhone, iPad and Android builds reach testers by invitation through TestFlight and Google Play internal testing. The download section has the links and the hash.
Start on signet. Do not use this prototype for savings.