De omvang van de blootstelling hangt af van het sleuteltype en hoelang de aanvaller toegang heeft; een ratchet garandeert niet dat slechts één bericht gevaar loopt.
Sterke versleuteling vereist ook een correcte uitvoering op het apparaat. Een kwetsbaarheid in het besturingssysteem, de cryptografische implementatie of de hardware kan toegang tot gevoelige gegevens openen. Onderzoek naar processoraanvallen bewijst echter niet dat elke telefoon of berichtenapp op dezelfde manier kan worden gecompromitteerd.
De nuttige vragen zijn: welke toegang heeft de aanvaller, welke sleutel of leesbare tekst kan die zien, en is de toegang tijdelijk of aanhoudend? De antwoorden zijn belangrijker dan de naam van het algoritme.
Wat is het verschil tussen zijkanalen en geheugen uitlezen?
Bij rechtstreeks uitlezen van het geheugen kan een aanvaller mogelijk delen van het geheugen van een proces of apparaat lezen. Bij een zijkanaalaanval worden aanwijzingen zoals de uitvoeringstijd van bewerkingen of het gedrag van de cache gebruikt om informatie af te leiden. Beide hebben niet noodzakelijk dezelfde voorwaarden of uitkomsten.
Het oorspronkelijke onderzoek naar FLUSH+RELOAD bestudeerde cachegedrag en gedeelde geheugenpagina’s in een specifieke testomgeving en toonde aan dat een sleutel uit een versie van GnuPG kon worden gehaald. Dat resultaat is geen beveiligingstest van Livara en geen bewijs dat alle telefoonprocessors kwetsbaar zijn.
| Soort toegang | Vraag die voor de beoordeling nodig is |
|---|---|
| Een gewone app op hetzelfde apparaat uitvoeren | Laten procesisolatie en de voorwaarden van de aanval waarneming toe? |
| Toegang tot het besturingssysteem met hoge rechten | Welke gegevens of sleutelbewerkingen komen beschikbaar voor de aanvaller? |
| Fysieke toegang of toegang in een laboratorium | Wat zijn de vergrendelingsstatus, het hardwaremodel en de sleutelbescherming? |
| Aanhoudende toegang tot de app | Kan de aanvaller opnieuw verse leesbare tekst of sleutels verzamelen? |
Zonder deze details is de algemene uitdrukking ‘RAM hacken’ geen afdoende technische uitleg.
Hoe helpen Keystore en veilige hardware?
Android Keystore kan het gebruik van sleutels beperken en op geschikte apparaten bewerkingen met hardwareondersteuning uitvoeren. In dit ontwerp betekent een niet-uitleesbare sleutel niet dat een aanvaller deze niet kan gebruiken: onder bepaalde omstandigheden kan een gecompromitteerde app toegestane sleutelbewerkingen misbruiken, zelfs zonder de sleutelbytes te bemachtigen. Handleiding voor Android Keystore.
Ook worden niet alle sleutels en algoritmen automatisch in veilige hardware ondergebracht. Het sleuteltype, de ondersteuning door het apparaat en het gebruik door de app moeten duidelijk zijn. De uitspraak ‘de sleutel staat op het apparaat’ bewijst op zichzelf niet waar deze staat of welk beschermingsniveau geldt.
Onthult één blootgestelde sleutel slechts één bericht?
Soms heeft de blootstelling van een onafhankelijke berichtsleutel een beperkte reikwijdte. Maar als de aanvaller een ketensleutel, de sessiestatus, een identiteitssleutel, leesbare geschiedenis of meerdere buffers bemachtigt, is het resultaat anders. Zonder vast te stellen welke gegevens zijn blootgesteld, kunnen we dus niet zeggen dat ‘hooguit één bericht’ gevaar loopt.
Een andere sleutel voor elk bericht verbreekt de toegang van de aanvaller evenmin noodzakelijk. Als volgende sleutels worden afgeleid uit een toestand die de aanvaller kent, of als de aanvaller op het apparaat aanwezig blijft, kan die mogelijk ook latere berichten bereiken. Bescherming van het verleden en herstel van toekomstige veiligheid zijn afzonderlijke eigenschappen met specifieke aannames.
Welke beperkingen hebben ratchets en het wissen van geheugen?
Een ratchet kan sleutels tijdens een gesprek laten evolueren. Herstel na blootstelling vereist nieuwe informatie waartoe de aanvaller geen toegang heeft; alleen een bericht versturen bewijst niet dat aan die voorwaarde is voldaan. De Double Ratchet-specificatie beschrijft naast herstel ook de risico’s van blijvende toegang en het terughalen van verwijderde gegevens.
De levensduur van gevoelige gegevens verkorten en buffers wissen is nuttig, maar daaruit volgt geen algemene garantie dat alle kopieën in het RAM zijn gewist. Bibliotheken, de programmeertaal en de weergavepaden moeten worden onderzocht.
Wat kunnen we over Livara zeggen?
Livara’s beveiligingspagina beschrijft de hybride opbouw en de sleutelevolutie in LVR1. Dit artikel is geen zijkanaaltest, geheugenaudit of bevestiging dat alle sleutels Keystore gebruiken. Met name de openbare documentatie over het dreigingsmodel garandeert geen bescherming van een gecompromitteerd apparaat.
Beloften zoals ‘het volgende bericht neutraliseert een hardware-inbraak’ of ‘hooguit één bericht wordt blootgesteld’ mogen daarom niet aan het product worden toegeschreven zonder specifiek bewijs voor die versie en dat scenario.
Praktische keuzes voor gebruikers
Houd het besturingssysteem en de app bijgewerkt, kies een apparaat met actieve beveiligingsondersteuning, vermijd onbetrouwbare installaties en onnodige machtigingen, en gebruik een passende vergrendeling. Bij een vermoeden van ernstige compromittering zijn een andere berichtenapp kiezen of een nieuw bericht versturen geen vervanging voor onderzoek en opschoning van het apparaat.
Vraag bij een beveiligingsclaim naar vier zaken: de geteste versie, de toegang van de aanvaller, de blootgestelde gegevens en de beperkingen van het resultaat. De naam van een processor of versleutelingsstandaard beantwoordt die vier vragen op zichzelf niet.
