Security & encryption

Security you
don't have to trust us on.

ZZPass uses zero-knowledge, end-to-end encryption. Your data is encrypted on your device before it goes anywhere. We can't read it. Apple can't read it. Nobody can — except you.

  • AES-256-GCM
  • PBKDF2 · 650K
  • ECIES P-256
  • Apple CryptoKit
The four principles

How ZZPass
protects you.

Four cryptographic guarantees, applied at every layer of the system. The rest of this page is the technical detail behind each one.

01

Zero-Knowledge

We never see your passwords. All encryption happens on your device, with keys we never receive.

02

Encrypted at Rest

Every credential, note, and attachment is AES-256-GCM encrypted in your vault.

03

Encrypted in Transit

Data is encrypted before it reaches iCloud. CloudKit only ever sees ciphertext.

04

Encrypted in Sharing

Shared items use end-to-end ECIES encryption. Only invited members can decrypt.

Your master key

From your password to
your encryption key.

When you create your ZZPass account, your primary password is transformed into a 256-bit encryption key using an intentionally slow process that makes brute-force attacks impractical. This key encrypts and decrypts everything in your vault. It never leaves your device. We never see it.

KEY DERIVATION RFC 8018 · OWASP RECOMMENDED
AlgorithmPBKDF2-SHA256
Iterations650,000
Salt128-bit · SecRandomCopyBytes
Output256-bit symmetric key
StorageDevice Keychain only
ComparisonConstant-time SHA-256 hash

OWASP recommends at least 600,000 PBKDF2-SHA256 iterations. ZZPass uses 650,000.

FLOW · KEY DERIVATION ON-DEVICE
PRIMARY PASSWORD
••••••••••••
RANDOM SALT · 128b
a3f9 c7e1 …
01
PBKDF2-SHA256
650,000 rounds
SLOW BY DESIGN
02
DERIVED MASTER KEY
256-bit symmetric
DEVICE KEYCHAIN
03
AES-256-GCM
Encrypted vault
AT REST
Vault encryption

AES-256-GCM —
the standard governments use.

Every password, username, note, TOTP secret, and attachment in your vault is encrypted with AES-256-GCM before being stored. Both confidentiality and integrity — nobody can read it, nobody can tamper with it undetected.

DATA ENCRYPTION KEY
Passwords, usernames, websites, notes AES-256-GCM Master
Secure notes & custom fields AES-256-GCM Master
Device metadata AES-256-GCM Master
Shared credentials & notes AES-256-GCM Group
File attachments AES-256-GCM Master / Group
E2E private key AES-256-GCM Master
What's not encrypted
  • UUIDs
    Opaque identifiers — reveal nothing about content.
  • Timestamps
    Creation and modification dates only.
  • Relationship pointers
    Which vault, which group an item belongs to.

Metadata is necessary for iCloud sync to function. It reveals nothing about your actual credentials.

iCloud sync

Encrypted before it
leaves your device.

ZZPass uses Apple's CloudKit for sync — no proprietary servers. Sensitive data is encrypted at the application layer; CloudKit only stores and transports ciphertext.

YOUR DEVICE
Plaintext
Mercury · m.koen@hello.com
AES-256-GCM ENCRYPT
CIPHERTEXT
iCloud · CloudKit
a3f9c7e10b9d…d2e4f8a1c
TLS · APPLE DECRYPT
YOUR OTHER DEVICE
Plaintext
Mercury · m.koen@hello.com
NSPersistentCloudKitContainer. Apple's first-party sync — no proprietary infrastructure.
Application-layer encryption. Ciphertext is created before CloudKit ever receives it.
No ZZPass server. The sync path is device → iCloud → device. We are never in the middle.
Apple TLS overlay. Transport is protected end-to-end at the network layer too.
Offline-first. Edits made offline reconcile and sync the moment you reconnect.
Compromise-resistant. The decryption key exists only on your devices.

Trust model: Even if iCloud were compromised, your vault would remain encrypted. The decryption key exists only on your devices — never in transit, never in the cloud, never on our servers.

ECIES KEY EXCHANGE PER MEMBER
1
Group created
Random 256-bit group key generated
2
Member public keys fetched
From CloudKit · P-256 public
3
For each member · wrap
Forward-secret envelope
Ephemeral P-256 keypair generated
ECDH shared secret computed
HKDF-SHA256 derives wrapping key
Group key sealed with AES-256-GCM
Envelope = { ephemeral pub, sealed key }
4
Member unwraps
Private key + ephemeral → shared secret → group key
Device security

Layers of protection
on every device.

