SHARE THE PERSPECTIVE
Een controlesom koppelt bytes aan een referentie. Een handtekening koppelt integriteit aan een sleutel. Geen van beide bewijst op zichzelf dat de software veilig is.

Voordat je een Android-APK installeert, moet je drie controles uit elkaar houden: Komt dit bestand overeen met de verwachte release? Is het ondertekend met de verwachte sleutel? Kunnen onafhankelijke bouwers het reproduceren uit de opgegeven broncode? Een SHA-256-controlesom, een APK-handtekening en een reproduceerbare build beantwoorden die vragen elk op een andere manier.

Geen van deze controles geeft op zichzelf uitsluitsel over malware. Een correct ondertekend, reproduceerbaar programma kan nog steeds een beveiligingsfout of opzettelijk schadelijk gedrag bevatten.

Wat elke verificatiemethode aantoont

Controle Bruikbaar resultaat Belangrijke beperking
SHA-256-hash van het bestand Je bytes komen overeen met een specifieke, vertrouwde hash Een aanvaller die zowel het bestand als de hash vervangt, kan deze vergelijking omzeilen
Verificatie van de APK-handtekening De handtekening van het pakket is geldig voor het bijbehorende ondertekeningscertificaat Je moet vaststellen welke ondertekeningssleutel wordt verwacht; geldigheid alleen bewijst niet de identiteit van de uitgever
Vergelijking van reproduceerbare builds Het opgegeven artefact kan opnieuw worden gemaakt uit gedocumenteerde invoer Overeenstemming tussen broncode en binair bestand bewijst niet dat de broncode veilig is
Beveiligingsbeoordeling Specifieke ontwerp- of implementatieproblemen zijn beoordeeld De reikwijdte, versie, bevindingen en onopgeloste problemen zijn van belang

Android vereist dat APK's worden ondertekend voor installatie en updates. Met Play App Signing kan Google de app-ondertekeningssleutel beheren en uit een app-bundel APK's voor distributie genereren. Dit zijn gedocumenteerde afspraken over vertrouwen, geen bewijs dat willekeurige tussenpartijen een pakket ongemerkt kunnen wijzigen met behoud van de geldige handtekening. Zie de Android-handleiding voor app-ondertekening.

Stap 1: identificeer het exacte artefact

Noteer de appversie, het releasekanaal, de bestandsnaam en de bedoelde platformvariant. Gebruik de officiële distributiepagina van de uitgever, niet een controlesom die is gekopieerd uit hetzelfde ongevraagde bericht waarmee je de APK ontving.

Een APK die rechtstreeks bij een uitgever is gedownload, kan verschillen van een APK die een appwinkel voor een bepaald apparaat genereert. Verschillende versies, architecturen, verpakkingsvormen of ondertekeningsafspraken kunnen terecht verschillende bestandshashes opleveren. Vergelijk gelijksoortige artefacten voordat je een afwijking als bewijs van manipulatie beschouwt.

De praktische vraag is: Waar komt de verwachte waarde vandaan, en waarom vertrouw ik die bron? Een hash offline berekenen lost het vertrouwensprobleem van een online verkregen referentiehash niet op.

Stap 2: bereken SHA-256 lokaal

Vervang messenger.apk door de naam van je gedownloade bestand. Deze voorbeelden lezen het bestand; ze installeren het niet.

Linux:

sha256sum messenger.apk

macOS:

shasum -a 256 messenger.apk

Windows-opdrachtprompt:

certutil -hashfile messenger.apk SHA256

Vergelijk de volledige hash en negeer alleen spaties in de weergave en verschillen tussen hoofdletters en kleine letters. Vergelijk niet alleen de eerste of laatste paar tekens. Bewaar de verwachte hash samen met de release- en versiegegevens, zodat je de vergelijking kunt herhalen.

Als de waarden verschillen, stop dan vóór de installatie. Controleer het artefact en de versie, download zo nodig opnieuw van de vertrouwde bron en vraag de uitgever om uitleg bij een onverklaarde afwijking. Pas de verwachte controlesom niet aan om die te laten overeenkomen met het bestand dat je toevallig hebt ontvangen.

