Crypto-agiliteit is het vermogen om een protocol van de ene cryptografische suite naar een andere over te zetten zonder duidelijke beveiligingsafspraken te verliezen. Bij berichtenverkeer betekent dat meer dan de naam van een nieuw algoritme toevoegen. Oude clients, offline ontvangers, opgeslagen berichten en gekoppelde apparaten moeten zich tijdens de overgang allemaal voorspelbaar gedragen.
De RFC 7696 van de IETF beschrijft algoritme-agiliteit als een migratievraagstuk waarbij identificatoren, implementaties en operationele veranderingen betrokken zijn. Een versienummer helpt vast te stellen wat er wordt gebruikt; op zichzelf maakt het een migratie niet veilig.
Drie versies die gemakkelijk door elkaar worden gehaald
Een berichtenapp kan een appversie, een versie van het communicatieprotocol en een identificator van de cryptografische suite hebben. Ze beantwoorden verschillende vragen:
| Identificator | Wat deze een beoordelaar vertelt | Wat deze niet aantoont |
|---|---|---|
| Apprelease | Welke softwarebuild is geïnstalleerd | Dat elk gesprek het nieuwste protocol gebruikt |
| Protocolversie | Welk berichtformaat en welke toestandsregels gelden | Dat de implementatie die regels correct volgt |
| Algoritme- of suite-identificator | Welke cryptografische componenten zijn geselecteerd | Dat de onderhandeling niet naar een zwakkere optie kan worden teruggezet |
Releaseopmerkingen moeten dit verband expliciet maken. ‘Nieuwe versleuteling uitgebracht’ is dubbelzinnig als alleen nieuw aangemaakte gesprekken deze gebruiken, of als een oudere gekoppelde client een terugval veroorzaakt.
Wat een veilige migratie moet vastleggen
Begin met een concreet scenario: Alice werkt vandaag bij; Bob blijft offline op een oudere telefoon. Alice verstuurt een bericht en voegt later een tweede apparaat toe. Wat moet elk apparaat accepteren, opslaan en weergeven?
Een beoordeelbaar ontwerp beantwoordt ten minste deze vragen:
- Hoe ontdekt elke partij welke versies de andere ondersteunt?
- Wordt de gekozen versie als onderdeel van de sessie geauthenticeerd?
- Wat gebeurt er als er geen gedeelde, aanvaardbare versie is?
- Kan een kwaadwillende relay een mogelijkheid verwijderen en een zwakkere modus uitlokken?
- Blijven oude berichten leesbaar, en welke oude sleutels blijven nodig?
- Herstelt het terugzetten van een back-up een verouderde protocoltoestand?
- Wanneer worden uitgefaseerde algoritmen uitgeschakeld in plaats van alleen afgeraden?
Een zichtbare fout is vaak veiliger dan een stille overgang naar een modus die de gebruiker niet bedoelde. Maar het precieze gedrag bij fouten en herstel moet worden gedocumenteerd, zodat mensen het niet omzeilen door naar een onbeveiligd kanaal over te stappen.
Een praktische testmatrix voor upgrades
Een beveiligingsupgrade vraagt meer dan een geslaagd gesprek tussen twee nieuwe installaties. Test deze gevallen met niet-gevoelige gegevens:
| Test | Vast te leggen bewijs |
|---|---|
| Nieuwe client naar oude client | Gekozen protocol of een duidelijk incompatibiliteitsresultaat |
| Ontvanger offline tijdens upgrade | Afleverings- en ontsleutelingsgedrag na opnieuw verbinden |
| Oud gekoppeld apparaat keert terug | Of het kan lezen, verzenden of een onverwachte modus afdwingen |
| Groep voegt incompatibel lid toe | Expliciet groepsbeleid en voor de gebruiker zichtbare toestand |
| Back-up hersteld na uitfasering | Of niet-ondersteunde toestand wordt geweigerd of gemigreerd |
| Gemanipuleerde versiemetagegevens | Authenticatiefout in plaats van een onopgemerkte downgrade |
Dit zijn beoordelingscriteria, geen beweringen dat een genoemd product de tests heeft doorstaan. Bewaar build-identificatoren en waargenomen resultaten, zodat een latere regressie kan worden onderscheiden van een wijziging in de documentatie.
Hoe u de protocolnamen van Livara moet lezen
Livara noemt LVR1 voor directe chats en LGS1 voor privégroepen in zijn beveiligingsdocumentatie. Deze namen onderscheiden verantwoordelijkheden; ze mogen niet worden opgevat als bewijs van onafhankelijke standaardisatie of een onafhankelijke audit. De pagina bespreekt ook het gedrag van clients of groepen die niet aan de voorwaarden van de versleutelde modus kunnen voldoen.
Volgend nuttig bewijs zou bestaan uit een specificatie met versiebeheer, testvectoren, compatibiliteitsregels en beoordelingsresultaten die aan een bepaalde release zijn gekoppeld. Het Proof Lab is expliciet over de beperktere reikwijdte van zijn demonstratie. Primitieven in een browser uitvoeren is niet hetzelfde als elk migratiepad in de app testen.
Wat gebruikers tijdens een versleutelingsupgrade moeten doen
Houd ondersteunde clients bijgewerkt, lees beveiligingsmeldingen over apparaatcompatibiliteit en let op gewijzigde indicatoren voor identiteit of versleutelingsstatus. Ga er niet van uit dat een nieuw apppictogram betekent dat elke oude groep en back-up nieuwe bescherming heeft gekregen. Als het product niet kan uitleggen voor welke gegevens de bescherming is veranderd, vraag dat dan voordat u gevoelig materiaal deelt.
Goede crypto-agiliteit maakt verandering controleerbaar. Ze benoemt wat er is veranderd, hoe partijen het daarover eens worden, wat er mis kan gaan en wanneer het oude mechanisme niet meer wordt geaccepteerd.
