In dit artikel probeer ik uit te leggen hoe je een PKI zou kunnen inzetten en ga tevens in op de belangrijkste zaken die meegenomen moeten worden in dit proces.

Een Public Key Infrastructure is nodig wanneer je public keys wil gaan managen. Waarom zou je dat nou gaan doen? Bijvoorbeeld als je veilig zaken wil doen via het internet. Dit kan op vele manieren, een website die gebruikers authenticeert voordat ze naar een afgeschermd deel
mogen of als je ge-authenticeerde gebruikers een gepersonaliseerde website wil laten zien (online bankieren of verzekeren) of je wil afnemers een kijken laten nemen in je voorraaddatabase waarna ze bestellingen kunnen doen of je wil je software laten ondertekenen en
zo zijn er nog legio voorbeelden. Gemeenschappelijke kenmerken zijn
authenticatie, autorisatie, privacy, onweerlegbaarheid en integriteit
van data. Deze vijf zijn nodig om iets met e-commerce te doen. Alle
vijf zijn nodig voor het veilig zaken doen via publieke netwerken. Als
je over een PKI gaat nadenken zijn er zoveel zaken die eerst
beantwoord moeten worden dat je al snel discussies over details kan
krijgen.

Het moeilijkste vraagstuk dat beantwoord moet worden is dat
het inzetten van PKI volledig afhankelijk is van wat jij of het
bedrijf er nou eigenlijk mee wil. Helaas is er geen kookboek al denken
sommige PKI-verkopers er anders over. Dus zoals met alle moeilijke
dingen begin je klein en groei je geleidelijk groter, anders gezegd
test voordat je het in produktie neemt. Het eerste wat je dient te
weten is wat voor zaken wil ik gaan doen en hoe had ik mij die
voorgesteld in de normale wereld. (de normale wereld is tegengesteld
aan de online wereld). Is het wellicht voldoende om alleen een
servercertificaat te installeren van bijvoorbeeld Thawte zodat de
webserver zich kan authenticeren en encryptie ( via SSL (secure socket
layer)) mogelijk is waardoor mensen hun creditcard gegevens veilig
kunnen invoeren. Voorbeelden zijn amazon.com, amazon.de en
amazon.co.uk. Een voordeel is dat dit vrij snel is opgezet, een nadeel
is dat degene die de bestellingen doet niet online ge-authenticeerd
wordt (dit gebeurd natuurlijk wel achteraf via dezelfde technische weg
die wordt gebruikt bij het afrekenen met creditcard in een
restaurant). Stel je wil dat ook de besteller online ge-authenticeerd
wordt, dan komt SET in beeld. Een voordeel van SET is dat zowel degene
die iets verkoopt ge-authenticeerd wordt (online) als de verkopende
partij. Een nadeel is dat SET niet simpel te implementeren valt.

Vanwege de vele spraakverwarringen wil ik tevens uitleggen wat een
public key infrastructuur niet is. Ten eerste is het geen applicatie
die je van de plank pakt en even installeert. Er zal aardig wat
nagedacht en voorbereid moeten worden vooral om die PKI binnen het
gehele bedrijfsproces rendabel te maken, vergelijk het maar met het
installeren van SAP of Baan. Ten tweede is het niet de oplossing voor
alles. Dus ook niet voor alle security zaken. Ten derde is PKI alles
behalve simpel. Fout is dus Koop produkt X en u bent veilig op het
internet/intranet/extranet/whatevernet. Bedenk security is een proces.