Stap 3: controleer de APK-handtekening

Voor gebruikers met Android SDK Build Tools beschrijft Googles documentatie over apksigner de verificatie van handtekeningen en de weergave van certificaatgegevens:

apksigner verify --verbose --print-certs messenger.apk

De verificatie moet slagen voor de platforms die de APK ondersteunt. Vergelijk de gegevens van het ondertekeningscertificaat met vertrouwde releasegegevens of met de door de uitgever gedocumenteerde opvolging van ondertekeningssleutels. Een handtekening met een onbekende sleutel wordt niet betrouwbaar doordat er ‘geverifieerd’ bij staat. Ook een legitieme vervanging van een ondertekeningssleutel vereist bewijs, niet alleen een instructie om een afwijking te negeren.

De SHA-256-hash van het APK-bestand en de SHA-256-vingerafdruk van het ondertekeningscertificaat zijn verschillende waarden. Vergelijk ze niet met elkaar.

Stap 4: zoek naar bewijs voor reproduceerbare builds

Een claim over een reproduceerbare build vereist een vastgelegde broncoderevisie, bouwomgeving, instructies en doelartefact. Onafhankelijke partijen moeten dat artefact opnieuw kunnen maken en het resultaat kunnen vergelijken. De definitie van het Reproducible Builds-project maakt deze invoergegevens onderdeel van de claim.

Bij een berichtenapp omvat nuttig bewijsmateriaal voor een release een broncodetag, vastgezette versies van afhankelijkheden en de toolchain, bouwinstructies en onafhankelijke vergelijkingsresultaten. Vraag wat er precies is vergeleken: een niet-ondertekend artefact, een ondertekende APK of geselecteerde onderdelen van het pakket. Leid reproduceerbaarheid niet alleen af uit het feit dat broncode en een hash van de download zijn gepubliceerd.

Reproduceerbaarheid versterkt het verband tussen beoordeelde broncode en verspreide code. Ze maakt van een niet-beoordeelde implementatie geen veilig protocol en bewijst niet dat een telefoon die in gebruik is, vrij is van compromittering.

Welke rol Livara's Proof Lab speelt

Livara's Proof Lab biedt de mogelijkheid om lokaal een APK-hash te berekenen en die te vergelijken met de gepubliceerde hash. De cryptografische demonstraties hebben een beperktere reikwijdte dan een audit van het volledige berichtenprotocol. Gebruik de hashcontrole voor het aangegeven doel, samen met de verwachte release- en ondertekeningsgegevens; beschouw haar niet als onafhankelijk bewijs van reproduceerbare builds of de afwezigheid van achterdeuren.

Het dreigingsmodel benoemt expliciet de beperking wanneer zowel een APK als de weergegeven hash kan worden vervangen. Daarom is de herkomst van je referentiewaarde net zo belangrijk als het correct uitvoeren van de berekening.

Veelgestelde vragen

Bewijst een overeenkomende controlesom dat een APK veilig is?

Nee. Ze toont overeenstemming met de referentiehash aan, uitgaande van een betrouwbare referentie en de beveiligingseigenschappen van de hashfunctie. Ze beoordeelt het gedrag van het programma niet.

Is verificatie van de handtekening overbodig als de controlesom overeenkomt?

Nee. De controles leveren verschillend bewijsmateriaal op. Een handtekening koppelt de integriteit van het pakket aan een sleutel; een bestandshash identificeert een specifieke reeks bytes.

Moet een download uit een appwinkel overeenkomen met de APK-hash op de website?

Alleen als het om hetzelfde artefact hoort te gaan. Controleer eerst het releasekanaal, de versie en de verpakkingsvorm. Een onverklaarde afwijking verdient onderzoek, geen automatische beschuldiging en ook geen automatische goedkeuring.

Kunnen deze controles spyware ontdekken die al op mijn telefoon staat?

Nee. Ze beoordelen een installatieartefact, niet elk onderdeel van de huidige uitvoeringsomgeving van het apparaat.

Verifieer je build in Proof Lab
CONTINUE THE THREADAndroid & device security ↗
YOU’VE REACHED THE ENDBack to the reading room ↗