Security Policy

Supported Versions

Version	Supported
Latest release on main	✅
Older releases	❌

Reporting a Vulnerability

We appreciate responsible security reports. If you discover an exploitable vulnerability, please report it privately before disclosing it publicly.

How to Report

1. Do not create a public GitHub issue for security vulnerabilities
2. Send an email to the maintainers or use GitHub's private vulnerability reporting feature
3. Include a description, reproduction steps, potential impact, and suggested fix if available

What to Expect

• We will acknowledge your report within 48 hours
• We will provide an initial response within 7 days
• We will keep you informed of our progress
• We request that you allow us reasonable time to fix the issue before public disclosure

Security Model

Open Babyphone is designed for local-network use in a trusted home environment. The supported product model is same Wi-Fi or same LAN. Advanced users may connect across a trusted VPN by entering the child device address manually.

The app does not require user accounts or project-operated servers for normal operation. Internet-based remote monitoring and hosted relay infrastructure are outside the current product scope.

Current security-relevant behavior: - An 8-character pairing code is generated by default, and valid codes require 8–64 alphanumeric characters - A valid pairing code and mutual challenge-response authentication are required; the pairing code itself is not sent over the connection - Audio frames and heartbeats use ChaCha20-Poly1305 authenticated encryption - The child pairing code stays in app-private preferences. On a parent, trusted-child credentials are stored separately from profile metadata and wrapped with an Android Keystore AES-GCM key; transient first-pair credentials remain only in bounded process memory until authentication succeeds - Trusted profiles and credentials are excluded from Android cloud backup and device transfer in both current and legacy backup rules - Listen notification actions target a non-exported internal activity. The app exposes no listen URI or deep link that another app can use to start a stored- credential connection - OBP4 protocol and capability validation reject incompatible clients cleanly - Key derivation uses Argon2id via Bouncy Castle with a per-installation random salt - Separate authentication and stream keys are derived from the Argon2id result - The salt is generated once per child installation, persisted locally, and sent in clear text in the handshake; it is not secret - The salt ensures identical pairing codes on different installations derive different keys, preventing precomputation attacks across installations - The protocol does not provide forward secrecy: anyone who later learns the pairing code and has captured a session can decrypt that recorded session

For design discussions or hardening ideas, please open a normal issue unless there is an exploitable vulnerability that needs private handling.

Security Fixes

Security patches will be released as soon as possible. Depending on severity, we may: - Release an immediate patch version - Coordinate with F-Droid for rapid inclusion - Publish a security advisory on GitHub

Thank you for helping keep Open Babyphone secure.