Zoek je een Nederlandstalige of Engelstalige cursus?

Wat zoeken op het Internet geeft me wel de Microsoft cursus "Designing and Managing a Public Key Infrastructure". Ook de beschrijving op http://www.vanveen.nl/workshops/141 past denk ik in jouw straatje. Hoewel het Engelstalige CISSP boek van Shon Harris veel overtollige informatie bevat, vind ik haar uitleg van PKI goed (en dat zeg ik als CISSP docent). Er wordt vanaf de grond af aan uitgelegd wat encryptie is, wat een symmetrisch en asymmetrisch algoritme is, wat een certificaat is, welke rol een CA en RA hierin spelen, hoe certificaten gebruikt kunnen worden in combinatie met hashing algoritmen en in protocollen zoals SSL etc.

Ik denk dat zoeken op Internet meer goede informatie krijgt dan dat je met een cursus kunt opnemen. Zoeken op "PKI introduction" of "PKI introductie" geeft al aardig wat informatie. Ik zou zeggen: begin te lezen en als je er niet uitkomt, post hier je vragen. Als ik even mijn eigen CISSP sheets voor de geest haal, dan is de volgende opsomming van punten denk ik een aardig PKI begin:

- Security bestaat uit drie pijlers, te weten beschikbaarheid, integriteit en vertrouwelijkheid van informatie (ook wel BIV codering genoemd).
- Vertrouwelijkheid geeft grofweg aan dat mensen alleen informatie mogen zien die ze uit hoofde van hun functie zouden mogen zien.
- Vertrouwelijkheid kan o.a. worden afgedwongen door middel van codering van informatie.
- Codering: het converteren van leesbare tekst in onleesbare tekst.
- Decodering: het converteren van onleesbare tekst in leesbare tekst.
- Codering en decodering vindt plaats met behulp van coderingsalgoritmen.
- Coderingsalgoritmen zijn onder te verdelen in twee groepen: symmetrische en asymmetrische algoritmen.
- Symmetrische algoritmen gebruiken 1 sleutel (het geheime deel in het conversieproces) voor codering en dezelfde sleutel voor decodering. Vergelijk het met een deur. Je gebruikt dezelfde sleutel voor het openen en op slot draaien. Veelgebruikte symmetrische algoritmen zijn AES, DES, Twofish, Blowfish, IDEA. Zie voor meer algoritmen de pagina http://en.wikipedia.org/wiki/Symmetric-key_algorithm.
- Asymmetrische algoritmen gebruiken twee aan elkaar gerelateerde sleutels: een sleutel voor coderen en de andere sleutel van decoderen.
- De tweee sleutels in asymmetrische algoritmen zijn elkaars inverse: wat de een doet, maakt de ander ongedaan en omgekeerd.
- Voorbeelden van asymmetrische algoritmen zijn RSA (een acroniem van haar uitvinders Ron Rivest, Adi Shamir en Leonard Adleman), Diffie-Hellman en ElGamal. Zie ook http://en.wikipedia.org/wiki/Public-key_cryptography.
- Voor asymmetrische algoritmen geldt het volgende: een van de twee sleutels is vrijelijk beschikbaar voor iedereen, terwijl de andere sleutel ALLEEN AAN JEZELF toebehoort. Die geef je dus NOOIT aan iemand anders. De vrijelijk beschikbare sleutel wordt de publieke sleutel (public key) genoemd. De sleutel die alleen aan jou toebehoort wordt de privesleutel (private key) genoemd.
- Als ik jou dus een bericht wil versturen dat is gecodeerd met RSA en dat alleen jij moet kunnen lezen, dan codeer is dat bericht met jouw public key. Jij bent immers de enige die dat bericht kan decoderen met jouw private key.
- De volgende opties werken in deze situatie niet:
* ik codeer het bericht met MIJN public key. Jij hebt echter mijn private key niet. Die behoort aan MIJ toe, NIET aan jou.
* ik codeer het bericht met JOUW private key. Dit kan niet, want ik heb jouw private key NIET. Die heb JIJ alleen.
* ik codeer het bericht met MIJN private key. Dit kan wel, want jij kunt vrijelijk mijn public key achterhalen en vervolgens mijn gecodeerde bericht decoderen, maar in dit geval kan iedereen met mijn public key de gecodeerde mail lezen en ik wilde juist dat alleen jij het bericht kon lezen.
- Om jouw identiteit te koppelen aan jouw publieke sleutel, zodat iedereen er zeker van is dat jouw public key daadwerkelijk aan jou toebehoort, wordt jouw identiteit en jouw public key (en nog wat andere informatie) vastgelegd in een certificaat.
- Dit certificaat wordt uitgegeven door een certificate authority, kortweg een CA genoemd. Misschien heb je wel eens van bedrijven als GlobalSign of Verisign gehoord. Dat zijn bedrijven die certificaten uitgeven. Als je naar een willekeurige website surft waarvan de URL begint met "HTTPS" en je vervolgens dubbelklikt op het slotje in je browser, dan kun je zien hoe het certificaat eruit ziet en welke velden er in zijn opgenomen. Je ziet daarin ook de publieke sleutel staan. Die is meestal 1024 of 2048 bits lang.
- Er zijn verschillende klassen certificaten. Hoe hoger de klasse, hoe meer ik er op kan vertrouwen dat de koppeling tussen jopuw identiteit en jouw publieke sleutel correct is. Zo dien je b.v. bij een klasse 3 certificaat meer informatie te overhandigen dan bij een klasse 2 certificaat. Soms moet je zelfs fysiek langskomen als vorm van authenticatie.
- Vaak geldt: hoe langer de sleutel, hoe groter de geboden veiligheid (mits het algoritme veilig is).
- Processen die gebruik maken van certificaten doen dit vaak automatisch, zonder tussenkomst van jouzelf. Zie bijvoorbeeld de handshake bij SSL (Secure Sockets Layer) op http://support.microsoft.com/kb/257591.


