In de vorige column heb ik flink geageerd tegen de praktijken van zogenaamde
"Trusted Third Parties" (TTP's) en het gebruik van x509 certificaten en de
daarmee samenhangende infrastructuur. Gestimuleerd door alle reacties heb ik mezelf nogmaals aan de schrijftafel gezet om een
(definitief) overzicht te geven van de door TTP's gehanteerde technieken,
voorafgaande doelstellingen, gewenste procedures en huidige praktijken. Tevens
geef ik aan wat banderen /bhiervan vinden en wat de desbetreffende TTP's bzelf
zeggen/b./p
h2bDe Techniek/b/h2
pEen digitaal certificaat-paar bestaat uit een publiek en een privé gedeelte en is
niets meer of minder dan twee hele grote getallen met daaraan gekoppeld een aantal labels (zoals
een emailadres). De twee getallen zijn met elkaar verbonden zoals een
Feyenoord-fan aan De Kuip of Willem-Alexander aan Maxima. Twee verschillende
certificaten kunnen dezelfde public key hebben. De privé sleutel is in dat geval
gelijk. We spreken dan over hetzelfde sleutelpaar. De basis van
de betrouwbaarheid van een certificaat ligt in het sleutelpaar dat er voor wordt
gebruikt. Specifieker, de algoritmes en sleutellengtes. En daar ligt dus ook een potentieel risico. /p

pTijdens het aanmaken van een sleutelpaar worden de publieke en privé
sleutel van elkaar gescheiden en voorzien van kenmerken zoals Naam,
Uitgevende instantie, Gebruikt algoritme en Sleutellengte en (niet te
vergeten) de Geldigheidsduur en de Certificaat doeleinden./p
pHet Publieke Certificaat u wordt uitgedeeld/u aan derden, zodat deze
informatie kunnen coderen (versleutelen) voor - en digitale handtekeningen
kunnen controleren van het Privé Certificaat./p
pHet Privé Certificaat uwordt niet uitgedeeld/u. De eigenaar van
dit certificaat kan hiermee ontvangen versleutelde informatie decoderen en digitale
handtekeningen plaatsen.

pHeeft men de beschikking over voldoende computerrekenkracht dan is het
mogelijk om met behulp van het Publieke Certificaat (de publieke sleutel) het Privé
Certificaat (de privé sleutel) te
berekenen. Om dit proces (genaamd factoring) nagenoeg onmogelijk te maken is het
van belang dat 1) een betrouwbaar algoritme is gebruikt en 2) de sleutellengte groot genoeg is. Des te groter des te
beter is het devies. Voor eindgebruiker sleutels wordt aangenomen dat een Publieke sleutellengte van 1024 bits voldoende
is. /p
h2iCertificering/i /h2
pEen certificaat ontleent zijn geldigheid (en dus betrouwbaarheid) aan de idigitale handtekening/i
die er op is geplaatst. Bij het plaatsen ervan wordt gebruik gemaakt van een ander sleutelpaar. Binnen de x509 standaard betekent dit dat
een certificaat pas geldig is indien het is getekend door ueen hogerliggend/u
certificaat. Deze hiërarchische structuur heeft in theorie geen einde,
wat wil zeggen dat bovenaan in deze structuur een imythische entiteit/i het
ultieme certificaat bezit dat door iedereen wordt / moet worden vertrouwd. Door
het instellen van zogenaamde iroot/i certificaten, u die zichzelf
certificeren/u, wordt bereikt dat de keten van vertrouwen (icertificate chain)/i
kan worden geverifieerd tot aan een bepaald certificaat. /p
pOm vertrouwen tussen organisaties en personen te kunnen delen is het concept van de TTP
in het leven geroepen. De TTP is eigenaar van een iroot /icertificaat (welke
trouwens in meerdere smaken te verkrijgen zijn, allemaal gebaseerd op dezelfde
mathematische technieken, maar met verschillende labels of kenmerken). Het idee
is dat, indien iedereen de TTP vertrouwt (of beter gezegd, het iroot/i
certificaat dat deze gebruikt), bedrijven en consumenten sneller en
betrouwbaarder zaken met elkaar kunnen doen. De TTP zorgt namelijk voor de
verificatie van de klantgegevens zoals de naam, voordat een sleutelpaar met
certificaten wordt uitgegeven. Op deze wijze wordt een valide relatie
aangebracht tussen het certificaat en de daadwerkelijke eigenaar/gebruiker
van dat certificaat. /p
pDoordat de TTP het certificaat
voorziet van een digitale handtekening voordat het wordt overhandigd aan een klant, kan een derde partij (die de klant van de
TTP nog nooit heeft ontmoet, laat staan een onderzoek heeft gedaan naar de
betrouwbaarheid ervan) iblind varen/i op het gedelegeerde vertrouwen dat in
de TTP wordt gesteld. Het enige dat deze nieuwe klant moet doen om het
vertrouwen te krijgen, is het controleren van de handtekening /p

