Join the early list

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

· Ritesh Bonthalakoti

  • Connectivity
  • Security
  • TRL 3
Read the paper Download

PDF, 21 pages, 1.5 MB · v1.0

The paper's cover: Device-to-app sync for VAHA: architecture, and the integrity and security of the current build

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.

Inside the paper

3 of the paper's 7 figures. Open any of them full size to zoom in.

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. ONE CAPTURE, FROM DEVICE TO HANDSET VAHA device Arduino UNO Q, FastAPI on port 8080 Companion app Android, SyncService and SQLite Capture package audio.wav, transcript.json, metadata.json, checksum.md5 (MD5 of the audio, made on device) Local store captures table (sync state) sync_queue table WAV files in app storage 1 GET /captures List of captures with transcript and audio_md5 2 Queue each new capture pending row in captures, entry in sync_queue 3 GET /captures/{id} WAV download; up to 5 tries, waits 2, 4, 8, 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 6 Mark capture synced Device copy is gone; the handset copy is the only one Serves the list and the audio; checks the bearer token on each request Deletes the capture folder on request SyncService drives every step Every request: plain HTTP on the local network, Authorization: Bearer <shared default token>
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.
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. TECHNOLOGY READINESS: WHERE THIS WORK SITS TRL 1 Basic principles observed TRL 2 Technology concept formulated TRL 3 Experimental proof of concept TRL 4 Technology validated in lab TRL 5 Validated in relevant environment TRL 6 Demonstrated in relevant environment TRL 7 Prototype in operational environment TRL 8 System complete and qualified TRL 9 Proven in operational environment This work Next
Figure 6 Where this work sits on the EU Horizon TRL scale.
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). PATH FROM THIS WORK TO TRL 4 1 Set the limits first: integrity, capture loss, latency and throughput, written down before any test REQUIREMENT, TODAY CHANGE TO THE BUILD TEST THAT PROVES IT EVIDENCE IN DATA/RAW R2 Verified before purge NOT MET Compare the file's MD5 with audio_md5 before DELETE; fail closed and keep the device copy At least 59 deliberately corrupted transfers: none accepted, every device copy kept corruption_test_log.csv R4 Protected in transit NOT MET TLS between the app and the device server Packet capture on the same Wi-Fi: no audio, transcript or token readable packet_capture/ (before and after) R3 Access limited to the paired app PARTLY MET Per-device credential from Bluetooth LE pairing; check always on in release builds Requests with the old default token, and from an unpaired client, are refused access_test_log.csv R1 Local-only sync MET No change The same packet capture shows sync traffic stays on the local network packet_capture/ — Sync performance NOT MEASURED Log time and size for every sync p50, p95, p99 latency and throughput over several sessions; Wi-Fi drop and app close mid-download sync_timing_log.csv interruption_log.csv TRL 4: every row passes against the limits set in step 1 Then: test on the home Wi-Fi it will ship on, with a second device listening (TRL 5)
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.

About this paper

Version
v1.0, published 22 October 2026
Written by
Ritesh Bonthalakoti
Reviewed by
Bharat Meda
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
The paper
21 pages, 1.5 MB, PDF

The full paper has the method, every table, the defects found along the way and what is still needed for the next readiness level.

Read the paper

Related reading