This document outlines the security architecture, data-protection posture, and vulnerability reporting procedures for the Android Dialer application.

The application is built on a local-first, privacy-by-design architecture. All database records, call history, and backup structures are secured directly on the physical device using hardware-backed cryptographic modules and standard authenticated encryption protocols.

The app employs nested cryptographic controls to ensure that even if the physical device is lost, stolen, or compromised (e.g., via root access), the user's sensitive call logs and contact databases remain fully secure.

• Engine: net.sqlcipher.database community edition.
• Algorithm: Full-database transparent AES-256 encryption.
• Key Generation: A cryptographically secure 256-bit key is generated dynamically on first boot using java.security.SecureRandom.
• Key Storage: The generated database passphrase is never stored in plain text. It is encrypted via AES/GCM/NoPadding and stored in the application's private SharedPreferences.
• Key Protection (Android Keystore): The encryption key for the SharedPreferences is managed using the hardware-backed Android Keystore System under the master alias DialerDbMasterKey. This ensures that key material is isolated from the application sandbox and cannot be extracted from the device memory.

Backups generated by the application are fully encrypted prior to being exported, ensuring secure storage in local directories or external cloud drives.

• Key Derivation (PBKDF2): User passwords are converted to a 256-bit AES key using PBKDF2 with HmacSHA256 (PBKDF2WithHmacSHA256).
• Work Factor: A configuration of 10,000 iterations is applied to thwart offline brute-force attempts.
• Salt Generation: A unique 16-byte random salt is generated using SecureRandom for every backup operation, preventing rainbow table attacks.
• Payload Encryption (AES-GCM): The backup payload is encrypted using AES in Galois/Counter Mode (AES/GCM/NoPadding).
• Initialization Vector: A unique, non-repeating 12-byte secure random IV is generated for every session.
• Integrity Validation: AES-GCM provides authenticated encryption with associated data (AEAD). Any tampering, truncation, or modification of the backup file will result in a validation failure during restoration, blocking malicious payload injection.

The application is designed with a strict zero-trust posture toward external servers:

• Offline First: There are no integrated cloud services, telemetry trackers, or external analytics SDKs.
• Local Isolation: All speed dials, call statistics, contact indexes, and custom settings reside purely within the SQLite database encrypted by SQLCipher.
• Permission Boundaries: The application only requests standard Android Permissions (READ_CONTACTS, WRITE_CONTACTS, CALL_PHONE, READ_CALL_LOG, WRITE_CALL_LOG, VIBRATE, MODIFY_AUDIO_SETTINGS). No background network permissions are requested or used, making remote exfiltration impossible.

We take the security of this local utility very seriously. If you identify a security vulnerability, please report it through the proper channels instead of filing a public issue.

Please submit vulnerability details to movstore.online@gmail.com.

When reporting, please include:

1. A detailed description of the vulnerability.
2. Steps or a proof-of-concept (PoC) to reproduce the issue.
3. The potential impact (e.g., local sandbox escape, memory leaks, cryptographic flaws).

• Triage: Within 48 hours of receipt.
• Remediation Plan: Within 7 days.
• Release/Patch: Depending on severity, we aim to deploy a fix within 14–30 days.

• Dependency Upkeep: Third-party cryptographic libraries (SQLCipher, AndroidX Security components) are updated regularly to patch platform-specific native exploits.
• Vulnerability Patching: Confirmed security flaws will be updated in the main development branch. Users are encouraged to always run the latest compiled version of the application.