Een browser kan sterke cryptografie uitvoeren; de code die eraan wordt geleverd moet nog steeds te vertrouwen zijn.
Een browser kan lokaal end-to-end-versleuteling uitvoeren, inclusief postkwantum-sleutelvaststelling, zonder een native berichtenapp te installeren. De moeilijke vraag is niet of de wiskunde in een tabblad kan draaien. Het gaat erom of de geleverde toepassing, de sleutelverwerking en het updatepad het vertrouwen verdienen dat het gesprek vereist.
Toegang via het web kan handig zijn wanneer installeren niet mogelijk is. Dat maakt de toepassing niet immuun voor censuur, gecompromitteerde hosting, kwaadaardige extensies of een gecompromitteerd apparaat.
De cryptografische bouwstenen van de browser
WebCrypto biedt laag-niveauhandelingen voor versleuteling, sleutelafleiding, ondertekening en sleutelbeheer. Gangbare implementaties leveren primitieven zoals AES-GCM en ECDH. Deze handelingen zijn bouwstenen, geen volledig geauthenticeerd berichtenprotocol.
Een webtoepassing kan een beoordeelde ML-KEM-implementatie in JavaScript of WebAssembly toevoegen wanneer de vereiste native API niet beschikbaar is. Browserondersteuning verandert. Ontwikkelaars moeten daarom de functionaliteit in de precieze doelversies testen in plaats van aan te nemen dat elke browser dezelfde algoritmen biedt.
Een conceptueel hybride proces ziet er zo uit:
- Genereer geschikte sleutels met cryptografisch veilige willekeur.
- Authenticeer het sleutelmateriaal van de gesprekspartner met het identiteitsmechanisme van het protocol.
- Verkrijg klassieke en postkwantumbijdragen aan het gedeelde geheim.
- Combineer deze volgens het vastgelegde sleutelafleidingsschema en de gesprekscontext.
- Gebruik afgeleide sleutels voor geauthenticeerde versleuteling, met correcte verwerking van nonces en toestand.
Dit is een verklarend overzicht, geen implementatierecept. FIPS 203 standaardiseert ML-KEM; de standaard certificeert geen specifieke browsertoepassing en definieert niet elke stap van een chatprotocol.
Levering via HTTPS maakt deel uit van het vertrouwensmodel
De server levert normaal gesproken de JavaScript en WebAssembly die leesbare tekst zullen verwerken. Een kwaadwillig gewijzigde toepassing kan een bericht vóór versleuteling of na ontsleuteling lezen, ook als de cryptografische bibliotheek deugdelijke algoritmen gebruikt.
HTTPS helpt de levering te authenticeren en te beschermen tegen inmenging op het netwerk. Het bewijst niet dat de beheerder van de oorsprong, diens uitrolsysteem of afhankelijkheden ongecompromitteerd zijn. Een gewone HTTPS-webpagina is niet automatisch een onafhankelijk ondertekend toepassingspakket.
De W3C-beveiligingsoverwegingen voor WebCrypto bespreken scriptinjectie en de noodzaak de integriteit van de toepassing te beschermen. Content Security Policy, zorgvuldig afhankelijkhedenbeheer en andere webbeveiligingsmaatregelen verminderen risico’s, maar geen daarvan verandert willekeurige scripts van dezelfde oorsprong in een onvertrouwde waarnemer die niet bij toepassingsgegevens kan komen.
WebAssembly deelt ook de beveiligingsgrens van de toepassing. De sandbox beperkt toegang tot de host via vastgelegde interfaces; dat maakt de aanroepende pagina niet betrouwbaar. C compileren naar Wasm maakt de brontaal niet geheugenveilig.
Sleutels bestaan niet noodzakelijk alleen in RAM
Een browsermessenger kan sleutels of versleutelde toestand blijvend opslaan, zodat de gebruiker naar dezelfde identiteit kan terugkeren. De toepassing kan ook apparaatkoppeling of versleuteld herstel bieden. Dit gedrag moet worden gedocumenteerd, niet simpelweg als afwezig worden verondersteld.
Nuttige vragen zijn:
- Welke sleutels worden blijvend opgeslagen, en in welke browseropslag?
- Wat gebeurt er wanneer sitegegevens worden gewist of een privésessie eindigt?
- Kan kwaadaardige code in de context van de toepassing een niet-exporteerbare sleutel nog steeds gebruiken?
- Kan een nieuw geleverde update toegang krijgen tot oude lokale toestand?
- Herstelt het herstelproces de identiteit, de berichtengeschiedenis of beide?
Een niet-exporteerbare WebCrypto-sleutel beperkt export via de API. Dat voorkomt op zichzelf niet dat vijandige toepassingscode toegestane handelingen aanvraagt of leesbare tekst verzamelt.
Webclients en native clients kennen verschillende afwegingen
| Aandachtspunt | Browserclient | Native client |
|---|---|---|
| Distributie | Oorsprong, hosting en webupdateproces | Appwinkel of pakketdistributie en ondertekeningsproces |
| Lokale persistentie | Browseropslag en profielgedrag | Appopslag van het besturingssysteem en levenscyclus van de toepassing |
| Blootstelling | Scripts van dezelfde oorsprong, extensies en browserkwetsbaarheden | Toepassingsafhankelijkheden en kwetsbaarheden in besturingssysteem of app |
| Beschikbaarheid | Bereikbaar domein en vereiste netwerkdiensten | Ook een geïnstalleerde app heeft de vereiste netwerkdiensten nodig |
Geen van beide kolommen wijst een winnaar aan zonder de implementatie te onderzoeken. Een webapp kan na verwijdering uit een appwinkel toegankelijk blijven, maar een geblokkeerd domein of ontbrekende netwerkroute kan toegang nog steeds verhinderen.
Meet prestaties in plaats van ze te beloven
ML-KEM-768 gebruikt volgens FIPS 203 een encapsulatiesleutel van 1.184 bytes en een cijfertekst van 1.088 bytes. Deze groottes helpen verklaren waarom protocollen KEM-updates kunnen inplannen in plaats van aan ieder kort bericht nieuw materiaal toe te voegen. Het zijn geen metingen van de bandbreedte of snelheid van een volledige toepassing.
Een bruikbare benchmark vermeldt de browser, het apparaat, de build, de opwarmmethode, de gemeten handeling en de verdeling van de gemeten tijden. Neem het opstarten van de pagina, laden van modules, geheugengebruik, minder krachtige apparaten en netwerkoverhead mee. Beweringen zoals ‘minder dan twee milliseconden op alle moderne telefoons’ vereisen gepubliceerde metingen; dit artikel levert die niet.
Wat dit betekent voor Livara
Livara’s beveiligingsoverzicht documenteert LVR1 en de grenzen van het herstelproces. Het Proof Lab demonstreert bepaalde lokale P-256-, HKDF- en AES-GCM-handelingen; de pagina plaatst de volledige LVR1/LGS1-compositie uitdrukkelijk buiten die testopstelling. Een geslaagde demonstratie bewijst daarom niet de veiligheid van alle geleverde webcode.
Gebruik vóór een gevoelig browsergesprek een authentieke, onderhouden client, bekijk het actuele dreigingsmodel, bescherm het browserprofiel en verifieer de gesprekspartner via het ondersteunde proces voor sleutelcontrole. Gemak en nuttige cryptografie kunnen samengaan, zolang de grens van weblevering onderdeel van de beoordeling blijft.
