OpenPGP als PKI voor bedrijven
Samenvatting
Nog steeds worden de mogelijkheden van het OpenPGP Trust Model door veel mensen onderschat. Dit paper toont aan dat het OpenPGP Trust Model en het X.509 concept vrijwel identiek zijn.
Inhoud
Introductie
OpenPGP en zijn Web of Trust certificering is een concept dat niet voor elk bedrijf geschikt is. Er bestaan echter mogelijkheden om het klassieke Web of Trust te veranderen in een superset van het X.509 systeem. Dit paper bediscussieert het OpenPGP vertrouwensmodel. Er wordt vanuit gegaan dat de lezer bekend is met de X.509 infrastructuur en haar concepten.
Dit paper is opgesteld in samenwerking met Christian Kirsch en Felix Storm van Biodata GmbH. Biodata is producent van o.a. de Biodata PKI server waarmee gecentraliseerd management van OpenPGP en X.509 certificaten mogelijk is.
Feiten
OpenPGP Web of Trust
Om het hierna volgende concept volledig te begrijpen, is enig inzicht nodig in het OpenPGP Web of Trust model. OpenPGP is initieel ontwikkeld voor de Internet gemeenschap, terwijl X.509 is ontworpen voor een hiërarchische structuur. Het X.509 concept stelt als eis dat er een certification authority (CA) bestaat die door de gebruiker vertrouwd kan worden. OpenPGP ziet elke gebruiker als een CA. Oftewel, met X.509 start de vertrouwensrelatie met een CA (top down), terwijl in OpenPGP de vertrouwensrelatie begint bij de gebruiker (bottom-up).
Het Web of Trust model is gebaseerd op de theorie dat ieder persoon ter wereld via een beperkt aantal mensen is te koppelen aan een willekeurig ander persoon. In OpenPGP wordt op deze manier de vertrouwensrelatie opgebouwd.
Een eenvoudig voorbeeld: Alice en Bob hebben beiden een OpenPGP sleutel. Alice tekent Bob's publieke sleutel. Hierdoor wordt Bob's sleutel gevalideerd door en voor Alice. Dit is de eenvoudigste wijze van opbouwen van vertrouwen in openPGP [figuur 1/Voorbeeld 1].
Als Alice de sleutel van Bob tekent kan ze aangeven of ze automatisch sleutels die door Bob zijn getekend en dus Bob's handtekening bevatten wil vertrouwen. In dit geval wordt Bob's sleutel getekend met de "Trusted-Introducer" specificatie. Als Bob vervolgens de sleutel van Charlie tekent dan wordt deze sleutel automatisch ook gevalideerd voor Alice. Dit noemt men overdraagbaar vertrouwen (transitive trust) [figuur 1/Voorbeeld 2].
In een Web of Trust kunnen ook complexere vertrouwensrelaties worden gemaakt: indien Alice de sleutel van Bob tekent met als specificatie "Meta- Introducer" dan kan Bob op zijn beurt voor Alice de sleutels van anderen tekenen als "Trusted-Introducer" [figuur 1/Voorbeeld 3].
figuur 1.
Deze voorbeelden laten de lineaire vertrouwensrelatie zien. Vertrouwen en validiteit worden echter niet vanuit één gebruiker verdeeld, maar vanuit elke gebruiker. Hierdoor ontstaat een driedimensionaal stervormig vertrouwensnetwerk; het Web of Trust.
Ondanks het academische karakter van dit model blijkt het verassend goed bij het menselijke begrip en gevoel van vertrouwen te passen. Het is echter ook te begrijpen waarom bedrijven de voorkeur geven aan een meer hiërarchische structuur. In de volgende paragraaf wordt duidelijk gemaakt dat het Web of Trust eigenlijk een superset is van een normale hiërarchische structuur.
Hiërarchie
Laten we nog eens kijken naar het tweede voorbeeld waarin een vertrouwensrelatie in twee stappen wordt aangemaakt. Alice tekent de sleutel van Bob als "Trusted-Introducer". Bob tekent de sleutel van Charlie met een normale handtekening. Op dat moment wordt de sleutel van Charlie gevalideerd voor Alice.
figuur 2.
Als we de sleutel van Bob hernoemen tot "Root CA" dan ontstaat een hiërarchische vertrouwensrelatie. Als Charlie vervolgens de "Root CA" sleutel tekent met als specificatie "Trusted-introducer" en de "Root CA" heeft Alice's sleutel getekend dan is de vertrouwensrelatie tussen Alice en Charlie rond.
Met deze acties wordt vanuit een Web of Trust model een hiërarchisch model gemaakt. Dit is de eenvoudigste vorm van een OpenPGP PKI. Het X.509 model ziet er exact hetzelfde uit.
Het is belangrijk om te begrijpen dat dit model volledig compatibel is met de OpenPGP standaard en daarmee dus ondersteund wordt door producten die deze standaard ondersteunen. De specifieke beperkingen van gebruikers in het bedrijf zijn de primaire focus, niet het misbruik van gebruikers van het Web of Trust.
Het basis concept uitgebouwd
Een Multi-Level PKI
Een eenvoudige hiërarchie zoals hierboven omschreven is niet flexibel genoeg voor veel scenario's. Het introduceren van een extra niveau waarop vertrouwen en geldigheid kan worden verdeeld is nodig. We introduceren een Sub CA die door de Root CA wordt getekend als Ttrusted-Introducer". Bijvoorbeeld:
Alice tekent het "Root CA" certificaat als "Meta- Introducer". De "Root CA" tekent de "Sub CA" als"Trusted- Introducer". Vervolgens wordt door de laatste het certificaat van David getekend. Hierdoor wordt het certificaat van David gevalideerd voor Alice.
figuur 3.
Meerdere Sub CA's
Ook is het mogelijk om meerdere Sub CA's te integreren in dit model. Hiermee kan een infrastructuur worden ontworpen die rekening houdt met internationale vestigingen en regio's, waarbij elke vestiging danwel regio een eigen Sub CA beheert.
Cross-Certificatie
Door het kruiselings certificeren van de sleutels van twee organisaties kan een wederzijdse vertrouwensband worden gecreëerd. Omdat de OpenPGP standaard het toestaat om meerdere handtekeningen op een sleutel te plaatsen kan dit eenvoudiger met OpenPGP dan met X.509 worden uitgevoerd. De vertrouwensrelatie wordt bekrachtigd door de Root CA van beide organisaties elkanders Sub CA's als "trusted-Introducer" te laten tekenen. Op dat moment heeft de publieke sleutel van de Sub CA de handtekeningen van de Root CA's van beide organisaties. Het is mogelijk om aan de geldigheid een bepaalde periode te verbinden van bijvoorbeeld één jaar, waarna de certificering opnieuw moet plaatsvinden.
De medewerkers van een bedrijf zullen de Sub CA's van het andere bedrijf automatisch vertrouwen, net als elke sleutel die door hen is getekend. Indien één van de partijen de vertrouwensband wil of moet verbreken dan is het intrekken van de "Trusted-Introducer" handtekening door de Root CA voldoende.
OpenPGP ondersteunt dus meerdere Root CA's. We introduceren het certificeren van partners en het gebruiken van meerdere Root CA's.
Partners
Als niet een volledige vertrouwensrelatie moet worden aangegaan met een andere organisatie, maar bijvoorbeeld alleen met de juridische afdeling of enkele medewerkers ervan, dan kunnen Partner Sub CA's worden gecreëerd. De Partner Sub CA wordt door de Root CA getekend als "Trusted- Introducer". Van daaruit kan de Sub CA rechtstreeks de medewerkers certificeren.
Exclusiviteit van het eigen Web of Trust
Doordat eindgebruikers alleen andere sleutels kunnen tekenen met een normale handtekening kan worden voorkomen dat vertrouwen onbedoeld wordt overgedragen.
Mocht echter een externe gebruiker het Root CA certificaat of een Sub CA certificaat tekenen van de organisatie, dan wordt alleen het externe Web of Trust beïnvloed, niet de PKI van de eigen organisatie. Dit heeft ook een voordeel, namelijk dat een gebruiker door het tekenen van het Root CA certificaat als "Meta-Introducer" automatisch alle organisatie sleutels kan vertrouwen, zonder dat hiervoor een actie van de Root CA zelf nodig is.
figuur 4.
Het is belangrijk te voorkomen dat een gebruiker zelf sleutels introduceert. Het introduceren van nieuwe sleutels loopt altijd via een Sub CA die door de gebruiker als "Trusted-Introducer" is aangemerkt. Zouden onbekende sleutels toegelaten worden in het PKI systeem dan verlaagt dit de totale veiligheid van de PKI en kunnen acties als het intrekken van sleutels bemoeilijkt worden.
Centrale sleutelgeneratie
Decentraal genereren van sleutels (de traditionele manier van OpenPGP) is niet voor elke organisatie geschikt. Door het centraal genereren van sleutels kan het aanmaakproces beter gecontroleerd worden. Fouten door de eindgebruiker kunnen op deze manier makkelijker worden voorkomen. Tevens kan het juiste formaat voor de sleutel worden afgedwongen en kan worden verzekerd dat de juiste publieke sleutels worden getekend en beschikbaar worden gesteld in de PKI.
Een back-up van de privé sleutel met gedecentraliseerde sleutelgeneratie is problematischer. Toch is een back-up van de privé sleutel aan te raden voor het geval dat een gebruiker het wachtwoord van of de privé sleutel zelf verliest en de versleutelde gegevens gedecodeerd moeten worden of de sleutel moet worden ingetrokken.
Om een PKI mogelijk te maken die werkt volgens bovenstaand schema moet het sleutel materiaal dat wordt gegenereerd er zo uit zien: De publieke sleutel van de gebruiker moet door de juiste Sub CA worden getekend. Tevens moet de gebruiker de beschikking hebben over de publieke sleutels van de Root CA en de Sub CA('s) zodat de validiteit ervan door de gebruiker gecontroleerd kan worden. Alle Root CA sleutels die de gebruiker in zijn sleutel ring heeft moeten worden getekend als "Meta-Introducers". In een goed ontworpen OpenPGP CA kan dit proces geautomatiseerd verlopen.
Tussen twee haakjes: Door het centraal genereren kan eenzelfde CA/RA structuur worden gecreëerd die ook met X.509 mogelijk is.
X.500 Directory Service en Keyserver
De gebruikers sleutels zullen via de Keyserver beschikbaar moeten worden gesteld. OpenPGP biedt hiervoor twee opties. Ten eerste zijn er HTTP servers. Indien er van diverse besturingssystemen gebruik wordt gemaakt is dit een goede optie. Keyservers managen de sleutels in een platte structuur en zijn niet diep geïntegreerd in de IT-infrastructuur. De keyserver bevat een database die door de organisatie moet worden onderhouden en moet worden gerepliceerd naar de verschillende regio's van de organisatie.
Een elegantere en snellere manier is het gebruiken van een X.500 directory service. Veel organisaties hebben reeds werkende, of zijn bezig met de implementatie van, zo'n directory service. Het is mogelijk om de OpenPGP certificaten in de directory structuur te plaatsen en ze via LDAP te benaderen.
Dit is de meest eenvoudige benadering voor de producten die op dit moment beschikbaar zijn op de markt, zoals Microsoft Active Directory, Netscape Directory Server of Novell NDS. Het is aan te raden om de reeds aanwezige directory service te gebruiken aangezien dan geen extra acties hoeven worden uitgezet om de keyserver te beheren.
Als het directory schema wordt ontworpen is het belangrijk om rekening te houden met het feit dat per gebruiker meerdere sleutels uitgegeven kunnen worden. Het KeyID veld uit een OpenPGP certificaat moet in een apart veld worden geplaatst en geindexeerd indien hier het meest op gezocht moet worden.
Conclusie
Alhoewel het klassieke Web of Trust model niet geschikt is voor (grote) organisaties kan het gevormd worden tot een hiërarchische infrastructuur met een grotere flexibiliteit in het managen van de vertrouwensrelaties dan bij X.509 het geval is. Voor de meeste organisaties wordt het multi-level CA model aangeraden. Deze flexibiliteit komt zeker bij complexere cross-certificatie tussen de organisatie en externe partners van pas. Het genereren van OpenPGP sleutels kan het beste gecentraliseerd gebeuren. Opslag van OpenPGP sleutels kan het beste gebeuren in een X.500 directory service.