Ik kan nog wel even doorgaan over dit geweldig fascinerende onderwerp, maar laat ik het hier maar bij houden. Ik ben alweer veel te veel aan het typen merk ik. Mocht je vragen hebben in je zoektocht, plaats ze dan hier. Wie weet leren we er allemaal wat van.

Gisteren bij een aantal lezingen, presentaties geweest georganiseerd door Carental & Kennisburo in Apeldoorn.

Sten Kalenda gaf daar een lezing over het gebruik van SSL certificaten.
Deze lezing was bedoeld om zowel technische als niet technische mensen meer kennis te geven over het gebruik van certificaten.

Je kan hem bellen via zijn werkgever TrustAlert, die zitten in Soesterberg.

Ik weet niet of je een cursus zult kunnen vinden die theorie en praktijk combineert zoals je lijkt te vragen.

In elk geval in het verleden boden sommige universiteiten cursussen "PKI" aan, maar die gingen vaak nogal diep in op de wiskunde achter RSA en dergelijke, en niet zozeer op de praktische aspecten.

Wat Googlen leidde me naar deze pagina: http://www.twice.nl/microsoft-windows-server-2003/moc2821/designing-and-managing-a-public-key-infrastructure.aspx; die categorie "Microsoft Windows Server 2003" zou op een flinke Microsoft bias kunnen wijzen - maar wie weet zit je in een MS omgeving.

Zelf heb ik ondertussen redelijk wat docs en url's over PKI, certifcate en key management etc. verzameld, als je daarin geinteresseerd bent hoor ik het wel (je vroeg om een cursus).

Beste Bitwiper,

Hopelijk ben ik niet te laat met mijn reactie.
Ik ben heel erg geintereseerd in de documentatie van key management en evt bruikbare url's.

mvg,

John.

Je Kan beter eerst voor een opleiding als MCSE Security gaan.
CISSP kan iets te hoog gegrepen zijn ;)

Op internet zijn er ook wel genoeg filmpjes en info te vinden over Certificaten , CA's en PKI

Beetje zouteloze opmerking, als je geen 'oefenexamens' uit je kop leert heb je er heus nog wel wat werk aan. Bovendien is het ondertussen al uit de tijd, tegen woordig is het een MCITP (en voor zover mij bekend is er geen apart security traject).

Als je een eenvoudiger (dan CISSP) security opleiding zoekt zou je aan CompTIA Security+ kunnen denken, daar zit ook een heel deel basis certificaten bij.

Sorry dat ik niet eerder antwoordde, ben een beetje druk met andere zaken.

Het afstudeerverslag van Arnoud Engelfriet (Nederlandstalig) bevat veel leerzame informatie (met name bijlage A): een downloadlink vind je onderaan http://www.iusmentis.com/technologie/digitalehandtekeningen/scriptie/

Technischer maar niet minder interessant (en eveneens NL) is het afstudeerverslag van Hugo Leisink, in link vind je in de onderste bijdrage in http://www.security.nl/artikel/20898

Engelstalig, erg technish maar wel goed is http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html

