Scannen aan de clientzijde onderzoekt inhoud op het apparaat van de gebruiker, waar die al leesbaar kan zijn vóór verzending of na ontvangst. Daardoor kan een route voor openbaarmaking ontstaan buiten het versleutelde afleveringskanaal. Een APK-controlesom vergelijken bewijst niet dat een app geen scancode bevat. Het beantwoordt een beperktere vraag: of de geselecteerde bytes overeenkomen met een bepaalde hashwaarde.
Deze beweringen uit elkaar houden maakt zowel versleuteling als softwareverificatie nuttiger.
Waarom scannen op een apparaat de privacygrens verandert
Een app moet onversleutelde gegevens verwerken om een bericht te tonen of een foto voor verzending klaar te maken. Een scanfunctie kan op dat moment werken, zelfs als het daaropvolgende netwerkbericht end-to-end versleuteld is. Wat het apparaat verlaat, hangt af van het ontwerp van de scanner: die kan een overeenkomst melden, geselecteerde inhoud uploaden of andere afgeleide informatie versturen.
Het onderzoeksartikel Bugs in our Pockets onderzoekt risico’s zoals misbruik, foutpositieven en extra aanvalsoppervlak. Dat zijn redenen om de gegevensstromen en het bestuur van een voorgesteld scansysteem te onderzoeken. Ze tonen niet aan dat elke functie op het apparaat surveillance is, of dat een bepaalde wet een universele scanplicht heeft opgelegd.
Een lokale functie onder controle van de gebruiker is niet automatisch hetzelfde als verplichte rapportage. Vraag wie de analyse kiest, wat haar activeert, wie de regels kan bijwerken en welke gegevens het apparaat kunnen verlaten.
Vier verschillende vormen van softwarebewijs
| Controle | Wat deze kan aantonen | Wat deze op zichzelf niet kan aantonen |
|---|---|---|
| SHA-256-controlesom | Het bestand komt overeen met een vertrouwde referentiehash | Dat het referentieprogramma veilig is of overeenkomt met de broncode |
| APK-handtekeningverificatie | De pakkethandtekening wordt geverifieerd en identificeert een ondertekeningscertificaat | Dat de ondertekenaar betrouwbaar is of de code geen ongewenst gedrag bevat |
| Reproduceerbare build | Gespecificeerde broncode en buildinvoer kunnen de verwachte artefacten produceren | Dat de broncode vrij is van kwetsbaarheden of schadelijke logica |
| Onafhankelijke beoordeling en tests | Bevindingen over een vastgelegde versie en reikwijdte | Een blijvende garantie voor elke toekomstige update |
De apksigner-documentatie van Android legt pakketverificatie en certificaatrapportage uit. De definitie van Reproducible Builds legt uit waarom broncode, buildomgeving en instructies allemaal van belang zijn bij het reproduceren van een artefact.
Een broncodearchief en een ernaast weergegeven controlesom vormen op zichzelf geen resultaat van een reproduceerbare build. Evenzo blijft een geldige handtekening op een kwaadaardige release een geldige handtekening.
Een download controleren zonder te veel uit het resultaat af te leiden
Bepaal eerst de bedoelde release en verkrijg de APK en de verwachte hashwaarde via een betrouwbare distributieroute. Bereken de hashwaarde lokaal. Als die afwijkt, installeer het bestand dan niet zolang het verschil onverklaard is: een andere release, een onvolledige download of manipulatie kan elk tot een afwijking leiden.
Als de waarde overeenkomt, leg dan de release en het resultaat vast. U hebt bytegelijkheid ten opzichte van die referentie vastgesteld, niet de afwezigheid van scannen aan de clientzijde. Als dezelfde aanvaller de download en de getoonde controlesom kan vervangen, kan de vergelijking nog steeds slagen. Onafhankelijke referenties, continuïteit van de ondertekeningssleutel en transparantie over releases helpen verschillende onderdelen van dat vertrouwensprobleem aan te pakken.
Zoek voor een bewering over de overeenkomst tussen broncode en binaire bestanden naar gedocumenteerde buildinstructies en onafhankelijk gereproduceerde resultaten voor de daadwerkelijke release. Leid die eigenschap niet af uit de woorden ‘open source’.
Updates blijven belangrijk
Softwaredistributie kan worden aangevallen, maar beveiligingsupdates voor onbepaalde tijd vermijden is geen deugdelijke algemene verdediging. Updates verhelpen ook misbruikbare kwetsbaarheden. Gebruik een vertrouwd updatekanaal, bekijk relevante beveiligingsmeldingen en verifieer releasebewijs wanneer uw risico dat rechtvaardigt. Een oude versie met een bekende fout is niet veiliger alleen omdat de controlesom ooit overeenkwam.
Wat het Proof Lab van Livara aantoont
Het Proof Lab van Livara biedt een lokale vergelijking van APK-hashwaarden en cryptografische demonstraties in de browser. De pagina vermeldt dat deze niet de volledige LVR1/LGS1-ratchets uitvoert en geen protocolaudit vormt. Het dreigingsmodel legt ook de beperking uit wanneer een aanvaller zowel een bestand als de verwachte hashwaarde kan vervangen.
Deze controles zijn binnen hun reikwijdte nuttig. Ze bewijzen niet dat een telefoon waarop de app is geïnstalleerd vrij van malware is, dat Livara onafhankelijk reproduceerbare releases heeft of dat de toepassing geen niet-openbaar gemaakt gedrag kan bevatten. Lees de beveiligingsdocumentatie afzonderlijk voor de geclaimde grenzen van berichtbescherming.
De juiste vraag is niet of een badge ‘geverifieerd’ zegt. Het gaat erom welke bewering is getest, tegen welke vertrouwde referentie en voor welke exacte release.
