Sovereign build and signing
Android-derived OS integration with founder-controlled release and Android Verified Boot keys. The bake path can be adapted to supplied COTS device trees without relying on foreign-held OS signing keys.
Sovereign privacy-secure mobile operating system
BharatDroid Vault is a working, Google-free Android-derived OS for commercial off-the-shelf hardware. It joins sovereign signing, enforced system integrity, identity and key mediation, sensor starvation, controlled app egress and lock-state radio policy into one inspectable mobile boundary.
What BharatDroid is
This is an operating-system control plane and build capability—not a launcher, a blocklist or a VPN skin. Each statement below is bounded by the fresh 3 October evidence set.
Android-derived OS integration with founder-controlled release and Android Verified Boot keys. The bake path can be adapted to supplied COTS device trees without relying on foreign-held OS signing keys.
The tested image contains no GMS, GSF or Play Services packages. App delivery remains an operator choice rather than a mandatory Google service dependency.
The measured handset reported Verified Boot green, dm-verity enforcing, SELinux enforcing, release-keys, read-only system partitions, no development overlay and no su binary.
Identity mediation, scoped identifiers, non-exportable key brokering, sensor starvation, foreground-only egress, fail-closed VPN and operator-selected WireGuard upstream are governed as one device policy.
Zero additional Wi-Fi or mobile IP bytes were measured over an 8h01m locked interval. Active app traffic entered tun0; ordinary probes received no physical markers or useful sensor data.
Published need → Vault control → market comparison → evidence
Public bulletins and capability documents establish the need. Alternative-platform descriptions are capability-specific, not universal rankings. BharatDroid claims come from the retained device evidence linked below.
MeitY described unauthorized collection and transmission of mobile data to servers outside India as a national-security concern.
Open public source ↗Vault applies default-deny app policy, masks or withholds device markers, dead-ends tested tracker DNS and admits application egress only through its controlled VPN boundary.
Stock mobile platforms and MDM offer permissions, vetting and VPN. GrapheneOS adds a network permission. Vault adds measured marker substitution and foreground-only tunnel admission under one operator policy.
E02–E05 · IMEI null; Wi-Fi identity masked; raw bypass and physical-underlay binding blocked; active flows observed through tun0.
Open evidence glossary ↗iDEX DISC 9 called for protection of service-personnel data and detection of malicious calls and IPs across smart devices.
Open public source ↗Vault combines COTS-oriented image integration, sovereign signing, policy-controlled applications, protected networking, local evidence collection and controlled signed updates.
BharOS also validates an indigenous COTS and private-app-store model. Knox is Samsung-specific; GrapheneOS officially supports a narrow device family. Vault is designed as an adaptation layer for supplied device trees.
E01, E07, E08 · Working Nothing Phone (1); release-signed immutable system; no GMS packages; 23/23 launcher apps completed the pass.
Open evidence glossary ↗NSA CSfC mobile guidance describes independently layered commercial components and nested tunnels for protected mobile access.
Open public source ↗Vault governs downstream application UIDs and exposes tun0 to apps; the operator selects the encrypted WireGuard upstream. Lockdown remains enabled and physical-underlay selection is denied.
Enterprise always-on VPN protects transit but does not normally combine identity, sensor and key mediation. CSfC is an evaluated reference architecture; BharatDroid does not claim CSfC certification.
E02, E03, E07 · VPN exit visible to probes; raw TCP/UDP and physical-network binding failed; lock retained tun0 without usable underlay.
Open evidence glossary ↗India's Ministry of Defence has recorded honey-trapping cases and issued advisories to service personnel.
Open public source ↗A newly installed app remains an ordinary UID. It receives masked or null identifiers, controlled foreground egress and no useful background sensor feed; screen lock cuts the tested underlays.
Training, advisories, allowlists and MDM can prevent or remove risky apps. Vault adds containment even when a permitted or deceptive app is already present.
E02–E06 · Temporary Dialer/SMS role elevation did not reveal telephony identifiers; foreground grants were revoked on close; sensors delivered no data.
Open evidence glossary ↗The U.S. Army reported that Strava heat maps could reveal bases and support targeting of individuals.
Open public source ↗Location returned null; motion and all enumerated sensor classes delivered zero samples; Wi-Fi scans returned no results; SSID, BSSID and MAC were withheld or masked.
Standard permission prompts depend on user choice. GrapheneOS adds sensor and network toggles. Vault's tested policy makes no useful sensor delivery the default for ordinary probes and ties radio cut-off to lock state.
E04–E06 · 38 sensor classes enumerated, zero registered or delivering; location null; role app still saw masked Wi-Fi identity.
Open evidence glossary ↗Apple Lockdown Mode illustrates the need to reduce functionality for users exposed to sophisticated mercenary spyware.
Open public source ↗Vault reduces post-compromise value by starving app-facing sensors, separating keys, denying physical-network selection and enforcing a Google-free, signed system boundary.
Apple Lockdown Mode and GrapheneOS provide substantial exploit-surface reduction. Vault does not claim exploit immunity; its distinct focus is sovereign policy mediation across identity, network, sensors and keys.
E01, E04–E07 · No useful sensor or media output; non-exportable key; cross-UID decrypt rejected; direct network bypass blocked.
Open evidence glossary ↗Conventional mobile platforms preserve connectivity for notifications and services, leaving privacy policy dependent on application behavior.
Open public source ↗Lock transition disables tested Wi-Fi, Bluetooth and mobile-data settings while VPN lockdown remains active. Without an underlay, scheduled WireGuard retries fail locally rather than bypassing Vault.
Airplane mode is manual and coarse; MDM can enforce settings. Vault makes the screen-lock transition part of the OS privacy policy and measures the result on the prototype.
E02, E09 · Wi-Fi off by the sampled 648 ms point; Bluetooth/mobile data off; zero measured Wi-Fi or mobile IP-byte increase across 8h01m.
Open evidence glossary ↗Government product assurance requires inspectable security claims and later independent evaluation under schemes such as STQC IC3S/Common Criteria.
Open public source ↗Vault exposes a mediated keystore path, produces non-exportable keys and rejects cross-UID decryption. Hardware-attestation requests from the ordinary probe were refused.
Knox Vault offers mature dedicated hardware-backed assurance. Vault's differentiator is operator-owned brokering policy across adapted COTS builds; hardware assurance still depends on the selected device and certification.
E01, E04 · Standard Keystore2 hidden from ordinary app; Vault service visible; encoded key null; cross-UID decrypt rejected; Verified Boot and enforcement active.
Open evidence glossary ↗Working handset
This short composite uses boot-animation frames and live locked and unlocked captures. It demonstrates the installed interface; the security findings come from the separate retained probe evidence.
Replacement-production economics
The ₹12.30 crore model is an illustrative 24-month engineering replacement cost—not a valuation, funding commitment or fleet manufacturing budget. It excludes handset bill of materials, fleet volume and classified-network accreditation.
Market outlook
iDEX documents an Indian service-device requirement; NSA CSfC demonstrates a global government pattern of layered, evaluated commercial components. BharatDroid targets the engineering layer below fleet operations: device OS, policy, sovereign signing and evidence.
Port and qualify the signed Vault image, vendor interfaces and policy for each approved COTS model.
Per-device enrolment, fleet policy, signed OTA, rollback, evidence capture and annual security maintenance.
Threat modelling, test artefacts, STQC/Common Criteria preparation, red-team closure and controlled pilot support.
License the OS policy, bake system and update authority into approved domestic supply and managed-service programmes.
No revenue, customer-count or procurement-volume claim is made. Market entry depends on independent security review, target-device supply, certification and a sponsored field pilot.
Engineering and certification roadmap
These are conditional gates, not a claim of present military certification or committed procurement dates.
Sovereign-signed image on COTS hardware with retained app, network, sensor, key, lock and idle evidence.
Unify source, signed OTA, both slots, recovery and rollback; repeat the build and evidence chain on the reference model.
External source review, red-team tests, STQC/Common Criteria pre-assessment and device-specific boot-chain reconciliation.
Adapt to approved COTS models, qualify supply, define operational acceptance tests and maintain signed security updates.
Move to applicable government certification, fleet provisioning, support SLAs and OEM, DPSU or integrator licensing.
Evidence glossary
The brief maps nine retained evidence groups: verified system posture, lock transition, app-wise VPN deltas, ordinary probes, temporary role probes, destructive microphone read, post-test cleanup, Google-package inventory and the exact 8h01m idle window.
Read the complete investor evidence brief ↗Investor diligence
Review the retained evidence, witness the handset, then diligence the independent validation, certification and multi-model supply programme.
Request an evidence-led briefing ↗