Pas als je wat ingelezen bent wordt de "Special Publication 800-52" (Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations) van het USA NIST (National Institute of Science and Technology) begrijpelijk, te vinden op deze pagina (samen met meer interessante security docs): http://csrc.nist.gov/publications/PubsSPs.html

Als je meer gevoel wilt krijgen voor cryptografie en PKI, compleet met oefeningen, kijk dan eens hier: http://www.cryptool.org/

Een goed leesbaar (Engelstalig) document over code signing vind je hier: http://msdn.microsoft.com/en-us/windows/hardware/gg487309.aspx

Googlen naar apache private key best practice levert interessante docs op maar veel ervan zijn verouderd. Let er op dat de public key van een keypair dat je nu aanmaakt 2048 (of evt. 4096) bits lang moet zijn.

Een korte lijst met algemene "best practices": http://threatpost.com/en_us/blogs/forged-certificates-five-steps-secure-your-enterprise-032411

Een korte samenvatting van de werking van PKI geef ik bovenaan http://www.security.nl/artikel/38352/Uitleg_DigiNotar_problematiek.html

Als je een webserver met TLS hebt opgezet check hem dan op deze site: https://www.ssllabs.com/ssldb/index.html (zet het vinkje onder de URL als je nog niet zeker bent van je zaak ;)

Ten slotte kun je via http://en.wikipedia.org/wiki/Public_key_infrastructure natuurlijk ook veel informatie vinden.

Enkele aanvullingen, PDF's in het bijzonder over key management:

- http://www.trustedcomputinggroup.org/files/resource_files/D70AC70C-1D09-3519-AD472D02B35B9332/Key%20Management_20091228.pdf

- http://www.snia.org/sites/default/education/tutorials/2008/fall/security/WaltHubis-Best_Practices_Secure_Storage.pdf

- Diverse docs te vinden in http://csrc.nist.gov/groups/ST/toolkit/key_management.html

Beste Bitwiper,

Heel erg bedankt voor de informatie.
Ik denk dat ik de komende tijd voldoende leerstof heb. De url's staan nu op mijn favorieten.

Beste Office_boy,

ik heb het afgelopen half jaar onderzoek gedaan naar SSL/TLS in combinatie met PKI. In het onderzoeksrapport kun je veel informatie vinden over het geheel en het wordt in een duidelijke manier uitgelegd. Daarnaast bevat het document een tal van bronnen die je kan raadplegen om dieper in de stof te duiken. Mocht je dit document willen dan hoor ik het wel.

Nimrodx

Beste Nimrod,

Ik ben erg onder de indruk van de kwalitatieve reactie van dit forum.
Alhoewel ik al voldoende leerstof heb gekregen van Bitwiper, zijn je bidragen meer dan welkom.

Gewoon ff zoeken op het Internet. PKI is geen hogere raketkunde dus met een beetje lezen kom je een heel eind.
Ik zou hier beginnen met lezen: http://technet.microsoft.com/nl-nl/library/cc757327(WS.10).aspx

office_boy en Giraffe59

en alle andere geïnteresseerden.

http://dl.dropbox.com/u/12795538/Onderzoeksrapport_V1.0.docx of
http://dl.dropbox.com/u/12795538/Onderzoeksrapport_V1.0.pdf

Ik haal hem over 1 of 2 dagen weer van dropbox af.

Groeten Nimrod

Op acbox.nl kan je zelf wat klooien. Wel leerzaam

Nimrod,

Ik heb je document net gelezen. Uit nieuwsgierigheid: wat voor cijfer heb je voor je onderzoeksrapport gekregen?

Overcome een 7,5 volgens mij.

Ik weet dat het document niet optimaal is. Er hoorde overigens ook een workshop van een halve dag bij. Maar die ga ik niet nog eens geven.

Even uit nieuwsgierigheid: Wat voor cijfer zou jij het onderzoeksrapport geven?

@Nimrod: jullie onderzoeksrapport ziet er netjes uit en veel zaken worden goed en uitgebreid uitgelegd, ook veel plaatjes, mijn complimenten!

Toch wil ik op een aantal zaken wijzen die ik erg belangrijk vind:

- Het is zinloos om een verbinding te versleutelen als je niet zeker weet met wie je communiceert.

- SSL of TLS werkt prima zonder PKI. PKI helpt je om vast te stellen met wie je communcieert, maar dat kan ook op een andere manier (bijv. door self signed certificaten te gebruiken en die via een veilige route in de webbrowser(s) te kopiëren of door de SHA1 fingerprint van het certificaat via een andere route door te krijgen en deze te checken).

