# Device-to-app sync for VAHA: architecture, and the integrity and security of the current build

- Version: v1.0, published 22 October 2026
- Written by: Ritesh Bonthalakoti
- Reviewed by: Bharat Meda
- Domains: Connectivity, Security
- Readiness: TRL 3, experimental proof of concept
- Tested on: VAHA's device server (Arduino UNO Q) and Android companion app, read as of 2026-08-17; the released v1.1.0 app builds inspected; the device server's code run on development computers for an access test, 10 timed downloads and 120 synthetic captures. Not yet tested on a handset
- Standards: ETSI EN 303 645 V2.1.1 as a reference baseline, not a conformity assessment; ISO 16290 for the readiness level; no accredited testing
- Full paper: [PDF, 21 pages, 1.5 MB](https://dharanova.com/whitepapers/vaha-device-to-app-sync-integrity-security.pdf)

## Summary

Describes the sync path from the VAHA device's FastAPI server to the companion app and checks the integrity and security of the current build against its design. Three known gaps: the app no longer compares the device's MD5 before deleting the device copy (HTTP 200 is the only check, since 2026-08-07); app and device share one default access token; all traffic is plain HTTP. Against four requirements taken from the product README, one is met, one partly met and two not met. Section 6.4 sketches how to close each gap (verify, record, then delete; per-device token and TLS pinned at Bluetooth LE pairing), and section 9 ends with a checklist for local-only sync. The README's four performance figures are kept in Appendix C as reported, with no recorded method, beside a first loopback timing that does not stand in for them. TRL 3; the path to TRL 4 is a restored, fail-closed MD5 check tested with at least 59 deliberately corrupted transfers, a per-device credential with TLS, and measured sync performance.

## Key findings

- **Integrity.** The app deletes the device copy after HTTP 200 without checking the MD5, and the released app contains this code. A damaged download becomes the only copy.
- **Access.** The app and the device share one default token, vaha-dev-2026. Run on a test machine, the server let a client holding it list, download and delete captures; with its check switched off, it let anyone.
- **Transport.** Plain HTTP. The released app allows it and the server does not accept TLS. Audio, transcripts and the token can be read by any device on the same network.
- **Readiness.** TRL 3. The README's performance figures have no recorded method. Next: restore the MD5 check and test it with deliberately corrupted transfers.

## Figures shown on the page

- Figure 1: One capture from device to handset, as the code runs it. Step 4 is the MD5 comparison the README describes; the app does not perform it. Sequence diagram between the VAHA device, an Arduino UNO Q running FastAPI on port 8080, and the companion app, on Android with SyncService and SQLite. The device holds a capture package: audio.wav, transcript.json, metadata.json and checksum.md5, an MD5 of the audio made on the device. The app's local store holds a captures table with each capture's sync state, a sync_queue table and WAV files in app storage. 1, GET /captures: the list of captures with transcript and audio_md5. 2, queue each new capture: a pending row in captures and an entry in sync_queue. 3, GET /captures/{id}: the WAV download, up to 5 tries, waiting 2, 4, 8 and 16 s. 4, compare MD5: the README's step, not in the code since 2026-08-07. 5, DELETE /captures/{id}, sent when the download returns HTTP 200; the device deletes the capture folder. 6, mark the capture synced: the device copy is gone and the handset copy is the only one. Every request is plain HTTP on the local network, carrying the shared default token as a bearer token.
- Figure 6: Where this work sits on the EU Horizon TRL scale. Technology readiness ladder from TRL 1 to TRL 9. TRL 1 to 3 are filled in; TRL 3, experimental proof of concept, is marked as this work. TRL 4, technology validated in lab, is marked as next.
- Figure 7: Path from this work to TRL 4, one row per requirement in priority order: its status today, the change to the build, the test that shows it is met, and the data the test leaves. Step 1: set the limits first, for integrity, capture loss, latency and throughput, written down before any test. Then one row per requirement. R2, verified before purge, not met: compare the file’s MD5 with audio_md5 before DELETE, failing closed and keeping the device copy; tested with at least 59 deliberately corrupted transfers, none accepted and every device copy kept; evidence corruption_test_log.csv. R4, protected in transit, not met: TLS between the app and the device server; a packet capture on the same Wi-Fi shows no audio, transcript or token readable; evidence packet_capture, before and after. R3, access limited to the paired app, partly met: a per-device credential from Bluetooth LE pairing, with the check always on in release builds; requests with the old default token, and from an unpaired client, are refused; evidence access_test_log.csv. R1, local-only sync, met: no change; the same packet capture shows sync traffic stays on the local network. Sync performance, not measured: log time and size for every sync; p50, p95 and p99 latency and throughput over several sessions, plus a Wi-Fi drop and the app closed mid-download; evidence sync_timing_log.csv and interruption_log.csv. TRL 4 when every row passes against the limits set in step 1. Then a test on the home Wi-Fi it will ship on, with a second device listening (TRL 5).

## Related reading

- [MQTT, CoAP and HTTP](https://dharanova.com/learn/iot-protocols.md): background on Learn
- [Security baselines and the law](https://dharanova.com/learn/iot-security-rules.md): background on Learn
- [Bluetooth LE, Wi-Fi and 802.15.4](https://dharanova.com/learn/short-range-radio.md): background on Learn
- [The one room a phone does not follow you into](https://dharanova.com/arduino-physical-ai-challenge-2026.md): an engineering note from our team
- [BLE application-layer authentication with ECDSA certificate chains on ESP32-C3](https://dharanova.com/whitepapers/ble-certificate-authentication.md): another whitepaper

This paper documents component-level work in the lab. It is not a product specification.