Waarom sleutelbeheer?

Encryptie-algoritmen hebben gemeen dat ze werken met gegenereerde sleutels, getallenreeksen waarmee de wiskundige problemen zijn op te lossen die de kern van encryptie vormen. Een van de kenmerken van (sterke) sleutels is dat door ingebouwde willekeur geen twee sleutels hetzelfde zijn. Alleen de houder van een sleutel kan bij de versleutelde data. Daarbij is het natuurlijk van het grootste belang dat alleen de personen en systemen die toegang tot de gegevens behoren te hebben de beschikking krijgen over die sleutels, en anderen niet. Andersom is ook belangrijk: als personen die toegang behoren te hebben geen sleutel hebben, dan kunnen ze niet bij hun gegevens.

De vele (soms duizenden) sleutels die worden gegenereerd, voor verschillende systemen, omgevingen en personen, moeten worden bewaard, bijgehouden, gedistribueerd naar de juiste persoenen en eventueel worden ingetrokken. Bovendien moeten om de zoveel tijd moeten symmetrische sleutels worden vervangen, om het risico op lekken te beperken. Om al die taken overzichtelijk te houden en consequent uit te kunnen voeren is beheer broodnodig.

Op welke manieren kunnen sleutels beheerd worden?

Daar zit juist het grote probleem, zo geeft Corné van Rooij van EMC encryptiedivisie RSA aan tegenover Techworld. Elk platform en elke oplossing heeft op dit moment zijn eigen manier om de sleutels bij te houden. Echt universele oplossingen zijn er niet, waardoor zelfs de oude vertrouwde spreadsheet nog steeds veel wordt gebruikt, "meestal om bij te houden waar de symmetrische sleutels exact staan. In een directory van een applicatie op een server bijvoorbeeld, in een registryregel of in een tabel of kolom van een database", aldus Van Rooij.

Maar een dergelijke handmatige aanpak brengt fikse problemen met zich mee. "Keys in VPN-oplossingen kunnen bijvoorbeeld verlopen, waardoor de dataverbinding er uren uit ligt. De beheerder kan de sleutel aan zijn zijde wel vervangen, maar kan door de verlopen sleutel niet bij de andere zijde." Wie wil automatiseren is aangewezen op bedrijfseigen tools, voor elk systeem eentje. Op die manier heeft een bedrijf apart beheer voor sleutels voor de laptops, voor de servers, voor het e-mailverkeer enzovoorts enzovoorts enzovoorts. Encryptiebedrijven, waaronder ook RSA, leveren een keur aan sleutelbeheertools mee met hun producten.

Hoe gaat dat opgelost worden?

Op dit moment heeft de industrie twee belangrijke lopende standaardisatieprocessen voor protocollen tussen encryptieproducten en de sleutelbeheertools. Eentje is van de IEEE 1619.3 commissie, die zich vooral toelegt op data-encryptie in de storagehoek, de ander is van OASIS: het comité voor Enterprise Key Management Infrastructure (EKMI). Voor OASIS is daar vorige week een initiatief bijgekomen met een bundeling van krachten van verschillende aanbieders, waaronder HP, EMC, IBM en Brocade. Deze hebben een gezamenlijk protocol naar voren geschoven om door OASIS te laten standaardiseren in het KMIP (Key Management Interoperability Protocol) comité. Dat protocol moet in gebruik vooral breder worden dan wat zowel de EKMI (gericht op symmetrische versleuteling) als IEEE 1619.3 (gericht op storageversleuteling) voor ogen hebben. Omdat het om een open standaard gaat, kunnen alle aanbieders gebruik gaan maken van KMIP

Hoe lang gaat dat nog duren?

Men zal zeker niet over één nacht ijs gaan. In het meest gunstige geval gaat het volgens Van Rooij nog tenminste een jaar duren voordat de standaardisatie is afgerond en aanbieders hun tools en producten gaan harmoniseren. Daar komt bij dat Sun deze week zijn eigen protocol open source heeft gegooid. Sun doet niet mee aan de KMIP-standaardisatie, en geeft in zijn aankondiging ondubbelzinnig aan dat zijn eigen protocol breed gedragen wordt en dat het vrijgeven van de broncode ertoe moet bijdragen dat het een standaard wordt. Conflicten over (open) standaarden kunnen hoog oplopen, zoals ook het OOXML-ODF-debat van vorig jaar heeft aangetoond.

Bron: Techworld