Encryption is foundational — but a vault is only as safe as the device unlocking it. ZZPass stacks five layers of defense before your data is ever decrypted.

LAYER 01

Biometric authentication

  • Face ID or Touch ID required to unlock the vault
  • Automatic revocation if biometric enrollment changes — a new face or fingerprint locks you out until the password is re-entered
  • Fallback to your primary password is always available
LAYER 02

Auto-lock

  • Vault locks automatically after a configurable period of inactivity
    • 30s
    • 1m · default
    • 5m
    • 10m
  • Locks immediately when the app is backgrounded
LAYER 03

Brute-force protection

  • Escalating lockout after failed password attempts
    • 5–7 → 30s
    • 8–9 → 2m
    • 10–11 → 5m
    • 12+ → 15m
  • Counter resets on successful authentication
LAYER 04

Clipboard security

  • Copied passwords and TOTP codes auto-clear after 60 seconds
  • Marked local-only — never crosses devices via Universal Clipboard
LAYER 05

Keychain storage

  • Master key hash stored in Apple Keychain with hardware-backed protection
  • Accessible only when the device is unlocked
    • kSecAttrAccessibleWhenUnlockedThisDeviceOnly
  • Protected by iOS / macOS Data Protection
Password change & recovery

Change your password
without losing a thing.

Re-keying the entire vault is a delicate operation. ZZPass's migration is atomic, fault-tolerant, and never leaves data unrecoverable — even if something goes wrong mid-flight.

RE-KEY MIGRATION ATOMIC
1
New password entered → new salt generated → new master key derived
2
Old master key backed up temporarily as a fallback
3
Every vault item decrypted with old key, re-encrypted with new key
4
After successful re-encryption, the old key backup is deleted

Safety net. If the process is interrupted (crash, power loss), ZZPass keeps the backup key so no data is ever lost. Items encrypted with either key decrypt transparently until the migration completes.

Secret key

Your account, on paper.

Z1-XXXX-XXXX-XXXX-XXXX

Your Secret Key is a human-readable encoding of your encryption salt. Combined with your primary password, it's everything you need to recover your account on a new device. Print it, store it safely, and you'll never be locked out.

RECOVERY MATERIAL YOU + ZZPASS = NEVER
FormatZ1-XXXX-XXXX-XXXX-XXXX
Encodes128-bit random salt
Pairs withYour primary password
Stored on ZZPass serversNever
Algorithm summary

The complete
cryptographic picture.

For technical evaluators — every algorithm, key size, and standard ZZPass relies on. No custom cryptography, no third-party libraries.

COMPONENT ALGORITHM KEY SIZE STANDARD
Key derivationPBKDF2-SHA256256-bitRFC 8018
Vault encryptionAES-256-GCM256-bitNIST SP 800-38D
Key agreementECDH P-256256-bitNIST FIPS 186-4
Key wrappingHKDF-SHA256 + AES-GCM256-bitRFC 5869
Passkey signingECDSA P-256 (ES256)256-bitFIPS 186-4
TOTPHMAC-SHA1/256/512VariableRFC 6238
Random generationSecRandomCopyBytesApple Security Framework
Crypto libraryApple CryptoKitNo third-party deps
Implementation note. ZZPass uses only Apple's CryptoKit and CommonCrypto frameworks. No custom cryptographic implementations, no third-party crypto libraries.
Zero knowledge means zero access

Things we cannot do —
by design.

We cannot read your passwords
We cannot decrypt your vault
We cannot reset your primary password
We cannot access your shared group contents
We cannot see your TOTP secrets or passkey private keys
We cannot view your notes, attachments, or custom data
We cannot provide your data to any third party
We don't have it. Nobody at ZZPass does.

This isn't a policy.
It's math.
Without your master key, your data is indistinguishable from random noise.

Threat model

What we
protect against.

Every security architecture has a boundary. Here's what ZZPass defends — and what remains your responsibility as the device owner.

Protected against
  • Brute-force password cracking 650K PBKDF2 iterations
  • Man-in-the-middle attacks AES-GCM auth + TLS
  • Unauthorized vault access AES-256-GCM, biometric + password
  • Biometric spoofing enrollment-change detection, auto-revocation
  • Timing attacks constant-time password comparison
  • Clipboard theft 60s auto-expiration, local-only flag
  • CloudKit compromise application-layer encryption before sync
  • Group key compromise forward secrecy via ephemeral keys
  • Removed-member access automatic key rotation
Your responsibility
  • Physical device security mitigated by auto-lock + biometrics
  • Primary password strength mitigated by PBKDF2 slow hashing
  • Emergency Kit storage physical document security
  • Social engineering awareness no architecture protects against you