Segurança

Criptografia de nível bancário para sua vida digital

Arquitetura Zero-Knowledge

O ByteGuard é construído sobre um modelo de segurança Zero-Knowledge. Nunca vemos, acessamos ou armazenamos suas chaves de criptografia.

• Senha mestra: Sua chave pessoal para desbloquear o app. Nunca transmitida, nunca armazenada remotamente.
• Chave secreta (Secret Key): Uma frase de recuperação de 12 palavras (BIP39) gerada ao criar seu cofre. Combinada com sua senha mestra para máxima segurança.
• Derivação de chaves local: Argon2id com custo de memória de 64 MB e 3 iterações deriva a chave mestra localmente. HKDF-SHA256 cria a hierarquia de chaves.
• Sem portas dos fundos: Se você perder tanto sua senha mestra quanto sua chave secreta, não podemos recuperar seus dados. Isso é por design.

Detalhes da criptografia

Uma hierarquia de chaves em cinco níveis, da sua senha mestra até o texto cifrado do campo, com isolamento explícito em cada camada.

• Master Key: Argon2id(senha mestra ‖ Secret Key, salt) derivada localmente. Parâmetros recomendados pela OWASP: 64 MB de memória × 3 iterações, suficientes pra derrotar força bruta em GPU. Nunca sai do dispositivo.
• Auth Hash: HKDF-SHA256(Master Key, info="vault-auth-v1"). Usada apenas pra verificação de senha. A comparação byte a byte em tempo constante derrota ataques de timing.
• KEK (Key Encryption Key): HKDF-SHA256(Master Key, info="vault-kek-v1"). Dedicada a desempacotar a Vault DEK; nunca toca diretamente nos dados do usuário.
• Vault DEK (do cofre todo): Uma chave aleatória de 256 bits. **A DEK em texto puro nunca sai da RAM do dispositivo**; a DEK encapsulada (texto cifrado AES-256-GCM sob a KEK) é armazenada junto com os metadados do cofre e sincroniza pelo CloudKit Private DB quando o iCloud está ativo — só o texto cifrado sai do dispositivo. Trocar a senha mestra exige apenas re-derivar a KEK e re-encapsular a DEK — o cofre inteiro nunca é re-criptografado.
• Item Key (por entrada): HKDF-SHA256(Vault DEK, info="type-{T}-item-{ID}-v1") derivada de tipo + ID da entrada. Cada registro usa uma chave independente — vazar uma não afeta as outras.
• Texto cifrado do campo: AES-256-GCM(Item Key, texto puro) criptografa os campos sensíveis por tipo: senhas de login, senhas secundárias, PINs, respostas de perguntas de segurança, campos secretos personalizados e números de cartão (PAN). Nomes de conta, usuários, URLs, datas de validade e tags ficam como metadados em texto puro pra busca e indexação. Um IV único por criptografia garante que textos puros idênticos resultem em textos cifrados diferentes.

Armazenamento de dados

Seus dados permanecem no seu dispositivo. A sincronização na nuvem é opcional e sempre criptografada.

• Local primeiro: Todos os dados são armazenados em um banco de dados local criptografado no seu dispositivo.
• Sincronização iCloud opcional: Quando ativada, os dados são criptografados no dispositivo antes de serem enviados ao seu container privado do iCloud via CloudKit.
• Proteção biométrica: Face ID e Touch ID via Secure Enclave. Dados biométricos são gerenciados pelo iOS, nunca acessados pelo app.

O que não podemos fazer

Nossa arquitetura Zero-Knowledge significa:

• Não podemos ver, acessar ou descriptografar seus dados armazenados
• Não podemos redefinir sua senha mestra
• Não podemos recuperar seu cofre sem sua chave secreta
• Não podemos compartilhar seus dados com ninguém — incluindo autoridades
• Não podemos inserir portas dos fundos na criptografia

Compatibilidade de segurança do dispositivo

O ByteGuard foi projetado para funcionar perfeitamente com os recursos de segurança integrados da Apple.

• Apple Lockdown Mode: Totalmente compatível com a proteção de segurança mais alta da Apple. Todos os recursos — incluindo AutoFill, sincronização do iCloud e widgets — funcionam normalmente quando o Modo de Bloqueio está ativado.
• Sem dependência de WebView: O ByteGuard não usa nenhum mecanismo de renderização web. Os dados do seu cofre nunca são processados pelo WebKit, eliminando toda uma classe de vetores de ataque baseados em navegador.
• Integração com Secure Enclave: A autenticação biométrica é gerenciada inteiramente pelo Secure Enclave do iOS. O ByteGuard nunca acessa ou armazena dados biométricos.

Device-Level Protection

The biometric quick-unlock boundary is maintained jointly by iOS Keychain and Secure Enclave. The application never holds any Face ID/Touch ID-derived key.

• iOS Keychain ACL: A copy of the Vault DEK is stored in Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly + kSecAccessControlBiometryCurrentSet. Unreadable when the device is locked or Face ID has not authenticated.
• Secure Enclave Takes Over: The Keychain entry is encrypted by a device key inside Secure Enclave. When the app calls SecItemCopyMatching, iOS triggers Face ID; on success SE decrypts and returns the plaintext DEK — the app never touches any SE key.
• Auto-Invalidation on Face ID Re-enrollment: biometryCurrentSet semantics: when the user removes/re-enrolls Face ID in system settings, iOS automatically deletes the Keychain entry. ByteGuard detects the invalidation at launch and forces Master Password re-entry.
• Strict Mode (No Fallback): If biometryCurrentSet is unavailable (simulators, no enrolled biometrics), the DEK cache simply fails — never falls back to a less-protected Keychain entry. Fallback would be weaker than not enabling Face ID at all and would violate user intent.
• Memory Zeroing (Vault DEK): On lock, suspension, or vault switch, the Vault DEK is overwritten three times (zero → random → zero) with a memory barrier defeating compiler optimization. Master Key / KEK are local variables inside the unlock function, released by Swift ARC (not explicitly zeroed). Argon2 internal buffers are zeroed by libsodium via sodium_memzero.

Baixar na App Store