Stel je wil als bedrijf een extranet waarop al je leveranciers toegang
krijgen en waarop tevens alle afnemers hun bestellingen kunnen
plaatsen. Dit betekent dat je alle leveranciers en afnemers moet gaan
authenticeren en dat je jezelf moet authenticeren. Tevens wil je voor
elke opdracht een digitale handtekening. En ik denk dat je ook
encryptie wil zodat al je concurrenten niet mee kunnen lezen. Verder
is het zo dat je je voorraaddatabase moet ontsluiten en natuurlijk de
database waarin al die orders geplaatst gaan worden. Oftewel je
bedrijf moet klaar zijn voor het zaken doen via internet. Volgende
stap is rondkijken in de markt om te bepalen wat er aan PKI te koop
is. Zo zijn er vertrouwde derde partijen (TTP = Trusted Third Party),
softwareleveranciers en natuurlijk ook opensource oplossingen.
Voorbeelden hiervan zijn, VeriSign en alle partners die in het
VeriSign Trust Network zitten. Of Entrust of Baltimore, of wellicht
PGP (Pretty Good Privacy van network associates) of GPG (een open
source versie van PGP) of als je het echt allemaal zelf wil doen dan
is openca (http://www.openca.org) een mogelijke oplossing. Stel je wil
geen open source en je kiest voor VeriSign (of een partner van
VeriSign). Dan zal één van hun eerste vragen zijn public of private of
iets ertussenin. Zonder voldoende voorbereiding sta je dan weer met je
mond vol tanden. Dan blijkt dat je ook over de jurisdische zaken een
menig dient te hebben. Omdat je zelf gaat bepalen wie jou certificaten
gaan krijgen ben je RA geworden. RA is registratie autoriteit en
VeriSign is dan de CA (certificatie autoriteit of uitgevende
instantie). Public houdt in dit verband in dat je gebruik kan maken
van de rootkey[1] van VeriSign die o.a. in alle browsers (zowel
Internet Explorer als Netscape Communicator) zit. Noodzakelijk als je
bijvoorbeeld door middel van ondertekende en versleutelde e-mail wil
communiceren met iedereen. Want als je private wil zal je bedrijf
ervoor moeten zorgen dat jou rootkey in al die applicaties komen die
ermee gaan werken. Verder is private vooral handig als je een
afgesloten gemeenschap hebt. Dat extranet wat je wilde opzetten is
afgesloten, immers jij bepaald wie je afnemers en leveranciers zijn,
dus je kiest voor private. Daarna komt die dure consultant weer terug
en vraagt: Hoe wil je dat de door jou uitgegeven certificaten eruit
gaan zien?. De ene is ondertekend door je eigen bedrijf en de ander is
ondertekend door VeriSign. Omdat je bedrijf groot is wil je liever dat
jouw naam op jouw certificaten staat. Afijn je wilt dus iets
ertussenin en bij VeriSign heet dat co-branding. Nu moet je je eigen
CPS (certificate practice statement) maken. In dit document staat
onder welke voorwaarden je certificaten gaat uitgeven en intrekken.
Tevens is het altijd zodat je bedrijf verantwoordelijk is voor de
eigen private keys. Dus je moet behalve een PKI ook een
beveilingsstructuur hebben en onderhouden. Pas als dit allemaal goed
geregeld is kun je beginnen met het opzetten van je extranet. Een
voorbeeld van zon extranet is het ANX (automotive network exchange
http://www.anxo.com) waarin de grote Amerikaanse autofabrikanten met
toeleveranciers en afnemers zitten.

Vergeet niet dat vertrouwde derde partijen jaarlijks geld vragen voor
het vernieuwen van de certificaten en de software. Al met al is het
managen van certificaten of public keys en een infrastructuur dus
duidelijk een proces.

Ik hoop met dit stuk een inleiding in PKI te hebben geschreven die in
elk geval duidelijk maakt dat authenticatie, autorisatie, integriteit
van data, privacy en onweerlegbaarheid nodig zijn om te komen tot
veilige e-commerce via publieke netwerken en dat het opzetten van een
PKI een goed doordacht en gemanaged proces moet zijn om mislukkingen
in de toekomst te voorkomen.

Leestips : Bruce Schneier,

http://thebusiness.vnunet.com/Analysis/600299.

Peter Gutman over X509 ,

http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt.