Omfattningen av ett röjande beror på nyckeltypen och hur länge angriparen har åtkomst; en ratchet garanterar inte att bara ett meddelande är i fara.
Stark kryptering kräver också korrekt körning på enheten. En sårbarhet i operativsystemet, kryptografiimplementationen eller hårdvaran kan öppna en väg till känsliga data. Men att det finns forskning om processorattacker innebär inte att varje telefon eller meddelandeapp kan angripas på samma sätt.
De användbara frågorna är: vilken åtkomst har angriparen, vilken nyckel eller text kan hen se, och är åtkomsten tillfällig eller fortlöpande? Svaren är viktigare än algoritmens namn.
Vad skiljer en sidokanal från minnesavläsning?
Vid direkt minnesavläsning kan angriparen möjligen läsa delar av processens eller enhetens minnesutrymme. Vid en sidokanalsattack dras slutsatser om information utifrån signaler som operationers körtid eller cachens beteende. Metoderna har inte nödvändigtvis samma förutsättningar eller resultat.
Den ursprungliga forskningen om FLUSH+RELOAD undersökte cachebeteende och delade minnessidor i en bestämd testmiljö och visade att en nyckel kunde extraheras ur en version av GnuPG. Resultatet är inte ett säkerhetstest av Livara eller bevis för att alla telefonprocessorer är sårbara.
| Typ av åtkomst | Fråga som behövs för bedömningen |
|---|---|
| Köra en vanlig app på samma enhet | Tillåter processisoleringen och attackens förutsättningar observation? |
| Åtkomst med höga privilegier i operativsystemet | Vilka data eller nyckeloperationer blir tillgängliga för angriparen? |
| Fysisk åtkomst eller laboratorieåtkomst | Vad är låsstatusen, hårdvarumodellen och nyckelns skydd? |
| Fortlöpande åtkomst till appen | Kan angriparen samla in nya texter eller nycklar igen? |
Det allmänna uttrycket ”hacka RAM” är ingen tillräcklig teknisk förklaring utan dessa detaljer.
Hur hjälper Keystore och säker hårdvara?
Android Keystore kan begränsa användningen av en nyckel och utföra operationer med hårdvarustöd på lämpliga enheter. I den konstruktionen är en nyckel som inte går att extrahera inte samma sak som en nyckel angriparen inte kan använda: en infekterad app kan under vissa omständigheter missbruka tillåtna nyckeloperationer även utan att få ut nyckelns byte. Se guiden till Android Keystore.
Alla nycklar och algoritmer hamnar inte heller automatiskt i säker hårdvara. Nyckeltyp, enhetens stöd och appens användningssätt måste anges. Att säga ”nyckeln finns på enheten” bevisar inte i sig dess placering eller skyddsnivå.
Röjer en exponerad nyckel bara ett meddelande?
Ibland har röjandet av en oberoende meddelandenyckel begränsad omfattning. Men om angriparen får en kedjenyckel, sessionstillstånd, en identitetsnyckel, läsbar historik eller flera buffertar blir resultatet ett annat. Utan att ange vilka data som röjts kan man därför inte säga att ”högst ett meddelande” är i fara.
Att byta nyckel för varje meddelande bryter inte heller nödvändigtvis angriparens åtkomst. Om kommande nycklar härleds ur ett tillstånd som angriparen har, eller om hen fortfarande finns på enheten, kan även kommande meddelanden bli åtkomliga. Skydd av det förflutna och återhämtning av framtida säkerhet är två separata egenskaper med bestämda antaganden.
Vilka begränsningar har ratchet och minnesrensning?
En ratchet kan utveckla nycklarna under samtalets gång. Återhämtning efter ett röjande kräver att ny information tillförs som angriparen inte har åtkomst till; att bara skicka ett meddelande bevisar inte detta villkor. Specifikationen för Double Ratchet beskriver, utöver återhämtning, riskerna med bestående åtkomst och återställning av raderade data.
Det är användbart att förkorta känsliga datas livslängd och rensa buffertar, men det innebär ingen allmän garanti för att alla kopior i RAM raderas. Bibliotek, programmeringsspråk och visningsvägar måste granskas.
Vad kan man säga om Livara?
Livara-sidan om säkerhet beskriver hybridkonstruktionen och nycklarnas utveckling i LVR1. Den här artikeln är inte ett sidokanalstest, en minnesrevision eller en bekräftelse på att alla nycklar använder Keystore. I synnerhet garanterar den offentliga dokumentationen om hotmodellen inte skydd för en infekterad enhet.
Därför bör man inte tillskriva produkten löften om att ”neutralisera ett hårdvaruintrång med nästa meddelande” eller ”röja högst ett meddelande”, om det inte finns specifika belägg för just den versionen och det scenariot.
Praktiska beslut för användaren
Håll operativsystemet och appen uppdaterade, välj en enhet med aktivt säkerhetsstöd, undvik opålitliga installationer och onödig åtkomst och använd ett lämpligt lås. Vid misstanke om ett allvarligt intrång ersätter byte av meddelandeapp eller ett nytt meddelande inte undersökning och sanering av enheten.
När du läser ett säkerhetspåstående, begär fyra saker: den testade versionen, angriparens åtkomst, de röjda uppgifterna och resultatets begränsningar. Namnet på en processor eller en kryptografisk standard besvarar inte i sig dessa fyra frågor.