het controle traject. Nadat de handtekening op het certificaat van CA3
is gecontroleerd met het Publieke certificaat van CA1 wordt de
handtekening op CA1 certificaat gecontroleerd met het Publieke iroot/i
certificaat.

pVanuit theoretisch oogpunt is dit natuurlijk een fantastische techniek, want
het
haalt een zware administratieve last weg bij organisaties die aan het e-commerce
geweld willen deelnemen. Voorwaarde is dan natuurlijk wel dat iedereen zichzelf
conformeert aan de regels die er zijn met betrekking tot de gebruikte techniek
en procedures (oftewel het vertrouwen). /p
pDe praktijk wijst echter anders uit. Allereerst is het zo dat een organisatie
zelf de verantwoordelijkheid neemt tot het controleren van de zakenpartner,
bijvoorbeeld door uittreksels op te vragen bij de KvK of naar de klantenkring
van desbetreffende potentiële partner te kijken. Als tweede moet worden
opgemerkt dat het een organisatie niets in de weg staat om haar eigen iroot/i
certificaten te maken en aldus een icertificate chain/i op te zetten die
volledig in eigen beheer is. Op dit moment ontbreekt het aan regelgeving voor een duidelijke, definitieve, controle op de validiteit van een
certificaat door de eindgebruiker (organisatie of persoon). /p
pAls voorbeeld noem ik de ion-line banking/i diensten die op
dit moment via het internet worden aangeboden. Op 25 April j.l. heb ik een aantal (binnen- en buitenlandse) online
sites getest. De resultaten zijn a href="http://www.nedsecure.nl/people/lk/publicaties/certificaten_controle_tabel.htm"hier/a
te vinden. Zonder een oordeel te geven over de kwaliteit en betrouwbaarheid van
de dienstverlening op deze sites kan in ieder geval één conclusie worden
getrokken: het op een juiste, correcte wijze inzetten van cryptografie is
ogenschijnlijk veel moeilijker dan men denkt. Zo moeilijk, dat zelfs de meest
gerenommeerde organisaties geen uniforme aanpak hiervan kunnen laten zien. En
dat is vreemd, want het controleren van het beveiligingsniveau is alleen
mogelijk indien duidelijk is hoe en waarom voor een bepaalde aanpak is gekozen en hoe daar vervolgens uitvoering aan is gegeven (vraag dat maar eens na
bij uw lokale EDP-auditor). Willekeur lijkt hoogtij te vieren in dit segment van
de e-conomy en dat brengt de veiligheid en het vertrouwen niet dichterbij./p
h2bDe Doelstellingen/b/h2
pDe Nederlandse overheid heeft vrij precies omschreven wat zij onder een TTP
verstaat en waar een TTP aan moet voldoen. Door staatssecretaris de Vries van het Ministerie van Verkeer en Waterstaat
werd op 3 Juni 1999 in een notitie aan de tweede kamer het nationale TTP-project
voorgesteld. In dit a href="http://rechten.kub.nl/keybase/kamerstukken/26581_1.pdf"kamerstuk/a
wordt de rol van een TTP als volgt omschreven: "Een Trusted Third Party
(TTP) is een vertrouwde derde die diensten aanbiedt om elektronische
gegevensuitwisseling betrouwbaar te maken en is in die zin u een belangrijk middel
om elektronische handel tot bloei/u te laten komen". En "TTP's kunnen
door het leveren van specifieke diensten een centrale rol spelen bij de
ontwikkeling van een betrouwbare infrastructuur u voor electronic commerce/u".
Verder wordt een onderscheid gemaakt bij het stellen van randvoorwaardes tussen
verschillende TTP-diensten, namelijk iTTP-diensten voor authenticiteit en
integriteit (digitale handtekening)/i en iTTP-diensten voor
vertrouwelijkheid (versleuteling)/i./p
pIn de a href="http://www.minfin.nl/miljoenennota2001/pdf/06t_02.pdf"Memorie
van toelichting op de miljoenen nota 2001/a van het Ministerie van Justitie
wordt op pagina 9 de overheidsbemoeienis met betrekking tot TTP's als volgt
omschreven: "Met de ministeries van Economische Zaken en Verkeer en
Waterstaat en relevante marktpartijen i[LK, wie zijn dat dan??? Degenen met de
beste "lobby"?]/i werkt justitie mee aan een Nederlandse
infrastructuur van gecertificeerde TTP's. Deze infrastructuur die begin 2001
operationeel moet zijn, moet waarborgen dat het in TTP's gestelde vertrouwen
gerechtvaardigd is." /p
pWat echter blijkt is dat we, doordat er geen directe regulering is vanuit de
overheid, te maken krijgen met een iwildgroei/i van TTP's die er allemaal hun
eigen procedures en richtlijnen op na houden. Weliswaar wordt voldaan aan de
bepalingen die wettelijk zijn vastgelegd, maar voor de gebruiker van de
certificaten wordt het alleen maar moeilijker gemaakt. En dat druist i linea recta/i tegen ba href="http://www.nedsecure.nl/people/lk/index.htm#Filosofie"mijn/a/b
drie gouden vuistregels
in. /p
h2b(Niet) Gewenste Procedures/b/h2
pIn TTP land is het icommon practice/i om risico's daar te leggen waar ze
thuis horen. De iCertificate Practice Statements/i die door TTP's worden
gebruikt om de eindgebruiker duidelijkheid te verschaffen over de gehanteerde
normen en waarden waar het het uitdelen van certificaten betreft, zijn doorspekt
met juridische termen en beslaan gemiddeld meer dan 50 A4 pagina's. In elke CPS
die ik tot nu toe gelezen heb (die van a href="https://www.verisign.com/repository/CPS1.2/intro.html"Verisign/a,
a href="http://certificaat.kpn.com/repository/docs/CPS97.doc"KPN Telecom/a
en a href="http://www.globalsign.net/repository/conpol.cfm"Globalsign/a)
wordt aangehaald dat de gebruiker, door het accepteren van een certificaat,
verklaart dat hij/zij op de hoogte is van alle ins- en outs van public-key
cryptografie. Het grote aantal exoneratieclausules legt uiteindelijk het risico
volledig bij de certificaat accepterende partij. U. /p
pEchter, zonder deze procedures is het helemaal niet mogelijk om het werk van
een TTP te controleren. /p
h2bWat anderen zeggen/b/h2
pIn 1998 schreef mr. Pieter Kleve een artikel voor het tijdschrift
Computerrecht over a href="http://cwis.kub.nl/~frw/people/koops/pub/ttp-nut.htm"het
nut van TTP's/a. Op fijnzinnige wijze wordt daarin aangegeven dat het
dienstenportfolio van TTP's voor het overgrote deel van nul of generlei waarde
is./p
p Simone van der Hof schreef in 1998 een artikel in hetzelfde tijdschrift
over het CPS van BelSign met als titel "uZwartepieten met
certificatenaanbieders; De risicoverdeling in de Certification Practice
Statement van BelSign/u". Hierin valt het volgende te lezen "Tijdens de
aanvraagprocedure wordt de (URL van de) CPS genoemd in de gebruikersovereenkomst
en kan de aanvrager meteen doorklikken naar het document om het te raadplegen.
Een aspect dat in dezen van invloed kan zijn, uis het uitgebreide karakter van
de CPS/u. Zoals gezegd omvat de CPS meer dan alleen de rechten en plichten van
partijen en wordt hierin tevens uitgelegd hoe het certificeringsproces in zijn
werk gaat. Dat betekent dat de CA in dit document een enorme hoeveelheid
informatie verstrekt; de BelSign CPS omvat uitgeprint dan ook 80 pagina's die
door de wederpartij moeten (kunnen) worden bestudeerd alvorens tot het afsluiten
van een overeenkomst wordt overgegaan". /p
pRoger Clarke is nog veel kritischer dan ik en ventileert zijn mening via zijn
eigen website (gehost door de a href="http://www.anu.edu.au/people/Roger.Clarke/II/PKIMisFit.html#TIW"Australian
National University/a). Hij haalt heel terecht aan dat het onmogelijk is om te
detecteren dat een Privé certificaat is gestolen, gekraakt of op een andere
manier openbaar is geraakt als daar geen ruchtbaarheid aan is gegeven. Tevens
zijn er grote problemen met het op een zodanige manier vastleggen van een iCertificate
Revocation List/i dat deze ook werkelijk gebruikt kan worden. En de enorme
hoeveelheid specificaties die bij het x509 protocol horen maken de zaak ook
alleen maar complexer. /p
blockquote
piIn dit laatste opzicht herinner ik mezelf nog de legendarische woorden die
een oud baas van me ooit tegen me zei: "bKISS/b". Ik reageerde met
"Pardon?", waarop me werd verteld "bK/beep bI/bt bS/bimple
bS/btupid!". Mijn leven werd nooit meer hetzelfde./i /p
/blockquote
pBruce Schneier heeft al meerdere malen de mogelijkheden en onmogelijkheden
van PKI systemen aangehaald. Zijn "a href="http://www.counterpane.com/pki-risks-ft.txt"10
Risks of PKI/a" zijn een begrip (tenminste voor mij dan). /p
pAdrian McCullagh (National Director for Electronic Commerce) geeft in dit a href="http://firstmonday.org/issues/issue5_8/mccullagh/index.html#m7"artikel/a
duidelijk aan dat zonder een 100% betrouwbaar systeem i.h.g.v. een geschil de
partijen die wederzijds op een digitale handtekening vertrouwen juridisch zeer
zwak staan. /p
pCar Ellison geeft een kort overzicht over de mogelijkheden van a href="http://world.std.com/~cme/html/web.html"SPKI/SDSI
in relatie tot een web of trust/a. /p
pEd Gerck schreef een vrij compleet overzicht van de verschillende
certificatie systemen die er zijn in "a href="http://www.thebell.net/papers/certover.pdf"Overview
of Certification Systems: X.509, PKIX, CA, PGP and SKIP/a". Wie wil weten
wat er nog meer te koop is kan hiermee beginnen. De "normale
mensentaal"-vertaling die hij heeft gegeven van de idisclaimer/i die
gebruikt wordt door diverse TTP's is ook goed voor een minzame glimlach. /p
blockquote
piDe lijst is nog veel langer ................./i /p
/blockquote
h2bWat TTP's zelf zeggen/b /h2
pIn de a href="http://www.thawte.com/support/crypto/certs.html"FAQ/a van
Thawte (ia Verisign company/i) wordt letterlijk aangegeven dat zogenaamde
server certificaten (waarmee men verbindingen tussen uw computer en een web site
versleutelt) en persoonlijke certificaten (waarmee email kan worden versleuteld
en digitale handtekeningen kunnen worden gezet) exact hetzelfde formaat
gebruiken. De technieken die worden gebruikt om beide type certificaten te maken
zijn dus gelijk. De garantie (tegen gevolgen van misbruik en fraude) die men bij
beide certificaten verkrijgt kan echter verschillen. Hiermee kan dus het
prijsverschil worden verklaard dat voor de diverse type certificaten geldt. Het
is de verzekeringspremie die men betaalt. Alleen, hoe zat het ook alweer met de
risicoverschuiving in een CPS?/p
h2Tenslotte/h2
pIedereen die denkt dat ik niet geloof in e-commerce en PKI systemen kan ik
vertellen dat dit niet het geval is. Ik verafschuw de systemen niet, noch
wantrouw ik de toekomst ervan. Ik denk alleen dat de wijze waarop ze aan de man
worden gebracht wel eens mag veranderen. Iedereen die mij kent weet dat ik er
een duidelijke filosofie op na houd. Ik ben recht door zee en zeg waar het op
staat. Af en toe ben ik wel eens "grof in de bek" en mag ik wel eens
"onverwachts van rechts komen". Dit doet echter niets af aan de
feitelijke, inhoudelijke discussie die ik op gang breng. Ik heb een hekel aan
geld verbranden en voor zover het politiek betreft: graag, maar dan wel waar het
thuis hoort; in de politiek. /p
pIk ben ervan overtuigd dat we het beter kunnen doen, als we maar
willen. Twintig jaar ontwikkeling op dit gebied heeft ons alleen maar verder van ons
doel gebracht. Dit is niet alleen een gigantische verkwisting van tijd en geld,
maar (en voor al mijn iconcullega's/i uit het veld:) het houdt ook "de
business" tegen. De algemene acceptatie van cryptografische technieken is
nog ver weg en als we niet beginnen met uniformiteit bieden aan, dus
betrouwbaarheid wekken bij, onze klanten, dan lopen we over 5 jaar nog steeds te
ploeteren. We hebben een lange weg te gaan en als ik voorop kan lopen, dan zal
ik het niet laten. /p
pAls afsluiter een quote van Carl Ellison's homepage. De quote maakt 1 facet van het probleem
overduidelijk: "iHumans are incapable of securely storing high-quality
cryptographic keys, and they have unacceptable speed and accuracy when
performing cryptographic operations. (They are also large, expensive to
maintain, difficult to manage, and they pollute the environment. It is
astonishing that these devices continue to be manufactured and deployed. But
they are sufficiently pervasive that we must design our protocols around their
limitations.)/i"/p
pGegroet./p
p- Leon/p
/div
/body

/html