De nuttige beveiligingsvraag is niet of versleuteling krachtig klinkt, maar wat ze beschermt, wie de sleutels heeft en welk bewijs de claim ondersteunt.
‘Versleuteling van militaire kwaliteit’ geeft onvoldoende informatie om een berichtenapp te beoordelen. De uitdrukking vertelt niet wie de sleutels heeft, welke gesprekken beschermd zijn, of back-ups leesbare tekst blootstellen of wat er gebeurt wanneer een apparaat wordt gecompromitteerd.
De nuttige reactie is niet om versleuteling af te wijzen. Het gaat erom een indrukwekkend etiket te vervangen door concrete claims die je kunt controleren.
AES-256 is een algoritmekeuze, geen volledig beveiligingsmodel
AES is een openbare standaard, geen geheime militaire technologie. FIPS 197 van NIST specificeert AES-128, AES-192 en AES-256; het achtervoegsel geeft de sleutellengte aan. De standaard is in 2023 redactioneel bijgewerkt, zonder het algoritme te veranderen.
Een sterk versleutelingsalgoritme kan nog steeds worden gebruikt in een systeem waarin de dienst toegang heeft tot leesbare tekst. Vraag wie kan ontsleutelen, niet alleen hoe lang de sleutel is. Vraag ook hoe sleutels worden aangemaakt en opgeslagen, hoe identiteiten worden geauthenticeerd en bij welke foutomstandigheden de toepassing stopt in plaats van onveilig verder te gaan.
Wanneer een leverancier AES-GCM noemt, is dat specifieker dan alleen AES: GCM combineert versleuteling met authenticatie. Correcte omgang met nonces, controle van authenticatietags en andere implementatievereisten blijven belangrijk. De GCM-specificatie van NIST is de technische referentie; een logo bewijst niet dat een app deze correct implementeert.
Vier verschillende claims die marketing vaak samenvoegt
| Claim | Wat deze betreft | Wat deze niet aantoont |
|---|---|---|
| Transportversleuteling | Bescherming over een verbinding, bijvoorbeeld van app naar server | Dat de server de inhoud niet kan lezen |
| Versleuteling van opgeslagen gegevens | Bescherming van opgeslagen gegevens binnen een bepaald sleutel- en toegangsmodel | Dat de beheerder geen ontsleutelingssleutel heeft |
| End-to-end-versleuteling | Bescherming van inhoud tussen aangewezen eindpunten | De veiligheid van een gecompromitteerd eindpunt of de eerlijkheid van een ontvanger |
| Postkwantum-sleuteluitwisseling | Weerstand tegen gespecificeerde kwantumdreigingen bij het tot stand brengen van sleutels | Een volledige audit van de app, anonimiteit of gegarandeerde toekomstige veiligheid |
Transportversleuteling betekent niet dat elke database van de aanbieder onbeschermde leesbare tekst opslaat. Een dienst kan opgeslagen gegevens ook versleutelen. Het relevante onderscheid is of de aanbieder de sleutels beheert of op een andere manier toegang heeft tot leesbare inhoud. Wees precies in plaats van de ene slogan door de andere te vervangen.
Voor een bredere introductie kun je lezen wat end-to-end-versleuteling beschermt.
‘Gebruikt een NIST-standaard’ is niet hetzelfde als ‘FIPS-gevalideerd’
FIPS 203 definieert ML-KEM, een mechanisme voor sleutelinkapseling. Een berichtenapp kan aangeven dat ze dat algoritme gebruikt zonder dat de hele toepassing is gecertificeerd of onafhankelijk is beoordeeld. Standaarden, algoritmetests, validatie van cryptografische modules en productbeveiligingsaudits zijn verschillende soorten bewijs.
Het Cryptographic Module Validation Program van NIST maakt duidelijk dat het implementeren van goedgekeurde functies onvoldoende is om FIPS 140-modulevalidatie aan te tonen. Als een product met validatie adverteert, vraag dan om het certificaat, de exacte module en versie, de gebruiksomgeving en de goedgekeurde configuratie. Bepaal vervolgens welk deel van het product dat certificaat daadwerkelijk dekt.
Daarom moet ‘256-bits beveiliging’ ook niet worden gebruikt als algemene score voor een volledige berichtenapp. De combinatie van protocollen, het sleutelbeheer en de implementatie kunnen verschillende grenzen opleggen.
Wachtwoordauthenticatie is geen berichtversleuteling
Een aanmeldmechanisme bepaalt of een gebruiker toegang mag krijgen tot een account. E2EE bepaalt wie de beschermde inhoud van berichten kan lezen. Geen van beide levert automatisch de eigenschappen van de andere.
SRP is bijvoorbeeld ontworpen om te authenticeren zonder het wachtwoord zelf te verzenden. Dat betekent niet dat een gestolen authenticatiedatabase onschadelijk is. De bespreking van SRP-beveiliging in RFC 5054 legt uit dat een gestolen verifier aanvallen door wachtwoorden te raden en andere risico’s mogelijk maakt. Vermijd de conclusie: ‘Er zijn geen wachtwoorden om te stelen, dus een serverinbraak kan geen gevolgen hebben.’
In de praktijk kunnen lezers het beste vragen naar accountherstel, actieve sessies en het verband tussen accounttoegang en versleutelingssleutels. Een antwoord dat alleen ‘zero knowledge’ herhaalt, laat de belangrijke vragen onbeantwoord.
Vijf vragen voor de beveiligingspagina van een berichtenapp
- Welke onderdelen zijn gedekt? Rechtstreekse chats, groepen, bestanden, oproepen, openbare berichten en back-ups kunnen verschillende grenzen hebben.
- Wie heeft bruikbare sleutels? Neem herstelsleutels, gekoppelde apparaten en verwerkingsmodi op de server mee.
- Hoe wordt het andere eindpunt geauthenticeerd? Zoek naar sleutelverificatie, betekenisvolle waarschuwingen bij wijzigingen en een gedocumenteerd vertrouwensmodel.
- Welk bewijs bestaat er? Specificaties, reproduceerbare builds, testvectoren en onafhankelijke audits beantwoorden verschillende vragen. Vraag bij elk naar de versie en de reikwijdte.
- Wat blijft zichtbaar of kwetsbaar? Metadata, gecompromitteerde apparaten, gekopieerde berichten en openbare inhoud mogen niet uit de uitleg verdwijnen.
Pas dezelfde vragen toe op Livara. De beveiligingsdocumentatie noemt LVR1 en LGS1 en publiceert operationele grenzen. Behandel die als productclaims die je moet beoordelen, niet als onafhankelijke certificering. Het Proof Lab biedt beperkte demonstraties en controles van artefacten, geen bewijs dat elke functie of release veilig is.
Hoe lees je een onafhankelijke audit?
Controleer de datum, de auditor, de coderevisie, de opgenomen platforms en de uitgesloten componenten. Lees de bevindingen en de status van oplossingen, niet alleen het samenvattende keurmerk. Een audit van een cryptografische bibliotheek dekt niet automatisch accountherstel, de webapp, meldingen of operationele beveiliging.
Het ontbreken van een audit is een leemte in de onderbouwing, geen bewijs van een specifieke kwetsbaarheid. Andersom is een audit geen levenslange garantie. Een nuttige vergelijking legt het bewijs en de beperkingen vast in plaats van één universele ‘veiligste’ winnaar uit te roepen.
Veelgestelde vragen
Is ‘militaire kwaliteit’ altijd een andere naam voor AES-256?
Nee. Leid uit de uitdrukking geen specifiek algoritme of certificaat af. Vraag de leverancier precies te omschrijven wat ermee wordt bedoeld.
Houdt sterkere versleuteling screenshots of malware tegen?
Ze voorkomt niet dat een ontvanger inhoud kopieert of dat een gecompromitteerd apparaat gegevens blootstelt waartoe het toegang heeft. Dat zijn andere dreigingen.
Wat is een beter teken dan een beveiligingsslogan?
Een duidelijke reikwijdte, een benoemd protocol, expliciete beperkingen en controleerbaar bewijs voor de geleverde implementatie. De uitleg moet je helpen beslissen wat je kunt vertrouwen en wat nog moet worden gecontroleerd.
