NFC Encrypted Backup — Your Master Key on a Physical Tag
VaultKeepR's NFC Encrypted Backup stores an encrypted copy of your master key on a physical tag. On the configured device, the tag works together with the device secret and your PIN, which the iOS path keeps in a this-device-only keychain; the tag alone does not restore a vault on a brand-new phone after the old one is gone. A new-device recovery needs the decryption material you explicitly preserve and a procedure you have tested. No cloud recovery. No "forgot password" email.
The Problem With Recovery Flows
Every major password manager relies on a centralized server for recovery. That creates multiple risks:
- Email-based recovery is a weak link. If your email is compromised, your vault is compromised.
- Servers store recovery tokens. Breaches at LastPass, Norton, and OneLogin have exposed encrypted data that can be brute-forced over time.
- You depend on the company. If the service shuts down or suffers an outage, your recovery path disappears.
VaultKeepR takes a different approach: your recovery key lives in your pocket, not on someone else's server.
What's Actually Stored on the NFC Tag?
An NFC tag is a medium for a recovery payload. It is not a full vault copy or an automatic export of a passkey private key. Biometrics verify the user; they do not generate an encryption key. Check the client's supported format and restore conditions.
Think of it like a physical house key: the key opens the door, but it doesn't contain the house.
NFC Tag = Encrypted Master Key
Device / IPFS = Encrypted Vault
Master Key → Decrypts → Vault
The tag contains a single NDEF record with this structure:
┌──────────┬─────────────┬─────────────────────────────┐
│ Header │ Nonce │ Ciphertext │
│ "vk3:" │ 24 bytes │ Encrypted master key │
└──────────┴─────────────┴─────────────────────────────┘
- Header: A magic identifier (
vk3:orvk2:) that tells VaultKeepR this is a valid backup. - Nonce: A unique 24-byte random value generated for each backup. Even if you write the same key twice, the ciphertext is completely different.
- Ciphertext: Your master password encrypted with XChaCha20-Poly1305. Without the decryption key, this is indistinguishable from random noise.
The Three-Factor Security Model
Here's the critical design decision: the NFC tag alone is completely useless. Decrypting the master key requires three independent factors:
| Factor | What It Is | Where It Lives |
|---|---|---|
| 1. Physical NFC tag | Nonce + ciphertext | In your pocket |
| 2. Device secret | 32-byte random key | Device Keychain (biometric-protected) |
| 3. PIN code | User-chosen digits | Your memory |
The encryption key is derived using HKDF-SHA256:
key = HKDF-SHA256(deviceSecret, salt = PIN, info = "vaultkeepr-nfc-v2")
Someone who finds your NFC tag gets nothing — they'd also need your specific device's secret AND your PIN. And the device secret itself is locked behind biometric authentication (Face ID / Touch ID).
How It Works — Step by Step
Writing a Backup (2 seconds)
Use the client's documented NFC flow on a test tag. Check what is written, which secret or PIN remains necessary, and whether restoration works on a second device. The ability to write an NFC payload does not establish that a hardware passkey is exportable.
Restoring on a New Device
- Install VaultKeepR on the new device.
- Tap the NFC tag — VaultKeepR reads the encrypted payload.
- Enter your PIN — VaultKeepR decrypts the master password.
- The recovered master password unlocks your vault (from local storage or IPFS).
The tag carries the encrypted master key; the tag, the device secret, and the PIN together give the key back on a configured device.
Smart Payload Compression
NFC tags have very limited storage (137 to 888 bytes). VaultKeepR uses clever tricks to fit within these constraints:
Hex Compression for Biometric Keys
When you use passwordless mode with Passkeys, your master key is a long hex string (64+ characters). VaultKeepR detects this and compresses it to raw bytes before encryption — cutting the payload size in half:
Hex string: "a1b2c3d4e5f6..." (64 chars) → 32 bytes
Text password: "MyP@ssw0rd" (10 chars) → 10 bytes
A 1-byte flag (h for hex, t for text) is prepended so VaultKeepR knows how to decode on restore.
Format Auto-Selection
| Format | Structure | Used When |
|---|---|---|
| v2 | vk2:{nonce}:{ciphertext} |
Short passwords (< ~53 chars) |
| v3 | vk3:{nonce+ciphertext} |
Longer keys (saves separator overhead) |
VaultKeepR automatically picks the most compact format based on your key length.
Tag Capacity Guide
| Tag Type | Storage | Fits |
|---|---|---|
| NTAG213 | 137 bytes | Most passwords and hex keys |
| NTAG215 | 504 bytes | All password types with margin |
| NTAG216 | 888 bytes | Maximum headroom |
VaultKeepR detects the tag capacity before writing and warns you if the payload won't fit.
Security Analysis
What if someone steals my NFC tag?
Confidentiality depends on the actual keys and secrets, not the cipher's nominal key length alone. Test restoration and protect the PIN and access material separately.
What if someone clones my NFC tag?
Same answer. A clone contains the same encrypted data. No device secret + PIN means no access.
Can someone modify the data on the tag?
XChaCha20-Poly1305 is an authenticated encryption scheme. If even a single bit is modified, decryption fails with a clear error. You get a rejection, not corrupted data.
What if I lose my phone AND my NFC tag?
This is where VaultKeepR's multi-path recovery shines. If you lose both:
The client encrypts vault snapshots before upload. Storage can involve IPFS gateways, pinning services, hosted APIs and S3-compatible backends. These services handle ciphertext, while timing, size, CIDs and on-chain activity may remain observable. IPFS content addressing does not guarantee persistence: retain an independent encrypted backup and test retrieval. The sync documentation and threat model describe those dependencies.
VaultKeepR Premium uses Shamir 3-of-5 recovery for the vault encryption key. The five configured channels are the device, remote storage, a trusted contact or QR handoff, a smart contract, and the API. Any three valid fragments can reconstruct the key; losing too many fragments or the recovery identifier can prevent recovery. See the current SDK defaults, channel distribution, and recovery guide. This recovers a vault key, not a hardware passkey or each seed phrase stored in the vault.
The NFC tag is one recovery path among several — not a single point of failure.
Passkey / Biometric NFC Backups
A PRF output is application key material, distinct from the passkey private key. Any NFC-backed backup of that material must be supported by the actual client and tested; it is not a universal property of passkeys.
PRF Key (hex) → Compress to bytes → Encrypt with device secret + PIN → Write to NFC
On restore, the hex key is decompressed and used to unlock the vault directly — no password prompt needed.
Choosing the Right NFC Tag
| Feature | NTAG215 (Recommended) | NTAG216 (Large Keys) |
|---|---|---|
| Storage | 504 bytes | 888 bytes |
| Price | Depends on model and vendor | Depends on model and vendor |
| Form Factor | Sticker, card, keychain | Sticker, card, keychain |
| Best For | Most users | Extra headroom |
You can buy NFC tags on Amazon, AliExpress, or any electronics supplier. Look for NTAG215 or NTAG216 specifically.
Pro tip: Buy a waterproof NFC keychain tag. Attach it to your physical keyring. Your recovery key goes everywhere your keys go.
Why This Matters
In a world of constant data breaches and account lockouts, physical key backup gives you sovereignty over your recovery:
- Offline: Works without internet
- Instant: Write and restore in under 3 seconds
- Portable: Fits on a keychain
- Three-factor: Tag alone is worthless without device + PIN
- Private: No cloud, no account, no recovery email
Your master key isn't sitting on someone else's server waiting to be exfiltrated. It's in your pocket, encrypted with keys that exist only on your device and in your memory.
This is what true self-custody looks like.
Ready to try it? Download VaultKeepR and tap your way to a secure backup.