- Het primaire doel van een gebruiker is dat zij/hij daadwerkelijk communiceert met de bedoelde instantie. De garantie die de combinatie van PKI met SSL/TLS tracht te geven, is:

A) dat er ofwel een versleutelde verbinding tot stand komt met "hostname" uit de door de gebruiker ingevoerde https://hostname/pad in de URL balk van de webbrowser (ongeacht het IP adres van de server en/of DNS aanvallen), ofwel de gebruiker gewaarschuwd wordt. Overigens hoeft de gebruiker niet zelf de hostname in de URL balk met de hostname in het certificaat te vergelijken, dat doet de webbrowser na ontvangst van het certificaat.

B) De gebruiker desgewenst het certificaat kan inspecteren om te zien of de hostname daadwerkelijk van de bedoelde instantie is.

E.e.a. is goed te zien in het plaatje op pagina 23, maar komt in de tekst niet echt uit de verf.

- In de literatuurlijst mag eigenlijk de klassieker (uit 2000, maar nog steeds van toepassing zijnde) "Ten Risks of PKI" (http://www.schneier.com/paper-pki.html) van C. Ellison and B. Schneier niet ontbreken.

- Rainbow tables bestaan om met MD5 gehaste wachtwoorden te ontmaskeren (om precies te zijn, een willekeurige equivalent van zo'n wachtwoord te bepalen die toevallig dezelfde MD5 hash oplevert, en waar je dus mee kunt inloggen). Rainbow tables zijn er niet de oorzaak van dat je geen MD5 meer moet gebruiken (je kunt voor elk hash type rainbow tables maken).
De reden om voor cryptografisch veilige hashes geen MD5 meer te gebruiken is dat het mogelijk is (met veel, doch in de praktijk haalbare, rekenkracht) om delen van een bestaande tekst zo te wijzigen dat deze dezelfde MD5 hash oplevert als de oorspronkelijke tekst (een zogenaamde collission). De verwachting is dat SHA1 binnen een paar jaar ook kan worden gekraakt.

- Het risico van diefstal van een private key van een CA is erg klein, omdat deze in een tamperproof HSM (zie http://en.wikipedia.org/wiki/Hardware_security_module) hoort te zitten. Voor zover bekend heeft de "ComodoHacker" geen CA private keys van Diginotar kunnen kopieren, wel heeft hij de apparatuur en software bij Diginotar opdracht kunnen geven om certificaten naar keuze te laten ondertekenen.

- Daarentegen is het risico van diefstal van een private key vanaf een webserver vaak groot, omdat deze in de meeste gevallen in een bestandje op de schijf staat. Soms is dit versleuteld, maar omdat de webserver software toegang tot de oversleutelde private key nodig heeft, stelt die versleuteling in de praktijk niet veel voor.

- Het thema revocation (voortijdig intrekken van certificaten) en het feit dat dit niet goed werkt komen geheel niet aan bod.

Nogmaals, ik vind jullie rapport helemaal niet slecht! Ik noem bovenstaande zaken dan ook alleen als aanvulling voor lezers als de TS om een completer beeld te geven.

Bedankt voor je feedback Bitwiper.

Ik weet dat de rapportering skills wat beter kunnen ;-)

Nimrod,

Ik had een 8 gegeven, zeker gezien de effort die jullie er in hebben gestoken met leeswerk, interviews en de breedte van het rapport (algoritmiek, wiskunde, protocolanalyse, het komt allemaal langs). Naast datgene wat Bitwiper hierboven aangaf, zijn er kleine dingen waarvan ik denk: dat had wellicht beter anders geformuleerd kunnen worden. Om een paar voorbeelden te geven:


- Pagina 1: "Tevens is het mogelijk dat encryptiealgoritmes als RSA worden gekraakt. Als dit gebeurd dan is SSL in één klap niet meer bruikbaar." Waarom? Waarom selecteren we niet gewoon een ander public key algoritme als vervanger voor RSA?

- Pagina 5: "Voor het onderzoek is het niet van belang om aan te tonen hoe de zwakke punten van SSL gebruikt kunnen worden voor doeleinden zoals spoofing." Spoofing is 9 van de 10 keer een middel, geen doel (tenzij je in de academische wereld werkt en wilt bewijzen dat SSL onderhevig is aan spoofing bedreigingen). Het doel is bijvoorbeeld het kunnen lezen van gecodeerd verkeer. De out-of-scope plaatsing vind ik daarom jammer, te meer doordat spoofing juist een van meest in het oog springende technische problemen is bij SSL.

- Pagina 5: "Hierbij was het plan dat de data over lijn zouden geanalyseerd zou worden, om zodoende het SSL/TLS protocol beter te begrijpen. Dit bleek echter niet nuttig aangezien er veel data encrypted over de lijn ging en zodoende niet nuttig was voor ons onderzoek." Brengen tools zoals Burp Suite geen uitkomst voor jullie om HTTPS verkeer toch te kunnen lezen en analyseren?

- Pagina 17: "RC4 is in 1987 door Ron Rivest ontwikkeld voor RSA, een asymmetrisch encryptie algoritme." Ik neem aan dat je hier het bedrijf bedoelt (http://en.wikipedia.org/wiki/RSA_(security_firm)), niet het algoritme.


Afgezien van dit soort dingen vind ik het rapport er goed uitzien. Zoals gezegd: veel plaatjes, en dat verduidelijkt de lastige theorie aanzienlijk.

Ik heb echter nog wat kleine dingen te zeiken, zoals een Hollander betaamt.

(1) Het hashing verhaal op pagina 19. MD5 wordt hier teveel gekoppeld aan rainbow tables en (waarschijnlijk) wachtwoorden, terwijl het echte gevaar juist ligt in d emogelijkheid tot het genereren van collisions. Zie http://www.win.tue.nl/hashclash/Nostradamus/ voor voorbeelden van PDF bestanden die allemaal tot dezelfde MD5 digest hashen, maar een andere inhoud hebben. MD5 is daarom ook zo dood als wat en zou niet meer gebruikt mogen worden. In die context maakt het gebruik van een salt ook niet uit, doordat het onderliggende algoritme niet deugt. MD5 is "gekraakt", geen discussie mogelijk.

(2) Conclusies dienen onderbouwd te worden met tekst die in eerdere paragrafen naar voren is gekomen. In hoofdstuk 3 ("Uitkomsten") geef je aan "De technologie van encryptie wordt steeds geavanceerder en steeds moeilijker om te kraken." Nergens in de tekst zie ik een onderbouwing van die uitspraak (afgezien van de paragraaf erna). Dit geldt ook voor het tweede punt in de "Zwaktes" paragraaf. De regel in paragraaf 4.1, "Vooral het feit dat de software eigenlijk niet tot nauwelijks wordt geüpdate naar de nieuwste versie was, hoewel te verwachten, toch vrij opmerkelijk.", zie ik nergens in het onderzoeksrapport onderbouwd. Het is wellicht waar (gezien mijn ervaringen bij meerdere bedrijven is het waar), maar waar zijn de cijfers en onderzoeken die deze uitspraak onderbouwen?

(3) Het feit dat bedrijven geen (SSL) updates installeren, wil niet zeggen dat het SSL protocol zwak is. Dat is gelijk aan het zeggen dat een Audi een slechte auto is, doordat mensen de nieuwe versie niet snel genoeg aanschaffen. Het betreft hier een zwakte bij bedrijven, te weten een slecht ingericht of slecht nageleefd patch of Lifecycle Management (LCM) beleid. Dat iets zwak is dient afgemeten te worden aan de eigenschappen van het object zelf, zoals het aantal uitgebrachte patches, veel aanpassingen op de RfC's, ondersteuning van algoritmen die minder veilig zijn dan gedacht (zoals MD5), teveel problemen met backward compatibility waardoor encryptie en hashing protocollen kunnen worden gebruikt die een lagere veiligheid geven (denk aan MD5, selectie van te korte sleutellengten, downgrade attacks (TLS 1.2 v-> SSLv3 v-> SSLv2)) etc.

(4) De eerste paar regels in paragraaf 4.2 verwonderen me een klein beetje: "Voor dit onderzoek is er vooral gekeken naar de sterktes en zwaktes die bekend zijn binnen SSL/TLS. Hierbij speelde theorie een belangrijke rol. De in de paragrafen genoemde punten zijn voor dit onderzoek dus niet getest. Een belangrijk punt voor vervolgonderzoek zou dan ook zijn om in de praktijk de zwaktes te gaan onderzoeken. Ook van belang is natuurlijk of de sterke punten wel echt zo sterk zijn als ze lijken." Oftewel, de punten die jullie als sterk en zwak definieren hoeven dat helemaal niet te zijn???? Dit zou ik veel stelliger hebben gedefinieerd: DIT zijn de sterktes, DIT de zwaktes, geen discussie mogelijk.


Samengevat: een duidelijk onderszoeksrapport. Mijn complimenten!