Kryptografisk flexibilitet är förmågan att flytta ett protokoll från en kryptografisk svit till en annan utan att förlora ett tydligt säkerhetskontrakt. För meddelandetjänster innebär det mer än att lägga till namnet på en ny algoritm. Gamla klienter, mottagare som är offline, lagrade meddelanden och länkade enheter måste alla bete sig förutsägbart under övergången.
IETF:s RFC 7696 beskriver algoritmflexibilitet som ett migreringsproblem som omfattar identifierare, implementationer och driftsförändringar. Ett versionsnummer hjälper till att identifiera vad som används; det gör inte migreringen säker i sig.
Tre versioner som är lätta att blanda ihop
En meddelandeapp kan ha en appversion, en version av kommunikationsprotokollet och en identifierare för den kryptografiska sviten. De besvarar olika frågor:
| Identifierare | Vad den säger till en granskare | Vad den inte fastställer |
|---|---|---|
| Apputgåva | Vilket programbygge som är installerat | Att varje konversation använder det senaste protokollet |
| Protokollversion | Vilket meddelandeformat och vilka tillståndsregler som gäller | Att implementationen följer reglerna korrekt |
| Algoritm- eller svitidentifierare | Vilka kryptografiska komponenter som valts | Att förhandlingen inte kan nedgraderas |
Versionsinformationen bör tydliggöra sambandet. ”Ny kryptering lanserad” är tvetydigt om bara nyskapade konversationer använder den, eller om en äldre länkad klient orsakar en återgång till ett tidigare alternativ.
Vad en säker migrering måste specificera
Börja med ett konkret scenario: Alice uppdaterar i dag; Bob är fortfarande offline på en äldre telefon. Alice skickar ett meddelande och lägger senare till en andra enhet. Vad ska varje enhet acceptera, lagra och visa?
En konstruktion som går att granska besvarar åtminstone dessa frågor:
- Hur får varje sida veta vilka versioner den andra stöder?
- Autentiseras den valda versionen som en del av sessionen?
- Vad händer när det inte finns någon gemensam godtagbar version?
- Kan en illvillig reläserver ta bort en kapacitetsuppgift och framkalla ett svagare läge?
- Går gamla meddelanden fortfarande att läsa, och vilka gamla nycklar behövs fortfarande?
- Återupplivar återställning av en säkerhetskopia föråldrat protokolltillstånd?
- När kommer utfasade algoritmer att inaktiveras i stället för att bara avrådas från?
Ett synligt fel är ofta säkrare än en tyst övergång till ett läge som användaren inte avsåg. Men exakt hur fel och återhämtning hanteras bör dokumenteras så att människor inte kringgår problemet genom att byta till en oskyddad kanal.
En praktisk testmatris för uppgraderingar
En säkerhetsuppgradering behöver mer än en lyckad chatt mellan två nya installationer. Testa dessa fall med icke-känsliga uppgifter:
| Test | Belägg att dokumentera |
|---|---|
| Ny klient till gammal klient | Valt protokoll eller tydligt resultat som visar inkompatibilitet |
| Mottagare offline under uppgradering | Beteende för leverans och dekryptering efter återanslutning |
| Gammal länkad enhet återkommer | Om den kan läsa, skicka eller tvinga fram ett oväntat läge |
| En grupp lägger till en inkompatibel medlem | Uttrycklig gruppolicy och tillstånd som är synligt för användaren |
| Säkerhetskopia återställs efter utfasning | Om tillstånd som inte stöds avvisas eller migreras |
| Manipulerade versionsmetadata | Autentiseringsfel i stället för en obemärkt nedgradering |
Detta är utvärderingskriterier, inte påståenden om att en namngiven produkt har klarat testerna. Spara byggidentifierare och observerade resultat så att en senare regression kan skiljas från en dokumentationsändring.
Så tolkar du Livaras protokollnamn
Livara anger LVR1 för direktchattar och LGS1 för privata grupper i sin säkerhetsdokumentation. Namnen skiljer mellan ansvarsområden; de ska inte läsas som bevis för oberoende standardisering eller granskning. Sidan diskuterar också beteendet för klienter eller grupper som inte kan uppfylla det krypterade lägets förutsättningar.
Nästa användbara belägg vore en versionshanterad specifikation, testvektorer, kompatibilitetsregler och granskningsresultat knutna till en viss utgåva. Proof Lab är tydligt med demonstrationens mindre omfattning. Att pröva primitiver i en webbläsare är inte samma sak som att testa varje migreringsväg i appen.
Vad användare bör göra under en krypteringsuppgradering
Håll klienter som stöds uppdaterade, läs säkerhetsmeddelanden om enhetskompatibilitet och var uppmärksam på ändrade indikatorer för identitet eller krypteringstillstånd. Anta inte att en ny appikon betyder att varje gammal grupp och säkerhetskopia har fått nytt skydd. Om produkten inte kan förklara vilka uppgifter som har fått förändrat skydd bör du fråga innan du delar känsligt material.
God kryptografisk flexibilitet gör förändringar möjliga att granska. Den identifierar vad som ändrats, hur parterna kommer överens om det, vad som kan gå fel och när den gamla mekanismen slutar accepteras.
